CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

Information and news about the 68SEC000 64MHz booster.
Post Reply
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 »

On the 68020 card we isolate these signals :
AS, UDS, LDS, R/W

We regenerate E and VMA as these need to be from the system clock (in addition to the fact that they don't exists on the 68020). You might not need this on your booster unless you run the CPU at 22MHz all the time in which case you still need to route VPA to the CPU and validate the external VMA with the CPU VMA but using the regenerated E clock so it match the system bus speed (it's not just used for ACIA access, it's also use for interrupt acknowledge on auto vectored interrupt).
As E is 1/10th the CPU clock, if the CPU clock goes to hi and you don't do the above you might feed frequency that is too high for the ACIA do deal with (the B version can do 2MHz max, so at 22MHz you're sending 2.2MHz) which could trigger the bus conflict issue you see as a bus conflict if the ACIA either don't respond or are too slow to respond and maintain data on the bus while your starting the next cycle.

Just my 2 cents :) (or pennies .. ;) ).
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
User avatar
exxos
Site Admin
Site Admin
Posts: 23496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos »

Yeah 22mhz constant likely kills acia access..

Though 8/22 switching shouldn't matter about isolation of signals as they are isolated by CPU itself and of course isolated when /as is high anyway.

I documented 22mhz constant needed LDS UDS isolation was needed.. Though shouldn't be needed for 8/22mhz as 8/16 doesn't and 8/32 on the STE doesn't either.. And normal bus access is at 8mhz anyway.

I can only assume something on the STF screws up at the point CPU switches back from 22mhz to 8mhz .. I don't think I did much changes to the code for 22mhz constant other than uds lds isolation. Might just be glue is unhappy at seeing lds uds low without seeing /as... 16mhz isn't a problem but must be at higher speed glue is unhappy...

Will investigate my dev board some more Monday...
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 »

If it works on the STE at 8/32 and STF at 8/16 it's probably not UDS/LDS but most probably some glitching on the frequency changes.
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
User avatar
exxos
Site Admin
Site Admin
Posts: 23496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos »

rpineau wrote: Sun Jan 21, 2018 8:28 am If it works on the STE at 8/32 and STF at 8/16 it's probably not UDS/LDS but most probably some glitching on the frequency changes.
No glitches in the clock :)

I think its something to do with multiples of bus cycles, such as 8,16,32mhz works, but go outside those values and problem starts. Could be something like some bus access happening on "odd" cycles and glue doesn't like it.. with related clocks, the timing is similar, just x2 faster...

For example, I have a feeling that /AS can arrive early to a point, but even sooner, it screws up, later also works, but only to a point also. Probably similar with UDS LDS maybe other signals. Maybe signals must always arrive on a CLK8 HI for example, and when out of sync clocks are used, that timing is now random at any part in CLK8 cycle. CPU shouldn't of course care about all this, but GLUE timings likely do.

I will do more testing when I get home from work tomorrow if I have time.
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: 23496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos »

Old dev-board connected up.. Just running stock 8MHz..

IMG_2180.JPG
IMG_2180.JPG (141.19 KiB) Viewed 5358 times

First order of test is to test sync of /AS to CLK8.

Firstly..

Code: Select all

ST_AS.CK = CLK16;
!ST_AS.D  =   !CLK8 & !CPU_AS & ST_BGACK   // ST_AS goes low on CLK8 low
            #  CLK8 & !ST_AS;
FF clocked with 16mhz clock ( I also tried CLK8 and no difference) .. I sync to when CLK8 goes low, though could be further delays because of CLK16 delays.. but good enough for testing..

So I got this result...

1.jpg
1.jpg (111.98 KiB) Viewed 5358 times

Then swapping to CLK8 high for sync..

Code: Select all

ST_AS.CK = CLK16;
!ST_AS.D  =   CLK8 & !CPU_AS & ST_BGACK   // ST_AS goes low on CLK8 high
            #  !CLK8 & !ST_AS;

I got 4 bombs just after GB6 screen was drawn... I changed to CLK8 and ST not even try to boot..

So I added in a 80mhz osc to drive the FF....

With

Code: Select all

ST_AS.CK = CLK16;
!ST_AS.D  =   CLK8 & !CPU_AS  & ST_BGACK // ST_AS goes low on CLK8 high
            # ! CLK8 & !ST_AS;
Where CLK16 is being driven from the 80mhz osc.. and scores are back to 100% again...

