Will you make a .cfg for ctchip? 😉

Rav wrote on 2023-04-03, 18:49:

Here are the documentation : https://stason.org/TULARC/pc/motherboards/A/A … 6-G-A1GX-2.html
Note that 50Mhz fsb is not on the documentation nor on the board silkscreen, found it by mistake because the 40mhz jumper setting was corroded and not making contact initially (JP11 not connected = 50Mhz)

Bios is "Acer"

I see that you only have one bank of cache. That's usually not a recommended configuration at FSB40, and might be the reason why the BIOS drops the cache timing. Upgrading to 8 SRAM chips might help a lot here. It might also make the L2 cache work at 50MHz, but I wouldn't count on it.

I recently pulled an ALi 1429-based VL board out of my parts bin, because I knew that it can drive 128MB RAM on 30-pin modules (using 8 16MB modules), which might make an interesting build, but I didn't do much with it, after I found that memory benchmarks were awful, even with a BIOS that allowed manual tuning. I'm afraid that this chipset is likely not a good performer, even in optimal configuration. Both my UMC 480 based board and an Opti 895-based board provided better memory speed than the ALi 1429.

mkarcher wrote on 2023-04-03, 21:41:

Rav wrote on 2023-04-03, 18:49:

Here are the documentation : https://stason.org/TULARC/pc/motherboards/A/A … 6-G-A1GX-2.html
Note that 50Mhz fsb is not on the documentation nor on the board silkscreen, found it by mistake because the 40mhz jumper setting was corroded and not making contact initially (JP11 not connected = 50Mhz)

Bios is "Acer"

I see that you only have one bank of cache. That's usually not a recommended configuration at FSB40, and might be the reason why the BIOS drops the cache timing. Upgrading to 8 SRAM chips might help a lot here. It might also make the L2 cache work at 50MHz, but I wouldn't count on it.

I recently pulled an ALi 1429-based VL board out of my parts bin, because I knew that it can drive 128MB RAM on 30-pin modules (using 8 16MB modules), which might make an interesting build, but I didn't do much with it, after I found that memory benchmarks were awful, even with a BIOS that allowed manual tuning. I'm afraid that this chipset is likely not a good performer, even in optimal configuration. Both my UMC 480 based board and an Opti 895-based board provided better memory speed than the ALi 1429.

Yeah, I did order more sram chip on alie last month but the postman returned it after deciding that the address was not valid.. (Did order many time on alie without issue...) I guess I'm going to wait another month for that extra SRAM...

Disruptor wrote on 2023-04-03, 21:38:

Will you make a .cfg for ctchip? 😉

Yes, If I can get it working

Rav wrote on 2023-04-03, 21:33:

