• Please review our updated Terms and Rules here

8086 emulator tech discussion

Should be /GF$ for global dollars and cents.

If you want to override the format for a cell, you can use /Fx, where x is "G" for general format, "$" for dollars and cents, "I" for integer, "L" for left-justified, "R" for right justified, or "*" for graph.
 
i gutted the CPU core and rewrote it. still don't know what was wrong, but things are looking much better now! and it's about 15% faster. :)

fake86-new-u6inst.png


fake86-new-u2.png


fake86-new-dos622.png


fake86-new-u6small.png


still some minor bugs, but i'm on it..
 
Last edited:
things are really running awesome now, although i need to implement a few video modes like EGA. Duke Nukem and Commander Keen both appear to run fine, but i need to emulate mode 0Dh. can't find any real specific info on it, mostly just on VGA planar modes. what is the formula i should be using to decode EGA graphics? and anybody know what EGA registers are used for page-switching? not sure why it's so hard to find straight-forward info on this stuff.

Wolf 3D also looks to work fine as well, but i need to implement chained VGA 320x200x256.
 
things are really running awesome now, although i need to implement a few video modes like EGA. Duke Nukem and Commander Keen both appear to run fine, but i need to emulate mode 0Dh. can't find any real specific info on it, mostly just on VGA planar modes. what is the formula i should be using to decode EGA graphics? and anybody know what EGA registers are used for page-switching? not sure why it's so hard to find straight-forward info on this stuff.

In terms of EGA emulation, best to consult either the EGA hardware reference manual or a some other (good) reference texts.

I say this, because when it comes to commander keen and other EGA games you really need to implement both the CRTC and attribute controller sections very well..

For example: Commander Keen did some neat tricks with the CRTC registers as well, to implement hardware horizontal panning necessary to pull off a decent mario-style game..

Other games may also use EGA's ability to do split screen, virtual screen sizing and/or custom fonts etc. etc..

Cheers,
Valentin
 
Last edited:
For example: Commander Keen did some neat tricks with the CRTC registers as well, to implement hardware horizontal panning necessary to pull off a decent mario-style game..
Kind of had to -- for sprite type games the EGA is a NIGHTMARE to program for due to it being pixel per bit across four planes. Manipulating the horizontal panning could often substitute for the shifts needed for the stationary sprites, even if it was useless for mobile sprites. The planar modes may have been really fast for doing text on byte boundaries, but for sprites it was.. problematic at best.

I was often surprised anyone was able to make 320x200 16 color games for the EGA, and I suspect that the dithering on the EGA version of Thexder was done NOT for 'greater color depth' as claimed, but because the EGA 320x200 16 color mode is four or five times slower for a raw sprite engine compared to the pixel-packed Tandy/Jr display modes. Even with the scanline interlace on Tandy/Jr that it's pixel packed means you only need a single nybble shift for one pixel, instead of a full four bytes of planar data and per bit shifts to pull off the same effect... Part of what made Commander Keen so impressive to me.

One of the keys to sprites is background preservation -- four port writes, four byte size reads, and... you can mask, but you have to mask per color pixel and OR per color pixel, making the writes painful at best, a disaster at worst... meaning eight or more port writes --- all just to write eight pixels?

Bad enough to make you go screaming back to the Jr/Tandy in terror.

Oh, as to a good resource for EGA programming, Ferraro's "programmers guide to the EGA/VGA card" is basically your bible. The 320 mode $0D is no different than the 640 modes $0E and $0F other than it being 40 bytes across per plane instead of 80 bytes per plane per scanline.

THANKFULLY the planar modes which work against people writing for it, should be easier to implement as a emulation... since it's just four linear buffers you just have to combine together as your colors -- though how you combine it could get a little tricky.
 
Kind of had to -- for sprite type games the EGA is a NIGHTMARE to program for due to it being pixel per bit across four planes. Manipulating the horizontal panning could often substitute for the shifts needed for the stationary sprites, even if it was useless for mobile sprites. The planar modes may have been really fast for doing text on byte boundaries, but for sprites it was.. problematic at best.

I was often surprised anyone was able to make 320x200 16 color games for the EGA, and I suspect that the dithering on the EGA version of Thexder was done NOT for 'greater color depth' as claimed, but because the EGA 320x200 16 color mode is four or five times slower for a raw sprite engine compared to the pixel-packed Tandy/Jr display modes. Even with the scanline interlace on Tandy/Jr that it's pixel packed means you only need a single nybble shift for one pixel, instead of a full four bytes of planar data and per bit shifts to pull off the same effect... Part of what made Commander Keen so impressive to me.

One of the keys to sprites is background preservation -- four port writes, four byte size reads, and... you can mask, but you have to mask per color pixel and OR per color pixel, making the writes painful at best, a disaster at worst... meaning eight or more port writes --- all just to write eight pixels?

It has been stated that IBM's EGA was technically the first 'graphics accelerator' for the PC, due to it's built-in ALU (it even predates PGA?). Not much of an 'accelerator' IMO, but Michael Abrash et. al. seemed to have some success with it.. ;-)

Bad enough to make you go screaming back to the Jr/Tandy in terror.

LOL! How VERY true..

Oh, as to a good resource for EGA programming, Ferraro's "programmers guide to the EGA/VGA card" is basically your bible. The 320 mode $0D is no different than the 640 modes $0E and $0F other than it being 40 bytes across per plane instead of 80 bytes per plane per scanline.

THANKFULLY the planar modes which work against people writing for it, should be easier to implement as a emulation... since it's just four linear buffers you just have to combine together as your colors -- though how you combine it could get a little tricky.

Well, one could (as I did) treat the 256K memory space as one linear buffer..

Note: this is what happens per every byte transferred for the solution I have done:

1.) Multiply the combined video segment+offset data value by four and read in (if requested) the following four sequential bytes, with each byte representing a plane color i.e. Plane 0/1/2/3 = R/G/B/I etc.
2.) perform a 'planar-to-linear' translation of the transferred byte to/from the CPU against those four fetched bytes - essentially a series of bit-level logic shifts and compares to various control regs like mapselect, map mask and byte mask etc.
3.) Execute the actual transfer i.e. read/write/read-modify-write those (possibly now modified) four bytes etc..
.
4.) Perform palette color lookup during the display render phase

Unfortunately, since I do not (yet) fully understand the behavior of the attribute controller, I have not been able to progress much beyond getting all the QBASIC EGA drawing primitives to work and a small handful of games..


Regards,
Valentin
 
Last edited:
thanks for all the good info.

and deathshadow, your Paku Paku game works well in Fake86, except the rendering looks a bit weird. am i handling the intensity wrong? does it work differently in that 160x100 "graphics" mode?

fake86-pakupaku.png
 
That's the behavior I've seen out of the PC Jr. that seems to come and go with every code revision... You are correct in that you aren't handling intensity correctly -- I reprogram the CRTC to turn blink off along with the other settings -- turning blink off enables the high intensity bit for background-color (since they're the same bit).

Which is why for the Jr. I'm just saying "screw it" and making a optimized 160x200 version (that's 160x100 line-doubled)

Basically on the CGA you have a choice, blinking foreground with 8 color background, or no blink with 16 color backgrounds.
 
ah, okay yeah that explains it. i've been a little bit lazy with emulating my registers. will fix all that. on another note, it runs Turbo C++ perfectly, and even compiles working EXEs. :)

fake86-tcpp.png


i can't help all the screenshots sorry. this is fun.
 
It has been stated that IBM's EGA was technically the first 'graphics accelerator' for the PC, due to it's built-in ALU (it even predates PGA?).
To my knowledge there is nothing on the EGA that can be called a ALU... not even CLOSE.

What it does have is some cute port tricks -- all four planes being mapped over each-other you can map/unmap a plane to quickly set one color -- combined with the mask port to write one bit, it's actually one of the fastest ways to write a single pixel or 8 pixels at a time on anything less than 256 colors... assuming you only want to write one color at a time.

In that way, the ability to set sixteen 4 bit-wide pixels -- a total of 4 bytes using just one word-wide write lets it do some of the fastest text and flood-fills/clears/vLines of any CPU controlled graphics interface.

It's just REALLY not suited to handling high speed multicolor sprites... The best approach to handling it is in fact really unusual; break the sprite into 8 pixel wide tiles AND into four separate color planes in addition to the mask... and even with the ability to write multiple planes it ends up a lot of shifts and trickery.

