REV 3 - REV 5 - The beginning (ST536)

[exxos]

Molished up a buffer board. I think the buffers have about 2ns delay each.. So on a 100MHz cycle, 5 buffers should be enough. The first chip is switchable for a simple inverter. This way I can experiment with the clock phase better.

Capture.PNG

Also added a 5V buffer to the CPU clock to see if I can improve the rise and fall times.. While this adds like 2ns delay, if it gives much better rise and fall times, then the overall timing hopefully won't change that much.. But It is switchable in case it makes things worse :D

2.PNG

I also added the 330R "termination resistor" . This seems to stop the minor oscillation on the high and low parts of the clock. I also added 2x 33R resistors in series which should stop the spikes on the rise and fall. Of course these could easily be bridged out or changed anyway.

[exxos]

Anyone know off hand how TOS206 and EMUTOS handles bad TTram ? I'm trying to figure out the problem with "corrupt" SDRAM.

In terms of TOS, it lists bad ram with XXXXXXXXXXXXXX on boot, BUT, does TOS (or EMUTOS) still try to use the ram after its been listed as bad ?

I'd assume in both cases that if the ram is marked as bad then neither operating system would try and use it.. Indeed both crash in the same scenario. I would assume EMUTOS wouldn't use the TTram if found bad, but its possible parts of RAM could be "good" one moment and not the next I suppose.

It's always been my assumption that TOS206 wouldn't use RAM marked as XXXXXXX.. But the entire ram block (64MB or whatever) would return a result (even if bad) and TOS would know it exists at that point, and *shouldn't" try to use it.. but I don't think TOS206 is that clever and could be what's confusing me..

But even if TOS allocated TTram when bad, I would also assume that nothing would actually use TTram until desktop programs were loaded ?

I'm just trying to figure out how I get from corrupted TTram to the system being totally unstable... I mean if the ram is bad and I'm not loading anything into it and it should be fine surely ? But it seems not...

Of course it could be something else completely causing the issue but I'm not really sure what.

[exxos]

New boards finally in production. I had the wrong footprints for several caps. So had to cancel that order and fix :roll:

Hopefully it be the last revision now.. But it depends on results from the buffer board tests. Hopefully the timings how they are now will be good enough. But I need to test various delays to figure out the optimum safest ones....

I'm still at a loss on how bad TTram leads to corruption in STram.. The internal state machine doesn't care. It does its thing regardless of what the SDRAM is doing..

[exxos]

So after getting side-tracked by my iffy DRAM board... viewtopic.php?p=137361#p137361

Now the ST536 is being sulky in finding TTram :roll: I flashed BETA5SS firmware just to make sure - same issues. So I flashed the test firmware I did for @coonsgm BETA5SS_STE0_INV and its working again now...

Problem with that firmware is TTram is slowed down a bit.. So its possible there is still a borderline timing somewhere.. hopefully I can fix that once I can play around with my buffer board. Though its still possible the CPU clock having a poor rise time could still be a factor in all this. Only have to have a ns in the wrong place at 100mhz.....

EDIT:
Put back BETA5SS firmware and now TTram is fine again :stars:
OK so I put freezer spray on the PLD, and now TTram isn't found again..

I put back BETA5SS_STE0_INV (more freezer spray) and working fine.. So maybe BETA5SS_STE0_INV would be the better firmware to trail for now then..

EDIT2:
Went to fast slew and without and without freezer spray on the PLD its now working fine with BETA5SS based firmware :stars: It must be the CPU clock causing issues at this point..

[exxos]

Been experimenting with some new ideas.... New corruptions to add to my collection :lol: :yay:

I've got 6 floppy B: drives! :lol:

20251212_000413.jpg

The blitter was off as well :lol:

TOS passed ST and TTram test at boot as well.

Answers on a postcard..

[coonsgm]

Stable is better than "a little faster"

[exxos]

Stable is better than "a little faster"

Yeah. The TTram looks like its going to take a 10% speed hit to keep things stable. There be a beta6 maybe tomorrow. No idea if it be happy on your board.. In theory it should..

Ironically that fix lead me to another idea to increase the speed by a bit more.. But something broke.. Need to figure out what :lol:

[exxos]

Tested just.. now working fine again.. weird..

IMG_4177.JPG

EDIT:
Now unstable.

It must be as it warms up it starts going nuts (after my test code changes) before it went nuts when it was cold :lol: :roll:

So it seems its all just tight timing.. Fast slew almost works, but only if the clock is inverted.. Then the speed bump vanishes and back to 10% speed loss. So not much else I can do until my buffer boards come so I can see what timings im dealing with.. likely 2-5ns which isn't much wiggle room !

Likely tolerances on hardware and thermal issues are all adding up to cause a very tight timing which is borderline. So I will do BETA6 firmware which will lower the TTram speed a fraction (about 10%) as its the only way it can (should) work more reliable..

So TTram has dropped from 847% to 832% in order for it to be stable currently.

[Darklord]

Stable is better than "a little faster"

Totally agree with this. Driving faster close to "the edge" is only beneficial
if you don't go over! :lol:

[exxos]

Totally agree with this. Driving faster close to "the edge" is only beneficial
if you don't go over! :lol:

I'm always close to the edge :lol: