• Please review our updated Terms and Rules here

Modern XT compatible PC on FPGA with real 8088

newold86

Experienced Member
Joined
Dec 7, 2014
Messages
72
Hi everyone !

At spare time I'm trying to create something VERY compatible with PC XT. The design is using modern FPGA (currently Altera Cyclone IV on DE2-115 development board, but it doesn't really matter) with real 8088, 8284 and 8288 chips.

At the moment I have almost 100% CGA-compatible video adapter (on register level) with output to VGA monitor (using 640x400 mode - every CGA pixel takes 2x2 of VGA pixels), so I'm using original XT BIOS almost for everything, except FDD and HDD.

I'm using my own int 13h BIOS handler to emulate HDD on SD card, and everything is working quite well. Tried more than 20 old classic games, they work quite well (including MS Flight Simulator and Lotus 1-2-3 that were used as a compatibility test for early IBM-compatible PCs).

Actually, I have one related question - does anyone aware of something like virtual FDD for DOS ? I wasn't planning to emulate FDD for now, but discovered that a lot of old software does exist on FDD images only and would not run from HDD. Quick search did not find anything for DOS - for Windows only... I can try to make my own emulator, but right now have too many other things to do...

And just for fun, a few pictures:

22.jpg

HDDtest2.jpg

IMG_0383.jpg
 
Last edited:
Interesting. Assuming the 8088 is being the actual CPU, is the FPGA used to emulate the rest of an XT system?

-Tor
 
Interesting. Assuming the 8088 is being the actual CPU, is the FPGA used to emulate the rest of an XT system?

Yep, except "the heart", everything else is in FPGA. Just wanted to have completely accurate starting point to build everything around.

Right now still need to work a bit more on 8259 and (especially) 8253 - they behave properly most of the time, but some games use them in really weird way.

Another problem - keyboard. Can't make it 100% accurate, because it's not realistic (or reasonable) to find original XT keyboard. So have to use PS/2 (PS/2 is not computer, just connector type) relatively modern keyboard and emulate, when possible, the behaviour of XT keyboard.
Learned a lot about XT in a last couple weeks :)
 
Very cool! May be it is possible to have all (including 8088/8086 + 8087,...) in one FPGA? I mean only with IDE/SD Card Interface, PS2 Keyboard & Mouse and VGA? One little circuit board with 1x VGA, 2x PS2 and one SD card holder and only this one FPGA? That would be very nice :D
 
Awesome stuff. What is the clock speed? Does your CGA have wait states like the original IBM CGA does, or will it run as fast as the 8088's bus will allow?
 
The CGA-to-VGA output is interesting. Is there a way to make this work on real CGA/RGBI hardware as well? Ideally by just plugging an FPGA-based device into the 9-pin output... but if not, perhaps it could somehow piggy-back on the 6845 or something?
Even nicer would be an FPGA that can take in RGBI, and then does simulation of NTSC composite colour too, then outputs to VGA.
Being able to simulate NTSC composite would be a nice addition for your project anyway, I guess, since quite a bit of 8088/CGA-oriented software has 16-colour composite support.
 
Awesome stuff. What is the clock speed? Does your CGA have wait states like the original IBM CGA does, or will it run as fast as the 8088's bus will allow?

