You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a data segment has both the "expand down" and "accessed" bits set, then the high-fidelity CPU core will treat it as a normal expand-up segment and fault for reads at offsets above rather than below the segment limit. (It appears the "default" core doesn't yet try to honor the expand-down flag on segments at all.) Looking through the source, it appears that this happens because the segment type (bits 40 through 44 of the GDT entry, including the "accessed" bit) is tested here without masking out the accessed bit:
although In SegmentProperty::GetType(), it appears to try to mask out the "accessed" bit for types >= 8 (which would correspond to code and data segments):
Thank you for finding an issue! But, isn't it the other way? I realized the condition in the GetType should be 16<=type since I am taking low 5 bits of the attribute byte, and the 0x10 bit distinguishes the system and application, and accessed bit is only for the application segment types. I rather feel that GetType was never returning Available 32-bit TSS, Busy 32-bit TSS, and 32-bit Trap Gate. (Looks like it never happens during Windows 3.1 and WIndows 95 boot process).
Also realized was line 453 of i486fidelity.h was only checking SEGTYPE_DATA_EXPAND_DOWN_RW and not checking SEGTYPE_DATA_EXPAND_DOWN_READONLY, if you were having an issue with read-only expand-down segment, probably the error in line 453 was the culprit.
I've made above changes and at least confirmed Windows 3.1 L12 Enhanced Mode/Standard Mode, and Windows 95 starts OK. I'm going to push changes soon.
Update: I had separate GetType() for InterruptDescriptor, that's why the error in the SegmentProperty::GetType was not doing anything. I've fixed it anyway. I've pushed the source. Thank you!
If a data segment has both the "expand down" and "accessed" bits set, then the high-fidelity CPU core will treat it as a normal expand-up segment and fault for reads at offsets above rather than below the segment limit. (It appears the "default" core doesn't yet try to honor the expand-down flag on segments at all.) Looking through the source, it appears that this happens because the segment
type
(bits 40 through 44 of the GDT entry, including the "accessed" bit) is tested here without masking out the accessed bit:TOWNSEMU/src/cpu/i486fidelity.h
Line 396 in d5c53f0
although In
SegmentProperty::GetType()
, it appears to try to mask out the "accessed" bit for types >= 8 (which would correspond to code and data segments):TOWNSEMU/src/cpu/i486.h
Line 279 in d5c53f0
I'm using the 20240223 automated release on macOS 23D60, Apple silicon.
The text was updated successfully, but these errors were encountered: