exxos's Atari, Amiga & retro forum

coonsgm wrote: 09 Nov 2026 13:41 All three TT Ram tests freeze.
The desktop is clearly accelerated with the rapid animations suggesting that TOS on RAM is working

I will continue to see if I can have find any hardware issues (bad soldering by myself).

Thank you again for all the help!

Could you take two photos for me please:

1. The memory test screen when the machine boots, so I can see exactly what it shows for ST RAM and whether anything at all appears for TT RAM.

2. The TTCHECK screen once it has frozen. Even if it looks like nothing happened, I need to see whether the title line and the _ramtop / _ramvalid / phystop line appear, and the last line it printed before it stopped.

You should see this on boot up (do not press any keys as it would skip the tests)


Obviously TTram is working as the ROM CRC copy passes.. But at this point, if you dont see the TTram check bar, then TOS has marked the RAM as bad for some reason and does not run the checks.. Which is of course a bit contradictory if ROm to TTram passes and works fine.. unless the bottom end of SDRAM is faulty for some reason.

Here you go

Photo #1 Photo #2

Thanks Greg, that is really useful. It has not actually frozen, test 3 was just sat there like a ZX Spectrum waiting for you to press play on the tape. Sorry, I should have made that clearer!

The important bit is test 1. That is exactly the same check TOS does before it sizes the TT-RAM, and it fails on your board. When it reads the TT-RAM at $01020000 the second time, it gets back the value that was just written to ST RAM, so TOS decides there is no TT-RAM and never shows the TT-RAM test. So we now know why it is not being found, we just need to work out what is causing it.

Could you run it again, press a key when it gets to test 3, and post a photo of the result? It writes and reads back all 60MB, so it may take a little while. It shows one character per MB, so we can see if it is all of the TT-RAM or just part of it. If it crashes, let me know as that tells us something too.

exxos wrote: 09 Nov 2026 13:29

Badwolf wrote:Well I still tend to think "most people" exposed to an accelerator that turns on everything with no input from the user will end up just going 'this, that, the other doesn't work with ST536...'

Incompatible with what exactly though? All fast ROM does is make GEM and TOS run a bit faster, and I cannot think of a single reason why that would cause anyone a problem. If it was running at 1GHz then maybe, but a few hundred percent faster is very unlikely to upset anything.

A couple of things conflated here. At this point I was talking about having everything turned on by default. The original 536 doesn't cache ST RAM, for example. It doesn't remap or replace the ROM. It doesn't decalre TT-RAM by itself. Personally, for me, this is closer what I would want from an accelerator, albeit the hard cache restriction wasn't ideal.

I understand mileage may vary. I understand it's your decision. But I was only offering some feedback as your LLM has now suggested to make every boot a cold boot and it pointed out it will upset some people.

I'm ambivalent over the cold boot, but if it *will* upset some people (maybe it will maybe it won't but your LLM thought it significant enough to mention) then I'm pointing out it may be doing so for a feature "some" people might not really want.

Fast ROM has been standard in my stuff for about two decades now, and in all that time nobody has ever complained about TOS running faster.
...
Sorry if this upsets some people, but this was all decided over a year ago and nobody said a word at the time. It is a bit late now to start complaining, after I have put tons of work into making it what I think is the best and simplest way for everybody to use it, without needing annoying software to load.

With respect, I think I've been fairly consistent in gently expressing my dislike of enforced ROM replacements and when testing the STE536 I did ask if it be turned off.

I haven't been complaining, no. I'm not in a position to. But I don't think I've said nothing either.

I apologise if I mistook your LLM's post about a proposal to change the approach as an opportunity to comment.

Badwolf wrote:Mind you, if not having it enabled is just a case of popping out the ROM then I suppose it could be a non-issue. That said when I last ran into debugging problems with the 536 there wasn't an easy way to avoid using the fast-access ROM either.

Yes, like I said, EmuTOS will not enable fast ROM, so a ROM without the copy patch simply never turns it on. It can also be turned off in the firmware if a developer wants that, so that is not a problem either.

If the TOS changes are easy to disable, then my points are moot. It wasn't clear to me that it was easy to disable, however. Stock EmuTOS will auto-declare TT-RAM too, for example. So would it need a replacement ROM? A fast one?

I understand your position is to make everything as automatic as possible. This is not an approach I like as I think it's much harder to turn things off from that position than to turn them on if they're off by default. It's why I shan't adopt the approach DFB1X has to the ROM in the DFB1 tree, for example.

It's entirely your perogative how you design your boards of course. If you don't want hear a contrary opinion when your'e doing your design work, no problem, I'll keep schtum.

BW

Test appears frozen. Screen simply shows "Testing, please wait..."

Been stuck here for the last 20 minutes or so.

Badwolf wrote:If the TOS changes are easy to disable, then my points are moot. It wasn't clear to me that it was easy to disable, however. Stock EmuTOS will auto-declare TT-RAM too, for example. So would it need a replacement ROM? A fast one?

No. Like I said, it is TOS which triggers the switch over in the PLD, and EmuTOS by default would not trigger the copy, so it never turns fast ROM on. That said, EmuTOS is not on my list of things to test right now, as everything is a huge time sink from every angle.

What comes later depends on sales, and I would bet those will be low. Things have to be worth my time, and I am not going to spend another year going through every combination of everything if only five people ever buy the things. If people are upset by that, then that is just how it is. I would hope people appreciate what they do get, rather than what they don't.

Also, for clarity, the cold boot on reset was my own decision, already built and tested on hardware last night, to fix the ROM bank switching and memory corruption problems I described earlier.

And no, a fast ROM is not needed either. Fast ROM on the ST536 has nothing to do with the speed of the ROM chips. TOS is copied into TT-RAM and runs from there, so ordinary ROMs are fine, there is no need for 55ns parts like older designs used. A stock ROM without the copy simply runs from the 16-bit ROM at stock speed, as intended. With my TOS, if the copy fails because of bad TT-RAM, TOS shows the error, does not switch over, and just carries on running from the onboard ROM.

As for the LLM comment, I find that frankly insulting. I did not ask an AI to write a reply for me. I wrote every response myself and used AI to reword it, and I have now spent over three hours typing out replies to you. I know you are against AI, but I simply do not have the time to check every typo and line up everything I say without it. Calling it my LLM's post just brushes aside everything I said without answering any of it.

So this will be my last reply on the subject. That is not me refusing to listen to other perspectives. I have listened, and I have given my reasons, I just have other things which need my time.

Still at "Testing Please Wait..." at 40 minutes.

coonsgm wrote: 09 Nov 2026 14:57 Still at "Testing Please Wait..." at 40 minutes.

Thanks Greg. Please do not run test 3 again for now, just power off.

Looking at all your results together, it looks like the PLD is never seeing address line A24 go high. That would make the TT-RAM at $01020000 look like ST RAM at $00020000, which is exactly what test 1 showed, and test 3 would then end up writing over ST RAM and the program itself, which is why it locked up. Everything else that worked happens to have A24 low anyway, including the TOS copy, which is why that passes.

On the PLD, A24 is pin 113, and pin 114 right next to it is GND, so a solder bridge between those two would cause exactly this. With pin 1 at the top left, pin 113 should be on the top edge, the 5th pin in from the right-hand corner. Could you have a close look there with a magnifier, and also check the A24 connection back to the CPU?

Those two pins are shorted, just measured.

Success