V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Help & information about the V2.X series boosters.
User avatar
exxos
Site Admin
Site Admin
Posts: 7639
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos » Thu Jan 31, 2019 8:50 pm

ijor wrote:
Thu Jan 31, 2019 8:40 pm
This is anyway just an academic issue. You don't do any harm by isolating AS to GLUE during ROM access. But you must do something similar for, at the very least, sound chip access as well!
Now I am confused, why do I need to stop GLUE seeing /AS on sound chip access ? If I did that, GLUE wouldn't decode SND_CS and the sound chip would never be enabled ?
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.

ijor
Posts: 92
Joined: Fri Nov 30, 2018 8:45 pm

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by ijor » Thu Jan 31, 2019 8:58 pm

exxos wrote:
Thu Jan 31, 2019 8:50 pm
Now I am confused, why do I need to stop GLUE seeing /AS on sound chip access ? If I did that, GLUE wouldn't decode SND_CS and the sound chip would never be enabled ?
I meant that somehow you must avoid the issue of DTACK being kept low for too long. This definitely happens when accessing the sound chip, it is much worse than on ROM access. If you can't generate the sound chip select by yourself, then you must intercept DTACK or somehow delay the CPU. Otherwise, as you said yourself, the following would happen:
The scenario is CPU accesses a SND register, GLUE issues DTACK, CPU completes cycle, starts a new cycle, GLUE still has DTACK low from previous cycle and CPU re-reads that DTACK. Eventually the CPU does something else, maybe access RAM, but if GLUE keeps DTACK low, the CPU may read the last SND DTACK access and complete the RAM cycle to early causing corruption.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by rpineau » Thu Jan 31, 2019 9:01 pm

