I remember as a kid being baffled by the weird memory layout for the Apple II's high-res graphics mode. Each contiguous row in memory corresponded to non-contiguous rows on the screen, probably to reduce top-to-bottom flickering on an NTSC display. The choice seemed to be between using BASIC, which abstracted away the layout but was extremely slow, or using 6502 assembly, which was fast but required my 11-year-old brain to invent an impossibly complicated algorithm for manipulating the memory.
Then one day I was disassembling the bootloader for a game disk. I think it was Borg; it showed a little dragon creature in the center of the screen that jumped each time the disk controller needed to move to a new track on the diskette. In 256 bytes, this code generated a look-up table for each screen row's starting location in memory, used it to blit incredibly fast, and loaded the game. And of course it left enough room for the dragon image itself. That snippet of code taught me at least a semester's worth of simple CS concepts.
As an aside to an aside, many cracked versions of Apple II games omit the loading screens, whose code was often enmeshed with the copy-protection code that needed to be neutralized. While many crackers replaced them with their own comparably creative loaders, I suspect many of the original elegant and cute screens are lost to history.
yeah, more or less the same experience (except I never got to the point of disassembling bootloaders).
What I do remember is the cracked version of Ultima IV, you could hit Control-C while booting and there was, just laying around, a file that played polyphonic music on the Apple (also a cool assembly trick). And All those BBSes... lost in time.
It's funny you mention the lookup table. If I had just known how to do that, I could have done row addressing.
The problem I had was that the width (in pixels) of the screen was larger than the Apple's 8-bit operands, and I got stuck on thinking I needed to do multiple-byte additions (with carries) manually.
Exactly. As they say, all optimization is caching. Seeing the hard part of the formula front-loaded into the LUT generation hammered that lesson home for me.
Then one day I was disassembling the bootloader for a game disk. I think it was Borg; it showed a little dragon creature in the center of the screen that jumped each time the disk controller needed to move to a new track on the diskette. In 256 bytes, this code generated a look-up table for each screen row's starting location in memory, used it to blit incredibly fast, and loaded the game. And of course it left enough room for the dragon image itself. That snippet of code taught me at least a semester's worth of simple CS concepts.
As an aside to an aside, many cracked versions of Apple II games omit the loading screens, whose code was often enmeshed with the copy-protection code that needed to be neutralized. While many crackers replaced them with their own comparably creative loaders, I suspect many of the original elegant and cute screens are lost to history.