I've just updated the Inboard memory map to behave as specified in the previous post, with 128KB RAM being reserved (like on the Compaq's 384KB RAM) and made it able to be mapped as RAM, ROM or unmapped.

Now I'll need to figure out how the software performs the mapping and unmapping (although by default it's unmapped, thus mapping to the ROM).
Edit: OK. Just fixed the reserved 128KB RAM mapping. It's able to be mapped in write-protected RAM, RAM and unmapped mode (thus resolving to any ROM that's there).
Edit: Just implemented support for the inboard to be able to unmap the UMA BIOS ROM and Video BIOS ROM.

Now I'll just need to figure out how the Inboard actually disables those ROMs and replaces them with the Inboard RAM (to be exact, how it facilitates that using I/O port accesses).

Edit: OK. Managed to get the driver loading copied (although the installer fails somehow) and the config.sys setup for testing (in all four configurations: basic (no caching), BIOS ROM caching, EGA ROM caching and All ROMs cached (so both BIOS and EGA ROMs).

Then ran the drivers. It of course told me it has 128KB of non-working RAM (probably the onboard reserved RAM) and 256KB extended RAM (which matches documentation for a 1MB board).

Hmmm... I do see it writing to 5E0000-5FFFFF at least? That's far after the last bit of installed RAM?
Edit: Mapped it to reserved RAM (beginning of implemented RAM, which is reserved for this purpose).

The driver keeps reporting all but the four top memory chips in the top-left corner (first four columns, except first row) as bad?

Hmmm... Disassembling the INBRDPC.SYS driver, then it's INIT call (according to MS-DOS 2.0 documentation), eventually on the 10th testing function called (out of 16), I see it's enabling the bit 0 of register (I/O port) 670h when performing the REP CMPSB, pretty much confirming it's involved with the caching somehow?

But when copying it beforehand, it doesn't seem to be setting the bit?
Perhaps writes are always routed to it's RAM and reads only to RAM instead of ROM(and in the case of reads from RAM being mutually exclusive to writes to obtain a ROM behaviour?).
So when bit 0 is cleared, writes are to RAM and reads from ROM. That explains why it isn't setting the bit at that point. And when it's set, the ROMs are ignored and routed to RAM, with writes being ignored? So it's toggling between write-only(0) and read-only(1) modes?

I've tried that solution. Unfortunately, the RAM test for the 'Extended memory' still fails even with that implemented.

Now, the specified reserved RAM isn't even touched at all. So there's probably something unknown going on still.

I did manage to get the failing test tracked down within the driver:
https://www.dropbox.com/s/ssgw4v80i38g7c1/INBRDPC.i64?dl=0

It's the 9th test that's executed in the main INIT function loop (so 8 tests before that, since it's numbering in my disassembly is 1 through 15). It's labeled 'testnumber9' in my IDA project (starting at B8C:9908 in UniPCemu under MS-DOS 6.22) with only the driver itself left loaded.

The config.sys is fairly simple (first statement done using an INCLUDE statement):

1SWITCHES=/k
2DEVICE=INBRDXT\INBRDPC.SYS NOCACHE

Just disassembled the driver a lot more.

Pretty much all the INIT tests are now almost fully disassembled, ready for observation.

UniPCemu seems to be failing some 1MB+ extended memory tests for some reason?
I do see it outputting (in the code at least) 0 and 0x80 to I/O port A0h (which is a second interrupt controller on a AT, but a XT doesn't have any?).

It does do a lot of memory read/write tests on the RAM though (in protected mode, but don't know how far it gets with those yet)?

I've just managed to finish the tests where it's failing in UniPCemu (test number 9 to be exact is where it's failing).

I really think that the weird 5E/5Fh 64KB segment (so memory area 5E0000-5FFFFF) is something weird for it to be addressing always.
Perhaps it has something to do with the ROM shadowing it's performing? It seems to match a slightly different scheme compared to the other tests (the other tests set different bits in their error variables (bit 0 to be exact), while this tests sets bit 1 in those instead). Those error bits being different aren't just for the normal tests (the writing and reading back data from memory and checking for errors). That applies to the bits for the I/O memory check of the PPI chip of the XT as well.

That test is a very suspicious one, probably the one that causes the weird error in UniPCemu at least?
Edit: OK. Managed to get all of those tests (up to test number 15) of the Init function disassembled and documented so far.

Although the I/O to port A0h is still suspicious, the remaining tests after test 9 are just reading of various ROMs and adjusting interrupt vectors to itself (hooking them).
Thus:
test1: display initial labels
test2: test processor flags register
test3: validate running in real mode
test4: detect if driver is already loaded
test5: parse command line
test6: various waitstate parameter checks
test7: some 640KB memory test
test8: setup protected mode IDTR storage and some small memory storage
test9: extended memory checks and ROM(as well as RAM emulating ROM) checks.
test10: seems to copy the BIOS ROM to 5F0000 and perform some interrupt hooking logic on the IVT.
test11: setup speed setting
test12: performs EGA ROM shadowing
test13: install disk speed interrupt handler
test14: install IRQ1 handler
test15: install #UD handler

Edit: Managed to get most of the driver disassembled and documented somewhat (at least the parts that matter).
Afaik the only unknown function in the driver is some print string function at address BABE (LOL). You'd almost think that's intentional 🤣

The 5Eh 64KB segment (so at 5E0000h in physical memory) seems to be the most interesting.
Especially when you notice that 5F0000h seems to have something to do with the BIOS ROM part in test 9 (according to it's GDT when performing the copying using INT15h). That would probably make 5E0000 the base of the EGA ROM before it's remapped?

Edit: Making a memory dump and looking at those error flags, at 34978 in the memory dump (B8C:90B8 (14978 in linear memory) as seem from the emulator, which is displaced by 128KB reserved RAM (for the ROM shadowing) upwards), it reveals the error data stored in the error variables: condition 02h (which means it's the 5E/5F 64K area that's faulting) and erroring bits 00000004h in it's 32-bit read/write errors.
That's a weird place for it to be faulting? The memory should be mapped in (due to the port A0 being 0 while testing the memory area). So it shouldn't fault?

Edit: OK. So it's writing the patterns to memory (fist all ones, then all even bits (01010101b), then all zeroes. But in all cases, the memory somehow keeps being stuck at all-ones? Even though the memory should actually be there? Hmmm...
Edit: OK. So the memory is unmapped for some reason.
Even in that case, looking further it's just enabling the NMI interrupts to take place using port A0h on the XT.

OK. After that, permanently mapping the reserved RAM area to address 5E0000-5FFFFF makes the memory tests succeed and the driver install.

Still, it's unknown exactly how the driver implements it's ROM shadowing to become active?

Edit: It looks like it performs the BIOS ROM shadowing simply by setting the 'cache' bit in the 670h I/O port (which is it's bit 0).
That seems to properly make the driver use it and start caching it in RAM without errors.

The EGA ROM however doesn't seem to be cached in the same way (as in being a ROM). It's actually cached by copying it into the driver's own memory (within a 64K block of memory inside it's own code, at offset F00h). So it's not actually a ROM memory it seems, just a local copy with the INT10h vector routed through through the driver's normal RAM it's installed in for both (by hooking the interrupt to it's own handler and the EGA ROM being copied in it's own location inside the RAM the driver is located in (which is actually writable by software)).

So now, at least with regards to the INBRDPC.SYS driver, everything seems to be properly emulated on the hardware side.
If the EGA ROM can be cached in a hardware way instead of a software copy is unknown, though.

Of course, having all that working I had to try:

Of course, with all caches in the driver enabled for maximum speed (INBRDPC.SYS using EGA and BIOS ROM shadowing with fastest CPU speed setting (though it has no effect in IPS clocking mode, it will have effect on cycle-accurate mode)).

It seems to complain about some sound driver dll not loading when starting the app, but the Adlib sound works without issues?
Keyboard and mouse(with mouse.com loaded) run fine as well.

Plain vanilla Doom seems to run somewhat, until the main menu. Then it doesn't seem to respond to key inputs?

I am starting to wonder though...

Is it possible that bits 6 and/or 7 of the register at 670h have some sort of function as well?

Perhaps one of them is the EGA shadowing counterpart of bit 0(BIOS ROM shadowing)? And there's another bit left, perhaps just enough to unmap the 5e0000-5fffff memory area altogether for compatibility?

Anyone?

superfury wrote on 2023-03-05, 14:02:

Of course, having all that working I had to try: […]
Show full quote

Of course, having all that working I had to try:

SC2000_ET4000_W32_SC15025_Inboard386PC_XT.png

Of course, with all caches in the driver enabled for maximum speed (INBRDPC.SYS using EGA and BIOS ROM shadowing with fastest CPU speed setting (though it has no effect in IPS clocking mode, it will have effect on cycle-accurate mode)).

It seems to complain about some sound driver dll not loading when starting the app, but the Adlib sound works without issues?
Keyboard and mouse(with mouse.com loaded) run fine as well.

Plain vanilla Doom seems to run somewhat, until the main menu. Then it doesn't seem to respond to key inputs?

I see the same behaviour with doom on actual hardware and fastdoom, I assumed we’re hitting the keyboard issue we see in other software. Is this the a20 gate at play? Similar behaviour observed with attempting to run the AT version of the bios extender to add a FDD drive 2M-ABIOS but if you add INT13 to the command line the keyboard isn’t lost (but bios extender still fails as meant for an AT class machine).

Not sure if it’s this same CMOS checksum causing issues mentioned here?

Similar again if you attempt an upgrade from Win 3.1 (using the intel 3.0 inboard drivers) to Win 3.11 it works with mouse but not keyboard. This is the keyboard issue we seem to experience in all these instances. Would be good to understand it further.

It’s one of the blockers to go beyond 3.1

I’m guessing the software is expecting something AT like but it’s not present on the XT with the inboard.

This is why I was exploring the stuff from Al Williams and the nuances of the inboard differences.

Be good to crack that one!

Started the same kind of thing of IDA project for the Inboard AT driver as well (could cross reference a lot already (with some differences) based on the XT one):
https://www.dropbox.com/s/gspnnrgaw7lyduo/INBRDAT.i64?dl=0

Managed to get most of the driver disassembled (some parts plainly refused to get converted to functions (like the installed IVT handlers themselves).

Did(n)'t see two things though:
- Only one new unknown register observed at I/O port 164h (unknown, something to do with speed setting (0-4) indexed from a table it seems, values 25h, 00h or 80h written).
- Doesn't seem to perform memory tests? That's weird?

OK. Just named the remaining functions (BABE functions (some kind of conditional string instructions, don't know their purpose) and a new hex2int function called by the commandline functions).

The BABE functions do weird things like reading and/or writing based on reads from the screen. I don't know what those are for exactly yet.
Other than that, both drivers are now (although the AT might be in less detail) having all their function names (by interpretation of roughly what they're doing, the BABE functions being an exception, called so in the AT version because the XT version were called like that (which was only because it's starting at address BABE and needed a name)).

Other than that, the AT version really doesn't seem to have much extra functionality to the XT. It has less functionality, if any.
It does support adjusting the EGA reported RAM in the BDA(using widely documented bits, just simple google the BDA to get the 64K memory count blocks in the BDA as a 2-bit field in there), but unlike the XT version it doesn't seem to use or have any reserved onboard RAM or RAM testing of any kind (as in none at all! All memory is 100% unchecked (although this might be because the AT will do that itself during it's POST))?

Basically all the support in the registers according to the AT driver seems to be just the speed setting (and some extra register which is only used in the speed setting applying function)?

Edit: Also, for the exact values written for all 4 speeds to the two I/O ports are (little-endian, upper byte is port 674h, lower byte is port 670h):
0=2500h
1=8000h
2=0001h
3=8001h

So, assuming that the waitstates for speeds 0-3 are as follows (in byte registers 670h(low)/674h(high)):
0=2500h
1=8000h
2=0001h
3=8001h

OK. I've just added a simple implementation of the Inboard 386/AT to perform those four waitstate values based on bits 674's highest bit (routed to bit 0 for values 1/3(set) vs 0/2(cleared)) and 670h bit 0 (routed to bit 1 for values 0/1(cleared) vs 2/3(set)).
Then just added a simple translation table to waitstates from that 2-bit value:
0=94 waitstates
1=47 waitstates
2=24 waitstates
3=0 waitstates

The speed itself defaulting to #0 atm (don't know what's appropriate on an AT that requires a certain speed to boot though(cycle-accurate requiring 286 BIOS (rev 2 motherboard emulated))).

Mike1978 wrote on 2023-03-07, 08:34:

Similar again if you attempt an upgrade from Win 3.1 (using the intel 3.0 inboard drivers) to Win 3.11 it works with mouse but not keyboard. This is the keyboard issue we seem to experience in all these instances. Would be good to understand it further.

I assume this is about PS/2 mouse+keyboard ?
If so, then there's a possible workaround.:
The MS Mouse 9 driver diskette contains a Windows setup program
which also replaces the keyboard driver by a modern version that works differently.

I'm not sure if it's applicable to the Inboard situation, though.

The PS/2 keyboard/mouse virtualization in Windows 3.1x is very complicated.
Especially in 386 Enhanced-Mode.
The original idea was to share keyboard/mouse among multiple DOS programs, AFAIK.

More background information here:
http://www.os2museum.com/wp/jumpy-ps2-mouse-i … de-windows-3-x/

Edit: There's something else that comes to mind.
Compaq laptops like the Contura/Aero had issues with mouse/keyboard on WfW 3.11, but worked with Win 3.10.
There were updates available by Compaq (Softpaqs), I vaguely remember.
The site https://remember.the-aero.org/ has information/drivers..
Edit: It might be CPQVKD.386 (SP0738.zip)..

PS: Good luck! 🙂👍 You guys are doing a very good job here!

Wrt the CPU emulation, I've just improved the BIU somewhat.

It's now able to read/write 64-bit chunks of memory (although performed in a 4-byte, immediately changed to 1-byte write, followed by 1-byte chunks atm, the BIU doesn't handle it that well yet, due to being unable to break it into straight 4-byte memory writes (instead first a 4-byte out of 8-byte 'try', followed by 7 1-byte breakups seperated in processing by 4 byte alignments (so that results in 4-byte write+4 1-byte writes during the first memory transfer cycle and 4 1-byte writes on the second dword on the second memory transfer cycle). Of course those memory transfer cycles themselves can have waitstates or anything else imposed by hardware as well, slowing transfer down more.
So on a 386SX (the 'reduced bus' variant setup in the settings) such a qword write would take 4 memory transfers (each transferring 16-bits in 8-bit chunks, with the first word also writing a 16-bit chunk which is retried for the 2nd byte only on the same cycle), each taking hits from waitstates accordingly. So assuming 1-waitstate RAM, that would take 16 cycles to fully transfer such a byte on a 386SX.

Also, the BIU can now, if directly addressing memory without the paging unit TLB used for translation, perform proper 64-bit memory addresses.
That means that the BIU can now reach past 4GB RAM with required memory accesses (although that would be mainly used for the Paging Unit itself once that's implemented (using it's PAE support on newer chips emulated).

The new 64-bit data accesses (both paged and without paging unit) thus can provide the Paging Unit with the 64-bit memory accesses it requires for the PAE paging methods.
Another nice thing is that because it can read 64-bit values from arbitrary places in RAM now, the CPU can actually perform any segment descriptor (from all possible tables) through the paging unit using the BIU now, once that's implemented into the EU part of the CPU emulation (currently both the paging unit(direct memory accesses bypassing the BIU timing etc.) and the descriptor fetches (stores using plain 1-byte accesses, since other bytes are essentially unmodified during the rmw operation of loading a segment descriptor (only access rights byte is modified, mainly the accessed(segment register) and busy(tss) bits)) using the tlb method instead (through the paging unit, as intended).
The whole rmw operation is already interruptable, although it just locks the bus and then freely reads/writes the descriptor location in RAM bypassing the BIU atm.
The same kind of bus locking and directly accessing RAM (which by definition is always aligned in the case of the paging unit) is also performed by the paging unit itself.

The main issue lies in seperating paging unit (32 or 64-bit accesses) vs descriptor cache (64-bit accesses for reads or 8-bit for writes) vs normal memory accesses (any size but 64-bits, except the MOV CR3 instruction on Pentium Pro and up (due to it loading the 4 PDPT 64-bit entries from RAM in a locked fashion)).

Fantastic effort I saw you finished the emulation:

https://superfury.itch.io/unipcemu/devlog/515 … 833-is-now-live

Great job!