> 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 astonishingly well; for a time, Video Seven’s VGAs were the fastest around, a testament to Tom’s ingenuity and creativity under pressure. However, the truly remarkable part of this story is that Paradise’s FIFO design turned out to bear not the slightest resemblance to Tom’s, and didn’t work as well. Paradise had stuck a read FIFO between display memory and the video output stage of the VGA, allowing the video output to read ahead, so that when the CPU wanted to access display memory, pixels could come from the FIFO while the CPU was serviced immediately. That did indeed help performance—but not as much as Tom’s write FIFO.
I started programming by making games in TI-BASIC, for the TI-83+ graphing calculators. There were some weird tricks like omitting all ending parentheses. Good preparation for weird hacks in real languages.
Monster Max on Game Boy happens to use unrolled "ld de,NNNN / push de" loops constructed in main memory to write to video ram.
For those unfamiliar with Monster Max (1994, Game Boy), it's basically the last of the British Isometric Platformers, a genre started by Knight Lore on ZX spectrum.
It is definitely in the spirit of the story of Mel, since Tom was exploiting an intimate knowledge of the machine to achieve the impossible by using instructions in unintended ways, but always remember that Tom is not a real programmer:
Real Programmers wrote in machine code.
Not FORTRAN. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.
Directly.
That said, I prefer Tom's story. It's more about the joy of understanding the machine than it is about the framing of a legend.
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 astonishingly well; for a time, Video Seven’s VGAs were the fastest around, a testament to Tom’s ingenuity and creativity under pressure. However, the truly remarkable part of this story is that Paradise’s FIFO design turned out to bear not the slightest resemblance to Tom’s, and didn’t work as well. Paradise had stuck a read FIFO between display memory and the video output stage of the VGA, allowing the video output to read ahead, so that when the CPU wanted to access display memory, pixels could come from the FIFO while the CPU was serviced immediately. That did indeed help performance—but not as much as Tom’s write FIFO.
[1] https://www.jagregory.com/abrash-black-book/#the-challenge-o...
I started programming by making games in TI-BASIC, for the TI-83+ graphing calculators. There were some weird tricks like omitting all ending parentheses. Good preparation for weird hacks in real languages.
Monster Max on Game Boy happens to use unrolled "ld de,NNNN / push de" loops constructed in main memory to write to video ram.
For those unfamiliar with Monster Max (1994, Game Boy), it's basically the last of the British Isometric Platformers, a genre started by Knight Lore on ZX spectrum.
This process is what’s missing in the ai era.
Wonderful. What an extraordinary effort and great results. Makes my 6502 efforts (using page boundaries) seem rather simple. Those were the days!
obligatory: The Story of Mel
https://users.cs.utah.edu/~elb/folklore/mel.html
It is definitely in the spirit of the story of Mel, since Tom was exploiting an intimate knowledge of the machine to achieve the impossible by using instructions in unintended ways, but always remember that Tom is not a real programmer:
That said, I prefer Tom's story. It's more about the joy of understanding the machine than it is about the framing of a legend.Terry Davis in the comments plugging Temple OS is a bonus