And see no trace of messing with index register 1Bh, which if is the same in M1429 than M1489, would mean that it would use default of slow timing for read and write, disable RAS only refresh, disable onboard parity check and 4T for CPU time slot (I don't know what that latter is).

Next step would be to try to unlock by writing 03h to port 22h and C5h to port 23 then write 1Bh to port 22 and 0Ah to port 23 then bench if it change anything...

Don't get your hope high on that. It's very unlikely that the registers are compatible. The M1429 is way older than the M1489. The M1429 doesn't support SMM (the M1489 has SMM configuration in register 19h), and the M1429 doesn't support EDO (the M1489 has EDO configuration in 1Ah). So even if the M1429 has the same cache interface (which is indeed possible), the configuration index surely will not be 1B. If your BIOS dis-assembly is deep enough, you should find a location where the BIOS loads different configuration values depending on the FSB clock. Those registers are the one to play with to get better performance at FSB40.

Hey. We need a .cfg for the 1489 too 😀

So far, in speedsys::
Test fsb33 cpu 66mhz

Doing bruteforcing of the register 0x1d ("Reserved" according to M1489 doc)
Memory Bandwidth = 62 -> 99.34 MB/s
Data cache L1 = 48.20 -> 51.61MB/s
Data cache L2 = 34.02 -> 37.44MB/s
Memory throughput = 23.69 -> 31.24

7zip benchmark = 13/12/12/217/18/18 -> 17/16/16/255/21/21

I also played a little with register 0x16 and noticed xxxx0000 -> xxxx1010 made memory speed like if I did switch to fsb40... Will check that one later after I switched to 40. I did that test without 0x1d untouched.

Update:

I did some more tests.
1 - For the register 0x1d, it have a big diminishing return. While it boost the memory speed quite enough on a 33fsb (enough so the read speed is about as fast as the L2), on 40fsb, the difference is a lot less. And on 50fsb, except for crashing the system most of the time while playing with that register, it did not do much.

2 - I did a scan of all registers between 00h and ffh, at 33fsb and 40fsb (to see the difference). There is no much difference, really like 7 registers in total. I did revert the "33fsb" value while on 40 and on most of them it did nothing so the cache adjustment between 33 and 40 is not there, not the stuff for the memory divisor. Only register that did a thing was 0x20, but I think it's related to the keyboard.

3 - Jumper JP12 must be positioned depending of what the bus is running at. one position for 25/33 and one for 40/50

4 - If I control-alt-del, the system reboot and do the whole bios post thing (about as much time as if I press reset). But unlike with the reset button, the registers change I did for the memory stay patched...

5 - 386MAX hate my register patch (but all games I tested work, Windows too, but 386max refuse to load if the registers are patched and if I patch them after loading it, it generate a protection error). I did not test with emm386 (yet)

Due to 3 & 4, I assume that the BIOS don't change the memory and cache performance settings, I assume that the chipset detect the jumper JP12 position and apply multiplier by itself, and use the **default** cache and memory performance settings. (according to the M1489 Docs, these have default setting)

Here the register difference between 33 and 40:
175,176c175,176
< 52=AE
< 51=AE
---
> 52=20
> 51=00
180c180
< 4D=19
---
> 4D=08
225c225
< 20=24
---
> 20=22
231,232c231,232
< 1A=80
< 19=5C
---
> 1A=40
> 19=7C
255c255
< 02=EC
---
> 02=E4

I also attached my current version of the patch for M1429 for memory performance improvement at 33fsb if there is someone who want to test it (it have no parameter, just set the max performance I was able to get by messing with that 0x1d register.) Again, it is allergic to 386MAX

Rav wrote on 2023-04-04, 06:48:

3 - Jumper JP12 must be positioned depending of what the bus is running at. one position for 25/33 and one for 40/50

Many 486 boards have a jumper like that, especially if they have VL slots. There is a pin on the VL slot that is intended to inform cards whether they got 1 clock cycle to claim a bus cycle (intended operation at 25/33) or they got 2 clock cycles until they need to have the signal ready whether they want to take over the cycle (intended operation at 40/50). Most 486 boards with that jumper only tie this jumper to the VL slots, and do not connect it to the chipset.

Rav wrote on 2023-04-04, 06:48:

4 - If I control-alt-del, the system reboot and do the whole bios post thing (about as much time as if I press reset). But unlike with the reset button, the registers change I did for the memory stay patched...

Rav wrote on 2023-04-04, 06:48:

Due to 3 & 4, I assume that the BIOS don't change the memory and cache performance settings, I assume that the chipset detect the jumper JP12 position and apply multiplier by itself, and use the **default** cache and memory performance settings. (according to the M1489 Docs, these have default setting)

You should be aware that there is a way to detect whether reset was pressed or not: There is a bit in the keyboard controller (port 64h, bit 2) that is cleared during hardware reset (both power-up and pushing the RESET button, but not ctrl-alt-del), and can be set using a keyboard controller command at the end of the POST. Many 486 BIOSes perform the initial memory configuration only when this bit is cleared. This does not have to apply to your case, though. A point for your interpretation is that the initial configuration that might be skipped on any kind of warm reset usually is performed before the CPU clock is measured by the BIOS, so it is unlikely to contain FSB-dependent setup.

Rav wrote on 2023-04-04, 06:48:

5 - 386MAX hate my register patch (but all games I tested work, Windows too, but 386max refuse to load if the registers are patched and if I patch them after loading it, it generate a protection error). I did not test with emm386 (yet)

This sounds like there are issues with memory access patterns that are generated when 386MAX is loaded. It is possible that 386MAX loads itself into the highest addresses available, so the start of extended memory stays free with or without 386MAX loaded. Do you have 2 banks of memory? Maybe you get issues when you rapidly mix accesses between both banks.

mkarcher wrote on 2023-04-04, 07:39:

Many 486 boards have a jumper like that, especially if they have VL slots. There is a pin on the VL slot that is intended to inf […]
Show full quote

Rav wrote on 2023-04-04, 06:48:

3 - Jumper JP12 must be positioned depending of what the bus is running at. one position for 25/33 and one for 40/50

Many 486 boards have a jumper like that, especially if they have VL slots. There is a pin on the VL slot that is intended to inform cards whether they got 1 clock cycle to claim a bus cycle (intended operation at 25/33) or they got 2 clock cycles until they need to have the signal ready whether they want to take over the cycle (intended operation at 40/50). Most 486 boards with that jumper only tie this jumper to the VL slots, and do not connect it to the chipset.

Rav wrote on 2023-04-04, 06:48:

4 - If I control-alt-del, the system reboot and do the whole bios post thing (about as much time as if I press reset). But unlike with the reset button, the registers change I did for the memory stay patched...

Rav wrote on 2023-04-04, 06:48:

Due to 3 & 4, I assume that the BIOS don't change the memory and cache performance settings, I assume that the chipset detect the jumper JP12 position and apply multiplier by itself, and use the **default** cache and memory performance settings. (according to the M1489 Docs, these have default setting)

You should be aware that there is a way to detect whether reset was pressed or not: There is a bit in the keyboard controller (port 64h, bit 2) that is cleared during hardware reset (both power-up and pushing the RESET button, but not ctrl-alt-del), and can be set using a keyboard controller command at the end of the POST. Many 486 BIOSes perform the initial memory configuration only when this bit is cleared. This does not have to apply to your case, though. A point for your interpretation is that the initial configuration that might be skipped on any kind of warm reset usually is performed before the CPU clock is measured by the BIOS, so it is unlikely to contain FSB-dependent setup.

Rav wrote on 2023-04-04, 06:48:

5 - 386MAX hate my register patch (but all games I tested work, Windows too, but 386max refuse to load if the registers are patched and if I patch them after loading it, it generate a protection error). I did not test with emm386 (yet)

This sounds like there are issues with memory access patterns that are generated when 386MAX is loaded. It is possible that 386MAX loads itself into the highest addresses available, so the start of extended memory stays free with or without 386MAX loaded. Do you have 2 banks of memory? Maybe you get issues when you rapidly mix accesses between both banks.

Yes, I do have many bank of memory. Could indeed be the issue. Maybe I also changed something I should not have changer, who know, it's undocumented 😁 I test with just one stick later today. Could also confirm if that jumper do only VLB by setting it to 40/50 while setting the bus to 33. Will see later, thanks.

I think I got an idea that should allow me to reverse engineer that way better than playing the poking random registers.

I already made a program that scan all register and print them on screen.
So what I need now is people with motherboard with M1429 or M1429G.

Then have them:

1 - boot the computer, go in bios save the settings (without changing a thing). Dump registers
2 - reboot, go in bios, change a thing but reverting it back, save again. Dump registers (to see if we have some register that change for no apparent reasons)
3 - reboot, go in bios, change **one** thing, save, Dump registers
goto 3

Each dump should be named the same, 0.txt, 00.txt (first to dump to detect register that can change for "no reasons"), 1.txt, 2.txt, 3.txt...

For fields that have many option, like wait states/timing, could set the lowest one, dump register, set the higher bootable one right after, dump registers...

With that I would need the persons who do that to document a text file in that format:

0 - initial boot
00 - change nothing, save again (to detect if some registers change for fun)
1 - enabled bank interleave
2 - setting worst timing
3 - setting best timing
4 - changed is bus divider...
etc etc, one option at a time

I think I should create a new forum topic only for this activity.
And that should give me the best change of mapping most of the useful registers

Complementary to that, I should check for potable bios to disassemble to try to get some clue.

Rav wrote on 2023-04-04, 06:48:

4 - If I control-alt-del, the system reboot and do the whole bios post thing (about as much time as if I press reset). But unlike with the reset button, the registers change I did for the memory stay patched...

Cool. Then you can try memtest 4.10 too

Disruptor wrote on 2023-04-04, 16:21:

Rav wrote on 2023-04-04, 06:48:

4 - If I control-alt-del, the system reboot and do the whole bios post thing (about as much time as if I press reset). But unlike with the reset button, the registers change I did for the memory stay patched...

Cool. Then you can try memtest 4.10 too

Yes.

So far I removed my extra ram and it fixed the 386max issue.
Now testing with memtest (with and without the patch (so I can time it too))

Disruptor wrote on 2023-04-03, 21:38:

Will you make a .cfg for ctchip? 😉

Here you go (tested on Acer AG1X/2 [ALI1429M])

Anyone know if there is a way to make it so it "auto unlock" with ctchip34 (as for now you have to patch the first register of the set with C5)
I did set the macro "Open/Close" But it does not seam to work.

Was there any change in registers between ALI M1429 A1 and M1429M ? I am using a Daewoo AL486V-D for a BL3 setup and it contains the M1429 A1. I was wondering if your CTCHIP34 config file will work on my chipset revision or will there be some anomalies?

Would you be able to provide a step-by-step instruction to "patch the first register of the set with C5"?

Did you already check AMISETUP to see if there were some hidden options you can apply or adjust to help with your speed issues? On my Daewoo board's BIOS, I recall there being about half the chipset options hidden, for which AMISETUP can unhide and adjust.

Pardon my ignorance, but is there any specific reason why you want to use 386max over other DOS-based memory managers? Do other memory managers also cause issues with your patches?

mkarcher wrote on 2023-04-03, 21:41:

I recently pulled an ALi 1429-based VL board out of my parts bin, because I knew that it can drive 128MB RAM on 30-pin modules (using 8 16MB modules), which might make an interesting build, but I didn't do much with it, after I found that memory benchmarks were awful, even with a BIOS that allowed manual tuning. I'm afraid that this chipset is likely not a good performer, even in optimal configuration. Both my UMC 480 based board and an Opti 895-based board provided better memory speed than the ALi 1429.

I also noticed that my board would work with 16 MB SIMMs and 128 MB total. Is the cacheable range of this chipset with 256K-WT still only 64 MB? Since I am using a BL3, the L1 can only cache up to 16 MB, so I only run 16 MB. If not for the BL3 and VLB support, I probably wouldn't be using this board because of the slow performance that you witnessed. However, I recall DOOM results being about on-par with the Alaris Cougar + BL3-100.

feipoa wrote on 2023-04-09, 09:25:

Was there any change in registers between ALI M1429 A1 and M1429M ? I am using a Daewoo AL486V-D for a BL3 setup and it contains the M1429 A1. I was wondering if your CTCHIP34 config file will work on my chipset revision or will there be some anomalies?

Would you be able to provide a step-by-step instruction to "patch the first register of the set with C5"?

From what I understand, the M1429G just have extra power management. There is one way to see if it's the same registers for the different options in the CFG files, Try them. I would think it's the same chipset with the extra power bits not laser-ed out / disabled.

Have you ever used CTCHIP34? If so it's simple, the register in question is included in the config file and it's the first one. You simply have to press "$C5[ENTER]" when you get to it.

If you never used ctchip, then you:
* run it with ctchip34 ali1429
* then you press [enter] one time to see the first register that can be patched
* You can continue to press enter to go to next register
* If you want to modify, simply press $ if you want to edit by writing an hex value or % if you want to write the value in binary. There is also P for pattern, not sure for that one and never used it.
* When you write a register it will display it to you a second time so you see if the change are effective.

feipoa wrote on 2023-04-09, 09:25:

Did you already check AMISETUP to see if there were some hidden options you can apply or adjust to help with your speed issues? On my Daewoo board's BIOS, I recall there being about half the chipset options hidden, for which AMISETUP can unhide and adjust.

As for editing the BIOS with AMISETUP, I could not do that as the BIOS of mine is not AMI. It's a custom proprietary bios from Acer so I don't expect any tool to be able to allow simple editing like that.

feipoa wrote on 2023-04-09, 09:25:

Pardon my ignorance, but is there any specific reason why you want to use 386max over other DOS-based memory managers? Do other memory managers also cause issues with your patches?

386MAX itself take less conventional memory than Himem+emm386.exe, barely one k... It's one program that do both. And it also move all the files/buffers/stacks and other of these options into umb. With all the kitchen sink loaded (with include the Pro Audio Spectrum 16 drivers, the packet drivers, the windows packet driver, univbe, mouse, smartdrv, ansi, setver.....), I still have 629KB of conventional memory with DOS 6.22.

And I can manage 621KB with DOS 7.1 because I'm not done messing with it, I think I have to tell dos to not autoload ifhlp.sys one another things so I can let the 386max maximixer to relocate them, else they stay in conventional memory.

As for compatibility, I did not get any issue that emm386 will also give, so far.

Thank you. Yes, I'm familiar with CTCHIP34. I just wanted to confirm your work-around, that is, I press $C5 when I get to a prompt asking me to press it. That is easy enough. Next time I have my ALi 1429 board out, I will try your config file w/CTCHIP34.

Have you tried to use an AMI BIOS on your board from a board with similar components? I guess that would destroy the ACER OEM authenticity factor.

That is a very impressive amount of conventional memory to have free. Thanks for the explanation of why you are using 386MAX.

feipoa wrote on 2023-04-09, 09:25:

mkarcher wrote on 2023-04-03, 21:41:

I recently pulled an ALi 1429-based VL board out of my parts bin, because I knew that it can drive 128MB RAM on 30-pin modules (using 8 16MB modules), which might make an interesting build, but I didn't do much with it, after I found that memory benchmarks were awful, even with a BIOS that allowed manual tuning.

I also noticed that my board would work with 16 MB SIMMs and 128 MB total. Is the cacheable range of this chipset with 256K-WT still only 64 MB?

Yes, the M1429 uses the same L2 cache implementation strategy as every other consumer 486 chipset and thus has the same limits on the cacheable area. A bigger cachable area would require more than 8 tag bits, so you are never going to see it on a board that requires 5/9 x8 chips.

feipoa wrote on 2023-04-09, 21:25:

Have you tried to use an AMI BIOS on your board from a board with similar components? I guess that would destroy the ACER OEM authenticity factor.

I plan to do that once I will have a proper eprom programmer and a few extra eeproms

I will keep the original ROM as is in a safe location so I will be able to restore the ACER OEM authenticity factor as needed.

Thanks! I briefly looked at the config file. The most interesting options to try on my system would be the AT clock speed, which is stuck at 7.1 MHz, and the VL device ready sync mode, which is stuck on Sync mode. Bypass mode should be faster. Are you finished with the config file, or do you think there are more options to reveal?