REV 3 - REV 5 - The beginning (ST536)

[exxos]

Bad news from my side. I think I destroyed my first ST536 proto not one time, but three times ...
What do you think, which pin is +5V at PWR2 connector ?

Why are you even using that header in the first place ? I don't think its even mentioned anywhere in the documents ? If it is, it was only there as a aux output to power a fan or something.

I tried the latest EPROM image (26.10.2025) and the CURRENT7,18 and 20 firmwares. I didn't try the 8MHz though. Everything the same.
There are two jumpers on the bottom side (SJ1+2), which I didn't set. What is the purpose of these ?

You need to set some solder jumpers on the STE536 ( dont think theres any on the ST536) , I am currently working on updated pages.. I hope will be uploaded later today.

[exxos]

Page updated

https://www.exxosforum.co.uk/atari/last/ST536/index.htm

[Miri]

Why are you even using that header in the first place ? I don't think its even mentioned anywhere in the documents ? If it is, it was only there as a aux output to power a fan or something.

I did not want to destroy my precious Mega ST4 by connecting a totally untested, unprogrammed(?) PCB to the CPU busses.
My ST still lives, so this is a kind of success

Next time I'll try the following:

Measure for a short on VCC-GND
Put the ST536 into a STFM
Turn the power on
If (Boom)
    Scream
else {
    Program firmware CURRENT20.jed
    Check the voltages and CPU clk and reset signals
    Turn the power off
    Insert 030 CPU + EPROM
    Turn the power on
    If (Boom)
        Scream
    else
        Insert ST536 in MEGA ST4 ...
}

Is this OK ?

[exxos]

Measure for a short on VCC-GND
...
Is this OK ?

Leave the CPU out for now. but when you program the PLD, make sure nothing on the PCB is getting really hot. If you connected power backwards at some point then you could have killed everything.

I would suggest power up via that header and make sure nothing is getting hot... Program the PLD then...

Capture.PNG (41.45 KiB) Viewed 148 times

You should also check you have 3.3V.. But if you can program the PLD, I would assume it has power..

11.PNG (81.4 KiB) Viewed 148 times

If all seems well, put CPU back in, try it on your MEGA ST.

But also you need to correctly program the ROM, some programmers byteswap.. So you could have it programmed "backwards". Also I noticed those Hitachi EPROMS make very bad connections in the PLCC socket.. Also don't forget you need to remove original ROMS..

If your MEGA had the blitter patch and you removed it, you need to fix the broken track under the CPU on bottom of MB.

Then all being well, you should be booting up really now..

[Miri]

But also you need to correctly program the ROM, some programmers byteswap.. So you could have it programmed "backwards". Also I noticed those Hitachi EPROMS make very bad connections in the PLCC socket.. Also don't forget you need to remove original ROMS..

If your MEGA had the blitter patch and you removed it, you need to fix the broken track under the CPU on bottom of MB.

Then all being well, you should be booting up really now..

Blitter patch was removed immediately (correctly), otherwise my TF536 wouldn't work like a charm
Nothing got overly hot. CPU and CPLD got slightly warm.

The byte order of the EPROM could be really an issue, but my settings seem to be right: (big-endian):

Endianess.jpg (50.92 KiB) Viewed 140 times

I checked the (main) 3.3V already a hundred times, but not the second 3.3V regulator (??) for the XO (which is not easily accessible).
If some critical part failed while reversing 5V I would expect that very regulator or the ABT16245A. The HC245s or the LVC08 are only related to the IDE port ...

Which other parts would short out a reversed +5V with a diode drop and thus could have been destroyed ?

The second damage I made is, that I a cracked PLCC-44 socket (Could already have happened during first insertion of the EPROM). The solder joints on it don't look very promising as well. Probably best to unsolder it and solder the EPROM directly on the PCB. I have a spare SMT PLCC socket at hand, but soldering these is Mehhhhh...

So your *.bin EPROM file doesn't have a weird byte order in it or has it ? I think it has, since it doesn't have any human readable string like "AUTO" inside ...

[Miri]

I think that should read "Document":

Document.jpg (8.22 KiB) Viewed 136 times

OK, one bug found, but that doesn't really explain why the ROM's CE is 3.3V all the time ...
I'll try to program a EPROM with reversed byte order with the EPROMMER setting to little-endian this evening ...

[exxos]

The byte order of the EPROM could be really an issue, but my settings seem to be right: (big-endian):

Yeah but if the file is swapped......

Which other parts would short out a reversed +5V with a diode drop and thus could have been destroyed ?

That's impossible to answer.. Probably all the silicon on 5V. Don't know about the 3.3V stuff.. maybe...

The second damage I made is, that I a cracked PLCC-44 socket (Could already have happened during first insertion of the EPROM). The solder joints on it don't look very promising as well. Probably best to unsolder it and solder the EPROM directly on the PCB. I have a spare SMT PLCC socket at hand, but soldering these is Mehhhhh...

This is actually why ROM_CE exists on the 536.. because if you have a DUALTOS board, you can drive CE from ROM_CE on the 536 and get around the broken socket problem.

If you have a known working DUALTOS ROM already, then you can read the byte order anyway.. Even so, original 206 will still at least get you to desktop..

Even the other way around, you can try the ST536 ROM in a dualtos board. My patched 206 will just complain it's wont run on a 68000.. but at least you know the byte order is correct then.

The SMT sockets are more fragile, but as long as you use a proper IC extractor and don't lever the chip out, then the socket shouldn't break.

[exxos]

I think that should read "Document":

It depends.. because my programmer and files are always swapped...

Capture.PNG (18.87 KiB) Viewed 116 times

0602 is TOS 0206 swapped!

That works for my programmer...

OK, one bug found, but that doesn't really explain why the ROM's CE is 3.3V all the time ...

No ROM access... no CPU running.. Bad ROM byte order, bad connection.. no programed PLD, or dead PLD.. could be lots of reasons..

[PhilC]

Lol ok well I've placed the order, please let Dawn know not to send it until you're ready with the st536.

Thanks, the stuff has arrived. I'll prepare the computers over the next couple of days and will give it a test.

[Miri]

That works for my programmer...

I checked again and first ROM I burned had the correct byte order, which means that the first proto is (still) dead. Whatsoever, obviously a third party is swapping the bytes back ...

I built up the second prototype now and it partially works.

- Boot from 2.06 freezes in several states, mostly during the TT RAM test. If I get to the desktop an opened floppy directory may show folders and files with wrong icon types. Folders can be opened, but files seem to contain garbage.

20251029_225118.jpg (302.51 KiB) Viewed 71 times

- Boot with EmuTOS "works" all the time. IDE seems to be entirely unproblematic. Floppy and ACSI read seem to work but I didn't dare to write a lot to them so far ... As you can see, there is no Blitter on the board ...

20251029_224856.jpg (77.66 KiB) Viewed 71 times

Interrestingly EmuTOS seems to work a tad more stable with mainboard ROMs still in place. In that configuration I had a few boot runs, where my NOVA/MACH32 combi worked nicely. In all other cases I get garbage and strange offsets between windows and mouse position. Interestingly, if the MACH32 initializes correctly, it works like a charm with no "pixel rot" or the like. I checked two of my 030 CPUs so far and they show absolutely same behaviour in the ST536 and TF536.
In order to rule the CPU finally out, I could extract the CPU from my DFB1X and try it as well.

20251030_000938.jpg (140.85 KiB) Viewed 71 times

Under EmuTOS GEMbench ran through in all circumstances and the measured performance seems to be reasonabe considering that ROM is not copied into TT RAM. My current hypothesis is, that code execution is bad/flaky within the TT RAM. Probably I need to check that in more detail next or try to get rid of these IMP chips in the board, or some of them ...

This is how I hope it will look soon (Here with TF536 and agranlund's 2xEmuTOS boot solution):

20251026_143941.jpg (140.46 KiB) Viewed 71 times