There should be no missing instructions on 486DLC class CPUs (by which I mean DLC, SLC, SXL and SXLC) other then undocumented UMOV, which is ICE type instruction and not used by any software, including system software. Simply because without the actual debug hardware attached it's identical to MOV in what it does, so why even bother. UMOV was removed on Pentium anyway.

Kernel crashing could be related to smaller cache or different organization (4-byte lines, not 16-bytes) and/or wrong config in the CPU. I had no issues running Linux kernels on these machines (at least those that still supported 486) but I'm not familiar with BSD, and what you consider "modern". Is this kernel 386-compatible? Or 486+ only? Is the BIOS setting the chip properly, did you test that? If not boot DOS and see what's in the CPU config registers. You might also get somewhere by hacking the BIOS, just before it boots the OS, to disable the L1 cache by setting 4G size exlusion zone (what the CPU actually does on reset). If it works (slowly, obviously) with that hack then it's clearly the cache that's the issue.

I was also corrected in my assumption that the data sheets don't list instructions - I just failed to find it in the data sheets I've scoured. So that's at least a solved problem.

Deunan wrote on 2025-05-25, 23:32:

There should be no missing instructions on 486DLC class CPUs (by which I mean DLC, SLC, SXL and SXLC) other then undocumented UMOV, which is ICE type instruction and not used by any software, including system software. Simply because without the actual debug hardware attached it's identical to MOV in what it does, so why even bother. UMOV was removed on Pentium anyway.

That at least confirms that the 86Box emulation is likely correct.

Deunan wrote on 2025-05-25, 23:32:

Kernel crashing could be related to smaller cache or different organization (4-byte lines, not 16-bytes) and/or wrong config in the CPU. I had no issues running Linux kernels on these machines (at least those that still supported 486) but I'm not familiar with BSD, and what you consider "modern". Is this kernel 386-compatible? Or 486+ only? Is the BIOS setting the chip properly, did you test that? If not boot DOS and see what's in the CPU config registers. You might also get somewhere by hacking the BIOS, just before it boots the OS, to disable the L1 cache by setting 4G size exlusion zone (what the CPU actually does on reset). If it works (slowly, obviously) with that hack then it's clearly the cache that's the issue.

Attached screenshot of the machine in 86Box.
As for the BIOS on the Panda: It's the same BIOS as in 86Box, with the exact same settings, and it correctly detects the CPU and enables both internal and external caches (according to the cyrix cache control software in DOS). I have tested with caches disabled, but I'll try that again just to make sure it's tested properly.

The BSD is NetBSD 10.x, which is pretty much bleeding edge. It still supports 486+; 386 support was removed a decade or so ago. The kernel is also compiled with special support for the xLC series, but those code paths only kick in (much) later in the boot. The point where it fails is literally immediately after the boot loader has read the kernel into memory - so presumably when the kernel starts executing, but before it prints anything on screen.

A friend tested in qemu (I think it was) and disabled INVLPG and a couple other instructions - this was in an attempt to simulate what the nx586 does, which is "almost" 486 compatible. He found the exact same behaviour as I get on both nx586 on 486DLC, so my assumption was therefore that missing instructions is the problem. Based on what 86Box does, your statements, and my "revised reading" of data sheets, that theory does not seem to hold. So it's back to the drawing board..

Thanks for your insights!
/Eirik

ltning wrote on 2025-05-26, 00:16:

Attached screenshot of the machine in 86Box. (...)I have tested with caches disabled, but I'll try that again just to make sure it's tested properly.

Emulating cache behaviour is extremly difficult and expensive, usually it's just approximated or not emulated at all, that is only the instructions and operating modes that flush or bypass cache are taken into consideration.
Since you can run Cyrix control software in DOS please provide its output so we can check if it makes sense or not. Quite a few 386 mobos claim support for 486DLC but it's actually broken - usually because the mobo doesn't have the necessary signals connected to the CPU. You can't expect emulators to account for that.

ltning wrote on 2025-05-26, 00:16:

