I think you are mixing up write-back internal cache (L1) and write-back external cache (L2)
The internal cache can cache the whole 4GB range.
It is the external cache that is set up such that 32MB can be cached by a 256KB cache and 7-bit tag. Write-back versus write-through cache is controlled by a chipset register and therefore by a (possibly hidden or missing) BIOS setting.

Okay, that make sense, so the CPU WB support is not related to the L2.

CTCM still say that the L1 is Write-back too with the 486/486DX4 settings.
But for some unknown reason, now it does not crash anymore when I set the L2 to 0WS/0WS instead of 1WS/0WS. Ali1429G magic 😁

Rav wrote on 2023-09-18, 22:44:

Okay, that make sense, so the CPU WB support is not related to the L2.

CTCM still say that the L1 is Write-back too with the 486/486DX4 settings.
But for some unknown reason, now it does not crash anymore when I set the L2 to 0WS/0WS instead of 1WS/0WS. Ali1429G magic 😁

On a 486:
The CPU has cache memory called L1 (level 1). It can be 8KB or 16KB depending on your CPU. Earlier ones have 8KB, later ones 16KB.
The motherboard may or may not have cache memory, called L2.

According to the link you posted, your motherboard does not have L2 cache. So you don't have to worry about that.

A board with L2 cache usually looks like this:

Those are DIP-28 SRAM modules.

According to the size of your L2 cache you can cache your motherboard's RAM. That means it would work a little bit faster.

And you don't really have to worry about L2 cache for a 486. Upgrading the CPU is far more important if you want a faster 486, the BUS speed and waitstates are also very important.

Disk drive caching is a different subject.

tauro wrote on 2023-09-18, 23:22:

On a 486:
The CPU has cache memory called L1 (level 1). It can be 8KB or 16KB depending on your CPU. Earlier ones have 8KB, later ones 16KB.
The motherboard may or may not have cache memory, called L2.

Cyrix 5x86 have 16K.

tauro wrote on 2023-09-18, 23:22:

According to the link you posted, your motherboard does not have L2 cache. So you don't have to worry about that.

Sorry for that, there is more than one model of A1GX-2, see : https://theretroweb.com/motherboards/s/acer-a1gx-2-w-cache
For the rest of the jumpers, it's the same

I have 256K

tauro wrote on 2023-09-18, 23:22:

And you don't really have to worry about L2 cache for a 486. Upgrading the CPU is far more important if you want a faster 486, the BUS speed and waitstates are also very important.

All benchs went off the chart since I have upgraded the ram and set the L2 to 0WS/0WS. Ram upgrade alone change nothing in the benchs except for 7-zip (7za b)
For now, only 48MB of ram (16MB not cached), instead of 32MB (fully cached)

As for the CPU, it's a Cyrix 5x86 @ 120Mhz, with the experimental stuff on (the safe one, no BTB).
The not the fastest 486 but it's not far.

tauro wrote on 2023-09-18, 23:22:

Disk drive caching is a different subject.

Indeed, the backup idea (if even possible) was to use the extra ram for disk caching if possible, Keep the cached RAM for the programs and the uncached RAM (anything over 32M) for the disk cache (Still faster than CF in PIO3...)

My actual limit, is the motherboard... You know, very limited ACER BIOS.
And onboard cirrus logic video card, It's "VLB" but well, it bench between ISA and VLB, it's really under-performing, and there is no actual VLB slot.

Would also be cool to know why the PC crash with the L2 to 0ws/0ws instead of 1ws/0ws if I run the jumper configuration in Cyrix 5x86 config, but it work just fine with a nice performance uplift if a set the board jumper to "Intel 486"

Rav wrote on 2023-09-18, 23:52:

The not the fastest 486 but it's not far.

That's one of the fastest Socket 3 CPU (only the 133MHz version is faster), but it's not exactly a 486, it's closer to a Pentium 😉

The fastest proper 486 is the AMD Am5x86, and it can run at 160MHz easily, some at 180MHz and far fewer at 200MHz... Personally I could get a few that work OK at 180MHz 4v (60x3). There's no point really in running a 486 so fast but... it's fun.

Rav wrote on 2023-09-18, 23:52:

Indeed, the backup idea (if even possible) was to use the extra ram for disk caching if possible, Keep the cached RAM for the programs and the uncached RAM (anything over 32M) for the disk cache (Still faster than CF in PIO3...)

