| |
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....
|
| |
rattus
Account closed
Registered: Oct 2002
Posts: 14 |
This might be actually quite interesting... Loading time for a warp file
was unbelievable in those days... Maybe usable in demos or so... |
| |
Mr. Mouse
Registered: Dec 2001
Posts: 235 |
The T/S link is not implied at all, in my view. Take a look at the first sector of a warped file. There are no immediate references to tracks or sectors. And the contents are really quite different from normal dos blocks. Try saving a small file on an empty disk, then warp-save the file and take a look at the BAM and sectors. You'll find the bytes in the warped sectors match nothing in the normal dos version. And that part interests me. What is happening, and how can I dissolve this. |
| |
Mr. Mouse
Registered: Dec 2001
Posts: 235 |
Here's an example file.
http://c64.xentax.com/downloads/warp_test.zip
There is an 8 byte file of values 01, 02, 04, 08, 10, 20 , 40, 80 (hex) stored at $1000.
And it's warped counterpart. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Implied as in: the order is implicit i.e 0, 2, 4, 6, 8, etc...
I haven't checked the BAM yet.
Here's your first sector:
--- sync -----------------------
0000: ff ff ff ff ff
--- gcr ------------------------
0005: 52 54 b5 29 4b d2 b4 a5 55 55 55 55 55 55 55
--- decoded --------------------
0005: 08 01 00 01 a0 a0 0f 0f 0f 0f 0f 0f
--- interpretation -------------
sector header, t=1, s=0 (ID='$a0,$a0') chk=$01 (calc=$01)
--------------------------------
--- sync -----------------------
0014: 55 ff ff ff ff ff ff
--- gcr ------------------------
001b: 55 d4 ad a6 a9 69 49 d5 db 76 ab ca 52 95 a6 a6 a6 5d 76 ce 49 49 49 72
0033: 79 7b aa ab 6e 4e 53 99 4b 9d 4e 9a 96 9e a9 d6 ca b2 d2 b5 ae db c9 a6
004b: b3 d6 9b db 52 9a 72 bd 53 6b 73 4e 53 b5 bd d9 d9 5e 96 ad 53 52 a6 6d
0063: ad d3 7a a6 d6 6a ca 56 5d d6 9b 49 c9 66 ca 9e 96 ca aa cd 9d b3 ae 5e
007b: 9a db 5a c9 5b 93 d2 55 53 49 73 bb 6a b9 53 9b ba 6d 5b ad d6 4d 7b 4d
0093: 4a 4d 56 da ce 66 ca c9 4a 5d 9b b3 72 75 4d 6d da b2 66 d5 ce ae 72 9e
00ab: 5b 79 ce d5 d9 a6 75 49 d2 a5 6e 4e 52 9b d6 d2 5a b2 ba 55 ab aa b3 69
00c3: 5a d6 66 ad 7a b2 ab 4b 65 a9 95 69 56 52 96 4d 79 d6 d5 4e 5a 9b bb 73
00db: b2 49 5a 7b 7a b2 ab 4b 65 cd a6 ce 56 52 96 db 4e 9e ba 79 53 da 73 d2
00f3: cb 9e 53 66 66 52 ca 9d 4b 75 d6 d2 5d a6 7b 6e c9 d2 d6 b6 5a 79 b5 9e
010b: 93 56 ba 79 7a b2 ab 4b 65 cb 9a da 56 52 96 ce 4d 9e d9 5a 7a b2 ab 4b
0123: 65 a6 d2 cb 56 52 96 52 da 9e 4a ab 53 da 73 d2 6b 56 65 a9 a9 52 ca 9d
013b: 4b 75 d6 d2 5d a6 7b 6e c9 d2 d6 b6 5b 53 b9 9e 93 56 ba 79 7a b2 ab 4b
0153: 65 cb 9a da 56 52 96 ce 4d 9e 5e 9d 9d ff 4a 55 55 55 55 55
--- decoded --------------------
001b: 07 00 b8 f8 xx xx 16 b6 f5 xx xx xx xx xx ad 64
002f: xx xx xx 39 54 f0 6b 24 04 xx xx 04 30 18 d0 46
0043: 90 9c xx c4 b5 xx xx e6 35 cf xx 32 7f 86 xx a4
0057: 04 ab b6 49 1a 10 xx a2 xx 6a xx ba xx xx f2 26
006b: 17 18 62 48 xx xx xx 60 f1 xx xx d4 1a cc 66 68
007f: 14 8d xx 03 xx 9b 6a f9 04 cb xx 0b f7 xx ae ac
0093: 88 xx c6 64 xx xx 22 2d 34 97 xx 0c c7 c1 xx 6f
00a7: 9a xx xx 2b xx xx 16 xx 4f xx xx 14 89 88 7f 62
00bb: 10 91 xx c1 f0 96 26 66 xx 67 xx f1 8c 2a xx 18
00cf: 09 88 xx 19 ab xx xx xx 7c 9b xx 0a 5c d1 xx a1
00e3: xx xx c3 26 00 1c 63 xx 78 xx xx 33 a1 xx xx xx
00f7: xx xx xx 01 47 1c xx xx 5c xx xx 66 69 xx 3c xx
010b: 2c 11 xx 1a 60 xx 69 41 31 xx xx xx 99 xx d6 0a
011f: 50 90 62 xx xx xx 6f 22 29 8c xx 20 fc 8d xx e2
0133: cc xx 10 c8 01 xx a2 bf ab xx b8 3b cb xx xx f6
0147: 1c 8b xx xx 0a xx 2e f2 fc xx 12 xx b8 xx xx 64
015b: 86 xx xx xx xx xx 0f 0f 0f 0f
As you can see the header block is normal, but the data block uses a custom encoding. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Here's an example file.
http://c64.xentax.com/downloads/warp_test.zip
There is an 8 byte file of values 01, 02, 04, 08, 10, 20 , 40, 80 (hex) stored at $1000.
And it's warped counterpart.
Warped files aren't storable on a d64 as it doesn't support bit level encodings. Please use g64 instead. |
| |
Mr. Mouse
Registered: Dec 2001
Posts: 235 |
http://c64.xentax.com/downloads/warptest_g64.zip
Okay, used g64. What tools do you use to view those, other than hex editors?
|
| |
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? |
| Previous - 1 | 2 | 3 | 4 - Next |
