CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Information and news about the 68SEC000 64MHz booster.
User avatar
exxos
Site Admin
Site Admin
Posts: 10496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » 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...

244.png
244.png (4.18 KiB) Viewed 2157 times

But.. LS244 vs /AS looks like makes more sense..

244as.png
244as.png (4.03 KiB) Viewed 2157 times

Zoomed in...
244as2.png
244as2.png (3.85 KiB) Viewed 2157 times
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:
24432.png
24432.png (3.73 KiB) Viewed 2157 times
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 :roll:

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...
16244.png
16244.png (3.84 KiB) Viewed 2148 times

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...
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
rpineau
Site Admin
Site Admin
Posts: 512
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by rpineau » Fri Jan 26, 2018 3:13 pm

When the DMA need to transfer data (floppy access or HD access), the GLUE request the bus, once the CPU assert /BG (and the GLUE assert /BGACK), the buffer isolate the CPU side of the bus so that the DMA car write to RAM ( the GLUE/MMU generate the addresses for the DMA). At the end the GLUE release the bus by de-asserting /BGACK.
So that's one of the 2 bus isolation.

The other one is when the shifter displays video data from the RAM. The GLUE/MMU isolate the CPU side of the bus while accessing data from the RAM to feed the SHIFTER. This is on a "precise" timing and is supposed to be interleaved with CPU access. That is most probably when you see issues with ASYNC access. Now when the GLUE/MMU are isolating the bus to feed the SHIFTER, if the CPU access the bus and assert /AS , /RW and the address, then put the the data on the bus and set /UDL, /LDS. As this happen the bus is potentially still isolated as the shifter is displaying data, specially if the CPU runs async from the bus. At that point, as you said the CPU waits for DTACK, which is generated by the GLUE.

So indeed you would think that running async would not be an issue as the bus is isolated and the CPU waits for DTACK.

So I wonder if there is something going on in the GLUE where it ignores anything on the CPU side of the bus while doing shifter access and miss the CPU /AS which mean the CPU waits for DTACK forever or as you said the GLUE is too slow to deal with the buffers isolation and some data are still on the RAM bus and interfere with what the CPU is putting/reading to/from the bus.
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2

User avatar
exxos
Site Admin
Site Admin
Posts: 10496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Fri Jan 26, 2018 4:39 pm

rpineau wrote:
Fri Jan 26, 2018 3:13 pm
So I wonder if there is something going on in the GLUE where it ignores anything on the CPU side of the bus while doing shifter access and miss the CPU /AS which mean the CPU waits for DTACK forever or as you said the GLUE is too slow to deal with the buffers isolation and some data are still on the RAM bus and interfere with what the CPU is putting/reading to/from the bus.
Million dollar question!

I think some fault with MMU or bus isolation.... Its hard to work out if /AS or /DTACK are issues, as change 1 timing, the other tends to change.

Just a crazy example... Maybe MMU needs to see /AS high for a 1x8mhz clock cycle to reset DTACK or something.. if CPU runs to fast, MMU sees as /AS low all the time, keeps DTACK low.. and "double bus read" happens..
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
exxos
Site Admin
Site Admin
Posts: 10496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Fri Jan 26, 2018 6:19 pm

I re-did the 16MHz constant (sys clock) code to "re-learn" from the beginning.. just in case I forgot to test something last time. Also making better notes on tests as I go along :)

/AS had 1x16MHz delay.. /DTACK had 3x16MHz delays. I couldn't use any less delays without not booting.

Got these results..

1.JPG
1.JPG (88.53 KiB) Viewed 2129 times

Likely problem here is I have to delay more because of ROM decoding and /DTACK arriving to early..

So I added in the ROM decoding (now TOS206)... DTACK issued fast (just after /AS low) but now PLD decoding is fast enough to allow that. Still same 3x cycle delay on all other DTACK access...

Got this result...

rom.jpg
rom.jpg (111.12 KiB) Viewed 2129 times

So ROM is 170% which is expected for 16MHz.. Int-div 189%, again expected. But all other tests are actually slower by about 20%...

So next up is to lessen the DTACK delays and see if things improve or not....

2x16mhz delays on DTACK..

c1.jpg
c1.jpg (67.68 KiB) Viewed 2128 times
So nope.. not happy..

Next was to remove delay on /AS , so ST_AS = CPU_AS now... Machine still stable and nothing changed with results (blitter was 1% higher but means nothing really)

So next to remove again a DTACK delay...and crashes again. So clearly does not like faster DTACK...

So I am not sure there is anything else I can try... ? Speeds this method are not the same as 8/16mhz switching.. no idea why..

EDIT:
Inverted the CPU clock just for the hell of it, blitter is now not happy..

bb.jpg
bb.jpg (107.91 KiB) Viewed 2124 times

So turned it off and re-did tests.. back to TOS104.. and...
r1.jpg
r1.jpg (110.5 KiB) Viewed 2124 times

So now on-par to the V2.2 speeds (actually fraction faster, but likely reason also for unstable blitter).

Next up is to use inverted delay clock and non-inverted CPU clock...

inv1.jpg
inv1.jpg (95.06 KiB) Viewed 2123 times

Result now more on-par with V2.2 results.. So next up to re-enable the blitter with TOS206... Where results seems the same as rom.jpg again.. odd...

So just to be sure I not messed up...I ran comparison machine as stock STFM no blitter... as I have benchmarks of this already for better comparison..

Known previous benchmarks..
16CRB_result.png
16CRB_result.png (4.5 KiB) Viewed 2121 times

Current benchmark...

b2.jpg
b2.jpg (104.58 KiB) Viewed 2121 times

So indeed blitter is running slower than it should... :roll:

Now I changed code to use 16mhz ext osc. Machine booted fine, ran GB6 fine, results looked fine (blitter disabled and crashed when enabled).

I changed to 20mhz osc and bombs and corrupt screen on boot up..I removed blitter just in case and still same results.

Next I added in a second delay on DTACK and now machine boots again. So currently, it goes not seem to care about sync of /AS...

Benchmark at 20MHz...

20mhz.jpg
20mhz.jpg (108.38 KiB) Viewed 2112 times
(comparison is inv1.jpg a couple images up)


So going up in speed needs more delay on DTACK.. I don't think its really the answer to do that, but problem is DTACK on the ST likely linked to the 8mhz clock so slow to go high again.. meaning the CPU can re-read DTACK more than once.. So likely no other way around that than to keep delaying DTACK until it works :roll:


....to be continued....
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
rpineau
Site Admin
Site Admin
Posts: 512
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by rpineau » Sat Jan 27, 2018 12:42 am

The faster the CPU goes the more delay on DTACK you'll need.
When DTACK arrives the CPU finished its cycle at the speed of its clock.. which is a lot faster than the system clock and will start the next cycle... but the GLUE is still on the previous 8MHz cycle.
That's what running the CPU faster is all about, re-syncing DTACK so that the next CPU cycle match the next bus cycle when accessing the ST. When accessing the TOS using your own decoding (so the GLUE doesn't see that access), you can DTACK as fast the the TOS chip can put data on the bus.
On the 68020 card, when running at 32MHz we delay DTACK by 5 to 6 32MHz cycle to get everything stable (depends on other things we do so we try different value but 5 look stable) and we have 0 delay when accessing the TOS (going above 32MHz we have to increase these wait state on DTACK from ST and on our internal DTACK for the TOS).

So the real issue is the GLUE doing a 4 8Mhz clock cycle (/AS to /DTACK to end of cycle) and will not start the next cycle early as it tries to respect 68000 bus access timing.
It's all about DTACK.
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2

keli
Posts: 95
Joined: Tue Aug 22, 2017 1:34 pm

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by keli » Sat Jan 27, 2018 1:40 am

Instead of delaying /DTACK by a fixed number of cycles, wouldn't it make more sense to set the delay to be X number of cycles after /AS is asserted? Because the at the original speed the CPU basically ignores the current value of /DTACK until S4 (with /AS asserted in S2).

User avatar
exxos
Site Admin
Site Admin
Posts: 10496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Sat Jan 27, 2018 10:11 am

