
The DooM-chip: no CPU, no opcodes, no instruction counter - MrBuddyCasino
https://twitter.com/sylefeb/status/1258808333265514497
======
AnotherGoodName
There's an old saying when judging a new architecture. Can it run Doom?

This question arises since pretty much anything can these days.
[https://www.vice.com/en_us/article/qkjv9x/a-catalogue-of-
all...](https://www.vice.com/en_us/article/qkjv9x/a-catalogue-of-all-the-
devices-that-can-somehow-run-doom)

Now we have a new answer: IT CAN ONLY RUN DOOM

~~~
willis936
If only mankind was capable of making a machine that can run crysis.

~~~
ummwhat
That's why we are developing quantum computers.

~~~
yetihehe
But will they run crysis? You will know only after opening them...

------
nabla9
I bet 2000 years from now Doom is belongs to canon like Iliad. It's of the
timeless classical epics among the oldest extant works from the early silicon
era. Doomguy is mentioned with Gilgamesh and Odysseus.

~~~
kick
Why? DOOM was a technical achievement, sure, but it has little in the way of
story; it didn't even attempt the whole "trying to tell a story without words"
thing common in video games of today. It's certainly not an epic.

If they wouldn't have released source code for it in 1997, who would actually
be thinking of DOOM today in terms of anything but "Wow, that had pretty cool
tech!"?

I could kind of understand the story appreciation for DOOM 3, because it at
least had a story, but DOOM?

