11 ms·
The DooM-chip: no CPU, no opcodes, no instruction counter
- tyingq 7y agoInteresting, 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 7y agoNext: analog implementation of Doom?
- goldenkey 7y agoOscilloscope doom? I can dig it. Kinda like I dig this [1] [1] https://www.youtube.com/watch?v=kPUdhm2VE-o https://www.youtube.com/watch?v=kPUdhm2VE-o
- MayeulC 7y agoI like this guy. I thought this was going to be a more introductory video: https://www.youtube.com/watch?v=rtR63-ecUNo https://www.youtube.com/watch?v=rtR63-ecUNo (holy c*, he published a lot of these since 2014, they're pretty good :) ) This has been done with quake: https://www.youtube.com/watch?v=aMli33ornEU https://www.youtube.com/watch?v=aMli33ornEU
- goldenkey 7y agoThat is cool but I think what the OP meant by analog DOOM was actual analog circuits driving a TV PAL/NTSC signal or oscilloscope output.
- djmips 7y agoNot 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 7y agoSprite_tm! His hacks are always tasteful.
- anthk 7y agoThe Vectrex had a 6809...
- mhh__ 7y agoI guess you could synthesize a HDL implementation into discrete logic?
- userbinator 7y agoSome of the ultra-cheap "battery portable handheld games" (https://en.wikipedia.org/wiki/Handheld_electronic_game https://en.wikipedia.org/wiki/Handheld_electronic_game ) which are still produced today may have such ASICs, although I suspect a lot of them are actually a 4 or 8-bit CPU with a mask ROM.
- artiscode 7y agoAmazing project! Next step: custom silicon ASIC, the Doom arcade machine
- aortega 7y agoNice work. However, a state machine "state" could be seen as an instruction counter.
- sylefeb 7y agoAuthor 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 7y agoQuestion is: How far will you go, fully playable level?
- sylefeb 7y agoUnsure, 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.
- tenebrisalietum 7y agoThis 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 7y agoMeh. 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.
- deleted 7y ago[deleted]
- phkahler 7y agoI'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 7y agoWhat is old is new again: https://www.businesswire.com/news/home/20050614005701/en/ART-VPS-releases-64-bit-RenderDrive-48-Ray-Tracing https://www.businesswire.com/news/home/20050614005701/en/ART...
- phkahler 7y ago>> 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 7y agoThis is the future of hardware. Specialized chips baked for a focused application.
- speedgoose 7y agoSo JavaScript processors?
- WatchDog 7y agoThe future sure sounds a lot like the past, given that everything, even toasters have CPU's in them these days.
- corysama 7y agohttp://www.cap-lore.com/Hardware/Wheel.html http://www.cap-lore.com/Hardware/Wheel.html We’re currently rolling around back to a new era of lots of specialized chips.
- daxfohl 7y agoIDK, even in operations the size of the cloud providers, executing some of the same things billions of times a second, there's still very few specialized chips. TPU is an example, and I think they all use some for network packet filtering and such. But you don't see anything for DB acceleration or paxos acceleration or maps acceleration or anything like that. They've had years to figure this out, so if they're not finding it worth it at hypercompetitive cloud scale then I don't see the revolution going too awful far anytime soon.
- monocasa 7y agoAlibaba has been pushing the envelope pretty heavily in this area. I've heard of them using their FPGA instance for memcachedb instances, and video transcoding instances.
- duskwuff 7y agoToasters are moving back to ASICs too: https://www.diodes.com/assets/Datasheets/PT8A2514A.pdf https://www.diodes.com/assets/Datasheets/PT8A2514A.pdf
- nabla9 7y agoI 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.
- hiccuphippo 7y agoFunny, I thought the same of Xena back in the 90's. What about Kratos or Spiderman?
- andrewflnr 7y agoSpiderman is another decent bet. He obviously has some long-term staying power.
- kick 7y agoWhy? 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?
- anthk 7y agoMost games except adventures and text adventures have a worse script (lit wise) than any average episode of X-Files/The Outer Limits and so on. Heck, Half Life looks like a -mediocre- episode of The Outer Limits.
- 2OEH8eoCRo0 7y agoThe more I've aged the more I've realized this. Most video games are horribly written and unbelievably cheesy without trying to be. The beauty of a game like Doom is that it knows it- it doesn't try to be anything profound.
- anthk 7y agoSo, 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.
- Koshkin 7y agoThis 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 7y agoI think you'd be surprised how many classic hardware designs take that approach as well. There's nothing wrong with that approach.
- AnotherGoodName 7y agoThere'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-the-devices-that-can-somehow-run-doom https://www.vice.com/en_us/article/qkjv9x/a-catalogue-of-all... Now we have a new answer: IT CAN ONLY RUN DOOM
- MaxBarraclough 7y agoThere is no instruction counter, only DOOM!
- floppy123 7y agoIT IS DOOM
- dorgo 7y agoIs it doom complete?
- m463 7y agofor $39.95
- willis936 7y agoIf only mankind was capable of making a machine that can run crysis.
- k__ 7y agoHow 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 7y agoMuch 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 7y agoNo it will not outperform your GPU for rendering, that is already a specialized hardware
- TheSoftwareGuy 7y agoIt’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 7y agoThe 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 7y agoFPGAs 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.
- vmception 7y agoeven 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
- causality0 7y agoUntil it takes control input it's more of an electronic sculpture resembling Doom.
- sylefeb 7y agoTrue - 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 7y agoGreat stuff, cool project. Could you share a few thoughts on your language and transpilation approach?
- sylefeb 7y agoHappy 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.