ST536 STE EDITION

[exxos]

I flashed and burn the latest stuff into my two boards and @PhilC and @Steve board.

I tested them all on @PhilC motherboard .

Currently the only anomaly is that @PhilC board refuses to work with BURST ON. But this is probably because that particular board is the only one with Micron RAM.

Previously it would work with fast slew but that trick does not seem to work now.

IMG_3393.JPG

[exxos]

Plugged in one of my boards (rev4.7) and that's acting oddly now as well with BURST ON.

TOS206 TTram test locks up at random, but even my TOS copy locks up at random.

In EMUTOS the floppy contents show corrupted with cache on. But fine with cache off. So I assume this is (again) pointing to a BURST fault on this one board.. but why..

IMG_3395.JPG

IMG_3396.JPG

[exxos]

One theory by GPT4 :

1.PNG

Not sure how a new CPU cycle can start during burst ? But I will go with the "glitch" aspect....

2.PNG

So BURST is now ON, and it seems stable on my board and Phil's now.

You can't bloody trust anything is doing what you think its doing with this stuff !! :pullhair:

[PhilC]

@exxos you'll get to the bottom of it I'm sure. I think the micron ram causing problems was a bit of a red herring as the st536 and TF536 will do burst mode ok with them I believe.

IE running frontier uses burst mode

[exxos]

@PhilC I think a lot of things are redherrings. I disabling the IDE earlier and it helped. But I think it just rewires stuff inside the chip making it work better. I suppose the way to look at it, more stuff you add, more internal noise and more glitches you get. So remove a chunk of code then stuff just happens to work better.

[exxos]

I left it running TTram test for 14 full passes last night. It would normally crash just after the logo somewhere. So thats another problem solved.. At the time of typing and not aware of any problems but I will have to go back and start retesting stuff on every board and combination again next...

I asked Grok about the issue...


Why Gating the MC68000 Address Bus with Address Strobe (AS) Isn't Enough in a Xilinx 9500 CPLD

You're correct in reasoning that, in an ideal scenario, the Address Strobe (AS) signal on a CPU like the Motorola MC68000 going low should ensure that the programmable logic device (PLD), such as a Xilinx 9500 CPLD, only processes the address bus when it’s stable. If the PLD’s logic is designed to ignore the address until AS is low, the transitions on the address bus beforehand shouldn’t matter. However, in practice, directly using the asynchronous address bus (even gated by AS) can still cause malfunctions in a synchronous PLD design. Here’s why this happens, focusing on the specific issue you’ve raised.

1. How AS Should Work

