| | Mr. Mouse
Registered: Dec 2001
Posts: 235 |
Warp compression method (AR)
Does anyone know the compression scheme used in Action Replay's "warp" disksaving method? I notice the sectors look a little different, where's the information about which next sector to go to while decompressing?
|
|
... 30 posts hidden. Click here to view all posts....
|
| | Mr. Mouse
Registered: Dec 2001
Posts: 235 |
Nice find, Count! |
| | Krill
Registered: Apr 2002
Posts: 2980 |
Quote: This GCR replacement is actually great for demos, with one small change: next track/sector is better put back in place, since its very useful to change interleave in a demo, according to free rastertime while loading.
A demo using this will have one disadvantage though - it wont be possible to spread it using D64.
I don't think so.
The custom encoding will speed things up a little, and i mean just a little. Keep in mind you want to do IRQ loading, and that slows down actual transfer quite a bit compared to switching off the screen and all interrupt sources and having 100% CPU for the loader.
Not to mention that demos which need maximum loading speed at all costs to keep up the flow are doubtfully crafted IMO.
The 1571 is capable of decoding a complete standard format block while reading it, just like the 1541 is with this encoding (minus a few bytes of format overhead), and really, it's not that much faster than a 1541 (like 4 kB/s instead of 3.5 kB/s with my loader).
And interleave is something no sane IRQ loader would need to worry about. Also there are scenarios when you have quite some varying CPU time free for the loader, which makes any fixed interleave a bad idea. Yes, i'm advocating out-of-order loading again. The extra revolution it takes to find the block order on a given track can be removed by using a special _high level_ format which would encode the block and file indices needed in the cooked data of every block, which is like 2 bytes lost for a plain 256-byte block. (And with warp encoding, you neither need these meta data nor sector linkage information, since the sector order is fixed, so you can do out-of-order loading easily without interleave worries and a scanning pass. This would work for plainly encoded files, too, and yield acceptable limitations, like e.g. only one file per track.)
And finally, a demo which cannot be spread on d64 is bad. Even when it comes with special tools for transfer, it's a pain in the arse to handle. |
| | WVL
Registered: Mar 2002
Posts: 902 |
I'm still wondering why there's no format that spreads the content of a page over all the sectors in a track. Basically that would allow the loader to always immediately start reading bytes and never have to wait for the correct sector to pass under the head.
The data content of a sector would look something like this:
(let's describe it compared to a normal disk and call what's a sector on the original disk an osector).
so on sector 1 of the new format :
byte 0 of osector 1, byte 0 of osector 2, byte 0 of oscector 3, etc, byte 1 of osector 1, byte 1 of osector 2, etc, etc, until the sector is filled.
sector 2 :
byte 20 of osector 1, byte 20 of osector 2, byte 20 of oscector 3, etc, byte 21 of osector 1, byte 21 of osector 2, etc, etc, until the sector is filled.
This does mean that more bytes are wasted though, but max bytes wasted is the number of sectors for that track.
The problem is ofcourse that the out-of-orderness is even more mayhem, because bytes that belong to a page are distributed over the whole track.
|
| | Krill
Registered: Apr 2002
Posts: 2980 |
I'm not sure if i understood you correctly, but this looks like it would be super-slow and/or super-complicated.
You can never read right away because you first need to know which sector you're dealing with, i.e., wait for and read the sector header, which means the time needed to read half a block is wasted, on average (without considering correlations arising from reading previous blocks on the same track).
And i don't see the advantages, since the loader does not have to wait for the one and only next block in the chain using out-of-order loading anyways. :) |
| Previous - 1 | 2 | 3 | 4 - Next | |