The BSD is NetBSD 10.x, which is pretty much bleeding edge. It still supports 486+; 386 support was removed a decade or so ago. The kernel is also compiled with special support for the xLC series, but those code paths only kick in (much) later in the boot. The point where it fails is literally immediately after the boot loader has read the kernel into memory - so presumably when the kernel starts executing, but before it prints anything on screen.

Again I have not used BSD in ages, and even back then it was mostly trying to boot stuff at all rather then using it. I can't remember if BSD uses any form of kernel image compression, and/or initrd-like mechanism. This code must run before the kernel, obviously, and if it's not properly CPU agnostic then it might be mis-detecting something and trying to do something odd perhaps. I'm still in the cache confing camp though, this is the #1 reason these CPUs don't work properly - broken BIOS support.

EDIT: Forgot to ask the important question: Is this floppy boot or HDD boot? Because floppy boot will fail with bad cache settings, and HDD boot might be a completly CPU unrelated issue with drive geometry being set in partition table on a different machine that supports LBA or CHS translation for example.

ltning wrote on 2025-05-26, 00:16:

I was also corrected in my assumption that the data sheets don't list instructions - I just failed to find it in the data sheets I've scoured. So that's at least a solved problem.

There is a full Instruction Set table in this document: https://bitsavers.org/components/ti/TI486/199 … rence_Guide.pdf
Section 7.5 Instruction Set, Table 7-17. Page 275+ of the PDF.

TL;DR: The same behaviour is observed even with all caches (internal+external) disabled.

Deunan wrote on 2025-05-26, 09:41:

Since you can run Cyrix control software in DOS please provide its output so we can check if it makes sense or not. Quite a few 386 mobos claim support for 486DLC but it's actually broken - usually because the mobo doesn't have the necessary signals connected to the CPU. You can't expect emulators to account for that.

Added to the end of this message. The chipset is an ALI M1429 variant, rebranded as Panda PR3029. It does support the FLUSH pin and writeback and such, and from what I can tell it works correctly.

Deunan wrote on 2025-05-26, 09:41:

Again I have not used BSD in ages, and even back then it was mostly trying to boot stuff at all rather then using it. I can't remember if BSD uses any form of kernel image compression, and/or initrd-like mechanism. This code must run before the kernel, obviously, and if it's not properly CPU agnostic then it might be mis-detecting something and trying to do something odd perhaps. I'm still in the cache confing camp though, this is the #1 reason these CPUs don't work properly - broken BIOS support.

This is the one part I haven't yet been able to confirm - that the loader is indeed sufficiently CPU-agnostic. That said, it works in a "real" Intel 486 and on Am486 boards (I have one running as a fediverse server..), so with caches disabled and presumably a full i486 instruction set, I'd imagine it really should work..

Deunan wrote on 2025-05-26, 09:41:

EDIT: Forgot to ask the important question: Is this floppy boot or HDD boot? Because floppy boot will fail with bad cache settings, and HDD boot might be a completly CPU unrelated issue with drive geometry being set in partition table on a different machine that supports LBA or CHS translation for example.

Behaviour is the same in both cases, floppy and "HDD".
I have some CF cards with NetBSD preinstalled, and I'm careful to use the same controllers and such. Usually a Promise ISA caching controller with its own LBA BIOS, but the disk layout is compatible with Tekram controllers and even XTIDE - in a 486SLC box I can use any controller and it will boot just fine.

1Internal 1kb cache is presently enabled via CR0.
2First 64k of each 1Mb boundary set as cacheable.
3640k --> 1Mb region set as cacheable.
4A20M imput enabled.
5KEN input disabled.
6FLUSH input enabled.
7BARB imput disabled.
8Internal Cache mode: 2 way associative.
9SUSP input and SUSPA output disabled.
10All low power mode features disabled.
11
12Mon-cacheable region 1: Start segment = 0x000A000, size = 128 kb.
13Non-cacheable region 2: Start segment = 0x000C000, size = 256 kb.
14Non-cacheable region 3: Start segment = 0x0C000000, size = 4096 kb.
15Non-cacheable region 4: Disabled.

ltning wrote on 2025-05-26, 16:57:

