[CSDb] - User Forums - Release id #197710 : Transwarp v0.64

You are not logged in - nap

CSDb User Forums

Forums > CSDb Entries > Release id #197710 : Transwarp v0.64

2020-11-22 17:12

Krill

Registered: Apr 2002
Posts: 2839

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....

2020-11-27 19:56

Krill

Registered: Apr 2002
Posts: 2839

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

2020-11-27 20:10

Krill

Registered: Apr 2002
Posts: 2839

Quoting Richard

Transwarp'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.

2020-11-27 21:37

Copyfault

Registered: Dec 2001
Posts: 466

Quoting Krill

Another 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!

2020-11-28 21:24

Krill

Registered: Apr 2002
Posts: 2839

Quoting Krill

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)? :)

Quoting BiGFooT

I'm in with https://en.wikipedia.org/wiki/Frequency_analysis ;)

New challenge image added, also containing some bonus material. =)

(But i'm really not so sure how much frequency analysis would help with this kind of scrambling.)

2020-11-29 01:23

BiGFooT

Registered: Mar 2002
Posts: 31

My understanding of "plaintext" was "plain text", so freq. analysis came from that. Anyway, I don't want to play alone.

2020-12-01 12:11

Krill

Registered: Apr 2002
Posts: 2839

Another technique: using interrupts to break out of the block read loop without stop condition checks.

In a loader, the loop to read data from disk normally terminates after having collected the block's data.
This is usually done by things like "inx : bne loop" or "tsx : bne loop" when storing block data on the stack using pha.

This requires at least an index register, and 2 cycles to increase it or to retrieve the stack pointer, both then setting the Z flag for loop termination or continuation.

This overhead can be avoided, or rather shifted out of the read loop (which needs to be extra-tight, and every cycle comes at a premium).

Since block read and transfer is tightly coupled in a fastloader, the C-64 can signal breaking out of the read/transfer loop, and it can do so by triggering an interrupt on the drive side via asserting the ATN line.

This causes the drive ROM's interrupt handler to be executed. However, one cannot simply install an interrupt hook or overwrite the IRQ vector, as it is possible on the C-64. (1571 has an interrupt hook, though.)

With some preparations (the disk controller VIA timer needs to have been underrun) the ROM interrupt handler will then check the job code table at $00 for active jobs (job codes $80+).
Having a jump job code ($d0) for $0700 then would execute the block read user code at $0700 to handle the next block rolling by, effectively breaking out of the read loop which was executing before the ATN interrupt was triggered.

Note that the job table is checked backwards, starting with the RAM-less job for $0800, then going down to $0300. So having the code to execute at $0700 spends the least cycles in the ROM interrupt handler.

2020-12-01 19:34

MagerValp

Registered: Dec 2001
Posts: 1055

Very nice, probably my favorite trick so far.

2020-12-02 20:45

Krill

Registered: Apr 2002
Posts: 2839

Submitted by JackAsser [PM] on 2 December 2020
Indeed awesome and now Krill can remove the encryption code becuase symmetric encryption with keys this small is utterly useless. 😂 better use the space for something else imo. But it was a cool challenge though, kudos for making it hard and still fast.

Sure, sure. :) And yeah, i did it for the fun of it. But... if i can somehow make the checksum-CRC stuff work with any key, correct or false, it cannot be used to guide bruteforcing (which i totally expected to happen) this ridiculously small key (real search space <40 bits, apparently). :D Wonder how hard that would be... =)

2020-12-03 07:22

Oswald

Registered: Apr 2002
Posts: 5017

nice tricks, tho I wonder a bit why did we have to wait 30 years for these :) I guess we were talking about non gcr irq loaders back in the ancient irc times already. probably the issue here is not many can code loaders.

2020-12-03 11:37

Krill

Registered: Apr 2002
Posts: 2839

Quote:

nice trick, tho I wonder a bit why did we have to wait 30 years for this :) I guess we were talking about the 9th sprite back in the ancient irc times already. probably the issue here is not many can code advanced raster routines.