So actually I was surprised the 286 had to run with more conservative RAS timings
I suspect this has more to do with the internal operation of the 320 how it connects its logic in timing to the 286 status signals.
That is not necessarily a speed thing but may also simply be related to timing and duration derived from the different timing of the 286 status lines and how these drive the internal logic for RAS output generation timing.
Otherwise I was pleasantly surprised that the 286 is able to run such fast DRAM timing.
The most notable value is the CAS duration for reads and writes.
This literally translates in wait state alike speed differences.
So those are much more important and critical for the performance than the RAS stuff.
Though one RAS value I was able to lower it which gained a slight speed increase.
In the end when raising the clock, I got another speed boost.
Maybe if we use a better ROM chip like the more modern EEPROM 1 megabit chips, this can allow the system to INIT with higher clock speeds.
And then everything can be re-tweaked again.
If we didn't have this AMI BIOS, we would not have those options at all.
I'm aware of a lot of the registers due to writing scamp/topcat drivers
Right, these are really very similar with each other.
So much so that your SCAMP EMS driver also works with the TOPCAT.
Comparing a SCAMP system with a TOPCAT one, the biggest difference between these is that with the TOPCAT they split the system control between the 320 and 331.
The 331 can do it's own system control which can run synchronous or asynchronous with the 320 clock timing.
Well since the SCAMP system has a single system controller, maybe such a design is superior in the maximum overclock ranges it can achieve.
Though I still reserve this for future testing when we can use 4 megabit 4 bit wide or better DRAMs on the TOPCAT.
Other optimizations may yet yield big improvements in the maximum clock range, which has definitely some good reasons behind expecting that.
Reducing the DRAM address bus load is very important for the maximum timing of all the DRAMs combined in the system.
It's not necessarily even the DRAM nanosecond rating but also the lesser impedance load on the address lines.
Maybe it's the conservative VGA timings, maybe its the RAS delay, maybe a little of both.
Indeed it must be both, as there is constant reading from system RAM and writing to VGA RAM.
So in my tests it was revealed that the VGA write cycles are really much slower than other systems I have tested.
I think the SCAT was much better, maybe almost twice the VGA write speed of the TOPCAT.
Unfortunately, the VGA write speed largely depends on the 331 system control timing, which can be somewhat influenced by the "BUS clock" sent from the 320 to the 331.
So any means to raise that clock if the system can still keep running, would probably improve the Cirrus Logic card performance a lot with the TOPCAT.
A way to increase the 331 system control speed may be to increase the BUS clock input oscillator speed, and setting the bus clock mode to asynchronous.
So this oscillator could be exchanged, though I would have to see about the floppy controller how to then handle that.
And the IO wait states can be slightly increased to keep the slot cards stable, while the slot memory operations (VGA and option ROM) may be increased in speed.
Especially when shadowing the option ROM, it can be taken out of the equation probably.
Maybe it's better to provide different clocks for the bus clock and floppy controller.
That way the bus clock can be raised to improve the VGA cycle speeds with the 331 system control.
However I did notice before that asynchronous mode may decrease performance compared to synchronous mode.
Though the clock increase may make up for this as well.
Still some stuff to be tested in the future.
Just curious, did I ever send you this dram refresh lowering program? It just simply programs the PIT to run a very very low dram refresh count which improves performance. I have never had trouble with it whether on a 5150 or a fast 286. I will include it here for you. I just stick it in my autoexec usually, but you can also run it manually.
Cool, thanks, I did not use this tool before!
Slowing the refresh timing definitely provides a performance boost as I could see with the TOPCAT tests where the maximum refresh slowdown is /16.
Indeed lowering the timer frequency seems like another way.
Though I am not sure how they slow the refresh in the 320.
If that is a division from the timer frequency, it could indeed be further lowered.
I think these DRAMs have very good retention since I even got garbled screens when powering back up too fast.
So some level of data was retained even after seconds.
I will review my other notes about the MSI board regarding the passives for bus series termination etc.
I don't plan to use caps on the IRQs like they did since this won't bring anything but other stuff I can include so it's easier to solder in these parts just to see how this affects the speed results.
And I want to do some scope measurements, though I am slightly skeptical whether my cheap scope is able to show the better edges.
When zooming into signals, at some stage the display becomes pretty rough and spiky and I doubt this is accurate anymore.
Anyway, it is what it is.
We can see from test speeds whether passive components can add anything positive.
About this I am also still skeptical but I am now willing to at least try this out.
I remember seeing such a huge difference in responsiveness of the system when powering on the MSI board.
At the time this was frustrating with the TOPCAT REV1.
Thankfully because of this cool AMI BIOS, at least the ATX TOPCAT REV1 now feels roughly the same!
Again, thanks for your modifications Patrick.
One day when you build your own TOPCAT board I think you will also appreciate being able to use this cool AMI BIOS, it's very useful!
If you can find other improvements that would be great too.
Maybe if you could find the setup default register values that the BIOS is loading.
If we could replace these with our best scenario, that could instantly load the optimal performance values.
And the "power on defaults" can be used for being able to initialize the system.
There is even a third set of register values at play which the 320 and 331 load by themselves when powering up.
And it's cool that the 331 is a sort of "slave" or "shadow" device when programming the registers, and listens to certain bits to setup itself as well.
I am not surprised with your findings of obfuscated stuff in the AMI BIOS.
This was surely also in part because of the times where a lot of commercial factors were at play.
It's a pity now of course since these systems are purely enthusiast hobby and historic value stuff, and if we can reduce this now, that will be much better of course to get rid of some things.
After your mentions of port 80, I am wondering if we are not better off using a nice large 208 pin CPLD and include a cool POST display on the board.
When soldering the TOPCAT chips on, the larger CPLD is no different in this regard.
I have been working on a somewhat straight forward interfacing of the PicoGUS in the mainboard which is of course different from an adapter card as it originally is developed on.
So I want to use some of the CPLD logic to do all the PicoGUS control mechanisms, and mostly use the bus switch ICs for the level adjustments to connect with the pico.
So the PicoGUS is always under development and it can do all sorts of emulation including Sound blaster, so maybe I should wire a few more interrupts to the larger CPLD just to increase the options for interrupts.
I don't see any gain in doing 16 bit DMA channel support since the sound data bus is 8 bits.
So DMA channel 1 seems enough.
I don't like jumpers really so it would be better to use the CPLD programming to setup stuff.
And a few register bits can be used to flip some interrupts too.
The IO decoder doesn't need many registers by itself anyway.
Kind regards,
Rodney
