The WeeCee – Tiny Vortex86-Based DOS Gaming PC
vogons.org
vogons.org
I was left wondering about the complexity of implementing a Voodoo 3 or early GeForce class card in a modern FPGA. They've got the logic density, memory bandwidth, and hundreds of hardware MACs. Compared to all the other technical hurdles, I keep thinking the most difficult task is actually getting ahold of the DirectX driver implementation manuals and references.
A $200 Xilinx part has 700 25x18 hardware MAC units, a couple hundred thousand logic cells, support for about 10 GB/s of memory bandwidth, and hardware PCIe support (use a PCI to PCIe bridge chip, if those are still around).
Things like the Graphics Gremlin and Snark Barker give me hope that some people are out there who'd care.
That and enough people who have the required skills and the desired to implement a graphics card from 20 to 25 years ago for antiquated operating systems.
It's also not going to be cheap, on top of the FPGA you'll want a PCB and support chips. Charging a few hundred dollars for retro hardware replacements is feasible but for now at least actual retro 3D cards can be had for less money.
So an interesting project, but I don't think we've reached the point it's interesting enough for someone to attempt. I think there's far more interest in FPGA replication of full consoles right now (check out the MiSTer project https://github.com/MiSTer-devel). There's lots of excitement around the upcoming PSX and Saturn cores for that. I suspect a Voodoo/GeForce replica would be a similar amount of work but far fewer people interested in having it.
I think it should be possible to use cheaper FPGA to make PCIe-host-as-PCI-device bridge to connect it to modern ARM SoC with integrated GPU and make some driver contraption on both sides to make it work. It feels like cheating though.
The idea was to stay open hardware / open software if possible though. Admittedly the xilinx toolchain is very closed source, but the "project x-ray" reverse engineering effort of Series 7 parts is quite far along.
I would expect a 2x slowdown over hardware rasterization, based on NVIDIA's work on such an approach, but this is probably fine if you're just trying to match Voodoo3 performance. And one could imagine bolting a minimal hardware rasterizer on top of Nyuzi to speed things up once the software implementation is working.
Of course, all this is going to be a lot of work, and the much quicker approach would just be to run llvmpipe on top of your favorite open-source CPU core.
[1]: https://github.com/jbush001/NyuziProcessor/
[2]: https://research.nvidia.com/publication/high-performance-sof...
rasteri also did a couple of build videos: Part 1: https://youtu.be/aJEp4ZUG7BI Part 2: https://www.youtube.com/watch?v=2P1E2vjpcRo
Even if you go from the launch date and not the last errata, the i586 architecture is only 28 years old. In today's world of copyright, that's practically an infant.
To be clear of most patents, you generally need at least thirty years, and copyrights are generally more than twice that number.
You will probably require a license from Intel. (Though whether or not they care enough to enforce things is another matter entirely).
But, that ruling is extremely whack as it means nobody but the ISA originator can make an assembler, for example.
That being said, back in the day there was concern about all of that, hence why a Z80 is binary compatible with an 8080, but has different mnemonics. It's all LD this ST that, as opposed to the 8080's MOV.
Surely if you do a (clean-room) implementation of hardware that is interface compatible with existing hardware that is ok? Isn't that how we got the IBM PC Clones?
IBM encouraging developers to target their BIOS and not the hardware, and BIOS clean room designs is where we got the IBM PC clones - but that's still the world of software. (Note: IBM managed to take clones by Eagle Computer and Corona Data Systems off the market because the software wasn't a clean room design).
The IBM PC's pluggable design with already existing standard ports made it easy to build clones, because it wasn't the hardware that was being interfaced with. If you could clone the BIOS and have that speak to your components however you wanted, then you could make an IBM compatible.
If this is the case it means a competitor can use an alternative design that is less efficient at the cost of space/heat but that can result in substantially less competitive product.
From what I recall, the closest thing to an answer I've received in the past is that you can not use the manuals to a modern x86 chip (or other part) to learn the instruction set. The use of any copyrighted material infects you project if the rights holder is particularly egregious about enforcement to that level.
It's the same thing with the IBM PC BIOS reverse engineering. If you'd seen the BIOS manual, you couldn't work on the clone. I can't recall if that was purely seeing it or because the source code to the IBM BIOS was printed in the back of the manual.
I know Intel, Microchip, and ARM have aggressively shut down any FPGA project that implements an instruction-level compatible core of x86, AVR, PIC, or ARM CPU. Intel seemingly hasn't gone after any of the 16-bit x86 core implementation, but I haven't seen an open source 386 or newer core.
Today, apart from Intel and AMD, only VIA has the right to produce x64 CPUs.
I just gave up on looking at them.