9 thoughts on “The Ultimate Commodore 64 Talk: Pushing Keynote to its Limits

  1. Stefan Tramm

    Many thanks for providing the slides. Your talk at 25C3 was fantastic, I really enjoyed it!!
    (as WMV, because I couldnt attend)

  2. Louise

    What a cool talk!

    Will you be doing a part 2 next year?

    It would be very cool if you could cover how some demos used the CPU in the 1541-II to do the demo effects on the screen. To my knowledge the CPU in the 1541-II was a lot faster than the 6502.

    Also how was some demos able to get text scrollers in the borders? Some even had vertical scrollers.

    Some games (Chessmater 2100) had no files even though it was a 2 side disk game. How did they do that?

    Or just how could crackers (Ikrai) take Last Ninja 2, whcih was a tape game, and port it to disk, without the source code?

    Or if you could perhaps show have Final Chartridge or Action Replay was used to make a trailer?

  3. Michael Steil


    * Although the talk was quite popular, I very much doubt it that the Chaos Communication Conference will give me another slot for basically the same topic this year.
    * I know that some demos used the 1541 CPU for helping with floating point calculations to calculate fractals. The CPU in the 1541 was only clocked at 1 MHz, but it for certain workloads, it could help double the performance of the whole system.
    * Text scrollers in the borders used sprites.
    * Vertical scrollers… maybe sprites, maybe some other creative combination of tricks…
    * No files on disk: Since could upload code to the 1541, you could have it manage a custom filesystem that presented itself as “empty” to the normal OS. Or you could just do block-reads (“B-R”) without even uploading code.
    * Porting games from tape to disk: Reverse engineering is not all that hard if all code and data must fit in 65536 bytes.
    * Trailer??

  4. Repose

    I’ve looked into using the diskdrive for calculations; but it’s not too useful. The 1541-II is not faster, but replaces some chips with a single one. The data transfer takes 30ish cycles at each end. The 1541 has too little ram to use calculation tables, e.g. multiply takes 5 times as long as C64.
    Compare 216 cycles average for an 8×8=16bit multiply, compared to 40 cycles using a table in C64. Assume 32 cycles to transfer a byte.
    The 64 cycles it takes to receive an answer is slower than the time to do it on C64 in the first place.
    You would have to vastly reduce the communcation.
    So let’s say you calculate a Julia set. One iteration with (large) tables can be done in 12 cycles on C64. This is probably 20x slower without tables, and even if it weren’t, the communication is still too slow. Even a drive with 8k ram, and 2MHz, sending pre-computed multicolor mode graphic data, could only approach 50% speedup I would guess.
    Imagine a cartridge with a hardware multiplier. Simply storing and retrieving the data is only slightly faster than integrated, optimized code for a multiply. Only with 16×16=32bit multiplies, would this ideal situation reach 3x faster, but you hardly need such high precision for any game or demo.
    The data must be very little compared to the time it takes to calculate. Perhaps displayed a jpg would be faster, but again you’d need a faster drive with sufficient ram, and the decoded bytes are 10x more than the file itself, so there’s a huge communication overhead.

    Games which show no files might use the vorpal loader, this uses a custom disk format.

    Vertical scrolling is done by forcing the vertical scroll to be one ahead of itself so it refuses to fetch data, this moves the screen down by one line each time it’s done, but also reduces the vertical resolution. You can scroll a smaller window in any direction instantly. See finely sliced demo.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>