[HN Gopher] My DIY FPGA board can run Quake II
       ___________________________________________________________________
        
       My DIY FPGA board can run Quake II
        
       Author : sznio
       Score  : 215 points
       Date   : 2026-03-22 23:06 UTC (3 days ago)
        
 (HTM) web link (blog.mikhe.ch)
 (TXT) w3m dump (blog.mikhe.ch)
        
       | sznio wrote:
       | Demo: https://www.youtube.com/watch?v=sioLAkNQC_I
        
       | argulane wrote:
       | That's some mad dedication to go from kicad schematics to running
       | Quake. Very impressive!
        
       | unethicalinfo wrote:
       | Cool write up, getting initial bill shock from 2 layer to the 4+
       | layer PCBs is a rite of passage :)
        
         | summa_tech wrote:
         | The next step up is HDI. I knew it was (still) expensive, but I
         | did not realize it was a cost multiplier, not adder :-)
        
         | rasz wrote:
         | Went with wrong board house. JLC seems to run 6 layer promo for
         | 2 years now. This board is $36 for 5, $100 gets you 50 pcbs.
        
           | unethicalinfo wrote:
           | When PCBWay stopped accepting PayPal last month I tried JLC
           | and I have to say, their quality was impressive and the price
           | was a little over half the PCBWay quote. Certainly worth
           | shopping around with your gerbers. Might be an interesting
           | write up comparing quality and price from the leading Chinese
           | fab houses for the same board.
        
             | bluescrn wrote:
             | Only done very small 2-layer boards for hobby projects, but
             | it's crazy that you can get custom PCBs made and shipped
             | from China for <PS10
             | 
             | It seemed like it might be coming to an end when PCBWay
             | suddenly had no reasonable payment options, but JLC has
             | been great so far (and I believe PCBWay has credit card
             | payments sorted now?)
             | 
             | (Just wish I had far more free time to spend on hobbies,
             | there's so many possibilities with 3D printing,
             | microcontrollers, and custom PCBs now all so readily
             | available)
        
       | markus_zhang wrote:
       | This is very impressive. How did you learn to design a real
       | computer, not the toy ones a lot of people made? I read part 1
       | and part 2 and looks like you just "thrown in" Ethernet and other
       | stuffs and it was done. Really hope to learn from the process,
       | thanks!
        
       | nacozarina wrote:
       | Quake II had the best fn soundtrack.
        
         | nntwozz wrote:
         | Yes, check out Radioactive Man (from Two Lone Swordsmen) -
         | Trespasser:
         | 
         | https://youtu.be/Zdy9TtInX-c
         | 
         | Lots of Quake II samples.
        
         | npunt wrote:
         | Sonic Mayhem!
        
           | wowczarek wrote:
           | I have the album on my phone. When I get called in to put out
           | a fire and save the day, I like to put on March Of The
           | Stroggs in the car when arriving at the destination. It's a
           | great soundtrack for two reasons - the first one is sweet,
           | wasted youth and the second is it's a great soundtrack.
        
           | skewbone wrote:
           | And Jer Sypult who made Climb (track 10) who is not in Sonic
           | Mayhem!
        
       | xracy wrote:
       | This is really cool and impressive... but relatedly...
       | 
       | Has anyone figured out what the minimum specs for Quake are?
       | 
       | I feel like the first thing everyone does with a computer is to
       | determine whether or not it can run quake, and I'm just wondering
       | what the like, most simple computer that could exist is, that
       | could run quake?
        
         | conception wrote:
         | That's only because everything can run Doom now.
        
         | klodolph wrote:
         | You can find a lot of discussion about what the minimum specs
         | for Quake are. Famously, it needs a decent FPU, and the Pentium
         | was a convenient early CPU with a decent built-in FPU. It was
         | significantly faster than a 486.
         | 
         | ...But people have managed to run Quake on the 486.
         | 
         | And the myth people tell about Quake is that it killed Cyrix,
         | because Quake performance on Cyrix was subpar. But was that
         | true? And if it was true, was that because the Cyrix was slower
         | than a Pentium, or was it because the Quake code had assembly
         | that was hand-optimized for the Pentium FPU pipeline?
         | 
         | Anyway. "Most simple computer that could run Quake" is probably
         | going to include a decent FPU. If you are implementing
         | something on an FPGA, you can probably get somewhere around 200
         | MHz clock anyway. At which point you can run Quake II.
        
           | NooneAtAll3 wrote:
           | can it be rewritten to use fixed point arithmetic instead?
        
             | Narishma wrote:
             | The PS1 doesn't an FPU but got a version of Quake 2, so
             | it's possible. That said, it was somewhat different from
             | the PC version, so it could be argued that it's not the
             | same game.
        
               | klodolph wrote:
               | The PS1 version definitely has its own engine, which is
               | not just a port of the Quake 2 engine to the Playstation,
               | but a new engine.
        
               | jasonwatkinspdx wrote:
               | I can't speak on Quake, but I was a level designer on the
               | failed effort to port Unreal to PSX.
               | 
               | My understanding from talking to the coders at the time
               | was that Unreal's software renderer was a huge advantage
               | as a starting point. They were able to reuse a lot of the
               | portal rendering stuff as setup on the R3K cpu, but none
               | of the rasterization. That had to go to the graphics
               | core, which was a post setup 2D engine that in addition
               | to the usual sprites, could do tris and quads.
               | 
               | We had a budget of about 3k polygons post clipping, and
               | having two enemies on screen would burn about half of
               | that. The other huge limit is the texture cache was tiny,
               | so we couldn't do lightmaps. Our lightning was baked in
               | at vertex level and it just was what it was.
               | 
               | There's a bit more info here:
               | https://www.terrygreer.com/unrealpsx.html
               | 
               | I imagine the situation with Quake was comparable. The
               | BSP stuff would carry right over, but I can't imagine
               | they got lightmapping proper working at the time. They'd
               | also need some sort of solution for overdraw, as Quake's
               | PVS was a lot more loose than Unreal's portal clipping.
        
               | ndepoel wrote:
               | The PS1 version uses a custom engine based on technology
               | built for the game Shadow Master, the previous title by
               | Hammerhead Studios. It was a technical tour de force for
               | the original PlayStation.
        
             | klodolph wrote:
             | I want to look at this from a different perspective... a
             | single-precision floating-point multiply is pretty simple,
             | no? 24x24 bit multiply, which is about half as many gates
             | as a 32x32 bit multiply.
             | 
             | Maybe I would prefer to rip out the integer multiplication
             | unit first, before ripping out the FPU.
        
             | rasz wrote:
             | Sure, but then you need CPU that is twice as fast :).
             | Playstation did it by pushing geometry calculations to GTE.
        
             | ndepoel wrote:
             | Yes but also no. The problem with fixed point arithmetic is
             | a lack of dynamic range compared to floating point. Floats
             | are great at representing both large numbers with limited
             | precision and small numbers with high precision, but with
             | fixed point you have to make a choice based on which kind
             | of number you're trying to represent. Meaning you need to
             | use a mixture of 8.24, 16.16 and 24.8 fixed point types
             | (and appropriate conversions) depending on the context of
             | the calculations that you're doing.
             | 
             | It's possible to write a game engine with that limitation,
             | but there's no easy natural conversion from Quake's
             | judicious use of floats to a fully fixed-point codebase.
             | You'd have to redesign and rewrite the entire engine from
             | scratch, basically.
        
           | polpo wrote:
           | I had a Cyrix 6x86 when Quake first came out. My
           | disappointment at how poorly Quake ran on it was significant,
           | especially because pretty much every other game at the time
           | ran well on the Cyrix. The FPU performance in Quake was
           | doubly handicapped on the Cyrix: not only was its FPU slower
           | than the Pentium's to begin with, Quake's code was indeed
           | hand-optimized for the Pentium's FPU pipeline. Fabien
           | Sanglard's writeup of Michael Abrash's optimizations for
           | Quake goes into great detail:
           | https://fabiensanglard.net/quake_asm_optimizations/
        
           | jasonwatkinspdx wrote:
           | My perspective from being a teen doing lan party stuff at the
           | time: Quake ran slow on them, but it was far from the only
           | thing that ran slow. Cyrix was well understood to be the
           | value brand for general office apps and such, but not up to
           | it for more demanding computing, and for having random
           | compatibility issues here and there.
           | 
           | Ultimately what killed Cyrix is they just couldn't offer
           | enough of a discount vs intel to matter, especially with all
           | the lock in stuff intel was doing with Dell, Gateway, etc.
           | 
           | Intel Inside was a successful marketing campaign as well. If
           | you were around back then I bet you can imagine the
           | jingle/chord immediately.
        
           | AbanoubRodolf wrote:
           | The Cyrix story is actually well-documented. Quake's software
           | renderer used hand-optimized x86 assembly with FPU
           | instruction sequences specifically tuned for the Pentium's
           | pipeline. Cyrix processors had a different FPU execution
           | pipeline that stalled on those specific instruction orderings
           | -- the issue wasn't raw FPU performance, it was that the
           | Pentium-optimized code ran slower on Cyrix than
           | straightforward C code would have. It was hand-optimization
           | that made things worse, not better, on a competitor's
           | hardware.
           | 
           | The timing was brutal for Cyrix. This was right when "Intel
           | Inside" was becoming a meaningful consumer brand signal, and
           | game benchmarks were becoming the primary way consumers
           | evaluated CPU purchases. Quake wasn't just a game, it was the
           | benchmark everyone ran at CompUSA to compare machines. Being
           | demonstrably worse at Quake, regardless of the cause, was a
           | marketing catastrophe.
           | 
           | The real floor for running Quake is basically "does it have a
           | hardware FPU." The 486 DX (with FPU) could do it at low
           | resolution and low framerate. The 486 SX (no FPU, software
           | float emulation) was genuinely painful. The Pentium was the
           | first CPU where it actually felt good.
        
             | 6581 wrote:
             | > Don't post generated comments or AI-edited comments. HN
             | is for conversation between humans.
             | 
             | https://news.ycombinator.com/newsguidelines.html
             | 
             | Your entire comment history seems to be AI generated.
        
           | Foobar8568 wrote:
           | Quake ran like shit on 486dx33, a few fps at best.
        
         | apgwoz wrote:
         | I played Quake on a 486 66Mhz DX2 with 16MB of RAM in the 90s.
         | On the lowest resolution, but it was fine.
        
           | Foobar8568 wrote:
           | I had a 486dx33 and it was unplayable, a few frames per
           | second...
        
             | apgwoz wrote:
             | I honestly don't remember what the frame rate was, but it
             | definitely improved when I upgraded to a Pentium 100. I
             | distinctly remember a buddy giving me some RAM (2x4MB)
             | which allowed me to play on the 486. I was so happy!
             | 
             | The DX2s _were_ a significant improvement over the 486DX,
             | but I'll admit, I might be remembering the excitement of
             | getting to play Quake at all! The framerate may have been
             | 15-20 fps and I just dealt with it,
             | 
             | The minimum requirements, on the box, were apparently
             | Pentium 75Mhz. 8MB (DOS), or 16 RAM (WIN95).
        
               | rasz wrote:
               | Quake DX2 framerate is 5-7 depending on rest of the
               | setup.
        
         | justsomehnguy wrote:
         | As other had said: the only 'deal breaker' here is FPU.
         | 
         | Q1 is _playable_ but not on any modern understanding of that
         | word on a system with Am486DX4 /100 with 16MB RAM and S3
         | Trio64V+. You can disable sound effects for a couple FPS more.
         | 
         | Mostly you would be fine because the level design in Q1 heavily
         | tends to the closed spaces and corridors with only a glimpses
         | of the outside and a rare halls and caverns. That being said
         | the Necropolis would be a test of strategic thinking for turn-
         | based FPS and Ziggurat Vertigo is unplayable.
        
       | UncleOxidant wrote:
       | Cool! Have you considered offering this board on Crowd Supply or
       | similar? There don't seem to be many boards available for Efinix
       | FPGAs.
        
       | klodolph wrote:
       | The diagonal traces and the empty spaces are throwing me for a
       | loop. Is this the autorouter in action? (But... still, nice
       | work.)
        
         | codebje wrote:
         | DDR3 traces need to be length matched, because at 800MHz (the
         | slowest "standard" rate, though I think you can drop to 666MHz
         | safely) the value on the pins is changing every 1.25ns, and
         | having traces of different lengths means you probably won't see
         | the right values on all the pins at the same moment. Length
         | matching produces the squiggles.
         | 
         | The diagonal orientation of the DDR3 chip and corresponding
         | diagonal traces I suspect is a choice made by the author to
         | ease the layout process - it's more likely that is hand laid
         | out to get traces of somewhat similar length with a minimum of
         | fuss, followed by a length matching tool. A non-standard
         | orientation can cause issues with pick-and-place machinery,
         | which usually will handle 90 degrees fine, and _often_ 45
         | degrees fine, but (AFAIK) _rarely_ anything else, but that's
         | not a problem for the author because he's assembling it
         | himself. A diagonal IC also usually results in wasted space,
         | which you can see in the empty areas of the resulting board. A
         | 90 degree orientation may have allowed for a few more
         | decoupling capacitor banks, but since his board works, who am I
         | to sit here and judge?
        
           | imtringued wrote:
           | > A non-standard orientation can cause issues with pick-and-
           | place machinery, which usually will handle 90 degrees fine,
           | and _often_ 45 degrees fine
           | 
           | This sounds like nonsense. Pick and place machines don't pick
           | up components perfectly deterministically. There is always a
           | tilt and an offset when you are picking the part up, which is
           | why a computer vision system has to account for part
           | orientation and the center of the part. The machine must
           | compensate the error by moving and rotating the part
           | accordingly.
        
           | whiskers wrote:
           | Pick and place machines can place components very precisely
           | at any angle - they really don't care!
        
           | ptmikheev wrote:
           | Yes, I had to place the DDR3 chip diagonally to simplify
           | routing. Otherwise the length difference on address lanes was
           | so big that I couldn't compensate it with serpentines.
           | 
           | I didn't use autorouter: I haven't found any reasonable
           | working KiCad plugin for it, and didn't want to buy and
           | commercial software for a hobby project.
           | 
           | (I am the author)
        
       | bee_rider wrote:
       | Quake 2 was the one with the clever approximate inverse square
       | root code, right? I wonder (especially since there's an
       | instruction nowadays to draw inspiration from), can you implement
       | it "in hardware," so to speak?
        
         | BoredPositron wrote:
         | No that was Q3 Arena.
        
         | shakna wrote:
         | In x86 that would be the SIMD rsqrtps [0]. So absolutely
         | possible to do at the hardware level.
         | 
         | [0] https://www.felixcloutier.com/x86/rsqrtps
        
       | wowczarek wrote:
       | Good to see I'm not the only weirdo still using Midnight
       | Commander.
        
         | Fr0styMatt88 wrote:
         | hahaha earlier today I needed to move some files on my server.
         | 
         | Used Midnight Commander within an SSH client.... on my iPhone
         | lol
         | 
         | Being able to click in Midnight Commander makes this
         | surprisingly usable for quick jobs!
        
         | justsomehnguy wrote:
         | Why would you be a weirdo? Two-panel is the only somewhat sane
         | way to navigate the file system, though I still try to Ctrl+\
         | and need to remember to Alt+S and only then to type the search
         | pattern.
        
           | wowczarek wrote:
           | It's just that I see so many people today with those new
           | fangled, asynchronous, rusty thingummywuts full of unicode
           | and sixels and kitties and whatnot that sometimes I wonder,
           | but an orthodox FM is the only life I understand and my
           | neural pathways for NC + MC key shortcuts run deep. I'm also
           | a diehard mcedit user and I refuse to vi* unless forced, so
           | that might be the weird bit. It's all good.
        
       | phendrenad2 wrote:
       | Hey, routing your own length-matched traces, nice. Is this
       | Altium?
        
         | Joel_Mckay wrote:
         | Even modern Kicad does auto length matched tracks now.
         | 
         | But I'm lazy, and just used the Zynq 7020 (Dual ARM A9 + FPGA)
         | MYIR Z-turn Board V2 for hobbies.
         | 
         | Best regards, =3
        
         | ptmikheev wrote:
         | It is KiCad. No autorouting. I only used the "tune length"
         | tools for adding serpentine traces.
        
       | tkapin wrote:
       | Very impressive project!
        
       | absynth wrote:
       | Another board has become Frag complete. Important milestone!
        
       | wadewatts wrote:
       | Section 6 where you link to Quake II is 404. (at the time of this
       | post)
       | 
       | URL: https://blog.mikhe.ch/quake2-on-fpga/part6.md
       | 
       | 404 File not found
       | 
       | The site configured at this address does not contain the
       | requested file.
       | 
       | If this is your site, make sure that the filename case matches
       | the URL as well as any file permissions. For root URLs (like
       | http://example.com/) you must provide an index.html file.
       | 
       | Read the full documentation for more information about using
       | GitHub Pages.
        
         | ordu wrote:
         | Parts 5 and 6 are 404. At the end of the article there are
         | words:
         | 
         | "More pictures in the next part.
         | 
         | Next part: coming soon"
         | 
         | I suppose the link came to HN a bit too early.
        
         | sznio wrote:
         | yeah, not the author here.
         | 
         | I found the project on YouTube[1] and wanted to share it - but
         | decided to find something that's text for HN, and in the rush
         | to post I failed to check if the post is even complete. I
         | should've posted the video instead.
         | 
         | [1]: https://youtu.be/sioLAkNQC_I
        
         | ptmikheev wrote:
         | It is because I haven't written it yet. I wanted to finish it
         | first, and post to Hacker News next week, but sznio did it
         | earlier :)
        
       | rasz wrote:
       | I find first version https://github.com/petrmikheev/endeavour
       | much more impressive. Dude somehow managed to get 100MHz DDR1 ram
       | working on 2 layer board with no ground reference :o Its one of
       | those things you only attempt when crazy or dont know any better.
       | Anyone with EE experience will tell you its impossible, like
       | flying commercial grade SoCs in satellites :) Mad lad.
        
         | joe_mamba wrote:
         | Signal integrity is a myth propagated by big-PCB.
        
         | chromacity wrote:
         | I can't imagine why a 100 MHz digital signal at 2.5 V would be
         | even particularly challenging on a small two-layer PCB. A lot
         | of signal integrity lore has to do with passing EMI compliance
         | (this almost certainly wouldn't), as well as with people
         | extrapolating from Rick Hartley videos without pausing to think
         | if it really applies to hobby stuff.
        
       | brcmthrowaway wrote:
       | With Claude, a software engineer can now be a hardware engineer.
        
         | 15155 wrote:
         | Let's see Claude's buck converter layout, BGA fanout, and
         | routing.
        
       | JoachimS wrote:
       | Very impressive, and I'm sure satisfying. Kudos!
        
       | ge96 wrote:
       | What's the deal with the diagonal squigglys
        
         | msk-lywenn wrote:
         | As I understand it, it's for all signals to cross over in the
         | same amount of time.
        
         | buckle8017 wrote:
         | They match the length of all the wires.
         | 
         | That way they all have the same delay properties.
        
       | Liftyee wrote:
       | Willing to solder BGA, but not willing to use 0402 components
       | while using the stencil anyways?
       | 
       | Nonetheless, impressive project!
        
       ___________________________________________________________________
       (page generated 2026-03-26 23:01 UTC)