| View previous topic :: View next topic |
| Author |
Message |
ltning
Joined: 12 Feb 2022
Posts: 4
Location: Oslo, Norway
|
 Posted: Mon May 12, 2025 4:42 pm Post subject: nx586 missing 486 instructions |
 |
|
Hi all,
TL;DR: Has anyone attempted to add any of the missing 486 instructions to the Hypercode for the nx586? Specifically INVD, INVLPG and WBINVD?
Long story:
I am on a foray to install NetBSD on all kinds of weird old hardware, and as of quite recently there exists a patch set to restore support for FPU-less x86 systems. This works fine on an IBM486SLC system, which is essentially a 386SX-class sytem (16-bit bus, 387 FPU if any).
My NexGen VLB board (P90) seemed to be a really good candidate, because it's missing the FPU but is otherwise very fast (compared to the 486SLC) and can have a ton of memory (again, compared to the 486SLC).
Alas, as stated in this post, even with "alternate instructions" enabled in BIOS, several 486 instructions are still missing.
Booting any modern version of NetBSD fails early, usually resulting in an instant reboot the moment the kernel starts executing. In a very old NetBSD, v4.0.1 (current is 10.1), it actually says the failing instruction is INVLPG - this may or may not be the same thing that causes the reboots in newer versions; having a kernel debugger embedded in the floppy kernel images is a luxury after all.
Seeing Herbert Oppmann's fantastic information, it looks like it might be theoretically possible to add support for the missing instructions. Has anyone ever attempted to do this (or otherwise fix bugs left there from NexGen's heyday)?
Thanks for reading, and have a good one!
/Eirik
Floppy Museum
~ love over gold ~ |
|
| Back to top |
|
 |
xsecret
Joined: 01 Feb 2004
Posts: 1846
Location: France
|
|
| Back to top |
|
|
mtx500
Joined: 21 Nov 2003
Posts: 117
Location: Nuremberg, Germany
|
| Posted: Sat May 17, 2025 6:30 am Post subject: Re: nx586 missing 486 instructions |
|
|
| ltning wrote: | | Has anyone ever attempted to do this (or otherwise fix bugs left there from NexGen's heyday)? |
I once tried to install Netscape Navigator on Windows 98SE, but the installer kept failing with an exception. I analyzed this a bit and found out, that while XADD is emulated correctly when "Alternate Instructions" are switched to on, the opcode LOCK XADD leads to an exception. I looked into the hypercode that emulates X86 instructions not implemented directly in hardware, and there sure is support for the LOCK prefix, but there seems to be a bug somewhere.
To further analyze this, I thought of a trace mechanism in hypercode. Tracepoints inserted in hypercode by me would, when hit, write some info into main memory, at an address that was previously told to hypercode via a new NXOP (0x0F 0x55) function. There would also be functions to start and stop tracing, so the important trace hits are not overwritten. Then there would be a small test program setting up a buffer, enabling the trace, executing LOCK XADD, disabling the trace and then displaying the trace on console.
This would have shown me which path in hypercode is taken by emulation of LOCK XADD, and hopefully point me to the bug. Alas, I did not get very far with this ... I still have the files around, so if anyone wants to pick up on this, let me know.
BTW, I created a dual-BIOS on my VL and PCI NexGen computers. There are two stacked BIOS Flash chips that I can select from the outside via a switch. It has a "Test" and "Original" label. This is very handy when some test with BIOS/Hypercode fails and the computer does not boot anymore 
That reminds me that I wanted to document this dual-boot on my web page sometime. |
|
| Back to top |
|
|
ltning
Joined: 12 Feb 2022
Posts: 4
Location: Oslo, Norway
|
| Posted: Sun May 25, 2025 11:55 am Post subject: |
|
|
There are some indications that it might be possible to replace the offending instructions in the loader/kernel of NetBSD. I have not made the progress I hoped to make - the kernel still reboots as soon as it starts executing - but it might be possible to work around this.
There's of course the possibility that other instructions are also missing - or implemented incorrectly. As an intermediate step, I might try to get it booting on a Cx486DLC or similar, but those also behave in the same way so I'm not sure what's going on there.
Which leads me to another question: Does anyone have solid information on which 486 instructions the 486DLC-class CPUs actually implemented? If not all, which are missing?
Thanks for your responses so far, it's fascinating to dig into this! |
|
| Back to top |
|
|
mtx500
Joined: 21 Nov 2003
Posts: 117
Location: Nuremberg, Germany
|
| Posted: Tue May 27, 2025 2:21 pm Post subject: |
|
|
| ltning wrote: | | Which leads me to another question: Does anyone have solid information on which 486 instructions the 486DLC-class CPUs actually implemented? |
I have this manual for Cyrix Cx486DLC: https://www.memotech.franken.de/Temp/94076.pdf (make a local copy - it won't stay permanently there). It contains a list of supported instructions (starting with page 137 in your PDF reader or 6-12 on the page). Does that answer your question? |
|
| Back to top |
|
|
ltning
Joined: 12 Feb 2022
Posts: 4
Location: Oslo, Norway
|
| Posted: Thu Jul 03, 2025 5:54 am Post subject: |
|
|
mtx500 - yeah I had this pointed out to me over at Vogons too, I feel pretty blind for not seeing it.
With the help of a friend I now have a kernel without any INVD, INVLPG or WBINVD instructions. In particular, the INVLPG instruction call has been replaced with this ASM blob:
| Code: | c0128af0 <tlbflush>:
c0128af0: 0f 20 d8 mov eax, cr3
c0128af3: 0f 22 d8 mov cr3, eax
c0128af6: c3 ret
c0128af7: 2e 8d b4 26 00 00 00 00 lea esi, cs:[esi + eiz]
c0128aff: 90 nop
|
The observed behaviour is still the same, though.
Currently spending what little spare time I have attempting to make the NetBSD kernel output useful debug information during the early stages of boot. On both Nexgen and 486DLC I have, as of yet, failed to make it do anything that gives me conclusive information, and every time I think I've found where it spontaneously reboots, it turns out to be in a piece of ASM code that *really* should not cause that.
Time I can spend on this is scarce so progress is slow, but I have not yet given up. Suggestions welcome, if anyone is familiar with NetBSD and the early kernel boot; for reference to anyone else crazy enough to hunt this problem down: I'm pretty certain I've narrowed down the insta-reboot to happen in | Code: | | sys/arch/i386/stand/lib/startprog.S |
/Eirik |
|
| Back to top |
|
|
|
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
Powered by phpBB © 2001 phpBB Group
|
