The calibration screen is 80x100 textmode.
It looks like you don't handle the scanline addressing properly. It looks like it skips every other scanline, or something like that.
The intro screen is regular 640x200 mode (mode 6). Clearly there is something wrong with the width, the scanlines seem to be displayed only half as wide as they should be, and two displayed side-by-side.
This is a very common mode in CGA software, so you'll have plenty of software to test with. I bet they all have the same problem, since 8088 MPH doesn't do anything special there.
The part with the cube etc. 4 times (first quarter of the screen being correct, but only 1/4 height it's supposed to be).
That is standard mode 4, and will work even on EGA/VGA systems, aside from not using the correct palette (or composite artifacts obviously).
superfury wrote:
Also concerning old style and new style RGB, I just added those for future implementations. I don't know if there's any difference between Old Style CGA and New Style CGA when connected to a RGB monitor? I could make it a simple RGB mode if there's no difference between the monitors?
There is no difference. The videocard just outputs 4 TTL-level signals (0-5v) for red, green, blue and intensity. The monitor 'makes' the colours, the videocard basically just outputs a 4-bit digital value to the port.
superfury wrote:
The intel logo looks like it's skipping every 4 lines(lines divided by four).
It should skip every other line (uses only the even bitplane).
superfury wrote:
The 1K image does the same as the flower girl (double height, half width).
Yes, it's the same routine.
superfury wrote:
The 16/256 colors is half the vertical display height, with the bottom half showing duplicates of memory overflow?
It's basically an 80x100 textmode. So you need to handle different character heights.
I removed the CGA patching stuff and fixed various stuff.
The display still seems to have horizontal timing bugs (displaying some stuff twice with the copy being moved up 1 row) and vertical timing bugs(black lines being inserted somehow and display only showing half the vertical content). Anyone can see what's the cause?
Are scanline always displaced 80 bytes(offset register of 80)? Or is this different in 320 or 640 pixels graphics modes?
In graphics mode, they are always 80 bytes wide. In lowres (320) each pixel is 2 bits, so 4 pixels per byte: 80 bytes form 320 pixels.
In hires (640) each pixel is 1 bit, so 8 pixels per byte: 80 bytes form 640 pixels.
With the 6845, the data for one row is always immediately after the data for the previous row. So the value of the "offset register" is essentially half the value of the Horizontal Displayed register.
I've modified the precalcs to apply half the CGA Horizontal Display to the VGA's offset register(used in the line calculations).
The part with the the sprites moving are moving diagonally(bottom right to top left at the end).
Now the height of the Intel logo, text moving up and down and starfield is displayed on full screen. Also the IBM text(balls) is now displayed(instead of strange stuff on the screen flashing), although the colors are yellow/red/green with duplicates in the four corners of the screen making the same movements.
Stuff like the flower girl is still doubled horizontally(actually about twice and a quarter) and halved vertically, even in the overscan area(showing black lines interlaced). Those black lines also appear in the Kefrens effect, but it now looks like it's horizontal lines have some kind of 'sinus' effect going on.
The cube etc. effect now show properly at full-screen, but with wrong colors only.
The faces are now at the top of the screen a bit, with another row below it containing half of the faces. The final face is still cut off partly.
The credits now don't show text anymore, only dots. The 8088 MPH logo thing it contains is still recognizable though. But as usual, pausing the emulator and closing the BIOS Settings menu fixes this and it is displaying mostly at half a screen of content. After the demo finishes it jumps back to the full screen size.
The palette used in the 4-color modes are (these values are input for the NTSC conversion function, the lookup table using these values is essentially placed at attribute controller registers 1-3, 5-7, 9-11, 13-15. Indexes 0,4,8,12. Palette 0 is set to 0 in 320x200 graphics mode(Mode control bit 4 is set), else 0. The other colors are set to the Palette Register bits 0-4 when the index is greater than 0 and bits 1-0 are 0, else they're looked up from the tables displayed below. CGA Mode control register bit 2 selects palette #3 when set, else CGA Mode control bit 5 is used to use palette #1(when set) or #2(when cleared)):
Palette #1: 4, 2, E
Palette #2: 5, 3, F
Palette #3: 4, 3, F
Edit: Looked at the specs at seasip again. It's supposed to be CGA Palette register bit 5 instead of CGA Mode control bit 5 to use palette #2. The text moving up and down now becomes gray-light blue-magenta-gray colors(top to bottom of the characters). The starfield becomes purple, green, cyan and brown dots.
Also, the Kefrens have no background anymore for some reason (have messed with that part though, might have to revert it after looking at the specs on background colors at seasip again).
Edit: Looked at en.wikipedia.org's CGA information and fixes the palettes used based on that. The text between the sections now changes colors to be close to that of https://www.youtube.com/watch?v=yHXx3orN35Y .
The part with the sprites changes colors to what looks like purple colors. The car is visible(It only is, together with the whole display) shifted each line, moving from the middle-right to the top-left and back instead of straight up-down.
The IBM text now becomes green with a bit of red/orange in the center of the balls.
Racing the beam still doesn't display background raster bars(horizontally). Might have to look at the implementation on background for that.
Edit: The cube etc. colors become weird now though.
Although entry #0 of the palettes aren't used(it's replaced by the overscan/background color in the palette register): it's just there to prevent having to substract 1 from the index too look it up.
I've found some errors in the CGA memory mapping used in x86EMU. It looks like either the VGA Graphics registers are programmed incorrectly, the VGA MMU on the CGA adapter(which is setup using the CGA mode changes(text 40c vs text 80c vs 640 pixel graphics vs 320 pixel graphics) using the CGA Mode Control register.
I notice that while the first row in display RAM matches, the second row(160 bytes after the first row on plane 0) contains different content (looks like it's on the 3rd or 4th character of the fifth line. It's the XT-IDE BIOS Primary master at 1F0 text that's displayed on the VGA. Only it's displayed on the third row(the second row is a duplicate of the first one), with the first few characters missing(overwritten during writing? It looks like it printed 3/4 characters, pressed backspace going back to the start of the line, then continued printing characters following by the content of the next line on the same line(Primary slave) which is then followed by the booting C>>C text). Although the vertical duplication shouldn't be happening, as the SLDIV and DIV2 bit in the CRTC mode control register of the CRTC registers are 0(Actually 0xA3 is currently set by the CGA, also used by the VGA BIOS).
The one question remaining: what happened to the missing content? Is the VGA MMU buggy? Is it wrongly set up by the CGA mode setup(Graphics registers?)?
1 getActiveVGA()->registers->GraphicsRegisters.REGISTERS.DATAROTATEREGISTER.RotateCount = 0; //No special operation! 2 getActiveVGA()->registers->GraphicsRegisters.REGISTERS.DATAROTATEREGISTER.LogicalOperation = 0; //No special operation! 3 getActiveVGA()->registers->GraphicsRegisters.REGISTERS.ENABLESETRESETREGISTER.EnableSetReset = 0; //No set/reset used! 4 getActiveVGA()->registers->GraphicsRegisters.REGISTERS.GRAPHICSMODEREGISTER.WriteMode = 0; 5 getActiveVGA()->registers->GraphicsRegisters.REGISTERS.GRAPHICSMODEREGISTER.ReadMode = 0; 6 getActiveVGA()->registers->GraphicsRegisters.REGISTERS.GRAPHICSMODEREGISTER.OddEvenMode = 1; 7 getActiveVGA()->registers->GraphicsRegisters.REGISTERS.MISCGRAPHICSREGISTER.EnableOddEvenMode = 1; 8 getActiveVGA()->registers->GraphicsRegisters.REGISTERS.MISCGRAPHICSREGISTER.MemoryMapSelect = ((useGraphics&&(GraphicsMode==2)) || (!useGraphics && (GraphicsMode==1)))?2:3; //Use map B000 or B800, depending on the graphics mode! 9 getActiveVGA()->registers->GraphicsRegisters.REGISTERS.BITMASKREGISTER = 0xFF; //Use all bits supplied by the CPU! 10 getActiveVGA()->registers->SequencerRegisters.REGISTERS.MAPMASKREGISTER.MemoryPlaneWriteEnable = 3; //Write to planes 0/1 only, since we're emulating CGA! 11 getActiveVGA()->registers->SequencerRegisters.REGISTERS.SEQUENCERMEMORYMODEREGISTER.OEDisabled = 0; //Write to planes 0/1 only, since we're emulating CGA! 12 getActiveVGA()->registers->SequencerRegisters.REGISTERS.SEQUENCERMEMORYMODEREGISTER.Chain4Enable = 0; //Write to planes 0/1 only, since we're emulating CGA! 13 getActiveVGA()->registers->SequencerRegisters.REGISTERS.SEQUENCERMEMORYMODEREGISTER.ExtendedMemory = 1; //Write to planes 0/1 only, since we're emulating CGA! 14 getActiveVGA()->registers->CRTControllerRegisters.REGISTERS.UNDERLINELOCATIONREGISTER.DW = 0; //CGA normal mode! 15 getActiveVGA()->registers->CRTControllerRegisters.REGISTERS.CRTCMODECONTROLREGISTER.UseByteMode = 0; //CGA word mode! 16 getActiveVGA()->registers->CRTControllerRegisters.REGISTERS.CRTCMODECONTROLREGISTER.AW = 1; //CGA mapping is done by the renderer mapping CGA! 17 getActiveVGA()->registers->CRTControllerRegisters.REGISTERS.CRTCMODECONTROLREGISTER.MAP13 = 1; //CGA mapping! 18 getActiveVGA()->registers->CRTControllerRegisters.REGISTERS.CRTCMODECONTROLREGISTER.MAP14 = 1; //CGA mapping! 19 getActiveVGA()->registers->ExternalRegisters.MISCOUTPUTREGISTER.RAM_Enable = 1; //CGA! 20 getActiveVGA()->registers->ExternalRegisters.MISCOUTPUTREGISTER.OE_HighPage = 0; //CGA!
As far as I know there are no errors here in the CGA emulation? All other VGA registers should be zeroed out in the CGA mode(Or rather, they're never updated with non-zero values after the VGA is allocated(which, by zalloc, is automatically filled with zeroes in all it's bytes of data), unless written to by the CGA/MDA emulation layer in VGA_CGA_MDA.c(which is the VGA extension handling all CPU MDA/CGA I/O, CRTC timing generation and Extension initialization, which can disable parts of(or completely) the VGA register accesses, depending on the emulation mode selected in the BIOS(Pure CGA, Pure MDA, Pure VGA, VGA with NMI(software emulation of CGA/MDA mode control&palette), VGA with CGA extension or VGA with MDA extension) ).
The VGA with CGA extension enables VGA until the CRT protection bit is enabled, after which it will redirect CRTC writes to the CGA CRTC registers.
The same happens with the VGA with MDA extension, but it's for MDA only.
Those extension modes are primilary for starting with a VGA BIOS, then starting CGA/MDA software, which forces it into Pure CGA or Pure MDA mode once the CRTC Protection bit is set. Although currently it's buggy, as it doesn't enforce full Pure CGA/MDA mode yet(It doesn't enable the CGA timings yet(Keeps VGA timings set atm), just sticking to the CGA register accesses being redirected to the CGA and handling CGA/MDA Mode Control and Palette like a CGA/MDA). This of course assumes that the first time the Protection bit is enabled the CGA/MDA can take over, using the set VGA timings(Except the CGA pixel Clock being applied instead).
I'm currently testing the CGA in Pure CGA mode. The MDA displays without problems somehow? It's mode 0,1(Text, MDA mode) as the parameters of mode set and memory set parameters(useGraphics=0, GraphicsMode=1). The CGA uses mode 0,0 for text mode.
Also, what happens to the CGA Start address and Cursor location when translating it to VGA Start address and Cursor location? Do I simply multiply it by 2? I've applied that and it seems to work (see below for more information about it's good effects with the adjusted emulation:) )
I've implemented the start address translation and cursor translation to simply multiply by two for the VGA equivalents. I've modified the VGA/CGA/MDA emulation to only update the start address on vertical total.
The CGA detection screen is now fully displaying. The calibration screen still only shows 50%(horizontally), vertically unknown(don't know if it's 50% or 100%).
Even the 16/256/1K and flower girl etc. now work correctly. Now most of the demo displays correctly (except the screen with the car(which is shifted each line), the Raster Bars(flashing on/off very fast) and the starfield(black screen). The black lines still display in the same places as before. The IBM logo no longer has duplicates. The text describing parts between the sections now properly move up and down in the middle of the screen.
The heads now completely don't show anymore.
The credits is now properly scrolling up instead of jumping left and right.
After it ends and enters the normal MS-DOS text mode, display goes awry (just as when the emulator is turned on(BIOS) until the application is started.
Although the colors themselves still seem to go wrong at some parts. Probably it has something to do with the NTSC or me simply using the value of the VGA's overscan register as first input of the NTSC conversion function (It's called "border" and is a 8-bit number(byte/Bit8u)) or the palette itself being wrong?
Edit: Looking at the original video at https://www.youtube.com/watch?v=hNRO7lno_DM&f … tion_1901077497 , I notice that active display seems to end at about the middle of the "o" of the word "old". Does the horizontal timing have anything to do with this?
I've made another video of the current emulation of the CGA(on top of the existing VGA emulation). As is visible, there are still some bugs to be worked out, but mostly it runs and works(except the starfield being skipped or not displayed at all).
Who ever said that a 'VGA' couldn't display CGA demos(with a little bit of extra support functionality added in the core)? :p It's essentially still the existing VGA emulation, but with some CGA patches on top of it (CRT timings according to CGA registers instead of VGA registers. Mostly it's still the existing VGA emulation doing the most of the work. CGA CRT registers and timing is added, which together with the Misc. registers (CGA Mode Control, CGA Palette and/or MDA Palette) change values in the VGA registers or special support variables/registers(currently only one: The CGA CRTC Interlace Mode register). The rest just patches the CGA timing for the VGA renderer or (in the case of the Mode control and Palette registers) load some CGA/MDA compatibility values into the VGA registers and apply the CGA/MDA palettes(MDA uses a special kind of 4-color grayscale palette, which is handled seperately from the CGA/VGA palette, at the same point the CRTC emulation normally renders the CGA scanline to the display using NTSC/RGB conversion).
I've improved the 'VGA with CGA' and 'VGA with MDA' combination emulation modes. It will use VGA-compatible registers and timings until the protection bit (protecting VGA's CRTC registers from writes) and the CGA Mode Control Register's Video Enable bit (bit 3) are set. When both are set, the VGA switches to CGA or MDA mode(including timings and CRTC calculations) until either or both are cleared.
That should enable the VGA in that mode to run normal VGA games without problems (they don't touch the CGA/MDA Mode control register or set it on when the protection bit is on), but also retaining compatiblity with CGA/MDA games (which set the CGA/MDA Mode control register bit 3 on while the protection bit is set, switching the adapter to CGA/MDA compatible timings and colors(which are depending on whether the CGA or MDA mode control register is enabled(though only one of the two can be enabled in the BIOS Settings menu))).
These correct modes have already been verified by starting the emulation with a VGA BIOS (still in VGA mode), then running a CGA application(8088 MPH). Both work without problems.
I have a little question: what happens when the CGA is programmed with character height values (maximum scanline register) bigger than 7(8 pixels in height)? Graphics mode duplicate the first line, so it isn't noticable, but what does the CGA text mode do? Does it just use the background color for the lines past line #7(essentially forcing the font to become background)? I've just implemented the limit in my CGA and MDA fonts (forcing anything past 8 or 14 pixels to background pixels), but stuff like the CGA compatiblity tester(by Trixter) get strange displays: the selections are 14 pixels high instead of the usual 8 used on the CGA?
I have a little question: what happens when the CGA is programmed with character height values (maximum scanline register) bigger than 7(8 pixels in height)? Graphics mode duplicate the first line, so it isn't noticable, but what does the CGA text mode do? Does it just use the background color for the lines past line #7(essentially forcing the font to become background)? I've just implemented the limit in my CGA and MDA fonts (forcing anything past 8 or 14 pixels to background pixels), but stuff like the CGA compatiblity tester(by Trixter) get strange displays: the selections are 14 pixels high instead of the usual 8 used on the CGA?
In text modes, scanline n+8 within a row is the same as scanline n, so you'll get vertically duplicated characters. In graphics modes, scanline n+2 within a row is the same as scanline n, so you'll alternate between the byte from 0xb8000-0xb9fff on the even rows and the byte from 0xba000-0xbbfff on the odd rows.
I don't see any dithering pattern on the polygons, and the graphics look rather 'chunky' horizontally anyway, so it looks like some pixels are skipped horizontally as well.
For some reason, when I boot up the machine with the horizontal total divided by 2 in the offset register, the lines are strangely aligned: The first row is normal, the second row is moved right by 3/4 screen. The third row (booting text is directly after the second row content (like the line ending is missing). After that there's nothing to display anymore(just empty space).
The horizontal total is correctly applied(divided by two and put into the VGA's offset register), but the VRAM contains that strange content at locations 0(first line) and 160(second line). Is this correct when using the XT-IDE BIOS in VGA mode(80x25 text mode)? The offset register of the VGA itself is 40. The horizontal display end of the CGA is 80.
Starting Ultima II after closing the CGA Compatibility tester still retains the super high character height (which isn't supposed to be used at all).
The attachment Snap 2016-04-03 at 19.56.36.png is no longer available
At location 0 I got: "A>>FDD [A] C>>HDD [C] F6ComDtct F8RomBoot"
The second row seems to be at location 282 in plane 0.
The rest of VRAM seems to be empty for some reason.
CGA CRT register 9 has the value 0Dh. Why 14 pixels height on a CGA? Is this a bug in the BIOS? Or an error in my emulation of the card?
Btw, can anyone tell me the exact three palettes used with the 4-color modes? There seems to be an error in translating it to color indexes somehow (as the colors go strange with the Intel logo):
(translated colors are in hex)
CGA Mode control bit 2 selects palette #2 when set.
When palette #2 isn't used by setting above bit, palette register bit 4 selects set #1 when set, else set #0 is used.
Also when the palette register bit 4 is set, 8 is added to the colors to produce bright colors.
The credits still show up as kind of fat dots until the BIOS menu is opened using select(PSP)/backspace(PC), which after it's closed changes to the correct text mode.
Btw the starfield somehow works again, although in colors (black, orange, green and blue it seems) instead of b/w? Also the IBM logo is now green with orange/red between it. Two of the palettes look fine in the CGA Compatiblity tester.
There also seem to be 10 vertical black bars flashing on top of the 16 and 256 colors text description, with the 16 color description not disappearing.
The background of the raster bars seems to be working again, although not with the border(fixed to be black)?
After looking at VRAM when the BIOS is in CGA mode(as far as I know, since it reads ports 3DA) with the CGA card. Anyone knows if CGA VRAM is always mapped to segment B800? Or can this change?
After looking at VRAM when the BIOS is in CGA mode(as far as I know, since it reads ports 3DA) with the CGA card. Anyone knows if CGA VRAM is always mapped to segment B800? Or can this change?
It's always mapped to B8000-BFFFF (32kB region so there are two copies).
Well. the BIOS itself itsn't outputting anything at B800:0000+. I guess it's addressing B000:0000+ for some reason. Is there any reason why it would be adressing that segment? Any jumpers that need to be certain values?
Edit: Looking at the BIOS Source code reveals that it seems like the first mode requested becomes the active adapter(Mode 7->MDA or not mode 7->CGA). The first call seems to be using mode 7 for some reason. Anyone knows why it won't select mode 1/3? The Port A/B register (Port 62h) used to determine the mode starts with bits 0-1=01(2 floppy drives), bits 2-3=00(Autodetect, not mono), bits 4-7=1111(All memory installed). The BIOS swaps the two nibbles and uses the bits like described in the source code. But probably the value is either overwritten(is the data editable or ROM?) or the BIOS doesn't use that value at all and determines the MDA/CGA somewhere else, based on different flags?
Edit: I've managed to get it working: Start with PPI 62 and 63 cleared (=0). Set bits 0-1 to 11 with MDA, 10 with CGA else 00 with VGA.
Set bits 2-3 to 01 to specify 2 floppy disk drives.
Although CheckIt Diagnostics now reports no floppy drives at all.
I'm trying to get floppy disk support working with all 3 devices (CGA, MDA and VGA), but for some reason only MDA seems to detect the floppy correctly?
PPI emulation code:
1byte SystemControlPortB=0x00; //System control port B! 2byte SystemControlPortA=0x00; //System control port A! 3byte PPI62, PPI63; //Default PPI switches! 4 5byte PPI_readIO(word port, byte *result) 6{ 7 switch (port) //Special register: System control port B! 8 { 9 case 0x61: //System control port B? 10 *result = SystemControlPortB; //Read the value! 11 return 1; 12 break; 13 case 0x62: //PPI62? 14 *result = ((PPI62|4)&~8); //Read the value! 2 Floppy drives forced! 15 return 1; 16 break; 17 case 0x63: //PPI63? 18 *result = PPI63; //Read the value! 19 return 1; 20 break; 21 case 0x92: //System control port A? 22 *result = SystemControlPortA; //Read the value! 23 return 1; 24 break; 25 default: //unknown port? 26 break; 27 } 28 return 0; //No PPI! 29} 30 31void setupPPI() 32{ 33 //PPI63! 34 if (((getActiveVGA()->registers->specialCGAflags&0x81)==1)) //Pure CGA mode? 35 { 36 PPI62 |= 2; //First bit set: 80x25 CGA! 37 } 38 else if (((getActiveVGA()->registers->specialMDAflags&0x81)==1)) //Pure MDA mode? 39 { 40 PPI62 |= 3; //Both bits set: 80x25 MDA! 41 } 42 else //VGA with floppy? 43 { 44 //Leave PPI62 at zero! 45 } 46} 47 48byte PPI_writeIO(word port, byte value) 49{ 50 switch (port) 51 { 52 case 0x61: //System control port B? 53 SystemControlPortB = (value&0x7F); //Set the port, highest bit isn't ours! 54 return 1; 55 break; 56 case 0x62: //PPI62? 57 PPI62 = value; //Set the value! 58 return 1; 59 break; 60 case 0x63: //PPI63?
…Show last 34 lines
61 PPI63 = value; //Set the value! 62 return 1; 63 break; 64 case 0x92: //System control port A? 65 MMU_setA20(1,value&2); //Fast A20! 66 if (value&1) //Fast reset? 67 { 68 doneCPU(); 69 resetCPU(); //Reset the CPU! 70 } 71 SystemControlPortA = (value&(~1)); //Set the port! 72 return 1; 73 break; 74 default: //unknown port? 75 break; 76 } 77 return 0; //No PPI! 78} 79 80void initPPI() 81{ 82 SystemControlPortB = 0x7F; //Reset system control port B! 83 PPI62 = 0x00; //Set the default switches! 84 PPI63 = 0x00; //Set the default switches! 85 86 if (EMULATED_CPU<=CPU_80186) //XT machine? 87 { 88 //Check for reserved hardware settings! 89 setupPPI(); //Setup our initial values! 90 } 91 92 register_PORTIN(&PPI_readIO); 93 register_PORTOUT(&PPI_writeIO); 94}
The CGA, MDA and VGA are now all working without problems, but the floppy disks (Drive A and B) only show up in Checkit Diagnostics when in Pure MDA mode?
Anyone knows how to fix this?
Btw some images of now better working 8088 MPH (in Pure CGA mode):
The attachment Snapshots 8088 MPH in latest x86EMU build(build 20160404_1931).zip is no longer available
Still some errors in resolution and floppy disk support(MDA only for some reason?), but it's getting better.
