Emm386.exe needed to enable L2 cache? My 486 seems to require emm386 present in order for its 256K mobo cache to be enabled. Shouldn't L2 be all hardware controlled and independent of software?
I seem to have confirmed this with CheckitPro and NSSI. When emm386 is not present, performance drops by about 1/3rd. And NSSI states that no L2 is present.
Hm, that's strange. Never noticed this on my 386DX and 486DLC (+cache utility) systems.
Which processor/mainboard are you using if I may ask ?
Maybe the L2 get's activated because EMM386 switches to V86.
That would make sense insofar, as that using extended memory in real-mode requires a working A20 control.
Which also is related to the necessity of flushing the caches.
So if you're in virtual mode (v86), this control could me "virtual" and it would be possible to bypass a defective cache/A20 mechanism.
Anyway, this is just a far stretch likely. I wished my memory was better, hah. 😅
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
//My video channel//
Gateway2000 486DX2/50
Micronics mobo Baby AT Gemini
09-00081-03 rev F
16MB RAM
256K L2
8K L1
Micronics 461/462 chipset
Phoenix BIOS
It very well may have to do with virtual mode..? Mm... How can I text the A20 line in this context?
It also may be HIMEM.SYS that had to executed. I just assumed it was EMM386.EXE. So I will confirm that.
HIMEM.SYS turns on A20 gate
I second that. The A20 thing could be related to this issue because..
Everytime the A20 gate changes its state, the cache might have to be flushed to guarantee data coherency.
So I believe if V86 is enabled, the A20 can be simulated, like about everything.
EMM386 is like a tiny Protected-Mode OS or a Hypervisor. In reality, though, the A20 line is connected.
(->The gate is open; or "closed" as in electronics, if you look at it like as switch symbol in a current circuit.)
wrote:It also may be HIMEM.SYS that had to executed. I just assumed it was EMM386.EXE. So I will confirm that.
I believe that's a good idea. Please try differnt versions and report back. Himem.sys had a dozen different methods to handle A20 mechanism.
Maybe it's just that is is not aware of your mainboard's mechanism. I'd try Himem.sys from DOS 7.1 first, since it is an upgraded version and supports XMS 3, too.
That being said, these are just ideas and suggstions. Feel free to experiment on your own.
Maybe the issue is also related to something else, not sure. It's just that the A20/Cache flush thing is the most logical reason to me. 😊
Edit: Edited- Removed some stuff I was uncertain of.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
//My video channel//