Right now I'm concentrating on maximum compatibility with the original XT, so CPU is working on 4.78MHz, but don't see any problem to introduce any turbo mode up to max frequency for the actual chip (I'm using Intersil with 10Mhz max speed).

Don't think original CGA has any wait states - the CPU has a priority, so you have to watch timing to avoid "snow" on a screen. I use on-chip two-port memory for the video memory, so the memory is transparent from both sides - CPU and CGA, no "snow" issues. Anyway, I emulate the proper status register to allow software to check if it's proper time to write into video memory - most of CGA-oriented programs use this register.
 
The CGA-to-VGA output is interesting. Is there a way to make this work on real CGA/RGBI hardware as well?

This will require some relatively minor VHDL coding and a bit of hardware to create proper electrical interface to actual CGA monitor (don't think there are any FPGA development boards with this interface), but it's nothing major...

Even nicer would be an FPGA that can take in RGBI, and then does simulation of NTSC composite colour too, then outputs to VGA.

I'm confused - don't understand why does someone may need to do this 2-step converter ??? If it's just to simulate proper NTSC colors on VGA, it can be easily done right now with my project - tweaking color palettes, they are adjustable.
 
Getting straight CGA-to-VGA is relatively simple; it'd be a ladder DAC similar to the one in a CGA monitor, and a line doubler so that a modern VGA screen won't scream when you hook it up. I know a few people on eBay sell converter boards that ostensibly convert a whole bunch of old digital and analog standard to VGA, but can't vouch for their quality because I haven't bought one yet.
 
Getting straight CGA-to-VGA is relatively simple; it'd be a ladder DAC similar to the one in a CGA monitor, and a line doubler so that a modern VGA screen won't scream when you hook it up.

Yea, it's the line doubler that seems to be the problem.

I know a few people on eBay sell converter boards that ostensibly convert a whole bunch of old digital and analog standard to VGA, but can't vouch for their quality because I haven't bought one yet.

The stuff I've seen was some Chinese stuff, which was advertised as RGBI->VGA, but in reality it wasn't.
What it was, was an analog RGB digitizing circuit (probably somewhat generic monitor/TV component for SCART input and such), which used some simple digital-to-analog conversion on the RGB TTL signals. Yes, RGB, the I part was ignored completely.
Then this digitzed signal was run through some standard VGA hardware, just a RAMDAC I guess, to make it analog again.

There were people who did their own RGBI->analog RGB circuit to incorporate the I signal in two separate TTL levels for the RGB. Since the hardware was analog RGB to begin with, they could now decode the proper 16 colours (and yes, the decoding of I was slightly complicated because of that weird brown colour that needs to be emulated).
It works, but it's a bit overkill. It's not a plug-and-play solution, and far less elegant than just a linedoubler.
 
Yea, it's the line doubler that seems to be the problem.



The stuff I've seen was some Chinese stuff, which was advertised as RGBI->VGA, but in reality it wasn't.
What it was, was an analog RGB digitizing circuit (probably somewhat generic monitor/TV component for SCART input and such), which used some simple digital-to-analog conversion on the RGB TTL signals. Yes, RGB, the I part was ignored completely.
Then this digitzed signal was run through some standard VGA hardware, just a RAMDAC I guess, to make it analog again.

There were people who did their own RGBI->analog RGB circuit to incorporate the I signal in two separate TTL levels for the RGB. Since the hardware was analog RGB to begin with, they could now decode the proper 16 colours (and yes, the decoding of I was slightly complicated because of that weird brown colour that needs to be emulated).
It works, but it's a bit overkill. It's not a plug-and-play solution, and far less elegant than just a linedoubler.

This solution (haven't played with it as much as I would like) seems to work well:

http://he-insanity.blogspot.com/2014/03/commodore-128-cga-video-dac-board.html

http://www.vintage-computer.com/vcf...-Video-DAC-Board-Available&highlight=c128+dac

Not sure if he still has the boards available...

Wesley
 
Yeah, from what I can tell boards like the GBS-8200 (or whatever it's called) are primarily meant for things that output analog RGBS like JAMMA boards, Amigas and the Apple IIgs. Doing CGA properly wouldn't be that much harder, but there were apparently a few machines that didn't have an I line (I remember QBASIC mentioning them...PC98 maybe?), and maybe they decided to support that instead of IBM-spec CGA.
 
Very cool! May be it is possible to have all (including 8088/8086 + 8087,...) in one FPGA? I mean only with IDE/SD Card Interface, PS2 Keyboard & Mouse and VGA? One little circuit board with 1x VGA, 2x PS2 and one SD card holder and only this one FPGA? That would be very nice :D

Actually, there are a couple projects on internet with everything (including CPU) inside of FPGA. As I mentioned before, I wanted different approach to achieve better compatibility (hard to be sure if "virtual" CPU is 100% accurate)...
 
BTW, thinking about making another CPU board and can't decide if I should put 8087 there. How many old programs (ones that can run on XT) can use a coprocessor ?
 
Not many. Statistical and math packages; freeware fractal programs; CAD packages; spreadsheets. There may have been well over a handful, but since they were specialized programs that cost quite a lot and were usually quite heavily copy-protected, they were usually not preserved. About all that survived preservation would be stuff like: Lotus 1-2-3, AutoCAD, FRACTINT, maybe MathCAD?

You'll probably find more math-coprocessor support in freeware/shareware packages from old SIMTEL and GARBO repositories, since it was not a big deal to enable floating-point in your compiler and then link in a floating-point emulator for systems that didn't have a mathco.
 
Actually, there are a couple projects on internet with everything (including CPU) inside of FPGA. As I mentioned before, I wanted different approach to achieve better compatibility (hard to be sure if "virtual" CPU is 100% accurate)...
You can probably do a cycle-accurate 8088, since it's effectively divided into two sections that work independently, and the timings for both sections are known (4 clock cycles per byte to read a byte into the prefetch queue, and the instruction timings apply after the instruction is fully in the queue). I'm not sure if theres a delay or not for the 8088 reading new bytes when the prefetch queue is full and the EU is ready to accept more data, however (assuming the prefetch queue is full, does the EU take a byte, and THEN the BIU reads a new byte into the queue? Or does the EU take a byte WHILE the BIU reads a new byte?)
 
Actually, I have one related question - does anyone aware of something like virtual FDD for DOS ? I wasn't planning to emulate FDD for now, but discovered that a lot of old software does exist on FDD images only and would not run from HDD. Quick search did not find anything for DOS - for Windows only... I can try to make my own emulator, but right now have too many other things to do...

A lot of old floppy-only games have routines that access the NEC 765 directly (mostly for copy protection). So if you really want to be thorough, you'll have to duplicate that functionality at least at a register level.

Or you can deal with floppy games that have had the 765-dependent code hacked out and deal with things strictly on an Int 13h level.
 
You can probably do a cycle-accurate 8088, since it's effectively divided into two sections that work independently, and the timings for both sections are known (4 clock cycles per byte to read a byte into the prefetch queue, and the instruction timings apply after the instruction is fully in the queue). I'm not sure if theres a delay or not for the 8088 reading new bytes when the prefetch queue is full and the EU is ready to accept more data, however (assuming the prefetch queue is full, does the EU take a byte, and THEN the BIU reads a new byte into the queue? Or does the EU take a byte WHILE the BIU reads a new byte?)

I did quite a bit of research while troubleshooting my project, and discovered a few things I can't explain just reading datasheets (especially regarding the prefetch queue). In any case, it's more fun to do at least a bit soldering :)
 
Back
Top