Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Warp compression method (AR)
2010-04-09 12:39
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?
2010-04-09 12:47
chatGPZ

Registered: Dec 2001
Posts: 11386
warp*25 uses a non standard sector format indeed... but no idea where to find info on it, could be interesting :)
2010-04-09 18:03
Krill

Registered: Apr 2002
Posts: 2980
Which "compression" are you talking about? It's merely a custom disk format. As far as i remember, there is no sector link information - the sector layout is fixed. That is the reason why you can't have more than one warp file per track.
2010-04-09 18:26
Mr. Mouse

Registered: Dec 2001
Posts: 235
What do you mean, no more than one file per track ? I've got several small ones that are on the same track. Okay, so I'd seen that one file was smaller after a warp save. Also the block contents are quite different compared to the non-warped saves. So what format is it in then? What is the order? I've noticed that on an empty disk the first normal files are started at track 17, the warped files start at track 1, sector 0. Suppose my file is smaller than oh 200 bytes. I won't need more than one sector. If I save several warped files of that small size, they each start in order, skipping 1 sector. So the first warped at sector 0, the next sector 2, then sector 4 etc.

Still, that leaves to find out for me how to read those sectors. Where do they start and in which direction does the reader go? And what process is used to alter the way the original bytes are represented.
2010-04-09 19:11
tlr

Registered: Sep 2003
Posts: 1790
It looks to me like a warp saved track has the same layout as a normal dos track except for the contents of the data block.
Maybe the "compression" you see is that the t/s link is implied, thus giving two more bytes per sector free?
2010-04-09 20:42
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...
2010-04-09 20:47
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.
2010-04-09 20:58
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.
2010-04-09 21:03
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.
2010-04-09 21:06
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.
2010-04-09 21:27
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?


 
... 24 posts hidden. Click here to view all posts....
 
Previous - 1 | 2 | 3 | 4 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Andy/AEG
Alakran_64
thesuperfrog
Guests online: 97
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Fullscreen Graphicians
1 Joe  (9.7)
2 Sulevi  (9.6)
3 The Sarge  (9.6)
4 Veto  (9.6)
5 Facet  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.054 sec.