Good news, I have run a Wolf3D test game demo of more than 4 hours and another one of 5:30 hours. So that's reasonably stable.
In the past I have tried several times to run the DMA controllers at 4,77Mhz instead of 4Mhz as was done in the 5170.
4,77Mhz is divided down from the OSC clock signal on the ISA slot of 14,318 Mhz, which also means that the DMA controller clock would not b e in sync with the 286_CLK and main CPU clock. It has been my theory all along that just like with the XT, it's not necessary to derive and sync the DMA clock from the main CPU clock for operating the DMA controllers.
In the past I was still having trouble with stability so I could not run a lengthy stable test with the DMA controllers at faster clock speed. After some variation in the results I would usually return the DMA controllers to 4Mhz at the time.
Since I have now solved the remaining problems by using faster EEPROM chips instead of EPROMs, this time I clocked the DMA controllers from the OSC clock divided by 3 and asynchronous to the main CPU clock once again for another test at 4,77 Mhz. As expected, the handshaking between the CPU and the DMA controllers to release the bus and return it back to the CPU enables DMA to work properly using this configuration, even at 16Mhz CPU clock. Today I was finally able to indicate this in a stable test by running a Wolf3D game demo for more than 7 hours, and the system is still running now without any issues.
Using a faster clock on the DMA controllers has the added benefit of a slightly faster DMA performance so it's great that this is possible. Faster DMA operation also means more CPU execution time on the bus, so this provides an additional performance increase in terms of extra CPU cycles.
Next I will test the memory card to run completely on HCT transceivers. I believe this could help with higher CPU clock speed tests later on because the signals on the RAMs will have much better amplitudes compared to LS or ALS logic.
If I find some faster Harris CPUs I will write about the results here as soon as I am able to test these. For these tests I will look at more detail at the crystal inputs of the 82284 in order to determine if I can provide the 40Mhz and 50Mhz from an external oscillator directly into these inputs. Otherwise I would need to find some even faster crystals. I am not saying that this would be impossible but I would prefer to use the construction of the external oscillator at 40Mhz or 50Mhz 286_CLK. This would be well above the 24Mhz specification of the 82284 I am using, but that's not to say that it would not be able to run. Right now the 82284 is already running at 32Mhz without any problems. The only thing which is nearing now is that the PCB load capacitance would become too high. Possibly I would need something else on the crystal if using a crystal of 40 or 50 Mhz, if I can find one, to keep it in oscillation on the 82284 inputs, like a circuit using a coil or something like that. Anyway, I would prefer an oscillator chip on the crystal inputs instead. As soon as I am able to determine if this is possible I will write about it. I tried before with the EFI input at 33Mhz, however at that time I was not even able to POST the system in my tests. So that's why I want to attempt using an oscillator on one of the crystal inputs to see how that runs.
Kind regards,
Rodney
In the past I have tried several times to run the DMA controllers at 4,77Mhz instead of 4Mhz as was done in the 5170.
4,77Mhz is divided down from the OSC clock signal on the ISA slot of 14,318 Mhz, which also means that the DMA controller clock would not b e in sync with the 286_CLK and main CPU clock. It has been my theory all along that just like with the XT, it's not necessary to derive and sync the DMA clock from the main CPU clock for operating the DMA controllers.
In the past I was still having trouble with stability so I could not run a lengthy stable test with the DMA controllers at faster clock speed. After some variation in the results I would usually return the DMA controllers to 4Mhz at the time.
Since I have now solved the remaining problems by using faster EEPROM chips instead of EPROMs, this time I clocked the DMA controllers from the OSC clock divided by 3 and asynchronous to the main CPU clock once again for another test at 4,77 Mhz. As expected, the handshaking between the CPU and the DMA controllers to release the bus and return it back to the CPU enables DMA to work properly using this configuration, even at 16Mhz CPU clock. Today I was finally able to indicate this in a stable test by running a Wolf3D game demo for more than 7 hours, and the system is still running now without any issues.
Using a faster clock on the DMA controllers has the added benefit of a slightly faster DMA performance so it's great that this is possible. Faster DMA operation also means more CPU execution time on the bus, so this provides an additional performance increase in terms of extra CPU cycles.
Next I will test the memory card to run completely on HCT transceivers. I believe this could help with higher CPU clock speed tests later on because the signals on the RAMs will have much better amplitudes compared to LS or ALS logic.
If I find some faster Harris CPUs I will write about the results here as soon as I am able to test these. For these tests I will look at more detail at the crystal inputs of the 82284 in order to determine if I can provide the 40Mhz and 50Mhz from an external oscillator directly into these inputs. Otherwise I would need to find some even faster crystals. I am not saying that this would be impossible but I would prefer to use the construction of the external oscillator at 40Mhz or 50Mhz 286_CLK. This would be well above the 24Mhz specification of the 82284 I am using, but that's not to say that it would not be able to run. Right now the 82284 is already running at 32Mhz without any problems. The only thing which is nearing now is that the PCB load capacitance would become too high. Possibly I would need something else on the crystal if using a crystal of 40 or 50 Mhz, if I can find one, to keep it in oscillation on the 82284 inputs, like a circuit using a coil or something like that. Anyway, I would prefer an oscillator chip on the crystal inputs instead. As soon as I am able to determine if this is possible I will write about it. I tried before with the EFI input at 33Mhz, however at that time I was not even able to POST the system in my tests. So that's why I want to attempt using an oscillator on one of the crystal inputs to see how that runs.
Kind regards,
Rodney