• Please review our updated Terms and Rules here

8086 emulator tech discussion

ah, that's right he did some work with adlib for his paku paku game.

also, i'm pretty sure i just did something awesome:

**cool image snipped!**

heavily modified the crynwr packet driver for the 3C509, and designed it to work with an ethernet bridge interface in fake86. i'm using the pcap lib, so it will work in windows or *nix. 8)

**cool image snipped!**

This has got to be one of the coolest milestones reached in your emulator thus far Mike! Also noted your Adlib sound and Tandy Graphics support are both off to a pretty neat start. Well done! 8)


Regards Valentin
PS: If there's any constructive comment I could make, I would personally try getting the (much easier to implement) Tandy sound support going first before taking on OPL2.. but hey that's just me :p
 
Funny that you should mention that. Before I posted the link, I wanted to make sure that it worked, so I clicked on the executable on my 2.4GHz P4 system. Window opened, window closed--I didn't even see the logo. Just tried it on a very slow 386/16 system with no cache. Takes about 15 seconds, I hear a rhythmic buzzing, but nothing that could be recognized as music.

Basman may want to give it a try on his emulator.

Hi Chuck!

Well, I just did. Here is a resultant recording of 'The Maple Leaf Rag' as played under the Flea86 emulator in 'legacy 4.77MHz' compatibility mode. I cannot confirm how the recording compares to a real 5150/5160 (don't have either), but I would be willing to bet it isn't far off the mark..


Regards Valentin
PS: Please excuse the low-quality audio, though it plays well enough to get a general impression of it..
 
Last edited:
Hi Valentin,

Your rendition is much closer to a "real" 4.77 MHz 5150. It still isn't quite right sonically; perhaps there's too much latency in setting up the 8254 or maybe you simply lack the resonance of the original 5150 enclosure. I'll try to get a better reading on exactly what the issue is in a couple of days for you.

So, good job as regards timing!
 
Hi Valentin,

Your rendition is much closer to a "real" 4.77 MHz 5150. It still isn't quite right sonically; perhaps there's too much latency in setting up the 8254 or maybe you simply lack the resonance of the original 5150 enclosure. I'll try to get a better reading on exactly what the issue is in a couple of days for you.

So, good job as regards timing!

Thanks for the feedback Chuck! Will concede that my PC speaker routine isn't quite as polished on Flea86 as say, Tandy sound support. On some games i.e. Beyond castle wolfenstein and Simcity, digitised sounds are somewhat clear while other games do not play at all (many as a consequence of using an 8052 microcontroller with 32K ROM as an emulation host..)

Oh well at least it does the mimimum expected - it beeps:
1.) Upon bootup
2.) When playing non-digitised sounds for most programs
3.) Any time an ASCII 'bell' character is printed via INT10h.. ;)

Regards Valentin
 
Last edited:
This has got to be one of the coolest milestones reached in your emulator thus far Mike! Also noted your Adlib sound and Tandy Graphics support are both off to a pretty neat start. Well done! 8)


Regards Valentin
PS: If there's any constructive comment I could make, I would personally try getting the (much easier to implement) Tandy sound support going first before taking on OPL2.. but hey that's just me :p

my OPL2 currently is "useable" minus percussion. it sounds nothing like a real OPL2, but it generates the correct frequency tones and makes music. needs some work, but i will do Tandy sound before finishing it. i just wanted SOMETHING working adlib-wise, since like EVERYTHING supports it. however, i couldn't find any real good info on programming the tandy DAC in the tandy manuals, maybe i missed something?
 
Hi Chuck!

