| |
stiggity
Account closed
Registered: Jul 2013
Posts: 5 |
c64 garbage collection, NEED HELP!!!
I came across a real nice "aftermarket" c64 garbage collection routine. I spent 2 hours on the source, and got it able to
compile in my assembler (64tass). but, all comments are in
German. Im writing a BBS program for the 64, and it runs and
works, but it will pause for 10/12/15 seconds here and there. And anyone not knowing its collecting garbage, may
drop carrier. I would like to intermingle this code, into my own project, but believe its a little above my skills level. If anyone is into c64 telecom, and thinks they could help me out, be my guest. I can describe, and explain how my memory is laid-out, with the BBS. So if you think your good, and believe this code _can_ be intermingled, I can fully credit you in docs, manual, website, and email support. Thanks. Id rather go back and forth via E-mail, rather than posting the source here. I'm safe! :)
-Thanks,
--Steve
stiggity99(@)Comcast.net |
|
| |
Urban Space Cowboy
Registered: Nov 2004
Posts: 45 |
1. Don't sign your posts.
2. What garbage collection routine from where? Like give a link or something.
3. The best way to deal with garbage collection is to not make garbage strings in the first place -- cut down on those A$=A$+(whatever) type assignments! If you absolutely can't live without them, try putting in an X=FRE(1) now and then to force a garbage collect and smooth out the bumps somewhat.
4. Any more specific advice can't be done without analyzing what your code's doing now. BBS software is a mostly-solved problem and you aren't doing yourself any favors by being stingy with your code. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"try putting in an X=FRE(1) now and then to force a garbage collect and smooth out the bumps somewhat."
yep. the typical solution for BBS is to do that at the prompt. |
| |
stiggity
Account closed
Registered: Jul 2013
Posts: 5 |
cowboy: chill, playah..
im not trying to be stingy with my source.
Obviously, you have never written a BBS prg for the
c64.
goepaz: Im trying my best...
-Steve |
| |
stiggity
Account closed
Registered: Jul 2013
Posts: 5 |
Plus, I have already set my end of basic pointers to $9000, where MORE of my BBS machine code lies..
So there's only SO MANY bytes of memory!!
and to have a nice bbs prg (Similar to Image BBS), it has to be highly modular. BASIC and ML.. with the speed of today's hard drives for the 64 or (128( which I wrote a BBS package for also)) loading modules here or there, really doesn't distract the user from the board. BUT!! waiting 15 seconds to collect garbage while reading bulletins is frustrating.. So, in short.. I haven't the slightest clue, on how this collection routine is b0rking me....im pretty sure its copying the basic ROM, and putting it in RAM. Which 100% goes against my BBS structure grain..i store code from $A000 - $BFFF If ANYONE want's too see this source, btw.. CHRISTIAN LOTT, contacted me, obtained the source, and quickly translated all the German comments to english, re-formatted it, and did a 100% bang-up job on it.
(Those are the types of ML coders I appreciate.)
email me: stiggity99(at)COMCAST.net
--Steve |
| |
The Phantom
Registered: Jan 2004
Posts: 360 |
Sounds like the buffer is on. How to fix it, I've no clue ;)
Had a similar issue with Evil Term
Sorry can't really help further.. We never fixed the issue. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
well if you want people to help, then you should post the code (or link to it)
however, it will need to copy the rom to ram because there is no other way to hook into it (there is no vector for the garbage collection). the only way to get around that would be to manually call the garbage collection every now and then (as said, at each prompt and/or after each message should do the trick - however, once you do that you can probably get away also by simply using fre(0) the same way) |
| |
TheRyk
Registered: Mar 2009
Posts: 2246 |
even
X=FRE(1)
will not solve the problem of an exponentially slowing down GC, the only difference is that you decide when GC takes place.
Quote:The best way to deal with garbage collection is to not make garbage strings in the first place
After a terrible experience when fixing a BASIC game
Murder V1.2 <- GC gets slower and slower while the game stays as crappy as it just is...
I'd even go further and say "Don't use strings at all", sounds weird but there are many other ways. |
| |
stiggity
Account closed
Registered: Jul 2013
Posts: 5 |
How do I 'properly' post my source??
-Stig |
| |
TheRyk
Registered: Mar 2009
Posts: 2246 |
Quote: How do I 'properly' post my source??
-Stig
use tags square bracket "[" 4 chars "code" square bracket "]" then of course your code and finally "[/" 4 chars "code" square bracket "]" |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
and if its more than a couple of lines, upload it somewhere and link to it. or use something like pastebin.com |
| |
AgentFriday
Account closed
Registered: May 2012
Posts: 4 |
TheRyk is right on the money. If you call the garbage collect routine twice in a row, it will take JUST as long the second time even though there's no work to do. So any thought of spreading out the pain by calling GC more often will only make things worse.
With the stock routine, your only hope is if you can call GC at a time when you know you can afford the penalty. If you can't go an entire session without doing a GC, your users will have to feel the pain.
:: THE GOOD NEWS ::
Pinacolada (Dragon's Eye BBS) knew about an improved garbage collection routine used by ImageBBS. A quick test in vice (DIM z$(9000):c$="A"+"":for i=1 to 9000: z$(i)=c$: next) shows that garbage-collecting 9000 1-length strings takes 106 minutes (!!!) with the ROM routine, but only 15.5 minutes with the replacement. (Thank you Warp Mode!)
Quick look at the algorithm shows it's collecting in batches of 128 strings at a time by doing an insertion sort in a separate table. Not sure if this reduces from O(n^2) to O(n log n), but it's something like that. Requires about 1.5 K of RAM (including space for the tables).
I did one more test to try to simulate your delays... With string array of size 500, but only 400 strings on the heap, ROM GC takes 16 seconds, ImageBBS code: 2 seconds.
I think this may be a good solution. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
interesting problem, are there any good read materials about this, links, anyone?
thanks. |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
And I thought Tao modded C*Base is the best there is anyhow nowadays? :) |
| |
AgentFriday
Account closed
Registered: May 2012
Posts: 4 |
Oswald: Specifically, are you interested in the topic of GC in general, how the stock GC works, or how string storage in general works? Or something else? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
AgentFriday, first two, mostly the stock tho. but knowing what it does in general would also help understand why it is so slow. I was never really aware of this "string problem" in c64 basic so far. |
| |
TheRyk
Registered: Mar 2009
Posts: 2246 |
In a German forum we did a fun coding contest recently, hosted by S.E.S/crest. winner was who manages to let the GC be occupied as long as possible.
Maybe you like to have a look at the results, maybe for fun, but maybe it even helps to understand. Though it's all in German, the first posting contains the .D64 Image with all the entries.
http://www.forum64.de/wbb3/board25-coder-unter-sich/board308-pr.. |
| |
AgentFriday
Account closed
Registered: May 2012
Posts: 4 |
I think there are probably a couple books that document how garbage collection works on the C64 at a somewhat high level, but I couldn't name any right now.
I'm having some fun with this one, so I'm thinking of doing a blog post on the subject, as well as updating my ROM annotations to cover the GC routine. If/when I do, I'll post a notification to this thread.
I'm looking into turning the Image BBS GC routine into a seamless fix that anybody could use (i.e., wedge it in, forget about it). It kinda sucks to have to build in periodic checks to see if the heap is getting nearly full. |
| |
Rough
Account closed
Registered: Feb 2002
Posts: 1829 |
Quoting TheRyk
http://www.forum64.de/wbb3/board25-coder-unter-sich/board308-pr..
I'm not sure if this is really cool or complete dorky, but I'd rather pick the first option. |
| |
TheRyk
Registered: Mar 2009
Posts: 2246 |
not at all kewl, was some kind of nonsense compo, MEANT to be dorky to "honor" some guy who back then terrorized that forum with REALLY dorky and mostly useless GC "solutions" in BASIC and ASM :) |
| |
Rough
Account closed
Registered: Feb 2002
Posts: 1829 |
Talking about dorky:
The program which made me know the garbage collection is
Quote: Stamping Collection Kit: Erfassen und Katalogisieren von Briefmarkensammlungen. Druckausgabe von Bestands- und Fehllisten. Steuerung per Puli-down-Menus (64'er-Sonderheft 15).
It was pretty well done for its time and being Basic. |
| |
Tao
Registered: Aug 2002
Posts: 115 |
Quote: And I thought Tao modded C*Base is the best there is anyhow nowadays? :)
It is :P But I don't use a custom GC routine. I expect most BBS programs do the same thing as C*Base -- call the standard garbage collector from the wait screen. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
i actually remember driving to moses for hacking a fast garbage collection into c*base so it wouldnt be vulnerable to the good old wait-at-prompt-for-minutes problem :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Found this floating around: http://www.atarimagazines.com/compute/issue49/422_1_Garbage_Col.. |
| |
soci
Registered: Sep 2003
Posts: 480 |
As the article says this is a solved problem in later basic versions.
The solution was to put a "back" pointer right after the allocated string which points to the string length and pointer of the original variable/array element.
Deleted strings reuse this pointer for noting down the size of the deleted string by using a special pointer of $ffxx.
With this it's trivial to garbage collect in O(n) time.
Just start from the end of string area. Either there's a normal back pointer, this can be used to find out how big the string is and where to adjust it's pointer after the move.
Or it could be a special pointer ($ffxx) then it's a hole, skip it over, the length is the xx part.
Then continue compaction until the beginning of string area is reached.
This costs 2 extra bytes per string of course. And the amount of extra code which fixes/replaces the original string handling... |
