4 ms·

4k here means that the program is 4096 bytes long and not the screen resolution. Yes, that's only four thousand and ninety six 8-bit octets. And they are suppo

4k here means that the program is 4096 bytes long and not the screen resolution. Yes, that's only four thousand and ninety six 8-bit octets. And they are supposed to run on a machine with 985.248 kHz clock frequency. Yes, thats kilo as in one thousand. The machine in question has only a single core (with a single thread), but the demo cleverly uses the CPU of the floppy drive for a speed up, so you could say it features true parallelism on multiple cores. Also arithmetic on the machine operates only on 8-bit values and of course there is no hardware multiplication. Division, you wouldn't even think about.

karmakaze 3y ago
To state the implicit/obvious, the CPU is a 6502 from the assembler mnemonics and specifically a 6510 in a C64 from reference to the 1541 external floppy drive. > Note that as far as the slope math goes, Bresenham is special since it doesn't require the division of x by y, but BRR lines do. So for short line segments, Bresenham can still "win". In fact, BRR lines also need a bit more elaborate math for the remainder. (So this method really shines if you're able to pull in the 1541 for help. See my upcoming post about drivecode) The BRR algorithm is 5 cycles per position vs 8-10 cycles for Bresenham, which is impressive. Its step position inner loop calculation is only cpx #imm ;compare x-register to constant adc zp ;add with carry the value in (0-page) address to accumulator (a-register)