Booster clock switching + DMA nerding

[ijor]

With the exception of the ACIAs I think (which run at 1/10th the anyway), every bus cycle on the CPU is asynchronous by design. Bus arbitration even more so.

It is true that the 68K bus is asynchronous by design, and it is also true that there are many successful asynchronous designs for the ST. Despite that I would never use an asynchronous design. I think it is an obsolete idea that made sense back in the day, among other things because there was no other choice. Modern tools and modern components, like virtually any FPGA, are based and designed for a rigorous synchronous design.

That doesn't mean that an asynchronous design won't work. But sometimes it will not, and you might have a very hard time trying to figure out what the problem is. E.g., it is very difficult to perform a good timing analysis for an asynchronous design.

I can't elaborate on your specific case however, just a small comment. The 68K has a synchronizer chain at the input of most control signals, including of course BR & BGACK. This is what allows bus arbitration to operate asynchronously reliably. But the ST chipset has NOT. Nor GLUE (or STE MCU) neither Blitter has any synchronization chain on any signal. Some control signals are not synchronized at all.

But, wait a moment! I was just re-reading the 68k manual page for bus arb timing and realised I'd completely forgotten that BG can be asserted mid cycle and the requestor waits for the end of the cycle to assert BGK.

Be aware that GLUE and BLITTER don't follow the bus arbitration specs very strictly.

If you want to investigate deeper , I suggest you look at BR and how fast the CPU reacts to it. IIRC , the NMOS CPU can take a clock cycle longer over the HC CPU.

Any signal that arrives late to the CPU (as could happen when working asynchronously), including not only BR, but also DTACK, might take an extra cycle to be detected by a slower CPU. But there is nothing specific to CMOS vs NMOS, just faster vs slower.

[Badwolf]

It is true that the 68K bus is asynchronous by design, and it is also true that there are many successful asynchronous designs for the ST. Despite that I would never use an asynchronous design. I think it is an obsolete idea that made sense back in the day, among other things because there was no other choice. Modern tools and modern components, like virtually any FPGA, are based and designed for a rigorous synchronous design.

Yes, thanks. I actually rewrote large parts of DSTB1's firmware with an eye to synchronous logic on the back of your recommendation previously.

However in this case I wasn't talking about the approach with respect to booster design but more that there's ought to be little reason there needs to be any clock phase synchronisation between the motherboard and the CPU at all.

Well other than it could incur delays, but delays aren't my concern ATM. I'm pursuing fouled interactions between the CPU and, specifically at the moment, the DMA subsystem.

But, wait a moment! I was just re-reading the 68k manual page for bus arb timing and realised I'd completely forgotten that BG can be asserted mid cycle and the requestor waits for the end of the cycle to assert BGK.

Be aware that GLUE and BLITTER don't follow the bus arbitration specs very strictly.

No, that's fair. But it seems I've had a bit of a head-slap moment here. I am following it even less strictly.

I have basically taken the approach of not assering AS to the motherboard when doing an AltRAM cycle. I do permit UDS and LDS to be asserted after emperical evidence this didn't seem to trigger anything it oughtn't, but I acknowledge that's not good practice in general.

However I'd overlooked (forgotten) that in bus arbitration scenario BG is not reserved for assertion between cycles. It asserts early and the requesting system is expected to wait for the next cycle to take control and assert BGK.

I've been refreshing myself on the MCU/DMA interaction and have verified that the MCU is checking for AS before asserting BGK and doing its thing.

So my design is fundamentally flawed: BG can assert mid-AltRAM cycle. The MCU cannot detect this cycle, however, as AS it not asserted on the motherboard side. MCU is therefore free to assert BGK and begin DMA cycles whilst all the while the CPU may still be driving the address bus and the data bus can still be driven by either the CPU or the SDRAM.

Whoops!

So, @exxos, I don't think the issues I've been seeing are at all related to Steve's STE536 problems as this is a design flaw in my board which you've already addressed by delayed BG assertion.

But I've very much learned a bunch from this rubberducking session & thanks to the both of you.

I'll be interested to see if I can implement a suitable bodge around and whether I can still make the problems happen then.

BW

[Badwolf]

I've cut the trace between the two BG pins and have hacked in wires to two of my test points.

This logic seems to have produced excellent results in this evening's testing:

Code: Select all

wire BGI;
wire BGO;

reg BGO_IN = 1'b1;
always @( negedge CLKOSC or posedge BGI ) begin
	if( BGI )
		BGO_IN <= 1'b1;
	else begin
		if( AS_INT )
			BGO_IN <= 1'b0;
		else
			BGO_IN <= BGO_IN;
	end
end

assign BGI = TP[5];
assign BGO = BGO_IN;

assign TP[4] = BGO;
assign TP[5] = 1'bz; //BGI;

Here TP are the test points, BGI is BG IN (from the CPU), BGO is BG out (to the mobo) and BGO_IN is the internal register driving BGO. AS_INT is AS from the chip that doesn't necessarily make it to the motherboard.

This has behaved very nicely this evening. MiNT is now back running again and I no longer need to slow down the CPU for bus arbitration (although I could for power and heat reduction, I suppose).

Tests with the STFM tomorrow, perhaps.

A big leap forward in trying to sort out my stability problems. Thanks to exxos and Ijor for putting it in my mind and czeitz for his MCU schematics.

BW

[exxos]

:bravo:

Now you know why I have the exact same bodge wire on my earlier V2 boosters ;)
https://exxosforum.co.uk/atari/last/V22 ... /index.htm

Welcome to 2015 :P

[ijor]

However in this case I wasn't talking about the approach with respect to booster design but more that there's ought to be little reason there needs to be any clock phase synchronisation between the motherboard and the CPU at all.

Again, if you are completely asynchronous to the main clock (which I understand you really are not), chances that you'll provoke synchronization issues at the chipset that is not designed to work asynchronously. This might be very infrequent though, especially metastability would be extremely rare, and depending on the signal you might not notice them.

However clock skew and asynchronous are two very different things. Clock skew might be ok and reliable as long as it doesn't violate timing. In practice this is not always easy to achieve, especially without performing a complete timing analysis. Negating the clock is oftentimes a quick and easy solution, at least as long as the skew is small in relation to the clock period. But it is not foolproof because sometimes the input device might latch a signal on the opposite edge, and then a negated clock would convert this relationship to latch on the same edge that is was launched.

[Badwolf]

Well I've just booted in to MiNT and launched Day of the Tentacle from within it. Played it for an hour and then quit back to the MiNT desktop and carried on there.

This is on a 512k STFM with a busted AY chip.

Did the same yesterday on the 2MB STE.

I'd say things are improving. :D

BW

[Steve]

:girldance: :girldance: :girldance:

[JezC]

@Badwolf I'll be interested to know if/when you think you have a final solution/version to test...

It might even give me the impetus to slap on the last few passives & program up the CPLD on my DSTB1... :D

[Badwolf]

@Badwolf I'll be interested to know if/when you think you have a final solution/version to test...

I think I do now, but it requires some physical modifications which I need to document. A new revision is probably on the cards.

If you're happy to cut a few traces and wire in a few bodges, then I'd be keen to get additional feedback.

BW

[ijor]

Well I've just booted in to MiNT and launched Day of the Tentacle from within it. Played it for an hour and then quit back to the MiNT desktop and carried on there.
This is on a 512k STFM with a busted AY chip.
Did the same yesterday on the 2MB STE.

I'd say things are improving. :D

Great job!