CURRENT PROTOTYPE STATUS (SEC 64MHz 68000)

[ijor]

That doesn't actually happen though with ROM access. I documented it a long time ago, I think TF even noticed the same.. That Based on normal 8MHz timings, GLUE DTACK stays low right up until S2 of the next bus cycle. There is about 20-40ns difference between DTACK going high and /AS going low in the next bus cycle. That time is only there with 1K pull ups on DTACK. Pretty much DTACK can been seen as staying constantly low during all ROM access.

That's not what I see. Do you have high bandwidth scope captures showing that behavior?

But when accessing the sound chip, GLUE uses synchronous logic. This is done on purpose for inserting wait states because the sound chip is not that fast. But then DTACK pulse would extend much more than S7 and S0 (let alone the slow raising time for being open drain). And this indeed can be a problem if the CPU is running at a faster clock.

The CPU still waits for DTACK, so even if DTACK arrived 20 clocks later, it wouldn't cause the CPU to do anything to fast.

You misunderstood (or may be I didn't explain it correctly). The problem on a sound chip access is not DTACK assertion, but DTACK DEassertion. The same logic in GLUE that delays DTACK assertion when accessing the sound chip, it delays DTACK deassertion as well. So in this case, when a very fast CPU accesses the sound chip, it might definitely happen what you thought that the CPU would see this DTACK still active on the next bus cycle.

In fact in terms of RAM access, DTACK is actually asserted a little bit faster than when data is actually ready. So I have to add in some delays there to compensate

Yes, because MMU assumes a bus cycle being performed at stock 8MHz.

[exxos]

You misunderstood (or may be I didn't explain it correctly). The problem on a sound chip access is not DTACK assertion, but DTACK DEassertion. The same logic in GLUE that delays DTACK assertion when accessing the sound chip, it delays DTACK deassertion as well. So in this case, when a very fast CPU accesses the sound chip, it might definitely happen what you thought that the CPU would see this DTACK still active on the next bus cycle.

I'm talking of both sides of DTACK. I know its very slow in the rise time, but DTACK doesn't deassert until S2, when the CPU is just starting to assert /AS again. Its not that slow on any other DTACK cycles other than ROM. Pretty much DTACK goes high just a new ns after /AS, in all cases but ROM access.

The cycle is /AS goes low, a few ns later DTACK goes low.. /AS goes high.. ages later DTACK does high in S2. I remember seeing it on my scope that DTACK stays low the entire time ROM is being accessed.

I can't find any screenshots of this, but this work is going back 4 or 5 years now.. When I get a stock machine connected again I will take get a capture.

[terriblefire]

I spent a year on this before i finally figured it out. If you want to be compatible with dumb external devices that dont have their own DTACK (and they exist) then you need to register DTACK on the falling edge of S5 (slow clock domain) and present it to the faster clock domain around the falling edge of S7 (slow clock domain). You can try presenting at different times after that such that the cycle terminates in mid S7. Depends on your relative speeds and you do the maths for the relative clock speeds if you want.

But importantly do not latch on the falling edge of S3 unless you know that address location is fast enough for the cycle to terminate in S5.

If you do not latch on the falling edge of S5 you need to wait and treat the next falling edge as S5 (if DTACK appears).

*Completely ignore DTACK from the other clock domain except at these decision points*.. i.e. dont ever let it just pass through. You can happily start another cycle with DTACK low... its expected that DTACK will stay low until around the positive edge of S2. But just dont pass it through.

This is the *ONLY* thing other than switching clock speeds that works.

EDIT: How i figured this out.. i found this in the Amiga Zorro Tech Ref manual

Capture.PNG

[exxos]

Yeah DTACK is only a reference point to when data is valid or not. It gets chopped up and re-timed all over the place. It gets complicated, but kinda like how you mention above anyway.

[ijor]

You misunderstood (or may be I didn't explain it correctly). The problem on a sound chip access is not DTACK assertion, but DTACK DEassertion. The same logic in GLUE that delays DTACK assertion when accessing the sound chip, it delays DTACK deassertion as well. So in this case, when a very fast CPU accesses the sound chip, it might definitely happen what you thought that the CPU would see this DTACK still active on the next bus cycle.

I'm talking of both sides of DTACK. I know its very slow in the rise time, but DTACK doesn't deassert until S2, when the CPU is just starting to assert /AS again. Its not that slow on any other DTACK cycles other than ROM. Pretty much DTACK goes high just a new ns after /AS, in all cases but ROM access.

??? Seem we have some big misunderstanding here. That paragraph you quoted me is *NOT* about ROM cycles, but about sound chips cycles. Let me start from the beginning to be sure we understand each other.

You claim that GLUE deasserts DTACK on ROM access too close to S2. And that in such a case, and because your CPU is running faster, the CPU might still detect DTACK being low at the next bus cycle, and then it might terminate the next cycle too early.

You also said that to avoid this problem, when you decode a ROM access, you don't let GLUE to see AS and instead you handle DTACK by yourself. Lastly, if I understood you correctly, you said that you are not decoding I/O and you are hiding AS on a ROM access only.

I say that I don't see GLUE being that slow when accessing ROM. But I do see that GLUE does delay DTACK a couple of cycles when accessing the sound chip both at assert and at release time!

That is the reason I stop GLUE seeing /AS for ROM cycles as its DTACK take forever to release. Though maybe GLUE is doing that with other cycles which I haven't taken into account.

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.

Exactly that! Yes, it is very likely that something like this will happen when accessing the sound chip. And it might be just a coincidence, but you say that EmuTOS crashes precisely when accessing the sound chip!

I can't find any screenshots of this, but this work is going back 4 or 5 years now.. When I get a stock machine connected again I will take get a capture.

I attached a capture screenshot on a ROM access cycle. I don't have a 4-channel scope, so I used a MSO to see all the relevant signals together. Not being a true scope, especially the analog channel is not very precise. But I think there is not much doubt that GLUE releases DTACK quite early some when around the second half of S7. This was taken on a Ricoh GLUE -38A. The behavior matches the logic that I see on the -38 GLUE chip I decapped.

[exxos]

I attached a capture screenshot on a ROM access cycle. I don't have a 4-channel scope, so I used a MSO to see all the relevant signals together. Not being a true scope, especially the analog channel is not very precise. But I think there is not much doubt that GLUE releases DTACK quite early some when around the second half of S7. This was taken on a Ricoh GLUE -38A. The behavior matches the logic that I see on the -38 GLUE chip I decapped.

I have never seen that behaviour on any of my machines.. DTACK would stay low for another full CLK8 cycle on ROM access. As to why you see something different , I really can't explain... Yours is more like how things should be yes, but we never saw that.

Maybe you could try GB6 on ROM test and recapture ? I would never see DTACK go high at all during ROM access. Myself and Rodolphe spent many many emails talking about this issue a few years ago. Its because of this we isolated /AS to GLUE during ROM access to simply avoid the DTACK issues.

[ijor]

I have never seen that behaviour on any of my machines.. DTACK would stay low for another full CLK8 cycle on ROM access. As to why you see something different , I really can't explain... Yours is more like how things should be yes, but we never saw that.
...
Its because of this we isolated /AS to GLUE during ROM access to simply avoid the DTACK issues.

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!

Btw, the issue with the sound chip seems to be "fixed" on the STE. STE MCU combo still delays asserting DTACK when accessing the sound chip (it must), but releasing DTACK is performed asynchronously. They added an async reset to the delay flip flops that is not present on ST GLUE, at least not on the earlier versions.

[exxos]

I found these images I took in Jan 2017, but these are just confirming your images...

rom3dtce.png

rom2asce.png

We definitely saw DTACK staying low all the time, but maybe that was when we was running the CPU faster at 16MHz and GLUE just saw /AS low all the time and kept DTACK low all the time as well... Maybe Rodolphe can remember ? I know we were talking about it being a huge issue years ago...

[exxos]

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 ?

[ijor]

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.