REV 3 - REV 5 - The beginning (ST536)

[exxos]

Congratulations Chris - 1000% !

That's impressive... :)

:thanksyellow:


I am trying to do what MAPROM does in remapping some lower RAM stuff to TTram, but in hardware.. Not having much luck with that. So far just seems to be a crash screen generator :roll: :lol: so I don't know, the idea works in my head, but then again, most things do :lol: :roll:

[agranlund]

@agranlund do you know / still have a older copy of MAPROM which compiles in Devpac 3 still ? I've found 1.8 and that won't compile :(

No I couldn't find any older version here either, the oldest one on my drive was the same as what's in the old folder on github:
https://github.com/agranlund/tftools/tr ... maprom_old

That builds with vasm motorola/devpac syntax so shouldn't be far off from being buildable with Devpac.
As far as I can see maprom.s includes the other sources directly and you only need to build that top level file.

The makefile is responsible for setting a couple of defines as the same source is used to build both maprom.prg and fastram.prg.
Suspect this is at least one of the reasons you can't build maprom.s directly from Devpac.

Perhaps try adding these somewhere at the very top of maprom.s:

Code: Select all

OPT_MMU EQU 1
OPT_STRAM_CI EQU 1
OPT_RELO_ROM EQU 1
OPT_RELO_RAM EQU 1

to mimic how the makefile builds maprom.prg

Code: Select all

$(OUT_DIR)/maprom.prg:
	rm -f *.o
	$(VASM) $(FLAGS) -DOPT_MMU=1 -DOPT_STRAM_CI=1 -DOPT_RELO_ROM=1 -DOPT_RELO_RAM=1 MAPROM.S -o $@

[exxos]

Perhaps try adding these somewhere at the very top of maprom.s:

Code: Select all

OPT_MMU EQU 1
OPT_STRAM_CI EQU 1
OPT_RELO_ROM EQU 1
OPT_RELO_RAM EQU 1

I tried but still no go..

Capture.PNG

I have been trying to remap a small address range and low around direct to TTram in hardware, but its not cooperating :(

[exxos]

@agranlund OK so what's your "secret sauce" :)

I managed to remap $008 to $FFF to TTRAM, but all I get is like 1% speed boost. When MAPROM is run, theres more like 20% speed boost ! :shrug:

EDIT:

I bet its STram cache ?

[agranlund]

I tried but still no go..

Did you add the defines before "include lib\mmu030.s" and so on?
(it looks like it doesn't see the OPT_STRAM_CI define when compiling mmu030.s)

[exxos]

Found another weird thing.. I got AI to explain, I'm not sure if this is real or its actually a thing ?!

```
ARAM/BA Idle State - Signal Integrity Note

The idle clear inside cycle==0 when AS30_int==1 in the SDRAM module:

Code: Select all

if (AS30_int == 1'b1) begin
    address <= 13'd0;
    bank    <= 2'd0;
end

is NOT required by the SDRAM protocol. The W9825G6KH ignores ARAM and BA during NOP/idle cycles - they are genuine don't-care inputs between commands.

However it IS required on this hardware for signal integrity reasons.

WITHOUT the idle clear:
ARAM and BA hold whatever value was last driven during the previous access column address phase. The starting state before each new access is therefore random and depends on access history. When a new access begins, the number of ARAM/BA bits switching simultaneously varies unpredictably. On sequential memory tests (such as YAARTTT moving through addresses in order) this produces correlated worst-case switching patterns that cause sufficient ground bounce on the SDRAM VSS pins to corrupt data. The failure signature is bit 10 errors (fffb!=fbfb pattern) in TT-RAM, consistent with noise-induced data corruption rather than a logic error.

WITH the idle clear (to 0 or any other fixed value):
Every access starts from the same known baseline regardless of what the previous access was. The switching pattern from idle state to row address is consistent and bounded for any given address. Ground bounce stays within the margin the hardware tolerates and errors disappear.

The specific idle value does not matter - both 13'd0 and 13'h1FFF were tested and both pass. What matters is consistency. Scope measurements confirmed approximately 1V overshoot on ARAM lines due to transmission line reflections from the ABT16245 bus buffer switching. Random simultaneous switching pushes this over the threshold that corrupts data.

Slow slew rate on ARAM/BA/RAS/CAS/RAMWE was investigated as an alternative fix but made things worse - it reduces setup margin from ~5ns to ~2ns which is insufficient at 100MHz. The idle clear costs only 2 product terms in the CPLD and has no timing impact since the SDRAM ignores these pins during idle anyway.

Important: The idle clear is inside cycle==0 only - it cannot fire mid-access during tRCD between RAS and CAS which would corrupt the row address. The visible ARAM transitions between RAS and CAS on a scope are normal address multiplexing (row address then column address on the same pins) and are not related to the idle clear.
```

[exxos]

Words cannot describe how much I hate JLCPCB right now..
I was doing some heating tests of the PLD to verify it still works when warm. The a few firmware versions later, the board is totally dead! :cussing:

Checked most 68K pins to the PLD.. all fine.. Checked AS30 pulsing 4 times low, then nothing.

So checked ROM CE and nothing !

Long story short...

Capture.PNG

Where the yellow arrow is, I lose the connection from there to the PLD ! So I assume another Via has failed. I bodged wired it to the PLD.. Now my monitor flick is as it does during a normal reset but no Atari logo or anything else :cry: I just get 12 AS30 pulses low and then nothing..

I was not even eating the board that extreme either and I was only giving a blast of a few seconds to the PLD ! But it seems pretty conclusive at this point that any sort of heat on these boards from JLC and the things fail ! Ultrasonic cleaning and heating up likely contributed to the failure of the previous boards.

:mad:

[exxos]

Not having much luck. Can't find anymore broken traces.. Tried EMUTOS.. not sure what its trying to tell me ? :lol:

IMG_4937.JPG

[exxos]

I found the issue, self-inflicted :lol: :roll: I was one pin out when I soldered ROM CE, I soldered it to A0 ! :lol: :roll: too many late nights adding up again :cry: Now back up and running!

The problem I'm trying to diagnose currently is the shadow which copies lower Ram variables to SDRAM. It's made the PLD sensitive to warming up again. I verified that the previous version before that modification worked fine.

I'm currently trying to diagnose why, but I believe it is likely going to be "to much logic" in the PLD as its been struggling to fit in a 288xl for a while now :( I have some code-branches even disabled to aid in debugging...

I think the amount of terms like in the address bus simply doesn't fit cleanly inside one macro cell. So it ends up being spread across various macro cells. Which then starts adding delays. This is the exact problem I had with the original 144xl design. Where ROM DTACK would go low with AS30 basically, but then managed to take 30ns to go low, thats how bad things end up !

I mean it only gave me 1% "across the board" speed up in GB6. Not much of a problem to remove it. But I'm just trying to find out exactly what the problem is and where first. I've been trying various optimisations and nothing is helped so far.

[exxos]

Interesting...

Each function block in the XC95288XL is essentially a GAL — 18 macrocells, 54 inputs, 90 product terms per cell. When your logic fits inside one function block it's fast and clean, just like a single GAL.

When a signal's logic cone is too wide for one function block, the fitter has to split it across multiple blocks and chain them together — exactly like daisy-chaining GALs. Each inter-block connection costs you propagation delay, and deep chains compound it.

The product term cascade within a single function block is like borrowing logic from the neighbouring macrocell in the same GAL — a small penalty. But crossing to another function block entirely is like going off-chip from one GAL to the next, which is where the real delay hits.

And the registered intermediate node is like latching the output of GAL 1 into a flip-flop before feeding GAL 2 — it breaks the timing analyser's view of the chain so it looks fast on paper, but you've now got a full clock cycle of latency baked into what should have been purely combinational logic.

It would also now makes sense why I ended up with like a 30ns delay on ROM DTACK on the original 144xl design.. Which all drove me nuts for literally months...

I think as soon as the compiler start struggling, you basically crossed the limits, even though you haven't technically crossed them...

Capture.PNG

My Pterms were a lot higher and I had more than available.. That a sunk significantly after a lot of optimisations.. Of the problem was that reducing Pterms ended up using more macrocells, which is worse. So took some messing about.

TL;DR
So far is running fine again..

I have got IDE auto boot disabled currently. I was adding in a module to have some registers so you could switch out TTram if you wanted etc, but considering the limits of the chip, I think that module will just have to be taken out now. It would have been nice to have some programmable settings but it's just not worth the aggro. As I keep finding, every little change reorganises the entire "circuit" and then timings break elsewhere again. This is one of the main problems I've been fighting for ages.. And why you cannot ever really "win" with what I'm trying to do.

EDIT:

It's crazy! :pullhair: :crazy: I can go from working code, to TT RAM failing code, to not booting up whatsoever, just by altering like one line of code..