I have exactly the same problem with one motherboard (M-321) while other MB is fine (MS-3131) when 486dlc is used. Both boards work 100% correctly with 386dx.

I didn't notice other problems, but speedsys was unusable... 🙁

There were some compatibility problems with some Cyrix 486DLC & motherboard combinations.
Alternatively, try enabling the Cyrix L1 cache via the Cyrix utility as opposed to using the motherboard BIOS - https://www.philscomputerlab.com/cyrix-486dlc.html

GigAHerZ wrote:

I have exactly the same problem with one motherboard (M-321) while other MB is fine (MS-3131) when 486dlc is used. Both boards work 100% correctly with 386dx.

I didn't notice other problems, but speedsys was unusable... 🙁

Does MS-3131 work fine while running speedsys? are you sure that L1 is enabled?

The reason this is happening is because your cache is not configured correctly. You need to make sure your cache is coherent, either by using the FLUSH# method (hardware) or the BARB method (software). The FLUSH# method is more efficient, but sometimes the boards lack the circuitry to make it happen. However, you can modify boards to add it. The easier way is the BARB method, but you need to make sure your board supports hidden refresh.
I suggest using 3rd party cyrix.exe. In order for BARB to work, you need to specify a memory exclusion range for cacheable areas. Cyrix.exe is case sensitive and has odd syntax, so you have to use it with care.

Try this in your autoexec.bat: (exactly as written)

cyrix.exe -e -b -m- -xA000,128 -xC000,256

I had the same issues as you guys and this fixed it. I had much less success with the FLUSH# method, even on boards already wired for it.

Register settings for various CPUs

RiP wrote:

GigAHerZ wrote:

I have exactly the same problem with one motherboard (M-321) while other MB is fine (MS-3131) when 486dlc is used. Both boards work 100% correctly with 386dx.

I didn't notice other problems, but speedsys was unusable... 🙁

Does MS-3131 work fine while running speedsys? are you sure that L1 is enabled?

Yes. All fine, everything enabled.

I did play around with cyrix utility on M-321, but i didn't exactly try to disable anything. On the contrary, i tried to enable various things to make it work, but couldn't make it this way.

GigAHerZ wrote:

RiP wrote:

GigAHerZ wrote:

I have exactly the same problem with one motherboard (M-321) while other MB is fine (MS-3131) when 486dlc is used. Both boards work 100% correctly with 386dx.

I didn't notice other problems, but speedsys was unusable... 🙁

Does MS-3131 work fine while running speedsys? are you sure that L1 is enabled?

Yes. All fine, everything enabled.

I did play around with cyrix utility on M-321, but i didn't exactly try to disable anything. On the contrary, i tried to enable various things to make it work, but couldn't make it this way.

Did you enable the internal cache from BIOS or with the utility?

My motherboard is MB-4D50L

@RiP, both. I kept it enabled in bios and i played around with utility enabling everything i could.

To be honest, i think i even had Windows 95 successfully working well on it even when the speedsys wasn't able to run. I concluded speedsys being not compatible with this cpu+mb combination. But maybe there's something that can be done? 😀

GigAHerZ wrote:

@RiP, both. I kept it enabled in bios and i played around with utility enabling everything i could.

To be honest, i think i even had Windows 95 successfully working well on it even when the speedsys wasn't able to run. I concluded speedsys being not compatible with this cpu+mb combination. But maybe there's something that can be done? 😀

I think you're right. It's speedsys that isn't fully compatible with 486DLC.
It doesn't detect the clock speed correctly or even the 1KB internal cache:

In my opinion, the graphics corruption you're seeing is the classic sign that the cache is not configured correctly. Things may appear to be working well until you try to do some kind of DMA related activity, and then it'll all come crashing down. I've spent countless numbers of hours trying to get the DLC working correctly in my SCSI based systems, and I've seen the exact same speedsys problems you're having. It only happens when the cache is not setup properly. Speedsys may not detect the DLC properly, but it should still work.

Also, I think it's better to leave the Cyrix cache setting disabled in the BIOS, and enable it with the utility. I've had a lot of boards with DLC support, and the BIOS cache enable never works properly for me.

Sorry to bump this thread, but as i played around a bit, i found some information.