This is the one part I haven't yet been able to confirm - that the loader is indeed sufficiently CPU-agnostic. That said, it works in a "real" Intel 486 and on Am486 boards (I have one running as a fediverse server..), so with caches disabled and presumably a full i486 instruction set, I'd imagine it really should work..

Well now I have kinda confirmed the loader isn't at fault. I used the 4.0.1 loader (which works on this hardware) to load the later kernel, and the behaviour is the same: Hang or reboot when executing the kernel. With or without cache enabled. :-/

Hi,

can you test it on some other motherboard? Like Opti 495SX/SLC that also has support for real 486 CPUs.

https://theretroweb.com/motherboards/s/a-tren … lc-vl-bus-3-486

kixs wrote on 2025-05-26, 17:53:

can you test it on some other motherboard? Like Opti 495SX/SLC that also has support for real 486 CPUs.

https://theretroweb.com/motherboards/s/a-tren … lc-vl-bus-3-486

I just did, it might even be exactly the same board as the one you linked to (looks very similar, at least). Same behaviour there.

/Eirik

Disabling internal cache in BIOS does next to nothing for protected-mode kernels. All BIOS does is flip the CR0 bit, and typically any 486+ aware kernel will try to enable cache as soon as it can.

Anyway, your Cyrix config looks good, but I'm suspicious of the "FLUSH input enabled." option. That's often broken or even completly missing. But it would only crash the system if something other than CPU has written to RAM - like floppy DMA for example. It should not affect HDD operation because on these mobos it's pure I/O - unless you have some odd HDD controller in there (some SCSI ones for example can use DMA). That being said do look into BIOS settings and if you have such options try disabling Flush and enabling BARB. This causes CPU to invalidate cache on every HOLD cycle so any DMA will do it. That might result in performance loss if you do not have Hidden RAM Refresh enabled, but other than lower performance it would not break anything. In other words BARB mode always properly flushes cache, worst case scenario it does it on every memory refresh cycle which will lower CPU performance below even 386 levels.

One thing that came to my mind is DLC class CPUs do not allow NE bit in CR0 to be changed, while true 486 does (IIRC even SX which lacks FPU). But I don't really see why it would cause BSD kernel to panic? Unless it requires FPU to work or has some weird method of establishing its presence for 486SX/DX detection. Still I'd think it would be more graceful about that.

If you want, and have the chips and EPROM programmer, I can try to hack your BIOS to disable the cache via the exclusion zones. It will prevent the kernel from being able to enable it via CR0, unless it's smart enough to try and mess with the config registers. Which it shouldn't - Linux doesn't. Other options are to try Linux boot floppies from old distros to see if they work (I know for a fact that anything up to Debian 2.2 "Potato" will work on these CPUs, Debian 3.0 "Woody" should work too but I have not tested it myself). And/or older BSD kernels, could be it's some sort of regression - I doubt the modern stuff is still tested on 486, much less on DLC-class chips. Well, you are testing it now 😀

The chipset on this board is an actual 486 chipset, it's just that the board only has 386+387/weitek scokets. All the cache tests in the various Cyrix and TI software bundles pass, including the floppy/DMA tests. For shits and giggles I also tested a RapidCAD pair, but those really don't implement much of the 486 instruction set, so that one insta-rebooted rather than hanging (same behaviour as with a 386DX, real or in 86Box).

Given that I see the same behaviour whether the boot source is HDD or FDD, I don't think DMA is the problem. Also of all my "386" VLB boards, this has been the one causing me the least trouble (and I'm quite familiar with DMA trouble and DLC-style caches...). As Kixs suggested I also tested on a Opti 495SLC board, which exhibits the same symptoms. I'll try to think of a way to properly exclude the possibility - however remote - of DMA-related trouble, but I will also investigate other avenues while waiting for a good idea.

Your offer to mod the BIOS is appreciated. The board is this one and I'm using the 1.3 BIOS at the moment. I have a programmer and, I believe, a metric ton of EEPROMs. I was actually going to try to achieve this using the AMIBIOS tool, but first I need to get the board to retain CMOS settings - I'm missing an appropriately-voltaged battery right now. And I don't remember which settings it exposes on this one..

