REV 5 BOM and Build/Install procedure

[Elethiomel]

BTW I have been reliably informed that the TF releases do not work on the ST536 board. Just passing the message along.

Thanks, that would make sense as Exxos would have needed to add decoding logic for the onboard ROM etc. I'll keep poking around the forum to see if there's a link to a source release for the ST version.

Also, I've found a fascinating doc on Floppy and Hard Disk Programming on the ST that I'm looking through right now. http://info-coach.fr/atari/documents/_m ... amming.pdf. It might be useful in some form for figuring out any HD issues with the board and ACSI/CosmosEX.

[stephen_usher]

As far as I'm aware @agranlund never released the source for the ST version.

[Elethiomel]

I'm pretty sure that 'D' comes from the boot sector of your emulated floppy. I don't recall if it's a cracking team's logo or if it's PPera's logo. Anyway, that probably shouldn't happen.

Makes sense. I grabbed the blank floppy images from his page!

The freeze isn't good.

You've done the right thing trying to test the memory, but I think DiagROM might be a bit too close to its Amiga original there. TT-RAM starts at 0x01000000 rather than 0x04000000. If you've 64MB (I suspect you have) your RAM will stop at 0x05000000.

Whoops, I googled "Atari altram address", got this as the first link https://www.atari-forum.com/viewtopic.p ... 1&start=25 and didn't read it properly as it coincided with the default address in DiagROM

0x05000000 - 0x04000000 is 16MB. So it's testing the top 16MB of your memory.

Your best bet is to use Christian's YAART(TT) [yet another Atari RAM tester, TT edition]. If you've got the Exxos multi diagnostic cart, you've probably got access to it already.

First, boot to the desktop but don't run FASTRAM.PRG. Run YAARTTT, press 'M' when prompted for 'S' or 'T' (M is a secret memory test option).

At this point it'll ask for a start end end address. That's 0x01000000 and 0x05000000, as above.

YAARTTT will test all your AltRAM and report errors. If errors start scrolling up the screen, hold SHIFT to pause in order to read them.

If there are no errors, it should loop infinitely with slow, easy to read output.

BW.

I do indeed have Exxos' wonderful multi diagnostic cart! Using the secret memory test option shows immediate issues. Here's the first 4 bytes of AltRAM. I get the same problems with 0x04000000 0x0400004.

20220401_230601.jpg (484.65 KiB) Viewed 2075 times

The bit error patterns are not consistent, but it's always the top byte. I'm thinking one of the 8bit 2.5/3.3V buffers may be dead/shorted/damaged ?

PS, you can run FASTRAM.PRG from the desktop too. TOS then doesn't try to use the AltRAM, which can make things easier to test.

Good to know thanks!

PPS, Unfortunately I don't think the TF536 Firmware is open source.

Maybe if I get far enough in getting this system working the authors might be interested in sharing it with me so I can look at getting IDE working or fixing ACSI. That's another project for the future

[Badwolf]

The bit error patterns are not consistent, but it's always the top byte. I'm thinking one of the 8bit 2.5/3.3V buffers may be dead/shorted/damaged ?

That's very strange. You're right, it's always the top byte of the lower word and it *sometimes* works.

Could be the buffer. Could be some pins on the lower word chip. Most obvious one I can think of is either the output enable line on the buffer chip or the apropriate DQM line on the RAM chip.

BW.

[Elethiomel]

Success! It was the RAM chips. Under close inspection under a microscope they really didn't have enough solder on some of the pins. I know I removed a bridge on each chip and probably soaked up too much. Some more flux, more solder and careful slow drag work got me much wetter looking pins. YAART(TT) now shows no issues!

I then grabbed MAPROME.prog, stuck it in auto, found a copy of Gembench 6.31, set the flags and booted it up...

20220402_160351.jpg (542.54 KiB) Viewed 2031 times

There's the integer division speed I've been looking forward to!

Now I'm going to play with with EmuTOS source a bit and a cartridge and poke around at ACSI driver using both a stock system and the 536.

[DoG]

Looks good. Congrats!

[PhilC]

Looks pretty good to me

[Elethiomel]

Thanks guys and thanks for the help and support everyone, especially BW!

Today I:

• soldered on the IDE header
• did some reading on the IDE and ASCI protocols including reading through some parts of the EmuTOS source
• removed the modulator (finally transforming my 520STFM in to a 4096/65536-STF030 )
• upgraded the Mitsumi SR98 PSU with Exxos' kit
• soldered some wires on to an SD to microSD card adaptor for an acsi2stm build

Tomorrow I'll probably do the bus pull-up resistors and install the Exxos 4700uF cap replacement.

[Elethiomel]

4700uF cap replacement is in and so is the NEW Exxos ST536 firmware which is looking promising! I can now list files from my UltraSatan, but running some things causes a hard lockup.

@Badwolf This system (PAL, ST536, 50MHz, Alt-RAM, TOS 2.06) does a whopping 2940 frames on FrontBench! Not bad for a system with an 8MHz bus for the graphics side of things!

For comparison, my other systems:

(PAL, 68000, 8MHz, ST-RAM, TOS 1.04) : 873 frames
(PAL, 68000, 16MHz (Exxos 1.5 booster), ST-RAM, TOS 1.04) : 1015 frames

[Badwolf]

@Badwolf This system (PAL, ST536, 50MHz, Alt-RAM, TOS 2.06) does a whopping 2940 frames on FrontBench! Not bad for a system with an 8MHz bus for the graphics side of things!

Excellent results.

I did a hack to FrontBench to do all the screen composition in TT-RAM and blit it to ST-RAM at the end as an experiment. It was slower on the Falcon than just using the STRAM for composition, but I wonder if it might be quicker on an ST536 where the bus is slower again?

Could be close.

BW