Well, I just did. Here is a resultant recording of 'The Maple Leaf Rag' as played under the Flea86 emulator in 'legacy 4.77MHz' compatibility mode. I cannot confirm how the recording compares to a real 5150/5160 (don't have either), but I would be willing to bet it isn't far off the mark..


Regards Valentin
PS: Please excuse the low-quality audio, though it plays well enough to get a general impression of it..

this sounds really good! O_O
 
i'm going to upload a new version on the website in a day or two, but if anybody wants to help test it out for me, here's a download:

http://rubbermallet.org/fake86-0.11.7.9-win32.zip


and here's a 20 MB sample hard drive image with MS-DOS 6.22, Wolf3D, Ultima 6, and Windows 3.0:

http://rubbermallet.org/testdisk.7z



thanks to anybody who gives it a spin! let me know how it works for you please. and fyi, fake86.exe requires winpcap ( http://www.winpcap.org ) to be installed, but if you don't want that i also included a version compiled without networking support fake86-nonet.exe


extract both of those archives into the same folder and go there in command prompt and run:

fake86.exe -hd0 test.raw



i'd especially like to know how the performance is your machine, let me know how it ran and what CPU you are using. the timing can be off quite a bit on slower machines, like under 1.5 GHz or so. once you get down to about 1.0 GHz or less, the audio starts sounding "wobbly" like it's underwater or something.

QueryPerformanceCounter (win32) and gettimeofday (*NIX) suck so much CPU but i need to poll them almost constantly to get accurate timing. trying to find some kind of alternative.

EDIT: forgot to mention, my specialized packet driver for fake86 is on the hard drive image too, it's PD.COM -- not sure why, but currently the only network stuff that seems to work with it is mbbrutman's mTCP apps.
 
Last edited:
QueryPerformanceCounter (win32) and gettimeofday (*NIX) suck so much CPU but i need to poll them almost constantly to get accurate timing. trying to find some kind of alternative.

For Linux systems at least (many other POSIX systems too), use times(NULL) to get the kernel jiffie count and call sysconf(_SC_CLK_TCK) once in the beginning to get the HZ count (# jiffies per second).
 
For Linux systems at least (many other POSIX systems too), use times(NULL) to get the kernel jiffie count and call sysconf(_SC_CLK_TCK) once in the beginning to get the HZ count (# jiffies per second).

thanks for the tip, i tried it but on the systems i tried, it's only 65536 Hz resolution. 1 MHz or more is ideal. it's accuracy wasn't even to the full 65536. :(

i wonder if it's possible to directly poll the ACPI PM timer (resolution of 3.5 MHz) from userspace in windows/linux. that's not going to be portable to non-x86 systems of course, but in that case i can just fall back to gettimeofday().
 
Found a bug. I booted up and played Wolf3d for a few minutes. I then quit to dos, entered "mem" to see how much memory was available, then ran windows. I simply exited after it came up. I then ran Qbasic, which loaded fine, but on exit I get a mess.

fake86_shot.png


"DIR" here scrolls garbage in those first three lines.

I ran Qbasic again and it came up ok, but on exiting, I ran MSD and the machine appears to be locked up.

I just restarted it and ran Qbasic first off. On exiting I get the same garbled top screen.

g.
 
Amazing! I find it completely amazing that this is a working PC emulator, with a bunch of features, and its all written in basic.

QBasic was the first language I learned on the PC, and I moved onto assembly and C a long time ago.

Seeing such a complex project done in a 'beginners' language really shows that plain old basic can still do a lot. And seeing your screen refresh routine made of two for loops and 'pset' in really telling in terms of modern CPU speed. I remember pset on a 286, it would take FOREVER to draw a fullscreen picture in qbasic using pset. Now you can emulate the entire CPU, and refresh the full screen, and still have time to do some sound, in pretty much the same language. That's crazy!
 
Found a bug. I booted up and played Wolf3d for a few minutes. I then quit to dos, entered "mem" to see how much memory was available, then ran windows. I simply exited after it came up. I then ran Qbasic, which loaded fine, but on exit I get a mess.

fake86_shot.png


"DIR" here scrolls garbage in those first three lines.

I ran Qbasic again and it came up ok, but on exiting, I ran MSD and the machine appears to be locked up.

I just restarted it and ran Qbasic first off. On exiting I get the same garbled top screen.

g.

yes, i also have run into the MSD bug, and i'm not yet sure why QBASIC does that on exit. i've found typing MODE CO80 fixes it, but it really annoys me. i'd love to find what's going on here and will try.
 
Amazing! I find it completely amazing that this is a working PC emulator, with a bunch of features, and its all written in basic.

QBasic was the first language I learned on the PC, and I moved onto assembly and C a long time ago.

Seeing such a complex project done in a 'beginners' language really shows that plain old basic can still do a lot. And seeing your screen refresh routine made of two for loops and 'pset' in really telling in terms of modern CPU speed. I remember pset on a 286, it would take FOREVER to draw a fullscreen picture in qbasic using pset. Now you can emulate the entire CPU, and refresh the full screen, and still have time to do some sound, in pretty much the same language. That's crazy!

heh, actually Fake86 is now completely written in C! abandoned the FreeBASIC version months ago, but it worked just as well minus some bugs i've found and fixed since (which i could fix in the BASIC version now that i am aware of them)

the only difference is the C version is about 8 times faster and far more portable. :)

It didn't use PSET, btw... when i first started it i tried that but it was slower than i liked so i started using SDL with FreeBASIC and drew to the screen directly using a pointer.


EDIT: wanna add that, since you were speaking of old machines like a 286... i actually took the C version and trimmed it way down as far as features and changed the emulated RAM to 32 KB and then compiled it for 16-bit DOS using Turbo C++ 3.0 and ran it on an XT! of course, i got rid of video emulation and just gave the emulator direct video card access to make it far faster.

but yeah, i was emulating an x86 PC on a 4.77 MHz 8088. of course, it took 5 minutes to POST but... it worked! :twisted:
 
Last edited:
but yeah, i was emulating an x86 PC on a 4.77 MHz 8088. of course, it took 5 minutes to POST but... it worked!

Awesome. Actually, when I was a kid learning x86 assembly on my 286, there was a moment when I realized the idea that all computers are equivalent: I realized that I could write a QBASIC program that read each instruction, and did what each instruction said to do one by one, and I should be able to run 386 and 486 programs on my 286 just fine... just too slow to be useful. That's the moment I 'got' the concept of emulation. Seeing your emulator written out in basic took me back to that moment.

Glad to see it's converted to C though. I have to admit, the first thing I thought when I saw it was written in basic was 'why?' It seemed about as absurd as this Javascript x86 emualtor I read about a little while ago.
 
after some tweaking...

Code:
2,752,131,198 instructions were executed in 49 seconds.
Average speed: 56,165,942 instructions/sec

this is on a 3.5 GHz Core 2 Duo.
 
if anybody is interested, i've put out a new version 0.11.7.22.

windows binary: http://fake86.rubbermallet.org/?downloads/downloading-fake86-0-11-7-22-win32-zip
debian/ubuntu x86 .deb binary package: http://fake86.rubbermallet.org/?downloads/downloading-fake86_0-11-7-22_i386-deb
source gzipped tarball: http://fake86.rubbermallet.org/?downloads/downloading-fake86-0-11-7-22-tar-gz (this has a proper makefile now. i'm noob at writing them, but i figured it out.)

a new feature i added is the "monitor" that lets you switch floppy disks on the fly, which was sorely needed. get to it with ctrl-alt-m.

command examples to change disks:
fd0=c:\path\to\images\dos622-disk2.img
fd1=blah.144

typing "exit" returns to emulation. also, ctrl-alt-enter toggles fullscreen mode.
 
Hi Mike, great job on this! Like the idea of running on an XT, so when will the Win3.11 enhanced-mode-on-XT be done!?

But seriously, I wondered if I extract the ROM code from a 515(0/5/6) whether this could be made to run somehow, i.e. to get to ROM BASIC etc?

Cheers!
 
hey pearce, thanks! :D

hmm, well i've tried 5150/5160 ROMs and they freak out and halt because i don't have the DMA controller emulated... at least i think that's why, but it can run ROM BASIC.. in fact, the legality might be questionable but i included rombasic.bin.... although i don't think IBM would really care at this point so i'll risk it.

just run it like:

fake86 -boot rom

and it should take you right into ROM BASIC C1.10 :)

it appears fake86 is now on several big emulation sites too, including the venerable Zophar's Domain. that made me happy. there were a number of months there i thought it would never really get off the ground when i was writing it, but it's really turning out to be pretty decent lately. it's no DOSBox, but it works! i need to focus on improving the adlib emulation. on some things it sounds utterly horrible. other things, sounds very good. thankfully, it sounds great playing wolf3d!
 
Back
Top