ltning wrote on 2023-06-19, 18:37:
Tested on a different MX-chipset board (which is the same chipset I have in the first machine I reported about). It inits, but only after one or two SLAM attempts. Typically it needs two the first time after boot, and only one afterwards (or after a warm boot). This is with a 386DX CPU; the other board has a 486DLC (but same socket).
I think some of this is starting to make a little bit of sense, but I still have to make sure I understand the details of what you've been testing. So, please confirm the details for me:
- You ran the EEPROM clearing tool on the FOREX/UMC machine, and it still produces exactly the same output.
- What is the configuration of the above-mentioned machine?
- You then moved the same card to another MX-chipset machine, this time with a 386DX, and it is now behaving mostly as expected (more on this in a moment).
- Between the MX-chipset machines, is the configuration exactly the same, right down to bus speed, ISA clock and timing configuration, as well as BIOS options, except that one has a 386DX and the other a 486DLC?
Part of the reason that we are seeing the behaviour that you observed on the 386DX-based MX-chipset machine is that we just cleared the critical part of the EEPROM. If your other card still has the original EEPROM content intact, you should see exactly the correct behaviour with that card, if installed in the 386DX-MX-machine. We can restore the proper content later, so that won't be a permanent problem for you, but having the two cards configured differently may end up being useful in testing, so it may be a good idea to leave it as is for now.
If we can't make any satisfactory progress on this issue, and you really want to use the card in one of those machines, I should be able to put together some alternate init tools for you to test. So, if nothing else, that should get the card working in those machines, and the changes would eventually have to be integrated into ORPHINIT. However, that feels like a bit of a dirty, last-resort solution. Now the burning question is: what is different about those machines that causes it to break, and can we fix it at the software level, so that it works as designed (without additional kludgey changes)?