| |
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....
|
| |
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. |
| |
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. |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Very nice, probably my favorite trick so far. |
| |
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... =) |
| |
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. |
| |
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. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
that doesnt stand as many can code advanced raster routines. and next time please dont make it a quote as if I did say that :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Oswaldthat doesnt stand as many can code advanced raster routines. and next time please dont make it a quote as if I did say that :) I was just mimicking any random quote and didn't put an "Oswald" there on purpose. :)
But my point was that "Why wasn't this invented 30 years ago already?" pretty much goes for any kind of demo novelty on this platform, doesn't it? =) (No matter how hard or how few people are dabbling in a particular sub-field.) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
ok maybe 30 was harsh, tried to understand what you did, could you explain what is ATNA used for normally ? the descriptions (i found) doesnt mean anything to me. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Oswaldok maybe 30 was harsh, tried to understand what you did, could you explain what is ATNA used for normally ? the descriptions (i found) doesnt mean anything to me. ATNA means "Attention Acknowledgement" and controls the hardware's response to incoming ATN ("Attention") signals.
The ATN line is what a bus master (the C-64) asserts when sending commands to bus devices. Any device on the bus would react to an incoming ATN signal by asserting the DATA line. The 1541 cannot control the ATN line, but only react to it.
Now, ATNA controls the ATN acknowledgement polarity.
If ATNA matches ATN (both are 0 or both are 1), nothing happens, and the DATA line is not asserted (but is left to unasserted if no device on the bus is "pulling" it, otherwise it's asserted anyways).
If ATNA does not match ATN, the DATA line is automatically asserted by hardware, signalling to the bus master that at least one device on the bus is responsive (if DATA wasn't asserted before, anyways).
This is also what disturbs ATN-clocked IRQ loader bitpair-transfer protocols (payload on DATA and CLK lines) with more than one device on the bus if no ATN responder code (make ATNA match the incoming ATN signal as quickly as possible in a tight loop) is executing on the passive devices. The DATA line then would be asserted when it's not supposed to be.
HTH =) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | ... | 18 - Next |
