The 6809 Hack That Made a Side-Scroller Playable
A great old-timey game-programming hack (2013)
In the 8-bit PC era, a friend's arcade port ran too slowly to play. The code was already tight—loops unrolled, offsets replacing post-increments—yet still too slow. Digging through a Motorola MC6809 manual, the author found an odd instruction that could move bytes fast enough to save the game. A nostalgic account of cycle-counting and a very old-timey optimization.
And that's where most programmers probably would have left it. But not my friend.
- sehugg
The 6502 has a more narrow and diabolical version of the 6809's PSHS trick. The BRK instruction pushes the PC and status register to the stack in three consecutive cycles, and is pretty much the only non-interrupt instruction that writes more than twice.
The Atari 2600 has horizontal object counters that you can't set directly, but they latch when you write to them, and they set the corresponding object to the X position of the beam at that cycle. Pole Position requires three of these objects to draw the left/right side of the road and center line, and they are supposed to meet at the horizon.
But the beam moves to the right 3 pixels for every CPU cycle, and writing with STA would result in each being separated by 9 pixels. What's the fix? Move the stack pointer to where the object pointers live (the 2600 maps the stack to zero page, where the RAM and registers live, and they're adjacent) and invoke BRK, making sure the BRK vector returns you to the next instruction. It writes to each object pointer on successive cycles, now each of them is 1 cycle = 3 pixels apart.
- mikewarot
Back in the MS-DOS days, my friend Ward Christensen worked at IBM in Technical Sales Support. They had a file informally maintained that listed every single product they had for sale, in a format that could be read on a PC. He was really good at searching it with his text editor, but he wanted a MS-DOS based stand alone program to make it easy to search for his co-workers. Thus was born, PCxREF which was a Turbo Pascal based program I wrote, that included search.
My first pass at it was a naïve search using the built in string matching. Because of the size of the file, and the speed of PCs, it would sometimes take more than 30 seconds to do a search. Ward wanted it faster, much faster.
I eventually came up with an algorithm that took the text you wanted to search for, and changed it into a special kind of bit mask, table. It was a table 256 bytes long, initialized to zeros. If the first character of the string you wanted to search for was a D, then the first bit of the $44 and $64 mask would be set, to handle case sensitivity. A wildcard * was only 1 character long, but would set all bits for that character. I then used the 8088 XLAT instruction and a very small loop ingest a character of the text being searched, use that as an index into the mask table, and AND that with the existing flag in a different register, then shifted it, checking for CARRY (a match!) and looping if not zero.
It took search down to less than 3 seconds if the whole file was loaded in RAM. The thin […]
- taspeotis
Somewhat related [1]:
> Years ago, I was working at Video Seven, a now-vanished video adapter manufacturer, helping to develop a VGA clone. The fellow who was designing Video Seven’s VGA chip, Tom Wilson, had worked around the clock for months to make his VGA run as fast as possible, and was confident he had pretty much maxed out its performance. As Tom was putting the finishing touches on his chip design, however, news came fourth-hand that a competitor, Paradise, had juiced up the performance of the clone they were developing by putting in a FIFO.
> That was all he knew; there was no information about what sort of FIFO, or how much it helped, or anything else. Nonetheless, Tom, normally an affable, laid-back sort, took on the wide-awake, haunted look of a man with too much caffeine in him and no answers to show for it, as he tried to figure out, from hopelessly thin information, what Paradise had done. Finally, he concluded that Paradise must have put a write FIFO between the system bus and the VGA, so that when the CPU wrote to video memory, the write immediately went into the FIFO, allowing the CPU to keep on processing instead of stalling each time it wrote to display memory.
> Tom couldn’t spare the gates or the time to do a full FIFO, but he could implement a one-deep FIFO, allowing the CPU to get one write ahead of the VGA. He wasn’t sure how well it would work, but it was all he could do, so he put it in and taped out the chip.
> The one-deep FIFO turned out to work […]
- pjc50
Trying to work out which computer actually had the 6509 in; candidates seem to be Dragon or Tandy?
This sort of thing is why the Amiga was so massively successful by adding a collection of co-processors: https://en.wikipedia.org/wiki/Amiga_Original_Chip_Set
Each of which had limited but dedicated functionality for moving and transforming bytes in RAM. The blitter in particular was dedicated to moving memory around for tile and sprite rendering.
- green_wheel
Awesome article. I guess grass is always greener but coding in those days seems really cool. Today it's all package managers this and toolchains that. We're so far abstracted away from what's actually running our code. Articles like this make me here the CPU calling "come back to meeeeee"