Doom on ZPU(turbogrill.blogspot.com)
turbogrill.blogspot.com
Doom on ZPU
http://turbogrill.blogspot.com/2014/06/doom-on-zpu.html
7 comments
That struck me as very weird as well. I never heard of this CPU, so I looked it up. Turns out it's not supposed to go fast: the designers boast of a tiny implementation and dense code, and it only intended for "light administrative tasks".
The design is pretty neat. It's a stack machine, no registers, and literally a bytecode: each instruction is 1 byte long. The only exception seems to be a little hack in the IM (push constant) instruction to allow chaining to build long constants.
The design is pretty neat. It's a stack machine, no registers, and literally a bytecode: each instruction is 1 byte long. The only exception seems to be a little hack in the IM (push constant) instruction to allow chaining to build long constants.
I'm not sure what exactly it is about this kind of combination between old and new, but I always smile when some old classic thing runs on some new hardware. "Linux on my toaster" has some property that just really makes me smile.
I would have loved too see in the article how the ZPU is extended with an instruction doing 64-bit multiplication and how that measuably improved the performance of the game. It would have been a good example of how a soft CPU core can be adapted to the application. And how hard it would be. In this case probably getting the compiler to emit the new instruction. (The HW part is very simple.)
Enhancing the blit/memcpy functions would also be a good example of this.
Weird, the project is using "The FreeBSD license". Not 2-clause BSD, but actually FreeBSD:
http://repo.or.cz/w/zpu.git/blob/b1bba840534b2e9a6f79564b006...
http://repo.or.cz/w/zpu.git/blob/b1bba840534b2e9a6f79564b006...
> Frame index 184, 14 FPS. Slowest frame. Way more fixed point multiplications than surrounding frames, not sure why.
Isn't the blood rendered as multiple frames? This would be an explanation for slow rendering.
Isn't the blood rendered as multiple frames? This would be an explanation for slow rendering.
Maybe it's translating more wall coordinates into the viewable area? A lot of different walls are visible in that picture.
Anyone have some information on the ZPU? He mentions that it's a ... gun? I'm confused :(
The gun is not what he's talking about, just another thing named 'ZPU'. The link right after that is what he's talking about, the 32 bit open source CPU. It is designed using a Hardware Description Language that can then be loaded into a re-configurable chip to make said chip, or part of it, act as a CPU.
http://opensource.zylin.com/zpu.htm
http://opensource.zylin.com/zpu.htm
More general information, and a list of other "soft microprocessors":
http://en.wikipedia.org/wiki/Soft_microprocessor
http://en.wikipedia.org/wiki/Soft_microprocessor
The gun reference is to a family of Soviet anti-aircraft machine guns, from the 1940s: http://en.wikipedia.org/wiki/ZPU.
The crazy thing about the ZPU is that it is extra _small_, speed is not its goal, so running DOOM on it is kinda a weird choice. It is a stack based cpu that uses half the number of logic blocks that a typical small soft microprocessor would use.
[deleted]
> To reach the same performance on a PC something like a 486 @ 66MHz and a decent graphics card is needed.
Even accounting for the assembly optimizations, it sounds curious that the ZPU would do so much less work per cycle. Does anyone know why this might be?
PS. Doom 1 just used the standard VGA mode (13h), and the graphics card didn't matter much.