4 ms·
Fun stuff, it always amazes me that people are surprised. Not having lived through it is a part of that I'm sure. The RP2040 is more powerful than an 80286. Th
by ChuckMcM 5y ago
Fun stuff, it always amazes me that people are surprised. Not having lived through it is a part of that I'm sure.
The RP2040 is more powerful than an 80286. The PC/AT which was hugely more powerful than the original IBM PC (on which DOOM also ran). Put a keyboard, mouse, and an frame buffer on an STM32F4 or F7 and you've got the computational and capability equivalent of the PC's that powered the world in 1985. People did accounting, CAD, spreadsheets, email, all sorts of things on them. Amazing I know, but here we are.
- vbezhenar 5y agoI thought about building toy pc with rp2040 but I wasn’t able to solve gpu problem. Driving display seems very hard task without some dedicated hardware. And using serial output is not fun.
- II2II 5y agoThere are a lot of options on this front. As far as I can tell, most displays for embedded platforms are sold as modules that you interface with via a serial or parallel bus. There are libraries out there to handle the grunt work, if you don't want to dig through data sheets yourself. If you want something that doesn't use any dedicated hardware, interfacing with analog displays (e.g. NTSC/PAL/VGA) can be done with a handful of resistors on GPIO pins. Conceptually, it is easier but actually dealing with timing is a pain. Again, libraries that deal with the grunt work are available.
- ChuckMcM 5y agoSo, FWIW, I've been playing around with this. I've got an FPGA board that has an HDMI output[1]. I have a simple 1280 x 720 frame buffer running on it (read the DRAM, display it on the monitor. I'm building a carrier board to connect it to an STM32F429 Nucleo-144 board using the ST Micros flexible memory controller (FMC) peripheral. This will present the frame buffer contents to the STM32 as memory. Additionally, some "control registers" are being implemented in the FPGA that can do certain actions. At a minimum they are "clear to one color", "copy region", "scroll region", and "copy glyph". The STM32 has the DMA2 peripheral that does a lot of cool bitblt type functions but these can be nominally slowed down by not synchronizing with the FPGA's schedule for displaying things. The STM32 is running micropython. The "plan", such as it is, is to let the REPL run using the display as its terminal, and a "graphics mode" to reserve parts of the screen for graphics. The small goal is to re-create sort of the VIC-20/C64/ZX Spectrum kind of "vibe" (interpreted language easy access to the graphics) and then build from there. Clearly the basic frame buffer is like 20% of the FPGA so there is lots of room to do other stuff in there. [1] https://www.kickstarter.com/projects/1812459948/minispartan6-a-powerful-fpga-board-and-easy-to-use https://www.kickstarter.com/projects/1812459948/minispartan6...
- vbezhenar 5y agoThanks, this sounds awesome and interesting topic for learning in the future.
- niutech 5y agoYou can use ESP32 for a toy PC, check out FabGL.
- klelatti 5y agoIsn’t it a __lot__ more powerful than a 286? 32 bit dual core at 133 MHz - roughly a Pentium say? Plus some of the early 8 bit machines drove a display with minimal extra hardware - eg the ZX80 / ZX81 although it was very very slow as a result!
- ChuckMcM 5y agoIn terms of instructions per clock and I/O bandwidth it compares more favorably to 16 bit architectures than 32 bit ones even though the Cortex-M family is nominally 32 bits.
- klelatti 5y agoI think memory bandwidth is key and I don’t know how the RP2040 stacks up but even 486 wasn’t superscalar and maxed out at 66MHz by comparison.
- happycube 5y agoRP2040 is designed to provide full bandwidth to both cores at once without bandwidth contention. Combined with the PIO's you can do some really impressive bitbanging.
- klelatti 5y agoThanks - that’s good to know. Must be into at least 486 territory then - with the exception of floating point.
- bombcar 5y agoDoom required a 386 (and really wanted a 486) iirc. Wolfenstein worked on 286.
- mobilio 5y agoAnd require 4MB ram... since i have machine with 2MB i wasn't able to enjoy it. But i found DOS4GW command line option to "emulate" ram with swap file on DOS. I make virtual memory like 4MB and run game. It took 15 minutes to start game and show main menu, another 5 mins to navigate on menu and 15 to run game. Frame rate was some like frame PER minute.
- _joel 5y agoSure, but it's not about the speed of the hardware but what was done to port it to the hardware. RAM and ROM would be larger then. It has 256KB, I remember 286's having well over 1MB, 386's even more! I don't think PC/AT was sub $1 either :)
- JohnBooty 5y agoSome good discussion here, but you've got Doom's original system requirements wrong. It required a 386 with 4MB of RAM. It would not run on a 286, much less the original 4.77mhz IBM PC. source: https://www.mobygames.com/game/dos/doom/techinfo https://www.mobygames.com/game/dos/doom/techinfo IIRC, Doom was very playable, but not exactly smooth on my cheap 386SX which was... 20mhz? But it ran like butter on the 66MHZ 486's in the school's computer lab.
- varajelle 5y agoThe computation power was not so much the issue for this port. The challenge was to make it work with much less RAM and storage available.
- pflanze 5y agoYes, they are solving the storage and RAM challenges partially by throwing CPU at it: not using native pointers, switching between multiple struct sizes where the original had one, compressed integer values, etc., also they restructured drawing to happen in slices as the beam travels, which must have its costs. Also I wonder whether original Doom relied on some GPU hardware, whereas here everything happens in software. RP2040 doom also has to emulate the sound hardware, and handle lots of interrupts to initialize the DMA for each individual video scanline. OTOH they are actually overclocking the RP2040 at 270Mhz.
- mkl 5y agoThe original Doom was all software. GPUs weren't a thing for mainstream PCs at that point.