| |
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....
|
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
You should use a disassembler and check the code reading and writing the warp files.
http://ftp.pokefinder.org/BANK_2.txt
Line 3035++
Enjoy.
/cz |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: http://c64.xentax.com/downloads/warptest_g64.zip
Okay, used g64. What tools do you use to view those, other than hex editors?
I used a rather crude analyzer I made a couple of years ago: g64scan-0.4.tar.gz
Run it with -t <track> to get detailed output, if not you'll get a full disk error scan.
Other than that I agree with cz that you should analyze the code.
I would go for the loader part I think. Run it in vice, Halt during loading and pop into the monitor. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quote: This might be actually quite interesting... Loading time for a warp file
was unbelievable in those days... Maybe usable in demos or so...
Possibly not so interesting. Somebody on Forum64.de has come up with a way to read a standard formatted track in two revolutions, which is warp speed. Actually i'll add this to my loader some day, but it's not that useable for demos. May be nice for booting games into ram extensions and flash cartridges, though :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Btw., this is not the first time i have the suspicion that there are some differences between Action Replay versions concerning warp. Which version are we talking about? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
So it seems like you CAN have several warp files on a track, but still with implied sector linkage - the next sector in the chain is always implicitly known, no matter on which sector the file starts.
The rest seems fairly easy: Some custom encoding which can be decoded and checksummed while reading the raw data, at the expense of more format loss, which means you can store less useable data on a warp track compared to a normal one. I don't think any warp-saved file gets smaller compared to its KERNAL-formatted counterpart. |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
AFAIK there is just Warp25 at all. There should be no differences on saving the same file with Warp25 on several versions. It may be that the drivecode was slightly changed between 4.x and 5.x Action Replays but I am not fully aware of that. The Bank2-link above is 4.x code resourced by Crisp and MWS.
/cz |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
I have somewhere a comparison of several *25 loaders (Warp*25, VorpaLoad, Heureka and at least one more I can't remember just now - Super Snapsot?) and not so surprisingly most of them seem to be copies of each other. Decoding routines may have index registers swapped or RAW -> decoded tables altered, but they all use eight raw bits as an index to six decoded bits (extra bits set/reset depending on the index value to keep hardware happy). That makes decoding much faster than GCR, but limits bytes per sector to 240. |
| |
Mr. Mouse
Registered: Dec 2001
Posts: 235 |
If I use vice to plug in an AR cart and warp save a test file on a d64 image, and transfer it to a c64 it works and loads, so the info on the d64 file is accurate enough to work with. Call me stupid, and I probably am, but using g64 then should not make a difference. [EDIT] I am stupid, it doesn't work with D64, never mind. :)
I've read in the original manual of the AR that warp*25 files will always be 6% larger than the original, because only 240 bytes of the 255 in the sectors contain file-data, so more sectors are needed. That rules out compression, but introduces some kind of encoding.
In the d64 image you can see that a warped file of only 8 bytes long originally has data that is about 9 or 10 bytes long. But this data is encoded somehow, perhaps as presented above. It will be interesting to find out how.
I'm wanting to find out, because I have a corrupted image of a warped file that used to work, and I want to find out where exactly things go awry when decoding those bytes, perhaps I can repair it. The BAM points to the start of these files and indeed the next sectors are probably arranged in a fixed order. I wonder if the code also checked for occupied sectors or would simply overwrite existing. If the latter is the case, then warp saving multiple large files may corrupt others. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
@mr.mouse: so you are saying is ...
warp save (GCR, not valid block data) -> d64 -> GCR -> warp load
... doesn't lose data in the general case.
I'd say it's unlikely, but not impossible.
(it also depends on what software interprets the invalid encodings into .d64)
I think you'll find it a hard time trying to find out how .d64 data gets mapped from the custom encoding by analysing the code though.
Better start by understanding the gcr encoding, and maybe then you can prove the next step... |
| |
Mr. Mouse
Registered: Dec 2001
Posts: 235 |
Yeah, you are right, I've tried it on other warped files, and it failed. So back to reading up on GCR and the source code. |
| Previous - 1 | 2 | 3 | 4 - Next |