Ok, from memory (I don't have time to go dig through the the last 4+ years of email between me and Chris ... over 2100 emails) :
GLUE assert DTACK as soon as it decodes a ROM access, expect the CPU to sample it on S4, then de-assert it at the end of S7 as the CPU latch the data on the falling edge of the clock when entering S7, and DTACK stays LOW until S7 rises and is actually HIGH "at some point" in S0 of the next cycle (depends on DTACK pull-ups and rising time after S7 falling edge).
so DTACK is low during the whole access to the TOS as soon as decoding is done, from memory, on S2 and is LOW until next cycle S0.
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos » Thu Jan 31, 2019 9:06 pm

ijor wrote:
Thu Jan 31, 2019 8:58 pm
I meant that somehow you must avoid the issue of DTACK being kept low for too long. This definitely happens when accessing the sound chip, it is much worse than on ROM access. If you can't generate the sound chip select by yourself, then you must intercept DTACK or somehow delay the CPU. Otherwise, as you said yourself, the following would happen:
ah right, I need to look into that... So what exactly happens then, literally DTACK on SND_CS stays low for a long time ? how long ? Assuming when /AS is high DTACK is still low for longer than "normal" ?

But thing is, one test I did yesterday was to delay all DTACK to the CPU by a extra CLK8 cycle. Basically this means DTACK goes high on the ST, and then I start a delay chain. Where I even delayed up to 3xCLK8 cycles. I'm way to tired to explain it all, but basically there was always a delay between DTACK's on the ST to the CPU.. Basically my code would wait for DTACK to go high and throw in a extra CLK8 cycle for good measure.

I also added in extra delays on any IO ranges, so any IO registers would get more delays on DTACK, and more "Gaps" between DTACK's. So regardless of how screwy GLUE's DTACK was, it shouldn't matter.

Even so, why would the sound test work on the diagnostic cart ? hmmmm, maybe I should try a game and see if the chip music plays correctly...
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
Site Admin
Posts: 7639
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos » Thu Jan 31, 2019 9:13 pm

rpineau wrote:
Thu Jan 31, 2019 9:01 pm
Ok, from memory (I don't have time to go dig through the the last 4+ years of email between me and Chris ... over 2100 emails) :
GLUE assert DTACK as soon as it decodes a ROM access, expect the CPU to sample it on S4, then de-assert it at the end of S7 as the CPU latch the data on the falling edge of the clock when entering S7, and DTACK stays LOW until S7 rises and is actually HIGH "at some point" in S0 of the next cycle (depends on DTACK pull-ups and rising time after S7 falling edge).
so DTACK is low during the whole access to the TOS as soon as decoding is done, from memory, on S2 and is LOW until next cycle S0.
It wasn't S0 on the next cycle though from what I remember, it was S2, because I saw DTACK go high about 40ns before /AS went low again. So must be around S2. I only saw that HI after using low value resistor on DTACK pull up. I remember saying to you we might as well treat DTACK as being low all the time on GLUE during ROM access..

But saying that, there was some odd times back then where one GLUE chip would work, and another one wouldn't with the booster, I put it down to tolerances of the hardware, but maybe there was some buggy GLUE's... oh man, thats going to be a whole new rabbit hole...
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
Site Admin
Site Admin
Posts: 490
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by rpineau » Thu Jan 31, 2019 9:16 pm

you could make the CPU DTACK go back to HI using /ST_AS
CPU_DTACK = DELAYED_DTACK # ST_AS;
ST_AS is your resync CPU_AS to the ST (registered).
DELAYED_DTACK is the DTACK for the CPU after proper delay and force it to go back up when ST_AS get de-asserted (CPU_AS resync'd on 8MHz clock).
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos » Thu Jan 31, 2019 9:27 pm

rpineau wrote:
Thu Jan 31, 2019 9:16 pm
you could make the CPU DTACK go back to HI using /ST_AS
CPU_DTACK = DELAYED_DTACK # ST_AS;
ST_AS is your resync CPU_AS to the ST (registered).
DELAYED_DTACK is the DTACK for the CPU after proper delay and force it to go back up when ST_AS get de-asserted (CPU_AS resync'd on 8MHz clock).
That is all done anyway.. Actually use .AP on the FF so DTACK goes high right away and doesn't even wait to be clocked high via the FF.
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
Site Admin
Posts: 7639
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos » Thu Jan 31, 2019 9:32 pm

Okay so this is interesting... I loaded up supercars 2, it got to the title screen where it normally starts playing music and it is totally frozen with no music playing...

EDIT:

Tried a few things...

IMG_3785.JPG
IMG_3785.JPG (115.06 KiB) Viewed 566 times

Best I got is a high pitch constant tone... So something is amiss with the sound system even though the tests work fine in the diagnostic cart...

I get the "key clicks" sounds on the desktop though... odd..


EDIT:

So SND_CS & DTACK here...
NewFile1.png
NewFile1.png (7.29 KiB) Viewed 548 times
About 240ns from CS to DT.
Then about 144ns on deselect, but still about 100ns longer before DT goes fully high.. So pretty much just say 250ns delay between SND_CS and DTACK.

/AS basically follows SND_CS.. not sure why /AS looks crazy like that though...
NewFile2.png
NewFile2.png (9.05 KiB) Viewed 545 times
EDIT:
Odd, those odd pulses are following the PLD CS to ROM.. Its like the PLD starts to set /AS then thinks, "oh crap I shouldn't be doing this", then sets it back high again... odd...
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.

ijor
Posts: 92
Joined: Fri Nov 30, 2018 8:45 pm

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by ijor » Thu Jan 31, 2019 11:40 pm

exxos wrote:
Thu Jan 31, 2019 9:06 pm
ah right, I need to look into that... So what exactly happens then, literally DTACK on SND_CS stays low for a long time ? how long ? Assuming when /AS is high DTACK is still low for longer than "normal" ?
DTACK on sound chip access is delayed for two cycles. But since the delay works on the raising edge of the clock, and the CPU deselects on the falling edge, it would actually be the second raising edge since S7. So GLUE releases DTACK only on S2! Add analog delays and the slow raising edge of DTACK for being open drain, and probably it will stay low until close to the falling edge of S3. That is obviously on the 8MHz clock. Guess that the CPU at 50 MHz completed another full bus cycle in the meantime!

If the next cycle happens to be something fast, like ROM, then probably DTACK might not raise at all to a high level. May be this is what you saw.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

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

Re: V2.5 BOOSTER CURRENT PROTOTYPE STATUS (SEC BOOSTER)

Post by exxos » Thu Jan 31, 2019 11:59 pm

It does kinda make sense so far. I mean at 16MHz it all works fine.. Though if SND DTACK is staying low for 100ns for arguments sake (after /AS goes high) , then the CPU running at 16MHz would take 62ns x 2 about 124ns before it will start looking for DTACK again. Data wouldn't be latched until a little later anyway.. .So DTACK being kept low form the SND cycle probably goes "un-noticed". Now when the CPU runs at 40mhz, thats now just 50ns for 2 cycles, and the CPU can probably manage to re-read DTACK from the SND cycle twice.

Looking at the EMUTOS code, it seems to malfunction when doing 4 consecutive writes to the YM chip. I would assume on the first cycle, it writes to the register fine, cycle completes, but DTACK is still low.. CPU being 40MHz starts next bus cycle, sees DTACK low still, completes the second cycle, only the write probably didn't actually happen as it all happened to fast.

So really, I need to decode SND address in the PLD and control DTACK myself and stop GLUE seeing a SND address also... I can check the YM datasheet to see how long it actually takes to setup the YM registers and emulate that timing in my PLD code...
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.

Post Reply