I also tried inverting the FF clock to !CLK16... and was still the same (no issues as expected).

Switching back to this...

Code: Select all

ST_AS.CK = CLK16;
!ST_AS.D  =  ! CLK8 & !CPU_AS  & ST_BGACK  // ST_AS goes low on CLK8 low
            # CLK8 & !ST_AS;
Back to slower speeds again.

So it seems /AS must go low on a CLK8 high sync.. (or S2 as it says in the 68000 datasheet). So I know things are correct.

As for 16MHz speeds, /AS will arrive 50% faster, So probably arrives in high part (or S1)... Really need to verify that, but ST seems happy as that is how all other boosters switch /AS anyway.



... to be continued...
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 »

On the 68020 card , in the first version (using the ATF), we only drive AS through a FF clocked with the 8MHz :

AS20_1.ck = sys_clk;
AS20_1.d = AS20;
AS00 = AS20_1 # AS20;
AS00.oe = BGACK;

sys_clk is the 8MHz clock
AS20 is the CPU AS
AS20_1 is an internal AS sync'd on 8MHz
AS00 is the AS to the ST.

If your CPU is a 8MHz and you do the above, as you're delaying AS by 1x 8MHz cycle you won't get 100% on the test.
Rodolphe
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
User avatar
exxos
Site Admin
Site Admin
Posts: 23496
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 22, 2018 5:48 pm If your CPU is a 8MHz and you do the above, as you're delaying AS by 1x 8MHz cycle you won't get 100% on the test.
Yes.. That is why I moved to 80Mhz clock :)

Incidentally, I have had the ST running that slow that it takes around 60 seconds to draw the gem window viewing floppy contents :lol:
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 »

My point was more that the CLK8 term in your equation shouldn't be there.

So something like this (Here CLK16 is your 80MHz or 16MHz input I assume) :

ST_AS_1.CK = CLK16;
ST_AS_1.D = CPU_AS;

ST_AS.D = ST_AS_1 # CPU_AS; /* or !ST_AS.D = !ST_AS_1 & !CPU_AS */
ST_AS.OE = BGACK;

with ST_AS_1 define as an internal node

Then when you start clocking the CPU at a higher frequency than the bus, change the ST_AS_1.CK to be CLK8;
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
User avatar
exxos
Site Admin
Site Admin
Posts: 23496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos »

But why use 2 FF's when 1 can be used ?

Using 16mhz system clock doesn't work as FF clock, not fast enough. So 80mhz works much better.

If the CPU is running 32Mhz for example, then likely the FF can just be clocked at 8MHz and no need for a sampling clock.. Though as my tests are mixed CPU speeds between 8Mhz and 16MHz or 32MHz for example, then sampling clock means I don't have to worry about anything, I add CLK8 into the equation to do the sync on the FF and not involve the FF's clock at all with syncing CLK8.
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 »

exxos wrote: Mon Jan 22, 2018 6:47 pm But why use 2 FF's when 1 can be used ?
Mine uses only on FF :

Code: Select all

ST_AS_1.CK = CLK16;
ST_AS_1.D = CPU_AS;

ST_AS  = ST_AS_1 # CPU_AS;
ST_AS.OE = BGACK;
ST_AS_1 is a FF
ST_AS is not (there was a mistake in my previous code... my mistake.. sorry .. . ).
exxos wrote: Mon Jan 22, 2018 6:47 pm Using 16mhz system clock doesn't work as FF clock, not fast enough. So 80mhz works much better.
Yes as your CPU runs at the same speed as the bus.
exxos wrote: Mon Jan 22, 2018 6:47 pm If the CPU is running 32Mhz for example, then likely the FF can just be clocked at 8MHz and no need for a sampling clock.. Though as my tests are mixed CPU speeds between 8Mhz and 16MHz or 32MHz for example, then sampling clock means I don't have to worry about anything, I add CLK8 into the equation to do the sync on the FF and not involve the FF's clock at all with syncing CLK8.
I think that adding the CLK8 as a term is delaying thing further that they should.
But yes, in my case it's for a CPU running at constant speed faster than the bus (or in less cycle than the original CPU as the 68020 runs in 3 clock cycles instead of the 68000 4 clock cycles), so we need AS to be resync to the next clock cycle even when it all runs at 8MHz).
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
Post Reply

Return to “SEC 64MHZ BOOSTER”