The MS-3131 board i have, that worked well with the Cx486DLC-40 CPU, just accidentally had it working well. When i used the command line utility to remove all disabled regions of caching, i got similar speedsys graphics error, as i did with my M-321 board. When i disabled the video ram area from caching, everything went back to normal.
I assume (Haven't tried on my M-321) that this video ram caching makes it incompatible with speedsys.

Right now, with MS-3131 board, i execute the cyrix.exe file like this:
cyrix.exe -f -m -xA000,64

No other regions needed exclusion for all phil's dos benchmarks to work properly.

NB: For fun, i also used AMISETUP to improve some mobo-cache timings and other things like that. I get 25,21MB/s memory bandwidth, 21,08 cpu score with speedsys.

GigAHerZ wrote:

When i disabled the video ram area from caching, everything went back to normal.

Thanks, it didn't work for me though.

I have a problem running Speedsys 4.78 on Tx486DLC-40BGA on my KMC-A419-8 MB - it hangs during CPU detection (it displays "Processor: Cyrix" and hangs). Is there some trick how to make it run? Disabling both caches didn't help.

This thread has a lot of helpful info-- 486DLC cache coherency blues and headaches

My 486DLC works fine in speedsys with L2 Cache enabled, but I'm also using MR Bios and cyrix.exe -e -b

I played a bit with cyrix.exe (-q successfully reported changes I made) but I didn't find any setting that makes speedsys working. My MB has AMI BIOS. When I enable L1/L2 in BIOS then cyrix .exe reports that they are enabled and using flush no barb. When I disable caches in bios cyrix.exe reports they are disabled but speedsys still hangs. I have no other stability problems with other programs when L1/2 is enabled. I remember that Speedsys had similar issue with Cyrix MII CPU and I had to disable some CPUID bit in control register to make it work. I guess it's similar Speedsys quirk...

TI chips are not 100% identical clones of the Cyrix core. One of the differences is TI DLC lacks the ID registers that a Cyrix does have. If your mobo has some config registers mapped into that I/O space then perhaps Speedsys damages the mobo settings trying to probe for Cyrix ID, thus crahsing the system. Possibly Speedsys has its own detection code that is more aggressive than other tools, so that's why it causes issues when other apps do not.

Yes, I guess it could be such problem. Has speedsys some switch to disable this detection? Or can be CPU IO space disabled/masked? BTW when I switched to onboard (SMD) Am386DX it works as expected.

RayeR wrote on 2024-10-15, 05:13:

Has speedsys some switch to disable this detection? Or can be CPU IO space disabled/masked?

Not sure about Speedsys switches but the CPU I/O space is hardwired, at least on these early SLC/DLC CPUs. There are some extra config registers on later 586 and 686 chips. The registers that do exist on CPU will be mapped during ins/outs, and no actual bus operations will take place. But the rest is executed like a typical I/O through the CPU bus and can affect any hardware that will respond to the address.

RayeR wrote on 2024-10-15, 05:13:

BTW when I switched to onboard (SMD) Am386DX it works as expected.

Usually you can detect a Cyrix-like core by doing a simple test: On Intel (and clones, thus also AMD) division trashes the result flags. Not randomly, there is a pattern to it, but they do change. Cyrix cores preserve the flags. So a simple division with hand-picked values will tell you if the core changes the flags or not. Usually you would not run a deep Cyrix-specific CPU ID discovery code if this test failed and the core is not Cyrix-like. Thus I would expect Speedsys to work without any issues on Intel and AMD, but not on TI. There is also IBM chips that are Cyrix-like but those have different internal registers and there also is another way of telling IBM "386" and Cyrix 486 apart. So again that bug might not get triggered.

Note, the TI problem is mobo specific. If there isn't any mobo config register that can be trashed by Speedsys during CPU discovery then system will continue to run. On my mobos Speedsys detects a true Cyrix DLC as such but gets the clock speed wrong (too slow). TI DLC is detected as Cyrix 5x86(tm) with correct clock, and TI SXL is also a Cyrix 5x86(tm) but the clock is wrong again (too fast this time). In general I'd say Speedsys doesn't detect TI chips properly at all.

Ok, thx for explanation. It seems only viable way woul be patch speedsys to replace such IO routines by NOPs or so... Speedsys seems to be abandonware but not opensource that makes it harder. Maybe some stepping in debugger could point to location where it hangs, as it runs in graphics and probably protected mode makes it more complicated too....