When the 386 is reset, the SS register has a value of 0 but SS behaves as if its base is nonzero. On a real 386, SS.base is set to 0 after reset. (...As far as I know. It does point to RAM, but I haven't verified exactly where.) Actually, upon further investigation, I think the issue is actually that SS is a 32-bit segment after reset, because stack operations are updating ESP instead of SP.
The code that tripped this bug reset the CPU using the keyboard controller, like below. I haven't tested what happens if the CPU is reset any other way.
MOV AL, 0xFE
OUT 0x64, AL
I found the bug while I was using this machine in Firefox on Windows.
Will do. What you suggest sounds plausible, but it'll require some debugging, because just looking at the resetRegs() code path, I don't see the problem yet.
When the 386 is reset, the SS register has a value of 0 but
SS behaves as if its base is nonzero. On a real 386, SS.base is set to 0 after reset. (...As far as I know. It does point to RAM, but I haven't verified exactly where.)Actually, upon further investigation, I think the issue is actually that SS is a 32-bit segment after reset, because stack operations are updating ESP instead of SP.The code that tripped this bug reset the CPU using the keyboard controller, like below. I haven't tested what happens if the CPU is reset any other way.
I found the bug while I was using this machine in Firefox on Windows.
Let me know if you need anything else.