I don't know how you could pull that off but maybe you could. I think DOS uses RAM incrementally, but Windows instead uses it the other way, so it always uses the uncached part.

Rav wrote on 2023-09-18, 23:52:

My actual limit, is the motherboard... You know, very limited ACER BIOS.
And onboard cirrus logic video card, It's "VLB" but well, it bench between ISA and VLB, it's really under-performing, and there is no actual VLB slot.

Cirrus cards are quite good. You could also find a VLB riser and use other cards too.

Rav wrote on 2023-09-18, 23:52:

Would also be cool to know why the PC crash with the L2 to 0ws/0ws instead of 1ws/0ws if I run the jumper configuration in Cyrix 5x86 config, but it work just fine with a nice performance uplift if a set the board jumper to "Intel 486"

Maybe it's because the cache chips can't take it. Maybe when you set the jumpers to use an intel 486 you are setting the L1 to WB mode, or you are changing the BUS speed.
To make sure if your L2 is running in WB or WT, run CTCM and see what it reports.

tauro wrote on 2023-09-19, 00:19:

I don't know how you could pull that off but maybe you could. I think DOS uses RAM incrementally, but Windows instead uses it the other way, so it always uses the uncached part.

Real mode seam to do that, I'm not sure about protected mode. (Try running cachechk in protected mode and see)

tauro wrote on 2023-09-19, 00:19:

Cirrus cards are quite good. You could also find a VLB riser and use other cards too.

