1. 20

  2. 8

    I know retro-computing is one of those weakly divisive topics: Either it interests you or it REALLY doesn’t and you find it eye roll inducing tedious. Why are people rambling on about all this Old Stuff when there’s so much shiny cool New Stuff to innovate and play with?

    In my opinion, this article is a great example of why retro-computing could (dare I say should?) be compelling for modern programmers: Prowess and craft.

    Implementing the techniques this article lays out in 6502 assembly language is no mean feat, and requires a deep familiarity with the hardware in ways many of us might find alien.

    But despite that alien-ness, I’d argue that this is a neighborhood well worth visiting and learning about.

    1. 1

      As a Sinclair owner who never had a C64, I don’t get it… could someone explain what and why and how this is clever or difficult?

      1. 1

        I did once own a C64, though my memory’s a little fuzzy. I think the deal here is that normally the C64 had a fixed border around the visible part of the screen, for which you could set the colour but not actually display anything. Except, apparently, if I understand the post correctly, there was some way to get the hardware sprites to display in the border part of the screen (C64 had support for a limited number of these, I believe that number was 8, but you could get around that limitation with some trickery). So this demo scrolls an image across the full width of the screen - partly via a regular screen scroll, and partly by some clever manipulation of hardware sprites (both their positions and their image data). Note that to get the speed it does, it can’t just blit the whole image at an updated location for each pixel row; it has to use the hardware scrolling support, and has to keep the sprites in sync with that.

        1. 1

          Aha! Thank you!