NetBSD 4.0.1 boots on the machine. From 5.0.0 onwards it does not. So naturally I'm also trying to find out what happened between those points - 386 support was removed, but perhaps they threw out the baby with the bath water there.

Lastly, another observation: During kernel execution, before it hangs, the HDD LED flashes once (when booting with no HDD defined it also hangs, it just doesn't blink, of course). To me that indicates that code is indeed executing (not just decompressing; this is done by the loader and it prints more after that is done), and I should be able to pinpoint with more accuracy how far it must have gotten. I installed an ISA diag card to see if there were any signals on the bus (that it would pick up) or change in POST codes around the same time, but as expected, nothing.

Just need my NetBSD kernel hacker friend to drop by one of these days - the beer offering has been made.

So cache aside, the two reasons 386 was dropped was lack of FPU and WP bit on pages not preventing writes in ring 0. The latter had to be worked around in kernel to allow the same paging optimizations (no HDD store if page not dirty) as for userland.

Of these two Cyrix DLC lacks the FPU and the internal error reporting mechanism (hence NE bit can't be toggled, should aways be zero). WP bit works properly as on any 486+ CPU, if the CR0 config bit is set. So it could be an FPU issue. Is there an option to run the emulator with no FPU? Or to run this BSD kernel on 486SX, if you have one. If it works without FPU then it leaves only the error reporting mechanism. That's going to be tricky to rule out, unless there is a command line option for the BSD kernel to force FPU emulation. That should skip any attempts to detect the FPU presence - or at least I hope so.

I'm running this on FPU-less hardware; the checks for that are much later in the boot and the kernel has the FPU-emulator enabled for when it gets that far. So I'm wondering now if that error reporting thing might be an issue, and if perhaps 86Box is doing something wrong there ..

ltning wrote on 2025-05-27, 20:47:

I'm running this on FPU-less hardware; the checks for that are much later in the boot and the kernel has the FPU-emulator enabled for when it gets that far. So I'm wondering now if that error reporting thing might be an issue, and if perhaps 86Box is doing something wrong there ..

Well preferably you should be hacking the BSD kernel to see where it dies and how. That's what I did every time I tried to get my foot into a system via code injection. Some sort of status channel, no matter how primitive. Once I had nothing to use, no initialized I/O or even good idea about the memory map - so I had the CPU run different code paths, one with halt and one with infinite loop. Then I probed the bus with a scope to see which path was taken (is CPU running or halted), and kept going from there. In this case I'd harcode some init for serial port and turn that into debug output (even single bytes output will be useful).

Anyway, here's two hacked BIOS images. I've corrected the checksum so these should work (being based on a code I wrote earlier that does) but I have not tested them. So start with the emulator maybe?
BIOS1 will restore the 4GiB cache exclusion zone that these CPUs have after reset. That should disable any cache fetches and thus cache as such since I also invalidate all of it.
BIOS2 is mostly a copy of your current cache settings, except BARB instead of FLUSH and A20M input disabled, with the required workaround enabled.

Start with #1 and it boots try #2. If #1 crashes then there's little point in testing #2. Note these images should work with 386 CPUs (the whole cache thing will be skipped) but not true 486.

Thank you very much. I just tested BIOS1, as I feared it made no difference. But at least it would seem to confirm the cache is not the problem.

About the NE bit: On a 486SX, or an IBM486SLC (both of which I own and have tested successfully), can the NE bit be modified, even if it doesn't do anything? In other words, is this an actual behavioural difference between those and the 486DLC (cyrix/TI)?

The kernel does touch CR0 early (not quite sure precisely *how* early). Some definitions first:

1/* From sys/arch/x86/include/specialreg.h */
2#define CR0_PE  0x00000001  /* Protected mode Enable */
3#define CR0_MP  0x00000002  /* "Math" Present (NPX or NPX emulator) */
4#define CR0_EM  0x00000004  /* EMulate non-NPX coproc. (trap ESC only) */
5#define CR0_TS  0x00000008  /* Task Switched (if MP, trap ESC and WAIT) */
6#define CR0_ET  0x00000010  /* Extension Type (387 (if set) vs 287) */
7#define CR0_NE  0x00000020  /* Numeric Error enable (EX16 vs IRQ13) */
8#define CR0_WP  0x00010000  /* Write Protect (honor PTE_W in all modes) */
9#define CR0_AM  0x00040000  /* Alignment Mask (set to enable AC flag) */
10#define CR0_NW  0x20000000  /* Not Write-through */
11#define CR0_CD  0x40000000  /* Cache Disable */
12#define CR0_PG  0x80000000  /* PaGing enable */

Then in sys/arch/i386/i386/locore.S (note AT&T syntax), it looks like it is inclusive-ORing, among other things, that bit. Won't that attempt to flip it, in this case? And won't that fail?

1    /*
2     * 3. Enable paging and the rest of it.
3     */
4    movl    %cr0,%eax
5    orl $(CR0_PE|CR0_PG|CR0_NE|CR0_TS|CR0_MP|CR0_WP|CR0_AM),%eax
6    movl    %eax,%cr0
7
8    pushl   $begin          /* jump to high mem */
9    ret

Removing that bit from the orl is trivial and I don't think it'll have any other effects..

Well that didn't help. Started patching loader and kernel now, by throwing printf's at the wall to see which ones stick..

ltning wrote on 2025-05-28, 16:36:

Thank you very much. I just tested BIOS1, as I feared it made no difference. But at least it would seem to confirm the cache is not the problem.

Welp. I tried. Must be something else, possibly an actual bug that executes code it should not.

ltning wrote on 2025-05-28, 16:36:

About the NE bit: On a 486SX, or an IBM486SLC (both of which I own and have tested successfully), can the NE bit be modified, even if it doesn't do anything? In other words, is this an actual behavioural difference between those and the 486DLC (cyrix/TI)?

AFAICT yes. Setting the NE bit on 486SX does nothing becuase there is no FPU so nothing will ever generate the exception. But the bit can be set, unlike on DLC CPUs.

ltning wrote on 2025-05-28, 16:36:

Then in sys/arch/i386/i386/locore.S (note AT&T syntax), it looks like it is inclusive-ORing, among other things, that bit. Won't that attempt to flip it, in this case? And won't that fail?

Fail, no. This bit only changes how FPU errors are reported, and for NE=1 the mechanism uses internal routing and exception #16. Unlike IRQ13 that IBM picked for this purpose for external coprocessors. Even though Intel chip did have a dedicated ERROR input and Intel surely told IBM people about this. Also, datasheets.

So 386/486 compatible Linux kernels actually test which method can be used and prefer the faster internal one on 486+. I assume they did account for the DLC chip and it's behaviour, so they try to set the NE bit and either test that it is set, or cause FPU to error out and see which interrupts arrives. What I was suspecting is BSD removed 386 support and assumed NE can be set (the code you pasted doesn't seem to check anything) and then some sort of test executes but receives unexpected IRQ13 instead of the correct exception, and panics. Kinda convoluted I agree but then I'm running ouf ot ideas on what could be making the BSD kernel unhappy.

There's a lot of DLC code in the NetBSD kernel. I specifically enable that in builds for the 486SLC builds I have, as it dramatically speeds things up especially where the BIOS doesn't do a good job of setting up the caches - like on an old ISA 386 board with no cache at all where I plopped in one of those 486BL upgrade boards.
I basically have two #defines I can use - CYRIX_CACHE_WORKS and CYRIX_CACHE_REALLY_WORKS. The former works on both the 486SLC and 486486BL; the latter only works on the Alaris Cougar 486BL. The kernel I'm currently trying to boot has neither; it'll simply leave those registers/settings alone.

In the same file there's also a lot of CPU detection and testing going on, but I've established that it doesn't even get that far. I'm not sure precisely how far it's getting, as I need to inject assembly code in order to debug the earliest steps of kernel start() function. So far all i've managed to do is scramble the display - but even that is telling me something :D

I'll check back in when I got someone who actually knows what they're doing to help me with the assembly parts (and other stuff). I really want this to work, because that probably means my NexGen will also work. :D