CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos »

I did a quick test to see if I could fake a DMA cycle, basically so I could use BGACK to isolate the CPU.

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 :roll:

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..
Oddly, if I add back in DTACK delays, machine tries to load BG6 but bombs out during load.

:stars:

OK, so small change to the code...

Code: Select all

ST_BG.OE = CPU_AS;
ST_BG = CPU_BG ;
Now the machine boots, running a lot slower than it should.. So I need to investigate this next.. Of course it is likely BGACK takes a couple of cycles to terminate could be result of what I am doing .. Though as the CPU is running faster should really not matter.. I will remove the /DTACK delays next..

bgack1.jpg
bgack1.jpg (102.06 KiB) Viewed 6129 times

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 :roll:

Another small change to the code...

Code: Select all

CPU_BGACK.OE = (!ST_BGACK # !CPU_BG ) & !CPU_AS;
Basically terminate the cycle when address strobe goes high.. I did get then 91% RAM access, but it crashed when I rebooted to try fresh boot.. So something is not happy with that idea.. I guess because BGACK isn't being used correctly ..

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...

bg.JPG
bg.JPG (70.1 KiB) Viewed 6122 times
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 :roll:

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 :(
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
rpineau
Posts: 534
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by rpineau »

Using BGACK (with BR and BG) is probably not a good idea as you saw as it involves finishing cycles and recovery time after a bus master change.
On the 68020 card, we run at constant speed, 32MHz, and only re-sync the DTACK from the ST. We generate our own DSACK0 and DSACK1 for the 32 bit TOS access (aka your rom DTACK).
Our clock is totally asynchrone and we don't see the slowdown you see (I'm not saying there is no slowdown on you implementation). The difference might be that the 020 does bus access in 3 cycle (so we delay AS by 1 8MHz cycle to make it look like a 68000 AS) and that at 32 MHz, with the number of wait state we have we always finish ST access on the 8MHz 4 cycle boundary.

It would be interesting to see some LA trace when you see that slowdown as we don't see it an our cycle are in sync with the 8MHz clock for the signal we generate to the ST even though the CPU clock is 32MHz async.

Rodolphe
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
User avatar
exxos
Site Admin
Site Admin
Posts: 23488
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos »

rpineau wrote: Mon Jan 29, 2018 6:06 pm It would be interesting to see some LA trace when you see that slowdown as we don't see it an our cycle are in sync with the 8MHz clock for the signal we generate to the ST even though the CPU clock is 32MHz async.
Problem is I'm not totally sure where the slow down comes from. RAM, ROM, blitter tests all as expected speed wise, but then running GFX tests there is a huge slow down. But this only happens when blitter is involved.. So I have gone back to previous code to try and work out why.

My concern of delaying DTACK is that if the signal arrives slightly earlier or later it is possible the machine may not boot or run a fraction slower. I actually just saw this as well.. Last week the code I used showed 100% access speeds, but same code today shows 92%. Also I have seen all sorts of speed differences between 68000 CPU's which I have been testing on the STE. So I am concerned while I could set up these delays to work on this particular motherboard, it may not necessarily work on another.. Of course I will try this out the future if needs be..

Currently I need to try and figure out this blitter issue... It must be some form of combinational bus cycles which is causing it.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
exxos
Site Admin
Site Admin
Posts: 23488
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos »

Made some progress I think...

It seems when the ST issues BGACK.. It does not always reach the CPU in time and CPU does not see the signal (assumes is high) and terminate the cycle.. And then CPU sees BGACK and crashes..

So what I did was ...

Code: Select all

CPU_BGACK = 'b'0;
CPU_BGACK.OE = !ST_BGACK # !CPU_BG;
So that CPU_BG holds BGACK low.. This seems to solve the stability issues.. At least so far, I need to do more testing..... And recheck benchmark results...

Showing speed boosts with blitter , CPU 20mhz..

f1.jpg
f1.jpg (102.82 KiB) Viewed 6098 times

Showing comparison of a stock STFM , with blitter and 20mhz. .
f2.jpg
f2.jpg (103.91 KiB) Viewed 6098 times

So definitely a huge improvement... But still slightly puzzled over some of the benchmark results... As they should look more like this..
(see VDI text , slower on 20mhz, but other tests are faster than the 16mhz tests below as expected) might be TOS things...
16CRB_result.png
16CRB_result.png (4.5 KiB) Viewed 6097 times

EDIT 1:

:WTF:

Reference machine now TOS 104 not 206...

f3.jpg
f3.jpg (108.04 KiB) Viewed 6094 times
All results are now faster than the 16MHz benchmarks.. So as far as I concerned that is all now working perfectly..

So it would seem TOS206 seriously sucks for VDI text with blitter and is a huge drop slower than TOS104!!
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
rpineau
Posts: 534
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by rpineau »

We did have some issue with the blitter BR/BG/BGACK and it turned out we needed to add one wait state to DTACK as the blitter was holding the bus longer than expected.
As for TOS 2.06 being slower in VDI, that could be the case.
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
User avatar
exxos
Site Admin
Site Admin
Posts: 23488
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos »

23MHz ASYNC TOS104 & BLITTER.

23mhz.jpg
23mhz.jpg (97.99 KiB) Viewed 6078 times

I guess ACIA maxed out here (about 2.3Mhz) . I have the "B" versions *somewhere* so will change them soon and re-try... But really I maxed out what I can do with this test board...
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by troed »

exxos wrote: Mon Jan 29, 2018 9:42 pm I guess ACIA maxed out here (about 1.3Mhz) . I have the "B" versions *somewhere* so will change them soon and re-try... But really I maxed out what I can do with this test board...
That's something I thought about regarding the "Stefan 16MHz mod" (doubleST is what I call it). The ACIAs run at 1.6MHz with it (no step down done on the E-clock). At least my machine has no issues with it.

I'm designing a circuit to allow me to change between stock, doubleST with regular video and doubleST with doubleVideo - and I've been pondering whether I need to include E-clk/2 ...
User avatar
exxos
Site Admin
Site Admin
Posts: 23488
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos »

troed wrote: Mon Jan 29, 2018 9:49 pm I'm designing a circuit to allow me to change between stock, doubleST with regular video and doubleST with doubleVideo - and I've been pondering whether I need to include E-clk/2 ...
You can't halve E-clock from the CPU to ACIA.. Believe me I went to great length to investigate all that.. http://www.exxosforum.co.uk/atari/last/16mhz/index2.htm maybe around 10th jan there...

This is the main problem I have at the moment and why I am moving to the SEC CPU as you can actually control the speed of E-clock since you have to emulate it anyway.

For 16MHz CPU you should not have a problem with ACIA anyway ..
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
troed
Moderator
Moderator
Posts: 908
Joined: Mon Aug 21, 2017 10:27 pm

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by troed »

exxos wrote: Mon Jan 29, 2018 9:56 pm You can't halve E-clock from the CPU to ACIA.. Believe me I went to great length to investigate all that.. http://www.exxosforum.co.uk/atari/last/16mhz/index2.htm maybe around 10th jan there...

This is the main problem I have at the moment and why I am moving to the SEC CPU as you can actually control the speed of E-clock since you have to emulate it anyway.

For 16MHz CPU you should not have a problem with ACIA anyway ..
Thanks! Saves me the trouble of finding that out myself :) I just reacted to your comment above about 1.3MHz being too much for the original ACIAs and I'm running mine at 1.6. (6850P so not 68B50 which indeed are rated at 2MHz).
User avatar
rpineau
Posts: 534
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by rpineau »

I have seen some 6850P run slightly above 1MHz but for 1.6MHz and up you'll definitely need a B version.
And then there is the case of going above 2MHz (aka CPU running at more than 20MHz). Same as for 1.3MHz on the P version where you might be able to go slightly above 2MHz, but anything above this and you need to regenerate the E clock and redo the VMA/VPA/E circuit outside the CPU and resync these with the CPU.
As exxos said, using the SEC cpu has the advantage that you don't have these pins on it so you have to regenerate these the same way you do for a 68020 (and up). So you can generate all of this from the 8MHz clock. If you use a 6850B, you could generate the E clock as 1.6MHz and make the ACIA access slightly faster.

Rodolphe
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
Post Reply

Return to “SEC 64MHZ BOOSTER”