• Please review our updated Terms and Rules here

Modern XT compatible PC on FPGA with real 8088

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).

It must be more complicated than that, because not all instructions fit in the queue! I have a (much neglected) project in progress to figure out the timings for a cycle-exact 8088 emulator.
 
Cool project! It is interesting to see a combination of the 8088 and an FPGA. Any reasons for not implementing 8284 and 8288 in FPGA as well?

As these parts (8088, 8284 and 8288) are providing timing for everything else, I decided to have them all (at least, for the beginning). It's easy to replace 8284 and 8288 with IP cores later, after the system is running properly.

Also, it's my very first FPGA/VHDL project, so I wanted to eliminate as much of uncertainness as possible - if I have CPU running I can handle everything else (within a reason :) )

BTW, I'm prepared to go with CPU only - the hardware is ready:

i8088.jpg
 
It must be more complicated than that, because not all instructions fit in the queue! I have a (much neglected) project in progress to figure out the timings for a cycle-exact 8088 emulator.

Completely agree - spent some time watching CPU cycles on an oscilloscope and could see that the behavior is not always straightforward...
 
It must be more complicated than that, because not all instructions fit in the queue! I have a (much neglected) project in progress to figure out the timings for a cycle-exact 8088 emulator.

So even MESS doesn't have one? Is cycle exact emulation of the 8086 easier? Are there programs that cannot run on any of the existing emulators or do they just not run at the proper speed?
 
So even MESS doesn't have one?

It does not. It does do some cycle counting, but uses the published (best case) counts and does not emulate waiting for the bus at all, as far as I can see.

Is cycle exact emulation of the 8086 easier?

I think it's actually marginally harder, because on the 8086 there are penalties for non-aligned accesses which (I'm pretty sure) don't exist on 8088.

Are there programs that cannot run on any of the existing emulators or do they just not run at the proper speed?

I'm not aware of any programs that have been published and for which the consequences for running without cycle exact timing are anything except running at the wrong speed. I expect that to change in the next couple of months.
 
I'm not aware of any programs that have been published and for which the consequences for running without cycle exact timing are anything except running at the wrong speed. I expect that to change in the next couple of months.

Hmmmm.... whatcha writing? :)
 
You two hush now!

There are no PC cycle-exact emulators. There are a few that make attempts to come close; pcem comes to mind. But none that are "perfect", like there are for other platforms such as the C64 or Apple II.

In a month or so, new software will be published that will not work 100% correctly on any emulator. It is my hope that emulator authors will use said software as a test suite for improving their emulators.
 
It must be more complicated than that, because not all instructions fit in the queue! I have a (much neglected) project in progress to figure out the timings for a cycle-exact 8088 emulator.

I'll leave that to you, as I don't have a (good) logic analyzer :p. You need some way to control the current size of the queue. I personally don't know how to do that, but that's just because I'm not smart enough :p (my guess is using NOPs or JMPs to drain the queue).
 
(my guess is using NOPs or JMPs to drain the queue).

Yes, the queue will be drained after a JMP and filled after a long-running instruction like MUL. I made an ISA card with a microcontroller on it that I should be able to use (once I've written the microcontroller program) to sample all the signals from the bus and some other interesting signals.
 
I suppose the only ways to get perfect cycle emulation is to a) look at the original RTL, or b) run a real 8086/88 along-side an FPGA implementation in lock-step through a significant amount of the code ever written for the 86/88 and stop the clock when the BIUs don't match. Now that would be an interesting project.
 
newold86 There is FPGA inmplementation of the 8-bit Vector-06c (i8080) computer. It contains very interesting floppy emulator.
For CPU side it emulates old WD1793 floppy controller. From the other site it contains tiny 6502 CPU which implements SD controller and FAT
filesystem driver. As a result CPU can use conventional FAT-formatted SDs with floppy images on it.
https://code.google.com/p/vector06cc/
 
I suppose the only ways to get perfect cycle emulation is to a) look at the original RTL, or b) run a real 8086/88 along-side an FPGA implementation in lock-step through a significant amount of the code ever written for the 86/88 and stop the clock when the BIUs don't match. Now that would be an interesting project.

That's almost exactly what I started doing. Except my implementation is in software, not on an FPGA (at least so far). And I'll also write a bunch of 8088 testcases specifically designed to poke at the timing edge cases, rather than just running existing software. I have an 8088 system set up so that I can programmatically reset it to a known state and load arbitrary code onto it.
 
Guys, what about my original question about virtual FDD ? :)

Oh yeah. Sorry for derailing your thread!

I'm afraid I don't know of any DOS VFD software either. I guess it shouldn't be too hard to do, though - just a TSR to redirect interrupt 0x13 and access a file instead of the floppy hardware. One difficulty is that most (all?) versions of DOS are not re-entrant, so an outer int 0x21 (for a file on the virtual floppy) calls int 0x13 but if that then calls an inner int 0x21 (for the image file) then DOS may very well get confused by that.

One way around that would be to load the entire image into RAM, but a 360kB floppy image is a pretty big chunk of conventional memory, so you might want to use EMS if your machine supports it. Another downside to keeping your image in RAM (EMS or conventional) is that you'll lose any saves made to the disk if the machine crashes.
 
Hello, this is a very intersting thing. But on the other side, why not use the MIST FPGA platform? It's ready working, you only need to create a PC core , the third one which would then exist...

Don't wonder on the follwoing link that it tells something about Commodore Amiga and ATARI ST emulation only. Until now MIST can support about 20 different computer systems by just swapping the FPGA code via SD-card. All based on open source.

- Mist homepage http://harbaum.org/till/mist/index.shtml

- Mist hardware oder http://lotharek.pl/product.php?pid=96

- MIST cores overview, also PC 8088 / 80186: https://code.google.com/p/mist-board/wiki/ListOfFPGAProjects
 
Last edited:
I use around 20 or 30 old games to check the compatibility, almost all of them now working well, but with two of them I ran into very weird problem. First of all, I would very appreciate if someone with real PC or PC XT (most important - 8088 CPU required) can try to run Paratrooper taken from here - http://www.abandonia.com/en/games/607/Paratrooper.html

I would like to know if it keeps working after the initial screen, or it doesn't...

Thank you in advance !
 
I would very appreciate if someone with real PC or PC XT (most important - 8088 CPU required) can try to run Paratrooper

OK, no need to run the Paratrooper - found the problem. And the problem is with the game, not with the computer. Seems like the file was packed with something that creates self-extracting .com files, and the extracting part uses 286+ instruction, so it can't run on 8086/88 ! Wasted quite a bit of time investigating this :(

At the moment have only one game, that does not run - classic Packman, again something is very strange...
 
Hello, this is a very intersting thing. But on the other side, why not use the MIST FPGA platform?

I have at least 10 very good reasons, but will provide just one (most important) - just because ! :)

Really, nothing of this has any practical purpose, so no point to look for logical reasons to do things in certain way.
 
Back
Top