Idea was to request the bus from the CPU as soon as the CPU started bus cycle.. So when /AS goes high we keep BGACK low CPU should be tri-stated and not doing anything.. Basically using this as a pause so that it does not double read DTACK. More of a automatic delay. So the idea is that BGACK will be kept low while CPU_AS is high and DTACK is low...
It seemed a good idea but does not want to boot up I guess it could be possible something else requests the bus and conflicts with what I'm trying to do
Code: Select all
CPU_BR = 'b'0;
CPU_BR.OE = !ST_BR # !CPU_AS; //when CPU_AS low, issue BR..
//BG will come end of bus cycle..
ST_BG = CPU_BG ;
CPU_BGACK = 'b'0;
CPU_BGACK.OE = !ST_BGACK
# CPU_AS & !ST_DTACK //if CPU_AS high and DTACK low, then isolate CPU with BGACK
# !CPU_BG ;
// when DTACK goes high, BGACK will go high, terminate fake dma cycle..
OK, so small change to the code...
Code: Select all
ST_BG.OE = CPU_AS;
ST_BG = CPU_BG ;
So I removed the 2 clock delay on DTACK, machine not boot.. I tried 1 clock delay and machine boots and seems stable, but still 50% RAM access speed
So I think the BGACK is working as 1 clock delay was unstable before.. but obviously something is taking to long
Another small change to the code...
Code: Select all
CPU_BGACK.OE = (!ST_BGACK # !CPU_BG ) & !CPU_AS;
So the idea works overall, but in practice, the CPU just takes too many cycles to recover from DMA bus cycle
Looking at the timing diagram...
It would seem the CPU will take two clock cycles to resume normal operations.. Would have thought that at 20Mhz so cycles would not really be relevant..
I have removed delays on /AS as well, so I cannot make the bus access the faster now. So I can only assume that resuming normal bus operations to simply take too long
I guess I could look into HALT.. manual says it will complete current bus cycle and tri-state.. but I guess its "recovery time" like DMA access... Looks like HALT needs 1 cycle to recover, so I could experiment with that I guess..
But there is still the problem slow graphics tests from previously.. I think what maybe the problem is that the CPU actually starts doing the next bus cycle at 8 MHz while DTACK is still low.. And the problem with delaying DTACK with a fixed delay, means that we always have to wait until just before DTACK goes high before we start the next bus cycle... I suspect the issue could be that in such cases the CPU starts a cycle too late and results in huge drop in benchmark speeds. I do not really see any way around this as there is no way to know how much to delay DTACK by depending on what is being accessed.
So while I was thinking more about isolating the bus and waiting for DTACK to go high, rather than trying to adding fixed delays on DTACK to basically stall the processor.. But likely my second thought on HALT is going to suffer from the same problem as delaying DTACK.. In that there is no way to know when to start bus cycle in effect early.. The CPU itself does this automatically on 8 MHz and I cannot really see way of emulating this
I will keep thinking about this, though I think running at constant speed is ultimately going to cause a lot of slowdowns which are not there with 8/16 switching. But of course this will need a synchronised clock which also means not much freedom on clock speeds