• The MC68000’s AS signal (active low) indicates that the address bus is valid and stable. The PLD’s logic should theoretically only process the address when AS is low, ignoring any transitions when AS is high.
• For example, a simple combinational decoder might look like this in Verilog:

  Code: Select all

  assign select = (~as_n) && (addr == 8'h10); // Only decode when AS is low
  

  In this case, the output select should only be active when AS is low and the address matches 0x10. Any address transitions when AS is high (as_n = 1) should not affect the output.

So why does this still cause issues?

2. Why Address Transitions Matter, Even with AS Gating
Despite gating the address with AS, several practical issues can arise in a PLD, particularly in a synchronous design like those targeting Xilinx 9500 CPLDs:

a. Glitches in Combinational Logic

• PLDs like the Xilinx 9500 implement combinational logic using sum-of-products (SOP) structures with product terms. When the address bus transitions while AS is high, these transitions can propagate through the combinational logic before AS goes low, potentially causing glitches on intermediate signals.
• For example, if the address bus changes from 000 to 001, some address lines may toggle slightly before others due to signal skew (e.g., different trace lengths or driver strengths). Even if AS is high, the combinational logic may momentarily produce an incorrect output (a glitch) because the address inputs are changing.
• When AS eventually goes low, the glitch may have already affected downstream logic, especially if the output feeds into sequential elements (like flip-flops) or other combinational paths.
• Why this matters: In a CPLD, glitches can consume product terms inefficiently or cause unexpected behavior in downstream logic, even if the final output is supposed to be gated by AS.

b. Timing Mismatch Between AS and Address

• The MC68000’s AS signal is asynchronous relative to the PLD’s clock. Even though AS indicates a stable address, the exact moment AS goes low may not align with the PLD’s clock edges. If the PLD samples the address or AS near a clock edge, it may capture a transitioning or invalid state.
• For instance, if AS goes low just before a clock edge, the address bus might still be settling (due to skew or propagation delays), and the PLD’s logic could process an incorrect address.
• Why this matters: In a synchronous design, all inputs to flip-flops must meet setup and hold times relative to the clock. Asynchronous signals like AS and the address bus don’t guarantee this, leading to timing violations.

c. Metastability Risks

• If the address bus or AS changes close to a clock edge in the PLD’s synchronous logic, flip-flops downstream may enter a metastable state, where their output is unpredictable for a short time. Even if AS gates the address, the combinational logic processing the address may feed into flip-flops, and any timing violation on the address inputs can cause metastability.
• For example, if the PLD uses the decoded address to generate a control signal that feeds a flip-flop, a glitch or invalid address could cause the flip-flop to capture an incorrect value.
• Why this matters: Metastability can propagate errors through the system, causing malfunctions that are hard to debug.

d. AS Signal Itself is Asynchronous

• The AS signal is asynchronous to the PLD’s clock, and its transitions may not be clean or perfectly aligned with the address bus. For example:
  • AS may have its own propagation delay or noise, causing it to toggle slightly before the address is fully stable.
  • If the PLD uses AS directly in combinational logic, any glitch or timing issue on AS itself can cause incorrect behavior.
• Why this matters: Using AS to gate the address doesn’t eliminate the asynchronous nature of the system, and the PLD’s synchronous logic may still see invalid states.

e. CPLD Resource and Routing Constraints

• The Xilinx 9500 CPLDs have a limited number of macrocells and product terms. Directly using the address bus in combinational logic (even gated by AS) increases the complexity of the logic, consuming more product terms and potentially leading to routing congestion.
• Asynchronous inputs also complicate timing analysis, as the tools (e.g., Xilinx ISE) cannot guarantee timing constraints for signals that aren’t synchronized to the clock.
• Why this matters: The 9500’s architecture is optimized for synchronous designs, where inputs are registered using flip-flops. Asynchronous logic is less reliable and less efficient in this context.

3. Why Latching the Address Resolves the Issue
When you latch the address bus with a flip-flop, synchronized to the PLD’s clock, you address these problems:

• Eliminates Glitches: The flip-flop captures the address at a specific clock edge, ensuring a stable output for the entire clock cycle. Any transitions on the address bus when AS is high are ignored.
• Synchronizes to Clock: The latched address is aligned with the PLD’s clock domain, meeting setup/hold time requirements and eliminating timing mismatches.
• Reduces Metastability: By registering the address, you give the signal time to settle, reducing the risk of metastability. A two-stage synchronizer can further minimize this risk.
• Simplifies Logic: The latched address is a stable, synchronous signal that’s easier to process in the CPLD’s logic, reducing resource usage and improving timing closure.
• Handles AS Asynchrony: You can use AS to control when the address is latched, but the latching happens on a clock edge, ensuring predictable timing.

Example Verilog for latching the address:

Code: Select all

module address_latch (
    input wire clk,        // PLD clock
    input wire [7:0] addr, // MC68000 address bus
    input wire as_n,       // Address Strobe (active low)
    output reg [7:0] sync_addr // Synchronized address
);
    always @(posedge clk) begin
        if (~as_n) begin
            sync_addr <= addr; // Latch address when AS is low
        end
    end
endmodule

This ensures the address is only captured when AS is low, and the latched address is stable and synchronous.

4. Why Gating with AS Isn’t Enough
You’re correct that the PLD shouldn’t process the address until AS is low, but the issue arises because:

• The address bus is still connected directly to combinational logic, which continuously evaluates its inputs, even when AS is high, potentially causing glitches.
• The asynchronous nature of AS and the address bus doesn’t align with the synchronous PLD’s clock, leading to timing violations or metastability.
• The CPL
  
  D’s combinational logic may not respond instantaneously, and any delay in AS propagation can allow transient address states to affect the output.

By latching the address, you’re not just ensuring stability—you’re ensuring the entire system operates synchronously, which is critical for reliability in a PLD.

5. MC68000-Specific Considerations

• The MC68000’s timing diagrams show that AS goes low after the address is stable, but the exact timing relative to the PLD’s clock is unpredictable. The address bus may also have slight skew or noise, especially in a real-world setup with long traces or external loading.
• The 9500 CPLD’s relatively slow switching speeds (compared to modern FPGAs) make it more susceptible to glitches and timing issues when dealing with asynchronous signals.

6. Practical Analogy
Think of the address bus as a noisy radio signal and AS as a “listen now” signal. Even if you’re only supposed to listen when AS is low, the noise on the address bus can still interfere with your receiver (the PLD’s logic) before AS goes low. Latching the address is like recording the signal at a specific moment when you know it’s clear, ensuring you only use a clean, stable version.

7. Recommendations

• Latch the Address: Always use a flip-flop to capture the address when AS is low, synchronized to the PLD’s clock.
• Synchronize AS if Needed: If AS itself is noisy, consider synchronizing it with a flip-flop before using it to control the address latch.
• Verify Timing: Use Xilinx ISE to check that your design meets timing constraints, especially for the address and AS inputs.
• Test for Noise: In hardware, ensure the address bus and AS signals are clean (e.g., proper termination, minimal trace length differences) to reduce skew and noise.

Summary
Even though the PLD should theoretically ignore address transitions when AS is high, directly using the asynchronous address bus (even gated by AS) can cause malfunctions due to:

• Glitches in combinational logic from address transitions.
• Timing mismatches between AS, the address bus, and the PLD’s clock.
• Metastability risks when asynchronous signals feed into synchronous logic.
• Resource and routing inefficiencies in the Xilinx 9500 CPLD.

Latching the address with a flip-flop ensures it’s sampled only when stable (when AS is low) and synchronized to the clock, eliminating these issues and making the design reliable in a synchronous PLD environment.

:dizzy:

I guess the problem is that when address strobe goes low, there is still a transaction time within the PLD itself going on. So you need to add a delay and latch everything to keep it all stable before actually doing any address decoding etc :roll:

[exxos]

I'm pleased to say (at the time of typing :lol:) DOTT now runs in my TOS206 build :)

20250620_165612.jpg

[agranlund]

Now don’t turn it off until you’ve finished it :D

[exxos]

Now don’t turn it off until you’ve finished it :D

It took me 20 years to complete castlemaster :lol:

[coonsgm]

I'm pleased to say (at the time of typing :lol:) DOTT now runs in my TOS206 build :)


20250620_165612.jpg

Woohoo! Looking amazing. This is Current 18 Firmware and the latest posted Emu1.4TOS.206 build posted?