V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Help & information about the V2.5 booster.
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 » Sun Jan 28, 2018 11:46 pm

Blitter registers : 0x00FF8A00 to 0x00FF8A3D (included).

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Mon Jan 29, 2018 3:10 pm

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 434 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 427 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 :(
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 » Mon Jan 29, 2018 6:06 pm

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

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Mon Jan 29, 2018 6:23 pm

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.
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: 2035
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Mon Jan 29, 2018 6:43 pm

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 403 times

Showing comparison of a stock STFM , with blitter and 20mhz. .
f2.jpg
f2.jpg (103.91 KiB) Viewed 403 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 402 times

EDIT 1:

:WTF:

Reference machine now TOS 104 not 206...

f3.jpg
f3.jpg (108.04 KiB) Viewed 399 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!!
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 » Mon Jan 29, 2018 7:35 pm

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.

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Mon Jan 29, 2018 9:42 pm

23MHz ASYNC TOS104 & BLITTER.

23mhz.jpg
23mhz.jpg (97.99 KiB) Viewed 383 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...
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.

troed
Posts: 172
Joined: Mon Aug 21, 2017 10:27 pm

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by troed » Mon Jan 29, 2018 9:49 pm

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
Posts: 2035
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by exxos » Mon Jan 29, 2018 9:56 pm

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

troed
Posts: 172
Joined: Mon Aug 21, 2017 10:27 pm

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS

Post by troed » Mon Jan 29, 2018 10:16 pm

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

Post Reply