REV 3 - REV 5 - The beginning (ST536)

[Badwolf]

It works but TTram ended up a speed drop from 847%

This is worrying. The SDRAM (terminated with STERM) is completely synchronous. Its speed should remain the same for the same starting conditions.

Unless you're modifying the state machine itself or the triggering of the state machine it shouldn't change. If it does, and you're not, it could indicate you're not actually correctly aligned with the SDRAM cycle and it's working by capacitance lag alone!

The good news is is that it's scopeable. The bad news is it's tricky to do so.

BW

[exxos]

Looks like the ACCESS delay I added in to fit the supposed address bus issue was the cause (the thing where those TTram tests showed wrong data on the lower side of the bus) Though I don't get, as it never caused any slow down originally... and it doesn't show up on the H4, only the STE.

TTram wise, nothing should really care. Though after all the tweaks done today, maybe that ACCESS fix is a hindrance now for some reason.. I will have to test both machines without that in place now

IMG_4025.JPG (340.13 KiB) Viewed 248 times

Will leave it on TTram test for a bit next..

Crossed streams a bit viewtopic.php?p=136536#p136536

[exxos]

So the STE works with my new firmware viewtopic.php?p=136536#p136536

But now the ST536 with the same firmware doesn't boot up. The only change was removing that ACCESS delay. Put that back in, all OK again, TTram speed as expected. I also have to delay DTACK a bit more on the ST chips..

So I need to figure out why the ST chips need the delay but the STE doesn't...

[exxos]

Scoped the address bus, not on 50MHz cycles specifically, but can see /AS goes low about 50ns after data changes on the bus, so it can't be unstable address bus unless its unstable internally in the PLD.

I can alter the phase of the CPU to the bus, so if there was a conflict on the bus, it should be shifted out, but it doesn't help.

The only things which worked, is delaying ACCESS in the SDRAM controller (that caused the STe TTram slow down) or inverting the actual SDRAM clock. But its back to WHY. TTram access is tripping up on something but no idea what. DATA bus is isolated. Doesn't seem to be address bus stability issue going by my quick tests.

I forced BR high to rule out bus request related issues. no change.

EDIT:

Slow slew makes it work.. but is that because of some noise on a signal somewhere or because its getting delayed a tiny bit...

IIRC the original TF536 only worked with slow slew.. But why..

[exxos]

With fast slew I am back to this problem..

but which bits are source and destination ? Its unclear which number is the correct one and which is the one read back and wrong.. I assume the left side numbers are the wrong ones ?!

IMG_4029.JPG (446.29 KiB) Viewed 209 times

I assume bits 12,13,14,15 are "bad" each time ?

Capture.PNG (28.71 KiB) Viewed 198 times

1.PNG (87.46 KiB) Viewed 197 times

I wonder if something is glitching with the bit masking logic

[exxos]

So it still seems the ST536 needs that ACCESS delay and the STE doesn't.

There must be something conflicting on the ST side bus, but theres not much common there.. only address bus and RW I think..

DTACK is isolated on RAM access so its slowness doesn't matter. AS/UDS/LDS are isolated..along with the databus..

This is very difficult to figure out without expensive LA gear. I can only guess, that something is driving RW longer than it should (or address bus) and when the CPU enters 50mhz mode on TTram access.. something ST side hasn't fully let go yet and it conflicts.No idea what. If I delay TTram access by 10ns and all is fine.

[exxos]

Even more odd, If I start the SDRAM cycle early.. it works.. if I start it late.. it works.. if I start it "on time" its unstable . You would think if it works early and late, that a timing in between would also work as nothing should be changing anyway.. but nope.. Delaying twice fails miserably.. It shouldn't matter surely.

I don't have this problem on the STE. The only real difference other than the PCB layout, also I added pullups on the SDRAM bus which the original TF536 didn't have. But can't see it being that.

EDIT:
Now its working without any delays.. when its been totally unstable for ages in that configuration

Trying fast slew and it locked up on TTram test. BUT, freezer spray on the PLD, it works fine for a little bit..

[exxos]

I've found out that its not loading STOS which is odd. Mostly it loads from floppy. But half the time its corrupted graphics on load and locks up before TOS 206 comes up on the splash screen.

I've swapped the PSU and upped the voltage. That seems to have helped as it wouldn't get to the desktop before. But even running at 8MHz with no TTram STOS isn't loading from C:

