VOGONS


Reply 20 of 55, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

30 wait states? As in 30 cycles for accessing 8bit value from memory? That is incredibly slow.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 21 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just been thinking: could bit 0 still be 'enable cache' bit? Simply OR in 1 to the values in my previous post(0x01. 0x0F, 0x17, 0x1F) to apply speeds with caching enabled?

Edit: About the 30 wait states: remember, it's a 80386 running at 16MHz, so it's probably to slow it down to get within the 8088 4.77MHz ballpark?
Also, this matches information about the normal XT BIOS being slow as hell during POSTing?

Say an instruction is 4 cycles 8088/3 cycles 80386(NOP)@16MHz. Add 30 cycles to get 33 cycles@16MHz. (33/16000000)=2.0625us.
((14318180/3)*4)=0.8376us.
Hmmm, the speed isn't exactly close, but about a 11.75MHz 8088?
Edit: Correction, it's inversed, not multiplied, so about an 1MHz 8088? 4 times as slow as an XT, which explains the slow POST I read on various wikis?

Edit: According to what I've read, the wait states don't apply to memory: they apply to the CPU itself. So for each clock cycle, it waits 30 cycles more. So it's running at 1/31 of 16MHz? Thus 516.13kHz 80386? Thus 1.9375us for a 3 cycle NOP? So it's about a 8088 @2.38MHz?

So state 3(1/17) should be in the 8088 ballpark?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 22 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've just fixed a little bug in the prefetch routine, which was executing data reads(memory mode 1) instead of instruction data reads(memory mode 3). The same applied to all memory reads in the normal processing and protection checking(in CPU_readOP()). Now the Inboard 386 driver crashes on #GP faults due to executing(parameters of) instructions at F000:10000, causing segment limit faults? So something is going terribly wrong here? The trap fault and DR0-7 register breakpoint emulation shouldn't be triggered (I assume it doesn't set any breakpoints or T-bit in the first byte of the TSS)? Otherwise, nothing has been changed? Or is it trying to execute the BIOS in protected mode for some reason? It seems to happen when it has checked 640K base memory.

New 80386 protected mode breakpoint emulation: https://bitbucket.org/superfury/unipcemu/src/ … ing.c?at=master

Edit: Could it be that the software requires the Virtual 8086 mode monitor to work? I haven't implemented Virtual 8086 mode PL0 interrupts themselves yet(IRET should be (largely, at least) emulated, though). Although IRET popping the segment registers from the stack isn't implemented yet.

Edit: Implemented the Virtual 8086 mode completely now afaik. Also fixed a little bug that caused the T-bit in the TSS, with a NULL TR register, to cause breakpoint exceptions.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 23 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

Well, for some reason, Megarace on AT 386 now crashes with strange output:

349_megarace_386_20170308_1936.jpg
Filename
349_megarace_386_20170308_1936.jpg
File size
7.9 KiB
Views
1200 views
File comment
Megarace displaying strange characters on the screen?
File license
Fair use/fair dealing exception

The Diagnostics port has the value 1D for some strange reason? Is it trying to enter Protected Mode and failing for some reason?
Also, the AT BIOS gives a "102-System board error" before booting, for some unknown reason(is essentially a 386 running at 286 speeds @6MHz)?

Also, Windows 95 setup simply hangs still, just like before.

The SuperSoft AT BIOS now doesn't display an INT#XX anymore in the bottom left corner, but does beep and show the old error 1 on the protected mode test(6 beeps, 1 beep)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 24 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

I'm struggling with something: What is the effective operand/address size when CS is reloaded? So during extra push/pop operations(different kind of gates), how does the CPU determine to push/pop 16/32-bit address/data? Also, what's the effect of operand/address size overrides in these cases? I can't find anything on the net about that(typical cas of "you're a programmer, you should already know this", thus not mentioned anywhere)?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 25 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried the Inboard 386 driver again. It keeps complaining about 640K+64K bad memory? Also, how does it disable the ROM area and enable the RAM in the High Memory Area? Anyone knows of this?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 26 of 55, by crazyc

User metadata
Rank Member
Rank
Member
superfury wrote:

I'm struggling with something: What is the effective operand/address size when CS is reloaded? So during extra push/pop operations(different kind of gates), how does the CPU determine to push/pop 16/32-bit address/data?

The D/B bit in the descriptor sets the operand size. So if B is set in SS, it will push 32 bits unless there's an override.

Reply 27 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

So the D/B(B in case of SS) bit in the SS descriptor selects between ESP and SP? And D/B(D in case of CS) of CS selects between pushing EIP/ESP/EFLAGS and IP/SP/FLAGS? Or does the D/B bit of SS do this for the latter case? Also, what about RETF, which pops these values from the stack?

If it's the first two cases, this should now be properly emulated. D/B of SS is used to select between ESP and SP, while D/B of CS is used to push 32-bits or 16-bits registers to the stack.

Edit: After fixing some bugs in the CALL/RET/INT/IRET mechanism(applying SS instead of the incorrect SP, support for interlevel INT/IRET from&to protected mode software), the BIOS now gives 6 long beeps 1 short(Cannot initialize monitor?), 3 long beeps 1 short(Keyboard controller?) during the Protected Mode test of the SuperSoft/Landmark AT Diagnostic BIOS?

IBM AT BIOS gives 104-System board error on 80386.

Edit: Running Megarace on the IBM AT BIOS reveals that's it's faulting on a REP MOVSD instruction past the segment limits?
Edit: Looking at the reporting of CS/(E)IP, it seems it was restoring EIP, but not CS before launching the fault handler, resulting in a possible invalid return address(CS segment not restored, EIP pointing to the wrong segment).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 28 of 55, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie
superfury wrote:

IBM AT BIOS gives 104-System board error on 80386.

BTW, which IBM AT BIOS are you using? If it is the one from minuszerodegrees (and the one I gave you the source code to) then it is from IBM 5170 and that expects a 286 and will never use 32bit segments and the GDT/IDT/LDT formats are of those the ones in 286 not 386.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 29 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

The BIOS I'm using is the revision 2 BIOS of the AT. Looking at the raw ROMs in a hex editor, it's dated 06/10/85? So it's a rev 2 BIOS(type 2 motherboard)?

When trying to run Megarace(a 386 program), it crashes in the BIOS with a REP MOVSD instruction faulting because of an invalid real-mode ESI register(ESI>0xFFFF). This causes it to keep faulting into an error handler, which eventually returns to the REP MOVSD faulting again etc.

Shouldn't the 80386 be fully compatible(except timings) with the 80286? It should be backwards compatible? All 80286 instructions working the same(although the unused bits of the GDTR/IDTR are defined now, as well as undefined bits in the descriptor tables), provided that the undefined bits are left with zeroes?

Also, there apparently exists a Inboard 386 AT as well, thus the BIOS should be able to handle a 80386?

Edit: I think the ROM i've compiled seems to be incorrect(I didn't add the .lst file that's used in the compilation process, using nasm 2.12.02_x86 with the disassembled source code at pcjs.org:
https://github.com/jeffpar/pcjs/tree/master/d … o386/1988-01-28

I installed the latest version of nasm, then executed:

nasm -f bin 1988-01-28_deskpro.asm -o tmp/1988-01-28-regen.rom

Although I removed the -l 1988-01-28_deskpro.lst, because that wasn't in the repository?

Edit: Just used this tool to convert the hex files back to raw files. These generate proper binary files(where the content is recognisable, with proper date and size etc.). It seems the ROMs I've used were incorrect when recompiled this way?

Judging from the information on the page, 109591-001 is the odd ROM, thus u15. The other is 10592-001, thus the u13 ROM?

Edit: Just verified with UniPCemu: the initial jump instruction is correct, jumping to the next, correct, instruction:) Thus I now have the 1988-01-28 (from a 386/16 motherboard) ROM to test my 80386 with. I've already implemented the special memory address listed in Bochs' IOPORTS.LST file, thus it should be able to run?

Edit: It seems to be processing MDA I/O ports for some reason(3B4/3B5)? Why isn't it using the IBM VGA ROM?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 30 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

After modifying the 8042 Input Status port to contain Compaq-compatible values, it now switches to ports 3D*h, but still no VGA ROM is executed instead?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 31 of 55, by CimonVG

User metadata
Rank Newbie
Rank
Newbie

hello
some what of topic, but in the same alley.
I use alot of time with the original hardware Inboard 386/pc, with the 4mb module and got the Inboard386 to run win32s and have tried the windows 95 instalation a few times. I am not a programmer, so kind of stuck with the windows 95 instalation. With a clone motherboard and Phonix bios i did install the windows 95 and did a hardware scan, but at first reboot the windows 95 halted 😒
If you have any idears how to get it running with the windows 95 - i would be very grateful 😀
Note - have you looked at the "windows 3.0 for inboard" it has some custom drivers , and the perhaps give clues how the hardware works ? 😀
If you have any test for the hardware Inboard386/pc and 4mb please write back - in limit amount i would gladly try code on the hardware, if you have tests to be done.

/cimonvg

Reply 32 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just found a little bug in my x86 stack handling: a stack access(including those during interrupts) could be overwritten to another segment when using a segment override for the current instruction. This causes the AT BIOS to triple fault due to trying to access the stack(to push IP, CS and flags of the originating instruction) with an ES segment descriptor and SS segment selector. Thus faulting on the invalid 'stack access', causing a double fault, which tries to call the interrupt handler, which faults again due to the very same bug, resulting in a triple fault. This is the 104-System board error reported by the AT BIOS. Now this bug has been fixed, the error isn't displayed anymore. Only the keyboard and floppy disk errors(as well as uninitialized BIOS SETUP(please configure) 'error') remain on that part of the booting process(of the IBM AT BIOS).

Megarace(which I'm testing on the AT BIOS with 80386 CPU) still hangs on a MOVSD instruction with offset>0xFFFF(DS register limit), which breaks limit rules, causing a General Protection fault, which eventually restarts the same MOVSD instruction(by IRET). This causes the function to infinitely fault. Anyone from the Dosbox crew knows what might cause this? Why is the DS segment descriptor still containing real-mode values?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 33 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've made a little log of the Compaq BIOS running on my 80386(with minimal 8042 Compaq supported(essentially AT 8042 with Compaq-compatible Input Port to improve graphics cards)) emulation:

Filename
debugger_80386_20170313_1546_CompaqBIOS.zip
File size
3.47 MiB
Downloads
54 downloads
File comment
UniPCemu's 80386 running the Compaq Deskpro BIOS dated 1988-01-28.
File license
Fair use/fair dealing exception

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 34 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just tried win95 setup again(dutch version). It has the same problem as Megarace it seems: it tries to execute a REP MOVSD to transfer memory from DS(0000):SI(5700) to ES(0000):DI(0000). ESI=5700, EDI=110000. I assume that EDI doesn't have such a high address(1MB+64KB) for nothing, but the execution results in a #GP fault due to using an offset >0xFFFF. The instruction address is 025D:0894. Anyone knows what might be the cause here?

Edit: The address size is 32-bit. So it's using EDI and ESI to form the source and destination addresses. All segment registers are loaded with 0xFFFF limit, so it's still using real-mode compatible values?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 35 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

While checking the INC/DEC instruction behaviour and fixing the 80386 instruction behaviour, I've noticed that the INC/DEC instructions were behaving odd(Carry flag checks failed). This has now been fixed. Also the 0xFE instruction didn't apply it's timings(or any timings, for that matter, essentially executing in 0(default) cycles). Now 8088 MPH reports a different speed altogether? Inc/Dec also didn't apply all required flags(also set the Carry Flag, which isn't supposed to be used in that instruction). Now the 8088 MPH metric cycle count changes to 1504(10%)? So with this last fix, it's become less accurate? Reenigne?

Edit: Although the demo speeds up during certain parts a bit now(may also be due to other changes to the emulator besides the CPU itself, which hasn't changed much(timing-wise)), the ending song sounds a lot more quiet, with the noise being reduced to a less noticable low buzz.

Edit: Looking at the sound recording, it looks like a signal containing lots of little sawtooth waves(viewing the recording in audacity).

This is a recording made using the emulator's recording functionality: https://www.dropbox.com/s/k0qrm7rh88ipmlk/808 … 5_1355.zip?dl=0

Although there seems to be a slight 0.5 second delay between the output being produced and me hearing it(output lag?). Or is this simply because I'm working using RDP?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 36 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've implemented the EISA timer chip(copy of the normal PIT timers) at ports 48h-4Bh, with ports 48h-4Ah being the three timer counters(see ports 40h-42h) and port 4Bh being the status/command port(see port 43h). I've also implemented the diagnostics port on the Compaq Deskpro 386 architecture, which is now generating the following log, when enabled to log:

00:00:28:66.06976: POST Code: 00
00:00:28:66.07512: POST Code: 01
00:00:28:66.07538: POST Code: 02
00:00:28:66.07548: POST Code: 03
00:00:28:66.07554: POST Code: 04
00:00:28:66.08334: POST Code: 05
00:00:28:66.08878: POST Code: 06
00:00:28:66.08900: POST Code: 08
00:00:28:66.09000: POST Code: 09
00:00:28:66.09040: POST Code: 0F
00:00:28:66.09080: POST Code: 10
00:00:28:66.09102: POST Code: 11
00:00:28:67.00082: POST Code: 12
00:00:29:23.04504: POST Code: 13
00:00:29:23.05478: POST Code: 14
00:00:29:23.05494: POST Code: 15
00:00:29:23.05514: POST Code: 17
00:00:29:23.05520: POST Code: 18
00:00:29:23.05526: POST Code: 40

So it crashes on some watchdog timer, which doesn't exist it seems? It eventually terminates the application (which is currently enabled in the build) because it detects an #UD fault.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 37 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

If I would have to believe http://www.matrix-bios.nl/checkp/cpq_386.html , the log above means something is going pretty wrong?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 38 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just fixed XT 286+ CPU compatibility with HIMEM.SYS: it was hanging because Port 61h wouldn't be handled correctly, thus not toggling bit 4(toggles on each DRAM refresh request). Since it now toggles, HIMEM.SYS won't hang while waiting for it to toggle, thus continueing with a message that the A20 line couldn't be activated(Inboard 386/XT has a different method to do this(probably in the Inboard 386 driver))?

Edit: Also, for some reason during The Secret of Monkey Island's Scumm Bar room, there's nobody hanging on the chandelier swinging in cicles? Does this have anything to do with the x86 bug?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 39 of 55, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've been thinking a bit lately.
Some functionality is still unimplemented.
Mainly, INBRD.SYS has some interesting options:
EGACACHE: Switches the EGA ROM to run from Inboard RAM instead.
NOCACHE: Execute the BIOS ROM from ROM instead of Inboard RAM

So basically, NOCACHE behaves inversed of EGACACHE wrt to the driver.

Then, looking at the RAM map the documentation gives is interesting:
0-640K: Conventional memory
640-784K: Reserved (this is VGA RAM A000-BFFF segment)
Then randomly EMS memory
960K-1M: BIOS ROM
1M-3.25M: Extended memory

Interesting, it also mentions 128KB reserved memory, probably for the ROMmed RAM remapping. That matches the extra 0.25M on top of RAM?

Last edited by superfury on 2023-02-27, 07:42. Edited 1 time in total.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io