~~~
sylefeb
Doom has had an immediate huge impact in its time ; even before the source
code got released the game had a hacker-friendly wibe to it. For instance DEU
(the first editor I used) was released in 1994
([https://doom.fandom.com/wiki/Doom_Editing_Utilities](https://doom.fandom.com/wiki/Doom_Editing_Utilities)).
The 'unofficial specs', still invaluable today if you want to hack Doom, were
released in 1994:
[http://www.gamers.org/dhs/helpdocs/dmsp1666.html](http://www.gamers.org/dhs/helpdocs/dmsp1666.html)

Magazines would bundle floppies (and then CDs) full of levels, with new
textures and recorded games. Total conversions were made. Tools appeared to
directly manipulate the executable and achieve various effects. As far as I
remember no other game before had clustered such a large and active community
around it? (which is not to say that no other great and amazing games existed
before, so many gems lie in the past!)

And then there was the networked play. I spent an afternoon with a friend
soldering a cable to play 'null-modem', and we got it working around ~6pm. At
5am the next day we were still playing, me on a luxurious 486 DX2-66, my
friend in a tiny window on a 386 DX-33Mhz, both with red eyes. This was an
experience like quite no other at the time.

The gameplay was simplistic but huge fun. The immersion was intense. The tech
was stellar. But I am obviously biased by nostalgia ;)

~~~
Baeocystin
I was in college at UCSD when the 14-Mb shareware DOOM was released. I finally
found it (after frantic searching) on a public FTP server somewhere in
Australia. I started the download, then went to dinner. After eating, I came
back to both the completed file and a salty email from the Aussie sysadmin
admonishing me for saturating their connection. The next few days (and my GPA
for that quarter) were a bit of a blur. Good times. :D

------
tyingq
Interesting, so it's somewhat like the original pong chip or the AY-3-8500. No
OS, just inputs drive video output.

[http://www.pong-story.com/gi.htm](http://www.pong-story.com/gi.htm)

[http://www.pong-story.com/gi8500.htm](http://www.pong-story.com/gi8500.htm)

~~~
amelius
Next: analog implementation of Doom?

~~~
djmips
Not a finished one but this concept is cool. Doom on a Vectrex.
[https://www.youtube.com/watch?v=VuVnoqFF3II](https://www.youtube.com/watch?v=VuVnoqFF3II)

~~~
MrBuddyCasino
Sprite_tm! His hacks are always tasteful.

------
tenebrisalietum
This contributes to the timelessness of Doom.

Doom pretty much has been ported to everything with a CPU, like Linux. Heck,
you can even search for JSDoom and get a few results. There's even a RISC-V
port (RISC-V emulator included:
[https://github.com/lcq2/risc-666](https://github.com/lcq2/risc-666))

It will be interesting if it progresses past simply drawing the level, e.g. if
you can actually play it.

Then Doom won't even need a CPU to exist.

~~~
anthk
Meh. I can play Minizork and Curses (version 3) on a:

\- Monochrome GameBoy and compatibles.

\- PDAs, nearly all of them.

\- That intelligent pen which parsed everything you wrote.

\- KA10 with Tops20 with dfrotz.

\- GBA/NDS/PSP/Android/ioS... anything portable.

\- Everything SIMH emulates, or nearly everything.

\- All of the 8/16/32 bit minicomputers.

\- Any OS with a gopher client. Even Nethack/Telnet may work with a dumb
wrapper.

\- A PostScript printer with a crafted input.

\- Over telnet/ssh/irc... name a text protocol and you will be able to play
it.

------
k__
How much more efficient is this than running it in software?

I'm asking, because if this thing can render magnitudes bigger/more detailed
worlds than a PC and it's basically copy protected because it's "in hardware"
this should be the wet dream of the industry.

~~~
floppy123
Much more efficient (some 0.x watts) and faster - but not very easy to develop
and even harder to deploy :)

and you will get in trouble with the amount of code(needed gates) for porting
nowerdays doom

~~~
floppy123
No it will not outperform your GPU for rendering, that is already a
specialized hardware

~~~
TheSoftwareGuy
It’s specialized for a very general problem though. If he made his own
graphics logic in there too he could maybe make it faster too

~~~
floppy123
The available fpga hardware is just not able to compete with the sheer
hardware power (ghz,ram,gates) of a todays gpu - but i would agree on smaller
problems

~~~
charlesdaniels
FPGAs _can_ achieve very compelling performance when programmed properly, but
usually not for compute bound workloads. Most interesting problems are memory
bound these days, and that's where FPGAs shine, since you can design your
hardware to be as wide as your problem. Or alternatively if you have many
parallel sub-problems, you can make your hardware as narrow as the sub-
problems and replicate it many times.

You can usually move data on and off chip very quickly also, since high end
modern FPGAs have many hundreds of pins. Generally these get connected in to
hard-logic like fiber networking or PCIe.

An FPGA soft core is never going to beat an ASIC if both were designed well.
But they can beat general purpose ASICs (e.g. GPUs) for certain classes of
problems, mostly those where you can exploit the massive memory bandwidth of
the FPGA.

I think that for rendering computer graphics, you really just want a big fat
pile of FPUs. FPGAs will usually have a number of hard logic DSP blocks on-
die, but nowhere near as many as a GPU. If rendering 3D graphics is the
problem you want to solve, you probably really want a GPU.

------
aortega
Nice work. However, a state machine "state" could be seen as an instruction
counter.

~~~
sylefeb
Author here - Thanks! You are absolutely correct there are several state
machines (vga, sdram controler, framebuffer, texturing, divider, renderer,
etc) and each with an active state index. The renderer is the biggest one with
69 states.

I agree the state index can be seen as an instruction counter, albeit into
very specialized instructions: there are no two same instructions in a given
module, each is uniquely implementing a precise subpart of the algorithm. Also
the states decide the flow and select the next state, there is no list of
instructions you could program or re-arrange. So I wanted to capture this idea
that the algorithm is completely embedded into the circuit itself, which is
not capable of doing anything else.

There is definitely a very interesting trade-off between a general instruction
set and an extremely specialized state machine like here - combining both
seems promising?

~~~
floppy123
Question is: How far will you go, fully playable level?

~~~
sylefeb
Unsure, I definitely would like to have fully working environments that can be
explored interactively (with proper BSP collisions, doors/lifts, blinking
lights etc). Everything is stored in BRAM, unsure the sprites would fit (maybe
a few, or at lower res, but I did not look into that yet). When this gets
released I hope this will also be reused/expanded.

My initial objective was more about creating some non-trivial hardware using
the language I am working on, as well as learning how to implement and
optimize algorithms in the context of FPGA. Due to my background in graphics /
game programming, revisiting the Doom renderer was a perfect test case! Now
that I have this first prototype I want to optimize and fine tune it some
more, before adding too many features -- especially as this is meant to serve
as a tutorial/example for the language.

------
causality0
Until it takes control input it's more of an electronic sculpture resembling
Doom.

~~~
sylefeb
True - I only (partially) re-implemented the render loop, and this is far from
the complete game. A game is always much more that its core technical
components.

Adding a keyboard/joystick input is high on my todo. In terms of moving around
this really should be just a question of wiring it to the board: the renderer
takes a generic x,y,z + angle viewpoint as did the original engine. However,
this also means checking for collisions with the BSP scene which is fun to
implement (a nice trick in a BSP is to shift the line equations and check with
a point as opposed to checking with a disc of some radius).

Side note: I instrumented chocolate-doom (fantastic port) to output the path
shown in the video. Initially I was loading a demo lump, but I realized that
these are only the inputs and could not easily reproduce the exact way the
game answers them (for example, progressive acceleration and of course
collisions).

Next up on my list are correct blinking lights, working doors/lifts and
sprites (things + enemies). But I also want to optimize it, and to release the
language I used to make this. So quite a huge todo; we'll see how it goes. In
any case all of that will be made available so everyone can join the fun!

~~~
mng2
Great stuff, cool project. Could you share a few thoughts on your language and
transpilation approach?

~~~
sylefeb
Happy to - but in full this will be better explained on release on the github
README, with code examples.

Also, I am no language expert, and not an FPGA expert either (I have been
learning for ~ 1 year). I shape this for my own use, hopping it will be useful
for others, but I wouldn't pretend nor expect to be achieving something
particularly new or interesting at large. Nevertheless, I am using it to build
increasingly more complex hardware, the doom-chip being the most advanced so
far. Every time the language is extended and fine tuned, so it is rooted in
practice.

=> The following is an excerpt from the being-written documentation
introduction:

My goal is to make it possible to write algorithms for FPGAs in the same way
we write them for processors: defining sequences of operations, subroutines
that can be called, and using control flow statements such as while/break. At
the same time, the language remains low level. Everything an algorithm does is
precisely timed, you can fully exploit the parallelism and niceties of FPGA
architectures, clock domains are exposed.

My approach is reminiscent of high performance programming in the late 90s (in
the demo scene in particular): the then considered high-level C language was
commonly interfaced with time-critical ASM routines. This enabled a best-of-
both-worlds situation, with C being used for the overall program flow and ASM
used only on carefully optimized hardware dependent routines.

The language aims to do the same, providing a thin programmer friendly layer
on top of Verilog, while allowing to call low level Verilog modules whenever
needed. It favors and exposes parallelism, so as to fully utilize the FPGA
architecture.

The main design principles are: \- Prioritize combinational over sequential
execution. Parallelism comes first! \- Clearly defined rules regarding clock
cycle consumption. \- Explicit clock domains and reset signals. \- Inter-
operates easily with Verilog, allowing to import and reuse existing modules.
\- Familiar C-like syntax (but this is not C! different constructs for
parallelism, pipelining, etc.). \- Powerful LUA-based pre-processor.

~~~
retro_guy
Hmm… I wonder what would it take to create an FPGA hardware version of the
PICO-8 fantasy console…

Baremetal projects are truly fascinating -- I cannot wait to read your
documentation. There's also a hardware Z-Machine:
[https://hackaday.com/2014/11/29/the-zork-virtual-machine-
imp...](https://hackaday.com/2014/11/29/the-zork-virtual-machine-implemented-
in-hardware/)

And this dev is working on FPGA Another World:
[https://github.com/felipesanches/AnotherWorld_FPGA](https://github.com/felipesanches/AnotherWorld_FPGA)

------
artiscode
Amazing project! Next step: custom silicon ASIC, the Doom arcade machine

------
phkahler
I'd like to talk to you about ray tracing. Have an algo that would be
incredibly fast in hardware. I think I may have tried integer math at one
time.

~~~
Keyframe
What is old is new again:
[https://www.businesswire.com/news/home/20050614005701/en/ART...](https://www.businesswire.com/news/home/20050614005701/en/ART-
VPS-releases-64-bit-RenderDrive-48-Ray-Tracing)

~~~
phkahler
>> The AR350 ray-tracing chips process 66 million ray-triangle intersections
per second per core.

I was doing 1.5 million Ray's per second against scenes with 100,000 polygons
back then on an AMD64.

Acceleration structures are everything. Traversing them quickly and having
dynamic updates is hard.

------
Vekz
This is the future of hardware. Specialized chips baked for a focused
application.

~~~
WatchDog
The future sure sounds a lot like the past, given that everything, even
toasters have CPU's in them these days.

~~~
duskwuff
Toasters are moving back to ASICs too:

[https://www.diodes.com/assets/Datasheets/PT8A2514A.pdf](https://www.diodes.com/assets/Datasheets/PT8A2514A.pdf)

~~~
DonHopkins
You could make toasters by recycling used MacBook Pros!

------
Koshkin
This feels like a breath of fresh air: too many FPGA applications today resort
to implementing a simple CPUs (a.k.a. PSM - “programmable state machine”), and
the required logic is implemented in its “machine code.”

~~~
monocasa
I think you'd be surprised how many classic hardware designs take that
approach as well. There's nothing wrong with that approach.

------
vmception
even with OpenCL I find FPGA's extremely complicated to program on

it doesn't help that Intel is charging $5,000 licenses to compile on them, for
some things

------
anthk
So, like the old 'Brick Game' ensembling a Tetris machine.

BTW, on portability, the Z-Machine has been ported even to "intelligent" pens.
There is even a GameBoy, Amiga, Atari and C64 port.

Sorry Doom lovers, but your knowledge on portability is really low. The
Z-Machine and the zillion of Infocom games/ homebrew can be run nearly
everywhere. No display? Hook up a printer/serial device.

Have a wifi/internet client? Write a dumb gopher client, set up a dumb server
on a VPS/Rpi. You could set a Z-machine playing bot to even be able to play it
via IRC.

Also, with a custom dfrotz and a FIFO file you may be able even play it over
morse with some software which decodes the morse input from radio and sends
the commands to the interpreter, sending the game output back.

