| |
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 |
|
... 14 posts hidden. Click here to view all posts....
|
| |
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. |
| Previous - 1 | 2 | 3 - Next |
