V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Help & information about the V2.5 booster.
Post Reply
Petari
Posts: 172
Joined: Tue Nov 28, 2017 1:32 pm

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by Petari » Sat Jan 06, 2018 8:55 am

Something is not clear for me here. 68HC000 CPU is stated as cycle identical with 68000. How then it can do VDI operations with more than 400% speed ? (at 32 MHz CPU clock) . Especially considering that RAM access is still 100% speed. Is it because blitter is enabled ? Maybe to compare with blitter on reference ?

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Sat Jan 06, 2018 9:43 am

Petari wrote:
Sat Jan 06, 2018 8:55 am
Is it because blitter is enabled ?
Yes.
Petari wrote:
Sat Jan 06, 2018 8:55 am
Maybe to compare with blitter on reference ?
This uses 32Mhz as reference machine, and then 38Mhz system.


Image

Tests were faster once 40Mhz was reached, but was to unstable to run proper tests.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

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

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Mon Jan 08, 2018 10:24 am

I did some testings with adding /DTACK into the switching code (was actually on the STE but relevant here). The problem is with DTACK, is that for ROM access for example, the GLUE doesn't release DTACK until a few nanoseconds before address strobe goes low again on the next cycle, basically around S2. The problem here is, the CPU is running at high speeds, it can reread DTACK from the previous cycle and obviously cause a crash.

So I did a quick test and added DTACK into my speed switching code to see exactly what happens in waiting for DTACK to go high before allowing 32 MHz speeds..

I got 266% on ROM speed (should be 309%)

I added 1K pull up on DTACK, then got around 295% (give or take 5%) .. Still a fraction slow.. but only a few %...

So GLUE is what has DTACK almost low all the time... and main cause of crappy DTACK generation.

There could be something else with slow DTACK release which could account for a few % drop in speed somewhere.. but no idea what. It does seem a little odd that speed seems to vary now, it is like DTACK is not arriving at a constant speed causing around 5-10% variation in ROM access.. So this would be difficult to determine.

But really, in the case of the STFM, ROM decoding is done on the booster board anyway. So this rules out likely issues with DTACK. On the STE however, I use the GLUE logic for the decoding as it is fast enough for 32 MHz. Though it is likely this logic will have to be bypassed in order to create a proper DTACK signal.

But in any case, when thinking towards the 64 MHz, the DTACK issue could be a problem, but the least I have a easy solution for this and it is fixable at least :) it is possible slowdown with this new code, could be compensated by the faster CPU anyway.. In that the CPU will start cycles twice as fast, and compensate the slowdown with using DTACK which delays a clock cycle.

Worst case currently is that a few percent is lost, but overall again should be higher with 64Mhz anyway, so it does not really matter much.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

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

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Mon Jan 08, 2018 11:30 am

As a update, I did a whole bunch of tests.. Long story short, changing to 500R resistor on DTACK made a whole world of difference..

dt11.png
dt11.png (6.61 KiB) Viewed 476 times
On the left, is 1K resistor... On the right is 500R resistor.. Not a great deal between the two, but makes a dramatic difference in results..

Basically now, worst case looks like about 1% variation in results. But this is about as good as things get anyway.

I really don't know why DTACK is such a "heavy" signal to pull-up :roll: I did a quick measurement of capacitance and read 250pF.. They may not be accurate due to the pull-up resistance being in the mix also.. But with a lot of gates to pull-up on chips, it probably isn't far off...

I did a close-up also..
dtz.png
dtz.png (79.54 KiB) Viewed 475 times

I also did a quick simulation..
sct.JPG
sct.JPG (18.61 KiB) Viewed 473 times
res1.JPG
res1.JPG (40.46 KiB) Viewed 473 times
So on my actual scope results I see that around 50% through the cycle (about 150ns) in must reach about 4 V.

On my simulation circuit, I see 4V around 200ns.

Of course there will be a lot of factors and this was only quick test, but it seems that the capacitance is indeed around 250pF. Which does not seem much, but it is clear you can take 200ns to get to 4volts. If we assume 2 volts as a logic one, then the time will be closer to 100ns.

500R on 5V is 5V / 500 = 0.010Amps (10mA) which is a lot really, I quickly checked the MFP datasheet and it quotes 5.3mA.. So likely in reality a 1K resistor should be the lowest value used about starting to strain the DTACK drive transistors.

A possible workaround could be control the 500R resistor by the PLD. In that when address strobe goes high, it connects the 500R resistor to DTACK and allows resistance to be pulled up faster. Then when address strobe goes low, the resistor is isolated so the actual DTACK resistance would be normal like 2.2K. This way DTACK switches to 0V with 2.2K as normal, and is pulled up high with 500R...
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

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

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Thu Jan 11, 2018 7:01 pm

Tried the PLL finally.. Wired it for x2, so 8MHz input, 16 MHz output...

Just seem to get varying speed for some reason :roll:

pllmess.png
pllmess.png (4.12 KiB) Viewed 451 times
pll2.png
pll2.png (5.28 KiB) Viewed 451 times
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

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

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Thu Jan 11, 2018 10:20 pm

OK, so small update.. I switched to x10 on my scope probes and it is now stable at 16mhz.. BUT..

