Oh yes the dithering takes 10 seconds all to itself. The Quicktake 100 format is much more simple (4-bits nibbles) and it still needs 22 seconds to decode 640x480.
(Decoding and dithering are done in two passes for memory reasons and space on floppy disk reasons but it brings auto-levelling)
It's about 450 cycles per pixel for decoding QT100 (1200 for QT150), and 230 cycles per pixel for dithering.
To be fair, starting with the Apple IIe, the $C019 softswitch is a good, light way of syncing to VBL.
Doing it with the mouse IRQ has an advantage when one requires a mouse, though: it works the same way on the whole line of Apple II computers, starting with the II+.
Without the mouse IRQ, if one wants to support the whole line of Apple II computers, one has to vapor lock on the II+, remember that the IIgs's $C019 high bit means the inverse than the IIe, and the //c requires more trickery around it. (cf https://github.com/cc65/cc65/blob/master/libsrc/apple2/waitv...)
According to people at CryptoAncienne (https://github.com/classilla/cryanc), a 25MHz 68030 needs about 22 seconds of maths to handshake a modern TLS server. During that time, most servers close connection.
So on an 1MHz 6502, I think it'd be minutes just for handshaking.
Thanks for that, I was going to point out its the public key, and cert validation that is going to be the problem more than the actual data encryption. I had this problem a couple years back with a project on a esp8266, which was taking on the order of 5 seconds at 160Mhz to setup a TLS connection. And it got worse with longer key lengths, and validating a cert chain.
So, ballpark it probably takes multiple minutes, and probably consumes most of the RAM for the intermediate steps with longer keys.
OTOH, I switched to an ESP32 because it has RSA offload, and something like that could be attached to an apple ][ fairly easily, to provide a connection offload accelerator.
I wonder if it would be possible to make a usable dedicated hardware encryption card for the Apple II using 80s tech.
(Of course, it has the downside that upgrading to a new protocol would require a new card, but hey... we're just having fun musing on retro-futurism here!)
The 68030 is also a 32-bit processor with 8 general purpose registers. The 6502 is an 8-bit processor with one accumulator and two index registers, though it could use the first 256 bytes of memory (zero page) as pseudo-registers.
Yes, although the zeropage is quite cramped. There's only about 8 bytes free there if you don't want to overwrite anything. Accessing the zero-page only gains 1 cycle out of 4 needed to access non-zero-page memory locations, anyway, so that's only a 25% performance gain in very limited applications.
Not that anyone would find this useful or practical, but I wonder if it would make sense to define an alternate protocol where the handshake is asynchronous and doesn't require the server to hold a continuously open connection while the client performs the encryption. This might be a non-starter for interactive applications, but for batch things like downloading emails (where you could get away with checking for new mails every hour or so) this could be tolerable.
That does make sense. I was assuming that HTTPS would be possible but slow in 80s' hardware, I was not considering that the slowdown would be so massive modern hardware would consider it a lost connection.
It should be possible to drop in a coprocessor board to handle the encrypt/decrypt. It's compute bound rather than bus bound so it should speed up nicely.
Hi! Author here.
That was a requirement until this week-end, but I've done some work to support II+ without 80-column cards this week-end. The menu is toggled instead of being on the left.
Hey folks!
As the author of this, I'm touched by your kind words in the comments!
I feel like I should quote some of you on the clients' page, because some of these comments really reflect on the reasons I wrote this.
