Alternate Title: "Booting DOS on something I built myself!"
Of all of the modular CPU boards, this is probably the one I'm most excited to have built - it's able to boot DOS (on a "real" processor, unlike Modular CPU Platform - Update 1 !
(the 8086 board has a few functional issues related to the level shifters, so that one isn't able to boot dos with a "real" 8086, although it can boot DOS very slowly with the MCL86 Verilog core on the FPGA).
It's based around an Intel 80486GX processor, which is a 3.3V, 16-bit bus version of the 486 typically used for embedded or low power applications.
Again, I used my On-FPGA Logic Analyser a lot during this project.
Gateware
The FPGA image is very similar to the 8086 build, but with a slightly different bus bridge between Wishbone and the 486GX.
At the moment, the design is functional, but there's a lot of room for optimisation:
- RAM accesses are extremely slow, around 15x slower than the original IBM PC.
- The FPGA has ~234kB of block RAM. I'm using 192kB of this to provide a "fast RAM" from address 0
- The remaining (640kB - 192kB) RAM is implemented via an 8MB QuadSPI RAM, but running in single SPI mode at the moment
- Moving this to QuadSPI should help access times quite a lot
- Additionally, my QuadSPI RAM controller doesn't support burst reads
- The 486 Cache is not enabled
- Enabling the Cache on the 486 is non-trivial, as it requires the address decode logic to selectively ignore LSBs during a cachable access
- The 486 is running slightly (~25.2MHz) slower than its maximum speed (33MHz)
- To minimise the CDC work, all of the design is currently running from the HDMI Pixel Clock (25.2MHz).
- The on-chip Wishbone busses are all 8 bit data
- The peripherals I'd already developed for the 8086 used an 8-bit bus, so to avoid too many changes at once, I reused them here
Of the above list, I think enabling the Cache seems the most likely to produce a visible improvement, so that's what I'd like to try first.
Software
The bridge between the 486GX and the STM32 (used for accessing the SD card and sending keyboard events) is more-or-less the same as was used for the initial 8086 tests.
The INT13 handler in the BIOS has been modified to copy the registers into a small dualport RAM and then assert the 486's STOPCLK signal.
Although I don't actually stop the clock, it's a useful way of allowing the 486 to finish whatever bus transaction it was doing and then block it from generating any more, without generating the Hi-Z nets that the other bus control signals (HOLD / BOFF) would generate.
Once I've seen the "Stop Grant" signal from the 486, I then mux over the wishbone bus to allow the STM32 to write the disk sector directly into RAM (using the target address that the 486 copied into the dualport RAM to know where to copy), copy the status back into the dualport RAM, and deassert STOPCLK.
I initially looked at adding a 512 byte Dualport RAM to the design and copying the data into that.
That approach might be more suitable if I was running a multi-tasking OS on the 486, as then it would be able to use the processor time more efficiently while waiting for the disk read, but for the moment the STOPCLK based design works OK.
Keyboard data is sent from the STM32 into an 8-bit register, which also generates an IRQ every time it is written.
Challenges
Initially, I was leaving the "RESET" pin of the 486GX low and asserting the "SRESET" pin, which seemed like it should work according to the datasheet, but occasionally produced some very strange results after startup.
A small bodgewire mod to connect a spare FPGA pin that was already on a testpoint to the RESET pin seemed to improve the reset issues a lot.
Status
The board is able to boot FreeDOS 1.3, MS-DOS 6.22 and DR-DOS 7, although I've not yet run many applications with it (QBASIC works though).
HWINFO16 locks up on startup, although I've not yet had much time to debug why.
I'd also like to slightly modify the STM32 handler, to allow redirecting disk read/writes to a host PC instead of reading from the SD card (which would make iterating through different disk images much quicker).
Design files: