So I would need to change ALL bitfields used in my emulator to bytes/words/dwords/uint_64 and use a support

1#define getbits(field,shift,mask) ((field>>shift)&mask)
2#define setbits(field,shift,mask,value) field=((field&(~(mask<<shift)))|((value&mask)<<shift))

to access each of the bitfields in order to keep it cross-compiler compatible?

Quite a lot of those bitfields are already used in the cases different structures use bits of data(literally). Like the CPU structures(x86 descriptors) and the floppy disk registers. Also the CMOS values use them.

I have no good answer to that. I know that for bytes, for example when data is transferred from device to another, there are two versions of bitfield byte defined, where one goes from bit0 to bit7, and the other one goes from bit7 to bit0, and the correct one is used on each device.

When you want to access for example a bit named ReadyFlag in StatusByte, you might define ReadyFlag as bit7, so no matter if the bit7 is the first or last defined entry in the structure, the correct bit7 position is always used when accessing StatusByte.ReadyFlag.

Now, it's easy for bytes, you need just two different versions. But imagine for 32-bit words, are there only two options (0 to 31 and 31 to 0) or even more possibilities, I don't know.

I've now replaced the all CPU routines to use bitmasks, shifts and ORs to apply all bits that need to be applied. Now the only places still using those bitflags are:
- All (S)VGA registers (vga.h and almost all VGA-related rendering functionality).

Those are all places that still need to be changed from using bitfields to using plain AND/OR instructions to be compatible with non-Little Endian systems etc.(emulation without using bitfields).

Edit: The PS/2 controller(8042),DMA Mode register and CMOS Status Register A&B, UART Interrupt Identification Register, Interrupt Cause register and Line Control register, Most ATA registers(IDE), ATAPI Sense Data(also changed from global data to drive-specific data) and all floppy drive registers&stored data(Configuration) have been adjusted and the BDA has been converted(Equipment word of the BDA). The VGA registers are still a WIP.

So now the only part of the emulator that still needs adjusting it's bitfields to become byte calculations are the VGA(not SVGA/CGA/MDA) registers. Although most are probably only used in the precalculations part of the emulator, since it gathers all register data for rendering etc.

I've just finished the VGA converting to a bytes/word/dword approach using the new method. So that means my application is fully portable now?

Just tried running DOTT(Day of the Tentacle) on my 80286-8(with IBM AT BIOS revision 3) emulation once again (with the entrie emulator being changed from bitfields to use byte/word/dword logic with bitwise operations instead).

It eventually crashes at 0020:1D13 with an #UD:(all values below are in hex)
OP: 65, ROP: 65
DS: 0000, ES: A000
SS: 3867
AX: C884, BX: 14AF
CX: 0000, DX: 0000
SP: 4267, BP: 6244
SI: 0003, DI: 0009
CR0: FFF0
F: 0086

So, since it's executing the program itself(not F000 segment), this means there's a problem with my 80286 CPU emulation somewhere? Something seems to be jumping to the wrong address?

Edit: It seems the previous instructions was at 0020:0000? It seemed to be opcode 6D(INSW)?

Edit: Looking at the instruction that fires the first exception in the software, its a LODSW instruction that seems to use offset FFFFh, causing a #GP because it accesses offset 10000h, causing a segment limit violation(>0xFFFF)? Is this supposed to happen on a 80286 in Real Mode?

Edit: It seems the last executed instruction was 0xB2(MOV DL,5D according to the leftover data from the previous instruction).

I've tried executing that part of the software again, but with full debugger logging enabled(always log setting) and #UD triggering the emulator(and logging) to terminate itself.

Debugger log of Day of The Tentacle from the point of starting the game(choosing the start option in the DOTT.EXE menu):
https://www.dropbox.com/s/5cpa41ylvnghidz/deb … 014_UD.zip?dl=0

Anyone knows what's causing the #UD in this case?

I've just modified the BIOS to be able to use practically any ROM size with it's seperated ROMs. I've started the ROM from minuszerodegrees for diagnostics (http://www.minuszerodegrees.net/supersoft_lan … dmark%20ROM.htm). I'm using the 5170 version:

Of course it's running on the CGA emulation(which itself runs on top of the VGA emulation(CGA compatibility layer) in RGB mode.

So the following tests fail with a 1 before the failed:
- Protected Mode CPU
- Real Time Clock Interrupt
- U126 keyboard controller
- CMOS RAM test

After Floppy Adapter passes and Floppy Read starts reading the floppy, the screen clears and corrupted input is displayed for a moment, after which the second capture displays:
- Floppy Read 1 failed.
- MDA Memory Not Pres

So now, apparently the CPU, RTC, keyboard controller(8042&PS/2 keyboard), CMOS RAM(???), FDC and CGA fail? Anyone can explain what's being tested there?

The CMOS RAM testing is basically outputs to 0x70 followed by outputs/inputs to 0x71. So they write an offset, then write some data to that offset via 0x71 then read it back, also via 0x71. If it does not match it fails.

The real time clock interrupt is 0x1A right?

I would suggest however running the XT testing ROM from minuszerodegrees. It is somewhat simpler than it's AT version and you can work your issues there first.

The RTC is connected to IRQ8, which usually maps to interrupt 50h, if I'm not mistaken?

It gives a lot of strange errors during the XT (on a XT with 80286 connected). Most of the display is corrupted after the first 5-10 tests. (it gives the same as the 31_ROMPOSTDIAGNOSTICS2.png given earlier). It seems to reboot without restoring it though.

Beep recording of the beep errors of the XT diagnostics(XT architecture with 80286 fitted in UniPCemu, by selecting XT architecture and 80286 CPU):
https://www.dropbox.com/s/f74k6en30a56blg/Uni … 3_1423.zip?dl=0

It sounds like it's rebooting in there somewhere, but that doesn't clear the screen for new output.

No, IRQ8 should be interrupt 70h if the default vector is 0x70 for second PIC. However the setting and manipulation of RTC is done also via ports 0x70 and 0x71 so it seems to be you might have a problem with CMOS/RTC emulation, since the BIOS also complains about CMOS memory.

Also I do not think the test BIOS should be rebooting at least not the 5160 one (it is possible the AT one, the 5170 will because it needs to get out of protected mode). Is it possible that the restart is a side-effect of a bug that you might have?

Well, the 80(1/2)86 core shouldn't be the problem, as it doesn't contains any new opcodes that deal with IP(There is one overwritten 8086 instruction (instruction 8E), but that disables the writes to CS(and thus the new IP that's set with CS too) and redirects those to a #UD exception). So the problem would either lie somewhere in the 8086 core itself, but normal 808X software (even 8088MPH) runs without problems?

So afaik the different JXX instructions used shouldn't be the cause of the problem? Could it be there's an exception that's causing the reboot? Like one of the exception handling vectors vectoring (in)directly into FFFF:0000 or F000:FFF0?

The hardware shouldn't produce any reset signals, since the 8042 is mostly disabled on the XT. Triple faulting also shouldn't exist, because there's no way to triple fault on a 808X(the only way would be to load the IDTR with an invalid limit(lower than 😎, causing a triiple fault on calling interrupt 8h and higher at any point of execution). So how could it even be possible, since the XT ROM wouldn't dare to use that instruction?

Does that mean there's something fundamentally wrong with my 808X+ emulation?

8086 instructions part of the 80(1/2/3/4/5)86 emulation:
https://bitbucket.org/superfury/unipcemu/src/ … 086.c?at=master