What I did not realise before, is on the STE...The 32mhz goes to 16mhz and is in sync perfectly.. but whatever is clocking down the 16mhz to 8mhz has a 16ns delay.. so its not in sync..So the PLL starts out 16ns out of sync... So the PLL 16mhz and ST 16mhz are also 16ns out of sync.

This means the STE screws up on floppy access, which it doesn't do when using the 16mhz ST clock.. but the PLL clock is 32ns "behind" the 8mhz and its to much and it screws up.

I could probably do some work arounds on the on a larger PLD based design, but not on the simple STE booster..But, this shouldn't be a problem on the STFM as the clocks are all perfectly in sync..

So I will try and find some time tomorrow to try the PLL on a STFM booster. The STFM is the one which a problematic 32mhz circuit.. so I am not to bothered about the STE issues with it.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

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

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Fri Jan 12, 2018 11:56 am

Right, working now :) I used the 16mhz input and x2 PLL for 32mhz output (to "bypass" the 16ns 8mhz skew issue)

Turns out the ST clocks are in sync on the falling edges of the clocks, and the PLL is syncing on the rising edges...


ST CLOCK 16 & 32
1632st.png
1632st.png (4.95 KiB) Viewed 417 times

PLL 32 & ST 16
1632.png
1632.png (4.96 KiB) Viewed 417 times
So I fiddled with the GAL code to invert the 32mhz input and now everything is happy again :)

Oddly I have some "bug" now which has resulted in a few % extra in speed :lol:
bug.jpg
bug.jpg (109.42 KiB) Viewed 417 times

EDIT:

Oddly now and then it crashed, so I took the scope probes off the ST 16MHz line and all was fine, but the speed went back to normal again.. put the scope probe back and higher speeds again.. odd..

EDIT2:
OK, seems the PLL latches onto 32.89mhz sometimes, other times 32.25mhz... now I want to try x3 on the PLL but not going to be easy to re-wire it as I intended to basse on 8mhz not 32mhz :roll:
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

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

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Mon Jan 15, 2018 7:35 pm

1.jpg
1.jpg (118.79 KiB) Viewed 367 times

Add a little fun earlier.. I took my RSO which I design for the CT60 while ago.. The clock multiplier is way too high for this test, so just a matter of lifting up a pin on the chip to half the output frequency from 100mhz to 50mhz kinda thing. Pin was tiny and ended up snapping off, but thankfully this pin needed to be floating anyway so it didn't matter :lol:

I tried various methods of getting more speed, but I did not break the speed barrier of what I got before of around 38Mhz. I really did not expect it to go any faster. I was just doublechecking that the CPU was maxing out at this frequency.

I still need to finish off the SEC PCB design yet :( but I got a little sidetracked in testing the PLL out before I added it to the PCB layout.. Hopefully I can find time tomorrow to try out the PLL on the STFM make sure I am happy with it before continuing with the SEC design..
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

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

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Thu Jan 18, 2018 8:54 pm

I've gone back to the V2.2 booster for PLL testing.. So far passing though the PLL (driven from 8mhz) results in 16mhz output inverted :roll:

So I can the 8MHz though a inverter before the PLL.. but oddly both 16MHz were still out of sync (180deg out of phase).


(ignore the ringing)
p1.png
p1.png (5.2 KiB) Viewed 331 times

So I tried inverting the 16MHz output from the PLL and saw 15ns skew..

p2.png
p2.png (5.13 KiB) Viewed 331 times

5ns measured is delay though the GAL, so there is 10ns delay though the PLL it seems..

Sometimes it boots and even loads GB6 but it is just to stable.. I think one of the problems is the PLL needs a very clean input and the 8 MHz from the MMU just doesn't cut it. Even with adding resistors and a few picofarads capacitance here and there I think it is time just to redesign a new PLL board.

Basically to take the 8 MHz through a schmitt trigger buffer to clean up the input to the PLL. I think inverting the 8 MHz is to be a lot worse than inverting the 16MHz... With two buffers on the input and output the delay should still end up being around 5ns.. So basically I need to add something like 20ns delay to bring the clocks back into sync again.

This seems a lot of work which is really what I was trying to avoid in using a PLL in the first place.. But if these things are super sensitive to noise, and the ST motherboard basically being one huge noise generating monster, it is not going to take much for the PLL to become unstable even if it is just for one clock cycle..

The problem here is that this particular PLL seems to just constantly depending on what the frequency is.. To me this totally defeats the object of having a PLL.. The idea is to lock onto the frequency and stay that frequency even if the clock input source is removed.. But this IC does not do this :roll:

Overall I am thinking just replacing the 32MHZ circuit in the STFM may ultimately be easier and more reliable..

Here is the datasheet..

https://www.idt.com/document/dst/570-datasheet

If anyone can find a similar chip which actually locks onto the frequency stays on that frequency when the source clock is removed then it will save me some time.. If it looks like it may work then a build up a small board and test it out. Of course the problem with a lot of these chips is they do not state the propagation delay time... This particular PLL would be ideal I think if it would actually latch onto the frequency stop at that frequency once it has been locked onto. I'm sure older PLL devices did that.. ??
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

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

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by rpineau » Thu Jan 18, 2018 9:46 pm

On the new 68020 V3 board we use a clock distribution chip, the NB3N551.
This might help cleanup the clock and then feed it to your PLL ?

Post Reply