Not possible unfortunately (not with that board, there is no extra VLB part on the riser slot

tauro wrote on 2023-09-19, 00:19:

Maybe it's because the cache chips can't take it. Maybe when you set the jumpers to use an intel 486 you are setting the L1 to WB mode, or you are changing the BUS speed.
To make sure if your L2 is running in WB or WT, run CTCM and see what it reports.

* I did not change the L2 since all the test
* CTCM say both L1 and L2 are WB
* I did not touch the bus speed (it's a different jumper that allow to select 25/33/40 and unofficially, 50)
I also did not touch the CPU voltage, with is 3.45V

Also, I did notice that the system "POST" a lot faster (spend a lot less time between memory count and actually start to boot from the hdd). That since I put the jumper in "486" configuration.

You can see that the board have very different jumpers weirdness specifically for the CX586
If you look at JP17 and JP26 (They are jumper array). For all the cpu **except** the cx586, there all on the same like all on 1-2 or all on 2-3. While in CX586 mode it's kinda random. Maybe Acer messed up?

I did manage to switch the L2 to WT!

Register 19h
00011100 -> 00010100

I fixed crash issue while switching that bit by issuing WBINVD command before patching it up.
Sometime it still crash when I run other commands but if after, I run other tools that fill that cache like cachechk then it seam to get rid of the crashing issue.

Do I need to put a barrage of NOP after the WBINVD command to "give time to the chipset to do it's job"?

Now all my 64MB is cached, with only 256K of L2!

CTCM say I have WT L2 now.

So beside the small issue I still have, I have getting nearer the goal!

Rav wrote on 2023-10-03, 15:14:

I fixed crash issue while switching that bit by issuing WBINVD command before patching it up.
Sometime it still crash when I run other commands but if after, I run other tools that fill that cache like cachechk then it seam to get rid of the crashing issue.

Usually, after reconfiguring the L2 cache, you should read twice the cache size of consecutive memory to get the L2 cache cleanly refilled. Furthermore, WBINVD only writes back L1, not the L2 on most chipsets (the 486 CPU generates a special WBINVD cycle which is ignored by most chipsets - the Intel Saturn being an exception). The proper procedure thus is:

• Disable interrupts
• Issue WBINVD to flush the L1 cache (just to be sure)
• Load twice the L2 cache size of consecutive physical memory (e.g. 00000 to 7FFFF). This will make sure every cache line gets re-loaded at least one, and written back if dirty.
• reconfigure the chipset
• As the interpretation of the TAG RAM changed, the tag may now be invalid, so load twice the L2 cache size of consecutive physical memory again
• Re-Enable interrupts

This should prevent any crashes.

mkarcher wrote on 2023-10-03, 15:26:

Usually, after reconfiguring the L2 cache, you should read twice the cache size of consecutive memory to get the L2 cache cleanl […]
Show full quote

Rav wrote on 2023-10-03, 15:14:

I fixed crash issue while switching that bit by issuing WBINVD command before patching it up.
Sometime it still crash when I run other commands but if after, I run other tools that fill that cache like cachechk then it seam to get rid of the crashing issue.

Usually, after reconfiguring the L2 cache, you should read twice the cache size of consecutive memory to get the L2 cache cleanly refilled. Furthermore, WBINVD only writes back L1, not the L2 on most chipsets (the 486 CPU generates a special WBINVD cycle which is ignored by most chipsets - the Intel Saturn being an exception). The proper procedure thus is:

• Disable interrupts
• Issue WBINVD to flush the L1 cache (just to be sure)
• Load twice the L2 cache size of consecutive physical memory (e.g. 00000 to 7FFFF). This will make sure every cache line gets re-loaded at least one, and written back if dirty.
• reconfigure the chipset
• As the interpretation of the TAG RAM changed, the tag may now be invalid, so load twice the L2 cache size of consecutive physical memory again
• Re-Enable interrupts

This should prevent any crashes.

Thanks for the info, so that's the next thing I do!

mkarcher wrote on 2023-10-03, 15:26:

Usually, after reconfiguring the L2 cache, you should read twice the cache size of consecutive memory to get the L2 cache cleanl […]
Show full quote

Rav wrote on 2023-10-03, 15:14:

I fixed crash issue while switching that bit by issuing WBINVD command before patching it up.
Sometime it still crash when I run other commands but if after, I run other tools that fill that cache like cachechk then it seam to get rid of the crashing issue.

Usually, after reconfiguring the L2 cache, you should read twice the cache size of consecutive memory to get the L2 cache cleanly refilled. Furthermore, WBINVD only writes back L1, not the L2 on most chipsets (the 486 CPU generates a special WBINVD cycle which is ignored by most chipsets - the Intel Saturn being an exception). The proper procedure thus is:

• Disable interrupts
• Issue WBINVD to flush the L1 cache (just to be sure)
• Load twice the L2 cache size of consecutive physical memory (e.g. 00000 to 7FFFF). This will make sure every cache line gets re-loaded at least one, and written back if dirty.
• reconfigure the chipset
• As the interpretation of the TAG RAM changed, the tag may now be invalid, so load twice the L2 cache size of consecutive physical memory again
• Re-Enable interrupts

This should prevent any crashes.

Hi, I don't know if you can help (or someone else).
My ASM is kinda rusted and I never actually did moving memory around since... today..

I try to do that memory loading thing but I have some issue (code included below):
* 4DOS + Himem.sys : It seam to work every time, no issue, it just work!!!
* Command.com + Himem.sys : Do not return to prompt, just hang (Would need that to work if possible, else I can just setup 4DOS to load before windows 95, on my Win95 partition...)
* 4DOS + QEMM : QEMM bark at me with option to terminate the program or reboot the system. Note that commenting out the two CALL instruction make it work (not every time as the call instruction are for the cache filling and so it just issue wbinvd and change the chipset register without refilling the cache memory.

I assume QEMM bark at me because of some protection fault, maybe I am not allowed to read absolute address like that?

1org 0x100
2
3cli
4
5wbinvd
6call fillthecache
7
8;we set 0x22 to 0x19 (cache control register)
9xor al,al
10mov al,0x19 ; Cache control register
11out 0x22,al
12
13; We read 0x19 register into al
14xor al,al   
15in al,0x23  
16
17; We set the register bit
18and al,11110111b ; WB/WT or TAG7+1/8+0BITS?
19
20; We write register
21out 0x23,al
22
23call fillthecache
24
25sti
26jmp lafin
27
28fillthecache:
29xor ecx,ecx
30next:
31; lea ebx, [ecx*4] (Apparently I can just put the ecx*4 in the mov instruction)
32mov eax, [ecx*4]
33inc ecx
34cmp ecx,020000h
35jne next
36ret
37
38lafin:
39mov ax,4c00h
40int 0x21

Finally, I went to the C route and made a tool to fix that M1429 chipset.

The tool work successfully for changing the cache mode, each time I tried. It work with all tested DOS configuration (command.com, 4dos, with or without QEMM)
HIMEM.SYS IS REQUIRED

The tool also do the other configuration change as needed using switches so it can adjust memory timing, cache wait states and the rest of the dumped registers from mkarcher

I am going to release it once I'm done polishing it.