| |
Krill
Registered: Apr 2002
Posts: 2844 |
Release id #197710 : Transwarp v0.64
General Q&A thread, also report problems and error logs here. |
|
... 162 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Ok, so who'd be in for a second challenge, then, with a high-entropy plaintext file that is still sensible (and rewarding to decrypt, not just random bitsalad)? :) |
| |
BiGFooT
Registered: Mar 2002
Posts: 31 |
Quote: Ok, so who'd be in for a second challenge, then, with a high-entropy plaintext file that is still sensible (and rewarding to decrypt, not just random bitsalad)? :)
I'm in with https://en.wikipedia.org/wiki/Frequency_analysis ;) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
@bigfoot: thanks!! |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting BiGFooTByte 2&3 contains the load address, 4&5 is the end
andress. Worth noting here, imho, is that Byte 1 contains a CRC8 checksum over the entire file. This is only computed (because slow) and checked when there are block checksum errors with retries, but ultimately a successful file load.
It does happen that funky drives or semi-broken disks load successfully eventually, and this second line of defence decreases the likelihood of false positives (good checksum despite bad data) quite a bit, even with the first line being somewhat more sophisticated than simple byte-wise EOR. :)
Ah, and byte 0 is the file's starting track. :D |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Another trick: JMP ($DD00) for less jitter when reacting to drive signals.
Normally you'd do things like- bit $dd00
bpl/bmi/bvc/bvs - to wait for a state change on the serial bus. This has a jitter of 7 cycles (on PAL, 8 cycles on NTSC/PAL-N because the C-64's CPU is clocked faster than the drive's CPU),
Using JMP ($DD00), this is reduced to 5 (6) cycles of jitter.
$DD01 (the RS232/parallel port bits connected to the user port) needs to be set to output and initialised to the high-byte of a jump table.
So it's trading size for speed, as this jump table is slightly more than $c0 bytes big, due to the incoming bus state bits sitting on bits 7 and 6. (Can of course stuff unrelated stuff into the gaps of this sparse table.)
Using this trick, it is possible to have a minimum of 6 cycles between serial bus signal updates (instead of 8 normally) without requiring further jitter reduction (using the half-variance technique), such that things likeldx #$0a ; CLKOUT + DATOUT
sax $1800; 2 data bits
asl
sax $1800; 2 more data bits sending multiple bitpairs over serial can be done quicker. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Another trick: JMP ($DD00) for less jitter when reacting to drive signals.
Normally you'd do things like- bit $dd00
bpl/bmi/bvc/bvs - to wait for a state change on the serial bus. This has a jitter of 7 cycles (on PAL, 8 cycles on NTSC/PAL-N because the C-64's CPU is clocked faster than the drive's CPU),
Using JMP ($DD00), this is reduced to 5 (6) cycles of jitter.
$DD01 (the RS232/parallel port bits connected to the user port) needs to be set to output and initialised to the high-byte of a jump table.
So it's trading size for speed, as this jump table is slightly more than $c0 bytes big, due to the incoming bus state bits sitting on bits 7 and 6. (Can of course stuff unrelated stuff into the gaps of this sparse table.)
Using this trick, it is possible to have a minimum of 6 cycles between serial bus signal updates (instead of 8 normally) without requiring further jitter reduction (using the half-variance technique), such that things likeldx #$0a ; CLKOUT + DATOUT
sax $1800; 2 data bits
asl
sax $1800; 2 more data bits sending multiple bitpairs over serial can be done quicker.
Neat trick. Love it! Also like how you use the word ’stuff’ both as a verb and a noun in the same sentence! ❤️ Almost like the Smurfs smurfing smurfs up. |
| |
Richard
Registered: Dec 2001
Posts: 619 |
Transwarp's speed is amazing. It would probably make a great C64 filebrowser/menu system ;) |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
User Comment
Submitted by ThunderBlade [PM] on 27 November 2020
I've waited for this since Heureka Sprint. The 64'er magazine had an article on it concluding with "In theory it should be possible to get even faster than that". Proven now! :) Hmm, but (slightly) faster systems than Heureka Sprint have been existing since before it was invented*. =)
It also seems like some conscious concessions were made for Heureka Sprint, paying with slightly slower speed for standard format compatibility. It uses a 70% encoding, not 75% as the original Vorpal (and its knock-off Action Replay Warp*25) does.
Transwarp does the same. If it were not for the intended d64 compatibility, it could use a slightly denser encoding and thus slightly more speed. But that decision was easy, nobody really wants to transfer weirdo g64 images to real disks. :)
* https://www.lemon64.com/forum/viewtopic.php?t=41482 |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
Quoting RichardTranswarp's speed is amazing. It would probably make a great C64 filebrowser/menu system ;) Not before there is a built-in 2-rev fallback fastloader for standard format. And that one will probably be somewhere slightly above half the speed of the custom format. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting KrillAnother trick: JMP ($DD00) for less jitter when reacting to drive signals.
[...] This is so nice!!! And personally I don't care if this requires a jump-table, usually there's enough mem space on c64-side.
Thanks for sharing! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | ... | 18 - Next |
