Here are the logs of 4 parts of the demo:
The first dump period is the CGA style screen (old vs new cga).
The second dump is the 4k screen showing CGA colors(ugly).
The third dump is the 4k screen showing 16 colors.
The fourth dump is the 4k screen showing 1K colors.

Is this good enough?

About the DMA controller: it's not 100% implemented, since PC software shouldn't be using all features?
The basic register addresses are implemented.
The registers for I/O ports 0x00-0x0F(DMA #1), 0xC0-0xCF(DMA #2) and ports 0x81-0x83, 0x87(DMA 1), 0x89-0x8B and 0x8F(DMA 2) are implemented.
As for the modes, only part of the modes are implemented:
- Controller disabled is implemented.
- Mode 3 channels are skipped.

The handling of the transfers:

1void DMA_tick()
2{
3	if (__HW_DISABLED) return; //Abort!
4	register byte controller; //Current controller!
5	register byte channelindex, MCMReversed;
6	byte transferred = 0; //Transferred data this time?
7	byte startcurrent = current; //Current backup for checking for finished!
8	nextcycle: //Next cycle to process!
9		controller = ((current&4)>>2); //Init controller
10		if (DMAController[controller].CommandRegister&4) goto nextchannel; //Controller disabled?
11		byte channel = (current & 3); //Channel to use! Channels 0 are unused (DRAM memory refresh (controller 0) and cascade DMA controller (controller 1))
12
13		//Handle the current channel, since the controller is enabled!
14		DMAModeRegister moderegister;
15		moderegister.data = DMAController[controller].DMAChannel[channel].ModeRegister.data; //Read the mode register to use!
16		if (moderegister.Mode==3) goto nextchannel; //Skip channel: invalid! We don't process a cascade mode channel!
17
18		if (DMAController[controller].DMAChannel[channel].DREQHandler) //Gotten a tick handler?
19		{
20			DMAController[controller].DMAChannel[channel].DREQHandler(); //Execute the tick handler!
21		}
22
23		channelindex = 1; //Load index!
24		channelindex <<= channel; //Assign the channel index to use!
25
26		MCMReversed = DMAController[controller].MultiChannelMaskRegister; //Load MCM!
27		MCMReversed = ~MCMReversed; //NOT!
28		MCMReversed &= channelindex; //For our current channel only!
29
30		if (DMAController[controller].DREQ&MCMReversed) //Requested and not masking?
31		{
32			if (DMAController[controller].DMAChannel[channel].DACKHandler) //Gotten a DACK handler?
33			{
34				DMAController[controller].DMAChannel[channel].DACKHandler(); //Send a DACK to the hardware!
35			}
36			switch (moderegister.Mode)
37			{
38				case 0: //Single transfer!
39				case 1: //Block transfer!
40					DMAController[controller].DACK |= channelindex; //Acnowledged!
41					break;
42				case 2: //Demand transfer?
43					//Nothing happens: DREQ affects transfers directly!
44					break;
45			}
46		}
47			
48		byte processchannel = 0; //To process the channel?
49		switch (moderegister.Mode) //What mode?
50		{
51			case 0: //Demand mode?
52				//DREQ determines the transfer!
53				processchannel = DMAController[controller].DREQ;
54				processchannel &= channelindex; //Demand sets if we're to run!
55				break;
56			case 1: //Single: DACK determines running time!
57			case 2: //Block: TC and DREQ masked determines running time!
58				//DACK isn't used in this case!
59				processchannel = DMAController[controller].DACK;
60				processchannel &= MCMReversed; //We're affected directly by the DACK!

61				break;
62		}
63			
64		if (DMAController[controller].RequestRegister&channelindex) //Requested?
65		{
66			processchannel = 1; //Process: software request!
67		}
68			
69		if (processchannel) //Channel not masked off and requested?
70		{
71			transferred = 1; //We've transferred a byte of data!
72			byte processed = 0; //Default: nothing going on!
73			/*
74			processed bits:
75			bit 0: TC (Terminal Count) occurred.
76			*/
77				
78			//Calculate the address...
79			uint_32 address; //The address to use!
80			if (controller) //16-bits transfer has a special addressing scheme?
81			{
82				address = DMAController[controller].DMAChannel[channel].CurrentAddressRegister; //Load the start address!
83				address <<= 1; //Shift left by 1 to obtain a multiple of 2!
84				address &= 0xFFFF; //Clear the overflowing bit, if any!
85			}
86			else //8-bit has normal addressing!
87			{
88				address = DMAController[controller].DMAChannel[channel].CurrentAddressRegister; //Normal addressing!
89			}
90			address |= (DMAController[controller].DMAChannel[channel].PageAddressRegister<<16); //Apply page address to get the full address!
91				
92			//Process the address counter step: we've been processed and ready to move on!
93			if (moderegister.Down) //Decrease address?
94			{
95				--DMAController[controller].DMAChannel[channel].CurrentAddressRegister; //Decrease counter!
96			}
97			else //Increase counter?
98			{
99				++DMAController[controller].DMAChannel[channel].CurrentAddressRegister; //Decrease counter!
100			}
101				
102			//Terminal count!
103			--DMAController[controller].DMAChannel[channel].CurrentCountRegister; //Next step calculated!
104			if (DMAController[controller].DMAChannel[channel].CurrentCountRegister==0xFFFF) //Finished when overflows below 0!
105			{
106				processed |= FLAG_TC; //Set flag: terminal count occurred!
107			}
108			//Process all flags that has occurred!
109				
110			if (processed&FLAG_TC) //TC resets request register bit?
111			{
112				DMAController[controller].RequestRegister &= ~channelindex; //Clear the request register!
113			}
114
115			if (processed&FLAG_TC) //Complete on Terminal count?
116			{
117				if (DMAController[controller].DMAChannel[channel].TCHandler) //Gotten a TC handler?
118				{
119					DMAController[controller].DMAChannel[channel].TCHandler(); //Send hardware TC!
120				}
121				DMAController[controller].StatusRegister |= channelindex; //Transfer complete!
122			}
123
124			//Transfer data!
125			switch (moderegister.TransferType)
126			{
127			case 1: //Writing to memory? (Reading from device)
128				if (controller) //16-bits?
129				{
130					if (DMAController[controller].DMAChannel[channel].ReadWHandler) //Valid handler?
131					{
132						MMU_directww(address, DMAController[controller].DMAChannel[channel].ReadWHandler()); //Read using handler!
133					}
134				}
135				else //8-bits?
136				{
137					if (DMAController[controller].DMAChannel[channel].ReadBHandler) //Valid handler?
138					{
139						MMU_directwb(address, DMAController[controller].DMAChannel[channel].ReadBHandler()); //Read using handler!
140					}
141				}
142				break;
143			case 2: //Reading from memory? (Writing to device)
144				if (controller) //16-bits?
145				{
146					if (DMAController[controller].DMAChannel[channel].WriteWHandler) //Valid handler?
147					{
148						DMAController[controller].DMAChannel[channel].WriteWHandler(MMU_directrw(address)); //Read using handler!
149					}
150				}
151				else //8-bits?
152				{
153					if (DMAController[controller].DMAChannel[channel].WriteBHandler) //Valid handler?
154					{
155						DMAController[controller].DMAChannel[channel].WriteBHandler(MMU_directrb(address)); //Read using handler!
156					}
157				}
158				break;
159			case 0: //Verify? Never used on a PC?
160			case 3: //Invalid?
161			default: //Invalid?
162				break;
163			}
164
165			switch (moderegister.Mode) //What mode are we processing in?
166			{
167			case 0: //Demand Transfer Mode
168				if (processed&FLAG_TC) //TC?
169				{
170					DMAController[controller].DACK &= ~channelindex; //Finished!
171				}
172				break;
173			case 1: //Single Transfer Mode
174			case 2: //Block Transfer Mode
175				if (processed&FLAG_TC) //Complete on Terminal count?
176				{
177					DMAController[controller].DACK &= ~channelindex; //Finished!
178					if (moderegister.Auto)
179					{
180						DMA_autoinit(controller,channel); //Perform autoinit!
181					}
182				}
183				break;
184			}
185		}
186	nextchannel: //Skipping this channel (used by cascade mode channels)
187		++current; //Next channel!
188		current &= 0x7; //Wrap arround our 2 DMA controllers?
189		if (startcurrent == current) return; //Back to our original cycle? We don't have anything to transfer!
190		if (transferred) return; //Transferred data? We're done!
191		goto nextcycle; //Next cycle!!
192}

Of course memory to memory transfers etc. not used on the PC are unimplemented. Comparing it to PCEm: https://github.com/MoochMcGee/PCem-mooch/blob … aster/src/dma.c doesn't look like significant differences(besides being directly using the TC, DREQ and DACK signals).

superfury wrote:

Is this good enough?

I think you have the sense of the -DISPEN bit (bit 0 of the status register) wrong. It should be 1 for the overscan/sync regions and 0 for the active area. I think flipping this bit should fix the glitching on the model identification and 1K screens and the centering on the faces image.

superfury wrote:

About the DMA controller: it's not 100% implemented, since PC software shouldn't be using all features?

I'll have to make a point of doing some more interesting stuff with the DMAC in the next demo 😀

The test that's failing in the XT BIOS just checks that it can write a word to each of the registers at IO port addresses 0-7 and read back the same word, so maybe you haven't implemented reading back correctly.

Just implemented reading back the address and count registers of DMA(also fixed the Status, Intermediate and Multi channel mask register reads to actually read their own controller instead of controller #1(8-bit controller) while needing to read controller #2(16-bit controller)). The IBM PC XT BIOS now starts checking memory, but ends with a 101?

Also, the screen now no longer flashes with most of the demo (except of course the Kefrens Bar effect). And the screen with the developers show up nicely:

So now the only problem left is the Kefrens Bar effect, which depends on accurate 8086 timing to work(and the MS-DOS prompt disappearing behind the text)?

Also, I seem to notice that the screen tears for some reason when in CGA resizing mode? Although nothing shows up when using the Direct plot setting (Forced, Fullscreen stretching), when selecting CGA display(which uses the SDL_rotozoom functionality to resize the screen to CGA or VGA(4:3) aspect ratio at 800x600 display). Also, the rendering from the resized SDL_Surface (done when the video adapter has finished a frame, on vertical retrace to be exact) to the screen happens in the same thread as the thead handling, so it cannot be a matter of threads using the same memory. It's visible during overlays when the 16 color scrolls over the ugly CGA colors and when the 1K image scrolls over that 16 color image. It looks like a square of 16x16 pixels (about 2x2 text mode characters of 8x8 pixels) not being updated in time(tearing?). So that's basically affecting the last 16 pixels of the last 16 scanlines(the scroll over effect, at the bottom right). After the scrolling moves past the 16-line point or finishes those likes look correct. Any idea what might be happening here?

Edit: Just looked up those error codes displayed:
301: Keyboard did not respond correctly
101: System board interrupt failure (unexpected interrupt)

Any idea what might have caused this? The Turbo XT BIOS doesn't say anything about a faulty keyboard or interrupt?

superfury wrote:

The IBM PC XT BIOS now starts checking memory, but ends with a 101?

This means that the TC0 status bit from the DMAC didn't go on. The 301 means that the keyboard didn't respond with scancode AA after a reset (clock line held low for 20ms).

Do you mean the TC of channel 0? Does it need to respond?

Logging keyboard input tells me the following:
Set leds 00h
Get keyboard ID(PS/2) which is ignored on IBM XT in my emulation.
Then it sends 01, 02, 03? It thinks they're invalid commands?

Is this correct? Does the reset happen using a 0xFF?

reenigne wrote:

superfury wrote:

About the DMA controller: it's not 100% implemented, since PC software shouldn't be using all features?

I'll have to make a point of doing some more interesting stuff with the DMAC in the next demo 😀

Indeed 😀
"Software doesn't use it" isn't a valid argument against implementing hardware-features in an emulator, in my opinion.
"Software cannot use it" would be something different. Eg if a certain chip has some functionality, but the registers for controlling it are not exposed to the rest of the system.
But anything that could theoretically happen on a real machine, should be emulated.

superfury wrote:

Do you mean the TC of channel 0? Does it need to respond?

Yes, because by the time this code is reached channel 0 should have caused at least 65536 DRAM refresh cycles and auto-initialized.

superfury wrote:

Logging keyboard input tells me the following: Set leds 00h Get keyboard ID(PS/2) which is ignored on IBM XT in my emulation. Th […]
Show full quote

Logging keyboard input tells me the following:
Set leds 00h
Get keyboard ID(PS/2) which is ignored on IBM XT in my emulation.
Then it sends 01, 02, 03? It thinks they're invalid commands?

Is this correct? Does the reset happen using a 0xFF?

No, like I said - on an XT, the clock line is lowered for 20ms to reset the keyboard. Unlike with PS/2, there is no standard mechanism to send bytes from the host to the keyboard.

superfury wrote:

So now the only problem left is the Kefrens Bar effect, which depends on accurate 8086 timing to work

Accurate 8088-timing to be exact.
8086 has different timings from 8088, and the effect might not work properly on 8086 systems.

Scali wrote:

"Software doesn't use it" isn't a valid argument against implementing hardware-features in an emulator, in my opinion.

Depends on what the purpose of the emulator is, I suppose. If you only want an emulator in order to run existing software then it's a valid argument. But some of us like using emulators to write new software (including software that pushes the limits of the hardware), so we want emulator authors to write emulators to run the programs that haven't been written yet!

I just added basic DMA0 support (just pulling DREQ always 1, no DACK handler and currently empty TC handler(it should affect the CPU once implemented)). It now passes the DMA0 test.

I disabled the default auto-init (executed by the keyboard) on XT systems. That should make it respond correctly with the initial 0xAA, after which normal commands can be sent (still gives 301 error though).

Now it gives me a 601 error and requests to resume using F1

1 301
2640 KB OK
3601
4ERROR. (RESUME = "F1" KEY)

Pressing F1 to that makes it boot the system(from HDD). Now only need to test 8088 MPH with it.

superfury wrote:

I disabled the default auto-init (executed by the keyboard) on XT systems. That should make it respond correctly with the initial 0xAA, after which normal commands can be sent (still gives 301 error though).

I think that's because the XT BIOS resets the keyboard more than once.

superfury wrote:

Now it gives me a 601 error

That indicates that resetting the FDC isn't giving the expected result.

Just ran 8088 MPH on the IBM PC BIOS: The demo runs normally, until it finishes, after which the command prompt still hides behind the final text. Ran using MS-DOS 5.0(either 5.0 or 5.0a).
Maybe MS-DOS is the problem? Or the CGA Cursor Location register itself(the CPU hasn't been touched during the whole 8088 MPH fixing)?

The FDC is currently acting like a 82072A(except without checks on density and gap length, to boot from diffent floppies on the Turbo XT BIOS v2.5).
https://bitbucket.org/superfury/x86emu/src/57 … ppy.c?at=master

I do have a MS-DOS 3.0 boot floppy, or does it need to be PC-DOS 3.1? Just found PC-DOS 3.30? Is that one OK too?

Edit: It doesn't seem to boot the floppy disk or be able to read anything from it. Probably because the FDC error?
Edit: The emulator can't read it because it's not able to auto-detect the geometry. It's a 162K disk image. Anyone knows the correct geomtry (160K IS supported, but it's 2K larger? 4 sectors more somehow?)? I've currently implemented it with the same geometry as a 160K disk image (1x40x8(CxHxS)@512 bytes/sector). It doesn't boot and straight away reboots.

superfury wrote:

Maybe MS-DOS is the problem?

Could be. I'm having trouble thinking of a hardware problem that could cause this symptom. We've ruled out the BIOS so DOS is about all that's left.

superfury wrote:

Or the CGA Cursor Location register itself

That's not it - that only tells the CRTC where to draw the cursor. Where the prompt appears on the screen is between the software and the BIOS.

superfury wrote:

The FDC is currently acting like a 82072A(except without checks on density and gap length, to boot from diffent floppies on the Turbo XT BIOS v2.5).

Is the reset sequence the same as an NEC u765PD? That's what the XT BIOS expects to find.

superfury wrote:

I do have a MS-DOS 3.0 boot floppy, or does it need to be PC-DOS 3.1? Just found PC-DOS 3.30? Is that one OK too?

I know for sure it works on PC-DOS 3.1, I haven't tried any others. I think the rules of this forum prohibit me from sending you a link, but it's pretty easy to find. The one from 03-07-1985 should match what I have.

superfury wrote:

Edit: It doesn't seem to boot the floppy disk or be able to read anything from it. Probably because the FDC error?

Probably!

A couple of other things to check: Do you have any TSRs or drivers loaded? (I'm thinking some versions of ANSI.SYS could mess with the BIOS cursor location but empty out your config.sys and autoexec.bat completely to be sure). Also, does it make any difference whether you start 8088mph from a command prompt that is at the top of the screen (after a cls) or at the bottom (after some scrolling)?

Can you check that the value in the CGA start address register is 0 after 8088mph finishes?

The reset sequence is that executing the Sense Interrupt 4 times to get the status of each floppy disk drive. ONLY on the Turbo XT BIOS (when detected CS:IP is in it at segment F000:IP and the header at F000:0000 matches the Turbo XT BIOS v2.5's header) it reduces the Sense Interrupt to 1 time (The BIOS has a bug that only senses one drive, then continues, and upon first drive access expects the drive to be ready (which it isn't because it's still waiting for 3 more Sense interrupts)).

There's only 2 driver TSR loaded: Low-Tech EMM driver (ltemm.exe) for the 2MB EMS board and the mouse.exe from MS-DOS 5.0 afaik. But that's been there since the beginning. Also the XT-IDE BIOS is used (for HDD support).

I'll check the start address now(MS-DOS 5.0 on the first revision IBM PC XT BIOS)...
Edit: The start address is set to 0. The cursor location is 03CB(Little endian order, Cursor address high=03, low=CB).
Edit: Found a IBM PC-DOS 3.10 image of 155031 bytes? It's a strange number (not a multiple of 512 or 1024 bytes large)? Thus the emulator can't determine it's geometry.

superfury wrote:

The reset sequence is that executing the Sense Interrupt 4 times to get the status of each floppy disk drive. ONLY on the Turbo XT BIOS (when detected CS:IP is in it at segment F000:IP and the header at F000:0000 matches the Turbo XT BIOS v2.5's header) it reduces the Sense Interrupt to 1 time (The BIOS has a bug that only senses one drive, then continues, and upon first drive access expects the drive to be ready (which it isn't because it's still waiting for 3 more Sense interrupts)).

Ugh, hacks like that are terrible - the hardware can't read the BIOS and change its behaviour based on the result. If the Turbo XT BIOS expects some particular behaviour from the hardware, the original IBM XT BIOS probably does too. Other than that, is the 765 returning the right sequence after being initialized with command 3?

superfury wrote:

There's only 2 driver TSR loaded: Low-Tech EMM driver (ltemm.exe) for the 2MB EMS board and the mouse.exe from MS-DOS 5.0 afaik. But that's been there since the beginning. Also the XT-IDE BIOS is used (for HDD support).

The bug has been there from the beginning too...

superfury wrote:

Edit: The start address is set to 0. The cursor location is 03CB(Little endian order, Cursor address high=03, low=CB).

Hmm... just thought of something else. Are you running 8088mph from autoexec.bat? Or from another batch file with "echo off"? Perhaps that's what's causing this.

superfury wrote:

Edit: Found a IBM PC-DOS 3.10 image of 155031 bytes? It's a strange number (not a multiple of 512 or 1024 bytes large)? Thus the emulator can't determine it's geometry.

Does it look like compressed data if you load it in a hex editor? The one I found was a .7z with two 360kB images inside.

You're right, it's actually a 360KB image zipped in a imz file when opening in 7-zip 🤣.
Yes it's called by autoexec.bat, which starts with @echo off, jumps to the second (games) harddisk(d:) and calls it's autoexec.bat. That autoexec.bat also executes @echo off, after which is changes directory to 8088MPH and executes 8088MPH.EXE.

And isn't the 765 supposed to be expecting 4 Sense Interrupts after it's reset? Originally based on: http://www.brokenthorn.com/Resources/OSDev20.html
Looking at:

Initializing the FDC

During a controller reset, you need to reinitialize the controller. After resetting the controller, it will fire IRQ 6. After it has been fired, you must send a SENSE_INTERRUPT command to all drives connected to the FDC (by calling flpydsk_check_int 4 times.)

So does it only require 2(the amount of drives installed in the emulator) or all 4 sense interrupts(all possible drives, whether connected or not) to become active (and report as being ready)?

Edit: Just changed the amount of Sense Interrupts to 2 (drive 0&1) without looking at the BIOS ROM installed. The floppy disk now boots and detects without problems? So it's just a matter of installed floppy drives?

Edit: Just ran it from PC-DOS 3.1 from the command line (not autoexec.bat). It will now appear at the right location, scrolling 8088 MPH one character row up.
Edit: Now testing with Turbo XT BIOS v2.5. It isn't able to use the second HDD(8GB partitioned in a 2GB partition), since it's probably too large for it (or unknown system of storage, as it detects it as non-DOS). It detects the windows 3.0 harddisk (which also contains Hocus Pocus) fine though. Currently testing using PC-DOS 3.1 with a second floppy drive containing 8088 MPH.
- The IBM logo slows down a lot, being unable to finish before continuing the demo(only about 2-3 turns).
Edit: MS-DOS 3.1 from the command prompt (non-autoexec.bat) also ends at the next row as it's supposed to. Now to test MS-DOS 5.0...

Edit: There's still the case of the "+" in the table column seperation not being positioned exactly right:

Edit: It seems the "+" sign is correct after all according to other videos of 8088 MPH? It IS displayed one pixel too far to the left on a real CGA+XT BIOS.

The FDC doesn't expect any number of sense interrupts. If the drive polling status changes it will give you the status of all 4 if requested but it isn't required. In fact you don't need to do a sense command at all after a non-read/write interrupt. Any byte written to the controller will clear the interrupt (you can trust me on this, I've tested it on a real 765 while working on the x68000 emulation which does unspeakable things to the fdc).

Just tested 8088 MPH in all those situations (both BIOSes with PC-DOS 3.1, Turbo XT BIOS with MS-DOS 5.0) from the command prompt. All work as supposed to do (starting a new line with the command prompt on it).

It seems that problem is indeed either caused by the @echo off in the .bat file, the autoexec.bat itself (or .bat file called by it or it's children processes(also .bat files)) or both of those combined(either/or). So it isn't a bug in my emulator.

So I should just set the polling for 4 status interrupts, where some things clear that status? What's supposed to clear the status interrupt requesting(counter counting down from 4 to 0 and then returns the status to normal when 0)? Any command other than Interrupt Sense sent to the controller? If the program wants to check if it's busy(for Interrupt Status execution), it shouldn't clear the status when reading the controller status (MSR)? So only clear when a command is sent that's not a Interrupt Sense?

You can really probably just clear ready status changed for all the drives when a new command if sent to the controller (this only works though for machines which don't connect the drive ready line).

reenigne wrote:

Depends on what the purpose of the emulator is, I suppose. If you only want an emulator in order to run existing software then it's a valid argument.

If it is a well-specified subset of existing software, then yes.
But in practice, you simply can't categorize everything that all existing software out there requires.
So a much more pragmatic approach to run all existing software is to just try to emulate the hardware as accurately as possible.