First post, by superfury

User metadata
Rank l33t

I notice that the 80386 programmer's reference manual specifies the D/B and G bit to be 1 when applying for 4GB upper limit(for expand-up and especially important, expand-down segments).

But when UniPCemu applies the D/B bit for this(set for 4GB, clear for 64K), certain loaders like DOS/4GW will crash due to setting the G-bit but not the B-bit(thus with 4GB addressing as bottom-up it will do what? 64KB or 4GB?)? Since I adjusted the core to always take the roof into account(even with Expand-Up segments), it will crash when the G-bit is set to 4GB addressing and B-bit to 0 for 64KB default?

So is the B-bit even used when checking against limits? Or is it just the G-bit?

Edit: Just made it work, depending roof(maximum offset, combined with limit check which is based on the G-bit always) on the G-bit(Expand-up, with up to 1MB in small granularity and 4GB in large granularity) or B-bit(Expand-down, with 64KB on small and 4GB on large, G-bit ignored for the roof and used for the limit).

That brings up an interesting topic: what happens when any of the highest 4 bits of the limit field(stored within the lower half of the byte with the G/D/B(/L on x64) bits) is set and a small size(B=0) is applied? The maximum offset would be 0xFFFF, but the minimum offset would be (limit+1), thus it's an unaccessable segment for any limit from FFFF(64K-1) to FFFFF(1MB-1) in the limit field?

UniPCemu Git repository
UniPCemu for Android, Windows and PSP on itch.io
Older UniPCemu PC/Android/PSP releases