Though if you want mono-color sprites, it can do really large ones pretty quick... reinforces the idea that the EGA was designed to render text, fills and boxes quickly in graphics mode, and not for gaming.
 
To my knowledge there is nothing on the EGA that can be called a ALU... not even CLOSE.

In that case, have a look at the 'data rotate' register function over pages 27-28 of the IBM EGA tech ref. Where it clearly states that the EGA hardware can be programmed to perform AND, OR, XOR logic ops against previously latched data. Even bit-rotation operations can be programmed to occur on any transferred byte data, when using write mode 0..

Now, if that isn't considered close to an integral ALU, then I really don't know what is! :)

From my own observation, there appears to be a fair amount of games that use this register - it's even employed as a primitive sprite handler (i.e. read-xor-write function)! This came about recently when I needed to get the XOR functionality right for a specific game whilst debugging my own EGA emulation routines..


Regards,
Valentin
PS: EGA emulators are VERY challenging to program for using 8-bit microcontroller assembly.. :cursemad:
 
Last edited:
ah, okay yeah that explains it. i've been a little bit lazy with emulating my registers. will fix all that. on another note, it runs Turbo C++ perfectly, and even compiles working EXEs.
Nice one Mike!


i can't help all the screenshots sorry. this is fun.
Addictive, is it not? ;-)


and anybody know what EGA registers are used for page-switching?
You mean for page-flipping/animation stuff, right? Well here's a hint - suggest you start by looking at Int 10h video function AH=05h..

Regards,
Valentin
 
Now, if that isn't considered an integral ALU, then I really don't know what is! :)

Valentin, I agree that some primitive bit logic (shift, mask, AND/OR) is possible, but where is the arithmetic part (add, subtract, multipy, divide)?

The best way to learn EGA, I think, is to write a few graphics programs for a real EGA (VGA will also do) that operate not through someone else's library, but through your own code manipulating the adapter registers directly. That's how I learned it--one hand on the keyboard and the other in the IBM techref. There's no substitute for the "let's see what happens if I do this".

If you don't have a real EGA to fool with, you're at a huge disadvantage when it comes to the original games programmers.
 
you guys should have a peek at this video demo i recorded. the performance is actually quite decent. very, very smooth running Indy 500! and that uses primitive 3D rendering.

http://www.youtube.com/watch?v=L4u5I8c74a0

8)


i added a feature where it can save screendumps to a BMP image sequence at 30 FPS, then i use virtualdub to re-save them into an AVI.
 
Valentin, I agree that some primitive bit logic (shift, mask, AND/OR) is possible, but where is the arithmetic part (add, subtract, multipy, divide)?

You're right Chuck, I was merely trying point out that that it was close to an ALU, because it appears to do nearly everything expected of an ALU except arithmetic ops.. That I didn't use the words 'close to an ALU' in my closing statement is a mistake on my part, I'll accept that..

Regards,
Valentin
 
Last edited:
whoooo, my VGA unchained mode decoding is functional. not flawless yet. note the status bar... but this is 100% playable!

fake86-wolf3d.png


fake86-wolf3d-2.png


:D
 
Looking good mike :)

Could it be a VGA attribute controller related problem? I noticed that Wolf3d switches the attribute controller between data write mode 0 and 1 numerous times, whenever it is rendering one of the affected screens.. Might be something worth looking into?
 
Looking good mike :)

Could it be a VGA attribute controller related problem? I noticed that Wolf3d switches the attribute controller between data write mode 0 and 1 numerous times, whenever it is rendering one of the affected screens.. Might be something worth looking into?

thanks for this, and the info you gave in your PMs. i am close to having it working correctly i think! btw, even though i'm working on a C port, yesterday i was able to speed up my BASIC version by about 30% ..... i removed a bunch of bitmasking that was not needed but the code was being run for almost every opcode. i also changed some divides to bitshifts.
 
just got hercules mode 720x348 working.. if anybody wants to experiment with fake86 as-is, i'd gladly upload it. the more programs that get tested in it the better!

jeez, hercules is so ugly.

fake86-hercules.png
 
Back
Top