CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

[rpineau]

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.

[exxos]

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

[exxos]

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

[rpineau]

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

[exxos]

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.

[exxos]

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 (115.06 KiB) Viewed 3601 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 (7.29 KiB) Viewed 3583 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 (9.05 KiB) Viewed 3580 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...

[ijor]

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.

[exxos]

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

[exxos]

I have cut the SND_CS form GLUE and managed to hack on a wire onto my PLD.

So far I decode SND_CS = ADDR:[FF8800..FF8808] ;

GLUE & PLD decode match (though PLD decoding is a bit faster). I can hear the key clicks, though floppy drive is not working.. So I guess there is another address range somewhere for floppy which I need to decode.. ??

EDIT:

Suska code doesn't list anything any different..

s.jpg (20.21 KiB) Viewed 3794 times

EDIT:

OK nevermind bad floppy cable

[exxos]

IMG_3789.JPG (310.31 KiB) Viewed 3785 times

TOS104 still comes up that error on floppy format, but at least this is now booting EMUTOS and the sound works! EMUTOS formats a floppy fine, So TOS104 has some "bug" with the floppy drive, no big deal, just use FCOPYIII instead.

So thanks to VInce for pointing in the right direction to being a sound issues, and thanks to Ijor for pointing out the slow DTACK on SND_CS !