| |
lft
Registered: Jul 2007
Posts: 369 |
GCR decoding on the fly
Here's how to do it:
http://linusakesson.net/programming/gcr-decoding/index.php |
|
... 149 posts hidden. Click here to view all posts....
|
| |
Axis/Oxyron
Account closed
Registered: Apr 2007
Posts: 91 |
I think every little speedup on loading would help everyone producing c64 trackmos. We all struggle alot and invest months of our life to optimize loading-/decrunchtimes of our parts to get the pace a little bit up and to have time left to do some nice transition work.
Perhaps it would be easier to get the gain on optimising decrunchers rather than loaders. I think there is also a big potential on that.
But perfect solution would be to optimize both to the max.
Because we are still so far away from what the amiga guys were doing back in the 90s due to slow loading and decrunching.
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
One brilliant piece of code in here, but i don't see that you gain very much in the total solution. Then i have to admit that i didn't even find any transfer-code in there yet :P, which is a quite essential part of the drive coding (and the major bottle neck of course).
LFT always has a fresh approach to c64 problems, and always seem to come up with something new!! A genius by definition :). Using extensive tables for gcr-decoding was used in my own loader(s) (in Cycle, EoD etc..) but not this beautifully of course.
One funny detail is that last fall i was also working on my disk-loader. I also came down to 100% on the fly decoding, but was not satisfied because it uses SAX, which doesn't work on all my (2) drives. So i reworked it and the result can be found in TimeMachine. Don't use that loader as any reference though, it seems to still have problems on 128DCR which are not solved yet. |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
why checksumming btw? if the data is fucked, running the demo is fucked either way, you know it explicitly or not.
approx how much time is a track revolution?
|
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
@Oswald:
My thoughts exactly, which is why I didnt bother with checksumming in my loader.
I mean, its a trackmo, even if there is a loading error, there's usually no time to reload, so why bother? :)
@HCL:
Will you ever fix EoD so I can finally watch it on my 128D (the only machine I've been using for years) ?
Its a loader problem, which I'm too lazy to debug :) |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
A revolution at 300 rpm takes 1/5 seconds.
Axis: Need for maximum speed noted. Give me a figure to work with for your next future release, and we can work on optimizing things towards that goal.
At some point you simply go into uneasy-trade-off territory and have to drop one or the other feature for the sake of that extra bit of performance.
As for packers, there are some choices to make, too. When going for maximum speed, the simpler/speed-optimized algorithms (e.g. ByteBoozer, but i also think Doynax and WVL made big progress when it comes to speed) are most often a better choice for best combined loading+decompression speed, compared to squeezing out every last bit at the cost of decompression speed (PuCrunch, Exomizer). Adding another decompressor to the loader is easy, but i can do that quickly following a specific request.
HCL: So you made it as well? Have to check that code. :)
Oswald: Good question. Disk errors are rare with good disks and under lab conditions, but there are spurious/transitional errors with not so good disks and again, under party conditions. Simply dropping the checksumming is an option, but IMHO not a good idea, as the drives and disks do age as well.
raven: And a demo that cannot tolerate slower loading (except for obvious sync problems) is not a good idea either. Drive coding is not like coding raster bars. Eventually you will find a drive/disk/track-skew combo that's slower than anything you tested, with the hardware still in good condition. And since you will end up with some slack anyways to have more of an error margin, why not use that slack with faster drives for retries? :) |
| |
HCL
Registered: Feb 2003
Posts: 728 |
@Krill: Well.. No i didn't, as i didn't keep the code i was unsatisfied with. I could of course do it again, but it would be a 1541-only loader for drives that can coop with SAX. The loader from the Cycle-era uses lots of tables and is faster. I took that code and used your trick of only synchronizing 2 bytes of 5, and got it down to zero overhead in the read-loop. But what i wanted in TimeMachine (and always) was a loader using less tables, so i have space for dir-table in the drive. So, first i removed SAX to make it work on my other drive, and then i made it use only one $20-table for gcr-decoding..
@Raven: Oh, i didn't know that was an open issue ;). Well, in fact this loader from TimeMachine may be able to replace the EoD-loader. Before now i didn't have any loader that could do all that the EoD-loader can. So.. perhaps some day :). |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quoting raven@Oswald:
My thoughts exactly, which is why I didnt bother with checksumming in my loader.
I mean, its a trackmo, even if there is a loading error, there's usually no time to reload, so why bother? :)
A load error message is better than continuing with broken stuff. Also demos is not the only use of a loader.
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
Hmm.. sorry i have to correct myself. I do not gcr-decode on the fly while reading data in my loader, i just manage to split the data into 8 chunks. Then the data in those 8 chunks are used to index into those different gcr-decoding tables on the fly when transmitting the data. I think this is more or less like Krill does and many other loaders i have peeked into during the years :). The only improvement i did was that i didn't need to waste any time between the reading and the transmitting, which on the other hand is exactly what LFT did as well :) |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
lft did it with less memory needed :P :) |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Quote:lft did it with less memory needed :P :)
Uhm.. not sure about that. He is using 2 pages of tables, the whole stack area plus half the zeropage. I managed to squeeze in all my tables into one page, but wasting another page for half-converted data.
..plus the major draw back: He should of course have generated those tables in the drive code!! Now he is wasting 2 precious blocks of disk space for stopid but beautiful tables, that could have been generated in less than half a block probably!! I mean, we *are* discussing beauty of code here, aren't we ;) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 16 - Next |