rpineau wrote:
Sat Jan 27, 2018 12:42 am
The faster the CPU goes the more delay on DTACK you'll need.
When DTACK arrives the CPU finished its cycle at the speed of its clock.. which is a lot faster than the system clock and will start the next cycle... but the GLUE is still on the previous 8MHz cycle.
I wonder if it still a issue with 8/32 switching with DTACK. Even so, DTACK control must be faster on STE, as it doesn't care about anything. I know I had to re-sync DTACK on previous 8/32 test.. there must be some situation where CPU trips up, as it runs in 32MHz until /AS goes low, but as delays in speed switching, maybe some point it does still do "double bus read", but this problem doesn't happen on STE.


keli wrote:
Sat Jan 27, 2018 1:40 am
Instead of delaying /DTACK by a fixed number of cycles, wouldn't it make more sense to set the delay to be X number of cycles after /AS is asserted? Because the at the original speed the CPU basically ignores the current value of /DTACK until S4 (with /AS asserted in S2).
If I delay from /AS I would need a lot more flipflops to do the delay, but it still would need to sync to DTACK and do extra delays anyway. DTACK can arrive at any point from when /AS goes low to several cycles after S4.

The problem is, DTACK is generated on 8mhz clock, so best it can go high is 1x8mhz cycle (putting it simply).. So when CPU runs at 32mhz for example, it can get to S4 again while DTACK is still low from previous bus cycle, so CPU re-reads previous data, terminates cycle, and likely gets to S4 again for a 3rd time.

So the "Trick" is to simply delay DTACK until the point where DTACK would normally go high.. This way the CPU terminates cycle and GLUE logic terminates DTACK as normal.

As I found before, if I have a few ns to much DTACK delay, GLUE will keep DTACK low for another 1x8mhz cycle and the machine then runs about 25% slower because cycle wasn't terminated fast enough. To little DTACK delay, CPU finishes CPU cycle to early, and re-reads DTACK from previous bus cycle.

But that is only valid for "ST bus cycles". As I decode ROM in the PLD, the delay logic can still be used, I issue DTACK with /AS on ROM address for example, so then you still have a couple cycles delay on DTACK, which doesn't matter since CPU won't read DTACK until a couple of cycles later (S4) anyway. This time CPU access ROM at 32mhz.

With all this , there is no real relationship between timing between /AS and /DTACK as /DTACK is a random signal. So its just a lot simpler to wait for DTACK and just delay a couple of cycles to make sure the CPU doesn't do "double bus read". That is all that is really needed.
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
exxos
Site Admin
Site Admin
Posts: 10496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Sat Jan 27, 2018 11:06 pm

No time this weekend to do more tests. But sat thinking about the odd "slow" results. oddly RAM, ROM, blitter, int-div all correct speeds, but overall other tests are around 40% slower than should be.

So I am thinking I need to increase DTACK speed to pull up faster. There must be some combo of bus cycles where my DTACK code is actually fraction to slow causing the cycle to terminate one bus cycle later in some cases.

So if I add better pullup on DTACK, as shown before in other tests (where also improved issues) then I hope my DTACK delay can be fraction shorter and the results will become what they all should be..
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
exxos
Site Admin
Site Admin
Posts: 10496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Sun Jan 28, 2018 9:33 pm

I tried adding in some more delays for BG stuff, but for some reason blitter is not happy when CPU is running 20mhz :(

EDIT 1:
Some small progress.. Had to add 2 CLK8 delays on ROM access.. GB6 locked up on first test.. Something like because I issue DTACK for ROM access.. maybe to fast for blitter for some reason to keep up..

So added 3 CLK8's to ROM access now running at 102% so almost stock values now..and GB6 so far seems to be almost stable...

I don't know anything about blitter programming, but are there fixed address to program blitter ? As I could add that address into "slow ROM access" in the PLD..

EDIT 2:
Was trying to add fast rom when CPU_AS low and slow rom when CPU_AS high.. but doesn't seem to be happy :roll:
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
rpineau
Site Admin
Site Admin
Posts: 512
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by rpineau » Sun Jan 28, 2018 11:46 pm

Blitter registers : 0x00FF8A00 to 0x00FF8A3D (included).
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2

Post Reply

Return to “SEC 64MHZ BOOSTER”