CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

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

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

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

[exxos]

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.

[exxos]

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

IMG_2180.JPG (141.19 KiB) Viewed 6028 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 (111.98 KiB) Viewed 6028 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...

[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

[exxos]

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

[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;

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

[rpineau]

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

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.

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