Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS
Posted: Fri Jan 26, 2018 10:32 am
I had another thought.. about DMA..
Because DMA can access the bus directly, and so can the CPU.. what stops the CPU from accessing the bus, assume DMA has to request bus so CPU doesn't conflict ?
EDIT:
Nevermind, I tried booting a floppy and saw BG going crazy.. so that seems ok.
EDIT2:
Pin 1 of the LS244 vs 8MHz clock... doesn't seem to be right...
But.. LS244 vs /AS looks like makes more sense..
Zoomed in...
BLUE /AS
YELLOW 244 OE (HI = Z)
So when /AS is high, the 244's are isolated...
I'm not really following what is going on there..
I assume /AS goes low, and for example data is written to the bus.. then some 100ns later, 244 buffers are active, so assume CPU writing to RAM. When cycle terminated /AS goes high and buffers are isolated again.. just seems odd to see constant cycle access like that.
EDIT3: Using my current dev-board... 8/32mhz async...
Looks like CPU sets /AS low, then waits long time for 244 buffer to become active, then cycle finishes. So that seems likely normal access...
This is really where a 4 channel scope would come in more useful
As the 244 buffers seem to go CPU -->> DRAM then 244 buffers must isolate CPU (or DMA) from writing to RAM.. So at that point it shouldn't matter speed of CPU as CPU is clearly waiting for DTACK to terminate the cycle...
EDIT4:
Running the CPU at constant 16MHz.. There is some basic bus sync code in there.. but this isn't a "problem" with current tests...
Problem is, nobody ever worked out why using separate clock for CPU fails to work.. This isn't issues directly with /AS or DTACK.. there is some other timing issue.. CPU can of course run ASYNC easily.. but I suspect some glitch in MMU logic maybe with bus isolation circuit... . So this is what I am investigating.
I suspect CPU starts bus cycle to early causing bus conflicts with RAM access.. so trying to see if that is part of issue... Really /AS going low shouldn't matter as bus-isolation should happen.. but possible MMU is to slow to activate buffers...
Because DMA can access the bus directly, and so can the CPU.. what stops the CPU from accessing the bus, assume DMA has to request bus so CPU doesn't conflict ?
EDIT:
Nevermind, I tried booting a floppy and saw BG going crazy.. so that seems ok.
EDIT2:
Pin 1 of the LS244 vs 8MHz clock... doesn't seem to be right...
But.. LS244 vs /AS looks like makes more sense..
Zoomed in...
BLUE /AS
YELLOW 244 OE (HI = Z)
So when /AS is high, the 244's are isolated...
I'm not really following what is going on there..
I assume /AS goes low, and for example data is written to the bus.. then some 100ns later, 244 buffers are active, so assume CPU writing to RAM. When cycle terminated /AS goes high and buffers are isolated again.. just seems odd to see constant cycle access like that.
EDIT3: Using my current dev-board... 8/32mhz async...
Looks like CPU sets /AS low, then waits long time for 244 buffer to become active, then cycle finishes. So that seems likely normal access...
This is really where a 4 channel scope would come in more useful
As the 244 buffers seem to go CPU -->> DRAM then 244 buffers must isolate CPU (or DMA) from writing to RAM.. So at that point it shouldn't matter speed of CPU as CPU is clearly waiting for DTACK to terminate the cycle...
EDIT4:
Running the CPU at constant 16MHz.. There is some basic bus sync code in there.. but this isn't a "problem" with current tests...
Problem is, nobody ever worked out why using separate clock for CPU fails to work.. This isn't issues directly with /AS or DTACK.. there is some other timing issue.. CPU can of course run ASYNC easily.. but I suspect some glitch in MMU logic maybe with bus isolation circuit... . So this is what I am investigating.
I suspect CPU starts bus cycle to early causing bus conflicts with RAM access.. so trying to see if that is part of issue... Really /AS going low shouldn't matter as bus-isolation should happen.. but possible MMU is to slow to activate buffers...