I've pretty much stripped the whole thing back to basics now and its still not loading STOS.

IMG_4030.JPG (209.41 KiB) Viewed 127 times

It's like a bit plane gets skewed somehow.. and it's always the same place.

I've stripped everything back theres nothing else left other than the IDE controller itself.


EDIT:

OK so something in my STOS folder is causing that I copied what I had on A: (very basic minimal version) and that loaded fine.. weird..

Its STE_EXTN which caused it never known a extension to crash before.. but I guess its not a STE anyway.. but still..

So I can go back to whatever the problem was before I got distracted with this STOS problem !

The only odd problem with STOS is when I do a DIR in the editor , it lists the contents as normal, but then throws up "disk error".. But im just going to ignore that for now...

Currently running YAARTTT.. Running on 5.30volts on the PSU.. I had similar issues with the DFB1X that some CPUs simply didn't run on only 5.00 volts.. So maybe that was the problem all along...

Be fine for people with one of my newer PSUs or a SR98 where you can adjust the voltage easily.. but not so much for other PSUs.

Also noticed "my old friend" of the distortion which happens on the screen when accessing the floppy drive with the original power supply (SR98) which doesn't happen with one of my more modern switch mode designs.. Maybe I will do a quick video short showing this if anyone is interested...

[exxos]

Current scores. Don't think anything can be made faster.

IMG_4033.JPG (339.17 KiB) Viewed 97 times

[exxos]

So it was working fine last week. Turned on today, not so stable again

Been doing some voltage tests with SR98. It locks up during TTram test in TOS below 5.30V. Above that it locks up every time on YAARTTT 5th test!

I have took some scope measurements of the 5V rail with SR98...

IMG_4036.JPG (238.09 KiB) Viewed 59 times

IMG_4037.JPG (273.33 KiB) Viewed 59 times

IMG_4038.JPG (279.71 KiB) Viewed 59 times

IMG_4039.JPG (230.4 KiB) Viewed 59 times

IMG_4040.JPG (265.94 KiB) Viewed 59 times

Then with 4,700uF added to the 536

IMG_4044.JPG (360.71 KiB) Viewed 59 times

IMG_4041.JPG (268.28 KiB) Viewed 59 times

IMG_4042.JPG (267.83 KiB) Viewed 59 times

But didn't seem to change anything..

I put back in one of my PSUs which outputs 5.00V and locked up on TTram test again during power up.

I even stripped back the firmware to barebones 8MHz (no TTran etc) and it randomly resets for no reason. Even removed the clock switching and "hardwired" the clock inside the PLD to 8MHz.. didn't help either.

I swapped back to SR98, with 5.50V and now its just done a full test loop on YAARTTT

As I have a "fly lead" on the CPU clock, I touched it with my fingers and instant lockup.. hmm.. On the STE version I had some series resistance on the CPU clock which the ST edition doesn't yet have..


The clock shows this.. could it be that simple.. (probably not)


I just noticed I have fast slew turned on still...

IMG_4045.JPG (284.72 KiB) Viewed 59 times

So back to slow slew..

IMG_4046.JPG (321.71 KiB) Viewed 59 times

Nothing drastically noticeable..

This is during TTram test..

IMG_4047.JPG (302.97 KiB) Viewed 59 times

Pretty amazing voltage wise since the PLD is driving the clock directly from 3.3V rail !

So with the scope probe still attached, touching it doesn't cause a lockup now. Its done a full loop on YAARTTT.

In case anyone is wondering, IIRC, the "fast slew" which a issue on the original TF536 (I am just trying to get to the bottom of exactly WHY)

If you set them to fast its fast on every pin and this can cause mega issues on the CPU clock line

So likely it is better having some series resistance in the clock line. But doesn't matter for slow slew anyway. It's currently locked up about half way through loop 3.. So for sure a improvement on slow slew.. Will experiment with various termination to see whats best...

I've uploaded CURRENT30SS on the STE page https://www.exxosforum.co.uk/atari/last ... /index.htm only tested on the ST536.. But assume it work fine on the STE536 as well..

EDIT:
So 47pF seemed to give bad ringing and crashed on ROM CRC test. 100R looked much better on the scope.. but now no TTram found ! So was still on 5.50V. lowered to 5.30 and TTRAM found and testing OK again.. this stuff is bonkers !!