| |
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?
|
|
... 24 posts hidden. Click here to view all posts....
|
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Super Snapshot v5 has identical tables, and they are at exactly same memory locations as Vorpal. Vorpal was written by Scott Nelson and Stephen Landrum, SSv5 manual credits Richard Bond for Turbo*25. I wonder who ripped who...
I need to get my hands on SSv3 & SSv4 images to check them too. |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Vorpal was released in 1986, SSv4 is from 1987/1988 according to manual. I don't know if SSv3 had turbo*25 already. |
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
Absolutely definately I'd bet on Vorpal. Warp25 became available with the Action Replay 3 according to adverts. Interesting part here: early adverts by Datel from April (AR3 release) to June 1987 do not mention Warp25 while any later advert often has an extra bright box for the feature.
Going to put more online sometime soon.
/cz |
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
Snapshot64 released November 1985
Super Snapshot 2 released January 1987 (two versions that year)
Super Snapshot 3 released February 1988
Super Snapshot 4 released November 1988
Super Snapshot 3 released December 1989
And now get me ROM dumps of SSv2 and SSv3!
(And while we are at that - Freeze Frame above MK1, FC2, Formel 64 and Game Killer I am missing out as well - anyone? :) )
@TNT: Take a look at Heureka Sprint while you are at it - would be interesting to know wether it uses the same tables as well. :)
/cz |
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
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. |
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
Just came across this - adding to this "warp info dump thread" - as I see it - for later reference :)
http://www.faime.demon.co.uk/retro/loader.html
/cz |
| |
Mr. Mouse
Registered: Dec 2001
Posts: 235 |
Nice find, Count! |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
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: 886 |
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: 2839 |
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 |
