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.
mikewarot 2 hours ago [-]
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 thing we used as a benchmark was searching for "DOS TECH REF", the IBM DOS Technical Reference Manual.
I can't find the code, lost it over the years, but it was one of my coolest hacks.
taspeotis 7 hours ago [-]
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.
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"
pjc50 9 minutes ago [-]
These days if you want to get esoteric you can do it in GPU shaders; https://www.shadertoy.com/ provides lots of fun examples with code.
Or there's MCUs with programmable IO for bit-bashing protocols.
Agentlien 2 hours ago [-]
It depends a lot on what you work with. I am a much younger generation of game programmer (only 15 years of professional experience), but a lot of the work I do has a similar feel.
Not saying that most game programming is like that, but if you specialize in graphics and performance, preferably in large productions, you get to work close to the hardware and solve a lot of really fun problems in interesting ways.
Krei-se 1 hours ago [-]
You can do that now - and id argue its even easier to get into it.
WebGPU in a browser is worth the learning curve - and gives you the same interface then in Rust!
When you sniffed that sweet sweet shader code and memory layouting - why not get into WebAssembly?
You can have sth very similar to an OS in your browser if you want. It's a lot of fun and knowledge actually useful instead of the next hypecycle of frameworks and dialects.
BrtByte 16 minutes ago [-]
[flagged]
Agentlien 1 hours ago [-]
This type of story is always so cool to read. In this type of community there's often a bit of wistful dreaming back to these days and the type of challenges they presented.
I'm young enough that I wasn't there, but I've been programming since I was a kid and working with graphics for the last 15 years.
This type of excitement is the feeling I got from learning C and C++ to begin with. Trying to really understand how things were working under the hood.
I still get that sense when working on low level graphics and performance in my current job. In fact, when the texture memory corruption was introduced the article felt eerily similar to the events which inspired me to write my own recent article about texture memory layouts ( https://agentlien.github.io/texture )
nigehban 37 minutes ago [-]
this feels like precursor of SIMD mechanism, instead of byte processing, process the capacity (max). I remember my image processing class with Ian R. Greenshild. We had to dig a lot of tricks for matrix calculations.
But the most important thing is that you have to rule the hardware (IRQs, Registers, PCs, etc). Thank you for the article, it made me smile and remember my 80s...
Dwedit 6 hours ago [-]
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.
BrtByte 4 minutes ago [-]
[flagged]
BrtByte 17 minutes ago [-]
I was already impressed by the stack pointer trick, but then the interrupts started corrupting memory and I thought, well, that's the end of that. Somehow the solution was to deliberately corrupt a different part of memory and change the drawing order. That's the kind of thing you'd never believe if you hadn't seen it work.
jimbobbam 7 hours ago [-]
This process is what’s missing in the ai era.
nunez 4 hours ago [-]
idk about that. people will always find a way of working together to solve problems. that "solving" the AI era means "pulling the lever on the claude machine" is sad, I agree
fferen 6 hours ago [-]
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.
awmc2000 6 hours ago [-]
Terry Davis in the comments plugging Temple OS is a bonus
Agentlien 2 hours ago [-]
Seeing that actually shocked me a bit. I remember when I was first on HN I'd see occasional messages of him either promoting his TempleOS or going off on crazy aggressive rants completely out of context. A lot of comments were saying never mind Terry, he isn't well. It's very sad how his story ended.
mrandish 5 hours ago [-]
The clever 6809 PSHU/PULS memory copy trick was probably independently discovered several times before Tom Moertel discovered it. The game Tom worked on was for the Coco 3, which was released in 1986.
My first computer was the original 4K Color Computer (1981). I learned 6809 assembler on it and worked full time programming it for several years, while also running one of the largest users groups for it. Traveling to Coco trade shows around the country, I met many of the devs writing the most popular Coco games and the trick was definitely known by around Summer 1983 as that's when the first Rainbowfest was held and I heard about there.
Around 1983, Steve Bjork (MegaBug / Zaxxon Coco) told me the devs at DataSoft, the company behind some of the popular 1st party cartridge games Radio Shack sold, were using it. I also heard about it in 1984 from Tim Jenison (CocoMax). The earliest usage of the trick in a commercial game was probably in a Williams arcade game, either Defender (1981) or Joust (1982). A few years ago at the Hackers Conference Tim told me he'd once asked Eugene Jarvis (Joust, Defender) about it and Eugene told him after discovering it they'd nicknamed the trick "PUSH-U / PUL-Me." I confirmed this with Sam Dicker (Sinistar (1983), Defender) last year during the Amiga 040th anniversary at the Computer History Museum.
While the basic trick to do a fast software block image transfer was discovered separately by several 6809 programmers, I can't recall ever seeing the Direct Page (DP) register used with it before today. That and some of the other refinements in TFA are quite clever additions. I think the Coco's lack of any hardware sprites, tiles, scrolling or acceleration made Coco devs especially desperate, so we had to become masters of software blits with PSHU/PULS and software sprites with XOR. And since all this was happening before Usenet and dial-up BBSes were commonly available, there was no way to share cool tricks widely except printed books and magazines.
Fortunately, the 6809 made up for Radio Shack's penny-pinching design by being much faster than the 6502 and Z80, which were microcoded while the 6809 was implemented directly in logic gates. It's widely considered the most advanced of all the 8-bit CPUs with an especially elegant, orthogonal ISA supporting position independent, re-entrant, multitasking code and powerful indirect addressing modes. One little known bit of history is that Jef Raskin's team at Apple used the 6809 for the initial Macintosh prototypes before Steve Jobs managed to cut a steep discount deal with Motorola on the workstation-priced 68000 CPU. By 1981, Moto was probably starting to realize they'd been pricing their CPUs far too high, having lost the Apple II, Commodore PET, VIC-20, C64 and then IBM PC designs, despite having a better chip. Waking up just in time to win, arguably, the LAST big desktop computer CPU design... ever? Way to go Moto!
The 6502 was most definitely not microcoded! It's way simple.
On the Vectrex, also a 6809 machine, the fastest vector draw routines use the stack to thread draw commands, not quite the same thing but those sixteen bit stack pointers sure are useful.
mrandish 3 hours ago [-]
Doh! You're correct - and I should have known that since the 6502 design was based on a greatly cost-reduced Motorola 6800, the 6809's dad. Somehow I bit-flipped between the 6502/Z80 (not microcoded) and the 8088 (microcoded). Thanks for the correction.
Re: the Vectrex, I never knew that but it makes sense since chasing the beam requires feeding a massive queue of vector pairs.
baud9600 7 hours ago [-]
Wonderful. What an extraordinary effort and great results. Makes my 6502 efforts (using page boundaries) seem rather simple. Those were the days!
Panzerschrek 4 hours ago [-]
On modern CPUs such tricks are irrelevant. They are able to process multiple instructions in the same time, so that the main bottleneck is no longer executing instructions, but accessing memory.
pjc50 51 seconds ago [-]
Eh, you can always move the performance frontier into something else, and the SIMD capabilities give you lots of strangely shaped instructions to play with. We have absolutely not seen the end of clever hand written code, it's just very rare.
4gotunameagain 23 minutes ago [-]
Those specific tricks are irrelevant mostly due to compiler optimisations, even in compute heavy workloads.
Rohansi 4 hours ago [-]
Kind of, but not really? At its core this article is basically a hack to do a bit of SIMD on an instruction set that doesn't have SIMD. Obviously SIMD is still highly beneficial on modern CPUs otherwise compilers would stop emitting it.
abrookewood 5 hours ago [-]
I love reading about this stuff, even if I understand very little of it. Similar to the demo scene and code golf stuff, I'm amazed at the knowledge that some people have.
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.
getbrew 6 hours ago [-]
[flagged]
minfazhai 7 hours ago [-]
[flagged]
exilonium 7 hours ago [-]
[dead]
dariozt 7 hours ago [-]
[dead]
Rendered at 09:38:25 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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 thing we used as a benchmark was searching for "DOS TECH REF", the IBM DOS Technical Reference Manual.
I can't find the code, lost it over the years, but it was one of my coolest hacks.
> 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...
Or there's MCUs with programmable IO for bit-bashing protocols.
Not saying that most game programming is like that, but if you specialize in graphics and performance, preferably in large productions, you get to work close to the hardware and solve a lot of really fun problems in interesting ways.
WebGPU in a browser is worth the learning curve - and gives you the same interface then in Rust!
When you sniffed that sweet sweet shader code and memory layouting - why not get into WebAssembly?
You can have sth very similar to an OS in your browser if you want. It's a lot of fun and knowledge actually useful instead of the next hypecycle of frameworks and dialects.
I'm young enough that I wasn't there, but I've been programming since I was a kid and working with graphics for the last 15 years.
This type of excitement is the feeling I got from learning C and C++ to begin with. Trying to really understand how things were working under the hood.
I still get that sense when working on low level graphics and performance in my current job. In fact, when the texture memory corruption was introduced the article felt eerily similar to the events which inspired me to write my own recent article about texture memory layouts ( https://agentlien.github.io/texture )
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.
My first computer was the original 4K Color Computer (1981). I learned 6809 assembler on it and worked full time programming it for several years, while also running one of the largest users groups for it. Traveling to Coco trade shows around the country, I met many of the devs writing the most popular Coco games and the trick was definitely known by around Summer 1983 as that's when the first Rainbowfest was held and I heard about there.
Around 1983, Steve Bjork (MegaBug / Zaxxon Coco) told me the devs at DataSoft, the company behind some of the popular 1st party cartridge games Radio Shack sold, were using it. I also heard about it in 1984 from Tim Jenison (CocoMax). The earliest usage of the trick in a commercial game was probably in a Williams arcade game, either Defender (1981) or Joust (1982). A few years ago at the Hackers Conference Tim told me he'd once asked Eugene Jarvis (Joust, Defender) about it and Eugene told him after discovering it they'd nicknamed the trick "PUSH-U / PUL-Me." I confirmed this with Sam Dicker (Sinistar (1983), Defender) last year during the Amiga 040th anniversary at the Computer History Museum.
While the basic trick to do a fast software block image transfer was discovered separately by several 6809 programmers, I can't recall ever seeing the Direct Page (DP) register used with it before today. That and some of the other refinements in TFA are quite clever additions. I think the Coco's lack of any hardware sprites, tiles, scrolling or acceleration made Coco devs especially desperate, so we had to become masters of software blits with PSHU/PULS and software sprites with XOR. And since all this was happening before Usenet and dial-up BBSes were commonly available, there was no way to share cool tricks widely except printed books and magazines.
Fortunately, the 6809 made up for Radio Shack's penny-pinching design by being much faster than the 6502 and Z80, which were microcoded while the 6809 was implemented directly in logic gates. It's widely considered the most advanced of all the 8-bit CPUs with an especially elegant, orthogonal ISA supporting position independent, re-entrant, multitasking code and powerful indirect addressing modes. One little known bit of history is that Jef Raskin's team at Apple used the 6809 for the initial Macintosh prototypes before Steve Jobs managed to cut a steep discount deal with Motorola on the workstation-priced 68000 CPU. By 1981, Moto was probably starting to realize they'd been pricing their CPUs far too high, having lost the Apple II, Commodore PET, VIC-20, C64 and then IBM PC designs, despite having a better chip. Waking up just in time to win, arguably, the LAST big desktop computer CPU design... ever? Way to go Moto!
2013 Hacker News comments here: https://news.ycombinator.com/item?id=6913467
On the Vectrex, also a 6809 machine, the fastest vector draw routines use the stack to thread draw commands, not quite the same thing but those sixteen bit stack pointers sure are useful.
Re: the Vectrex, I never knew that but it makes sense since chasing the beam requires feeding a massive queue of vector pairs.
https://users.cs.utah.edu/~elb/folklore/mel.html