REV 5 BOM and Build/Install procedure

[Badwolf]

Hi @Elethiomel,

Sorry -- I missed a few of your post here but you seem to have covered off most of what I was going to suggest.

1. The diagnostic cart is *really* early in the ST's development. It likely only supports stock 68k chips. After all TOS 1.x can't run with an '030, so why would we expect the diagnostics to? Words I've heard that don't understand are I "stack frame size" around something to do with interrupts.

2. Surface mounted PLCC sockets? Yep, real PITA. You've done the right thing with punching out the floor. Need to go for a very fine tip when soldering them, which means drag is out. Remember to stick the floor back in with a bit of double sided tape. It's important for keeping the chip at the right height and letting you get underneath it at the corners to extract it again.

3. Programming/reading the ROM. My Falcon guide may of interest. Same chip but with a single 512k image rather that two 256k ones: https://www.exxosforum.co.uk/forum/viewt ... =27&t=4271 I think Troed's guide was the one I followed when hacking my adapter. More recent versions of the Minipro accessories have jumpers you can move to switch between ROM and MCU modes.

4. Your integer division score seems a bit low. I know you don't have the AltRAM installed at that point, but still, you've got the CPU cache on. What oscillator do you have in there & do you get a different figure after running FASTRAM.PRG?

Cheers,

BW.

[Elethiomel]

Hi @Elethiomel,

Sorry -- I missed a few of your post here but you seem to have covered off most of what I was going to suggest.

1. The diagnostic cart is *really* early in the ST's development. It likely only supports stock 68k chips. After all TOS 1.x can't run with an '030, so why would we expect the diagnostics to? Words I've heard that don't understand are I "stack frame size" around something to do with interrupts.

Thanks for checking in! This makes good sense.

2. Surface mounted PLCC sockets? Yep, real PITA. You've done the right thing with punching out the floor. Need to go for a very fine tip when soldering them, which means drag is out. Remember to stick the floor back in with a bit of double sided tape. It's important for keeping the chip at the right height and letting you get underneath it at the corners to extract it again.

This is a great tip. I have definitely had issues extracting the ROM! Luckily I still have the punched out part.

3. Programming/reading the ROM. My Falcon guide may of interest. Same chip but with a single 512k image rather that two 256k ones: https://www.exxosforum.co.uk/forum/viewt ... =27&t=4271 I think Troed's guide was the one I followed when hacking my adapter. More recent versions of the Minipro accessories have jumpers you can move to switch between ROM and MCU modes.

This was very enlightening, thanks. I'm kinda new to all of this and hadn't realised the that the AT27C4096 was a write once chip
I prepared an image by concatenating tos2.06 and emutos and tried to overwrite it with the existing tos2.06 and 1.62 on the ROM. It "wrote" and verified up to 0x2000, but failed verifying byte 0x2001. The reason why is very obvious to me now . My minipro clone is an XGecu and didn't have the DIL to PLCC adaptor with the jumpers. I just used some resistor legs jammed carefully behind the PLCC socket and it seemed to do the trick.

I'll order a few HN27C4096s and AT27C4096s and a cheap eraser for experimentation.

4. Your integer division score seems a bit low. I know you don't have the AltRAM installed at that point, but still, you've got the CPU cache on. What oscillator do you have in there & do you get a different figure after running FASTRAM.PRG?

Cheers,

BW.

The oscillator appears to be soldered on to the underside of the ST536 as part of the manufacturing process. I'm assuming the various birdseed surrounding it sets its operating frequency. I'll see if I can find a point on the board while it's running with something that looks like a clock.

20220331_205602.jpg (334.96 KiB) Viewed 4378 times

This board seems to be having ACSI issues as it won't boot my CosmosEX. The floppy emulation is working. I'll try get FASTRAM.PRG running on an emulated floppy later tonight.

My current main issue is that in removing the now superfluous onboard RAM and caps, I seem to have buggered something up. My ST is now only detecting 512KB instead of 4MB. I've probably bridged something in the RAM area or misunderstood the install instructions.

[Elethiomel]

4MB is working again. Using copious amounts of flux, and meters of desoldering braid, I cleaned up the old RAM area. I got a little bit heavy handed with the SMT RAM IC removal and definitely lifted a pad or two. I think one of those was touching a neighbouring pad.

The CosmosEx boots AOK via the virtual HDD when the original ROMs and 68000 CPU are fitted. With the original ROMs removed and the ST536 in place, no boot, but I do get the desktop. All of my software is on the CosmosEx and I don't have a PC compatible floppy drive anywhere. If anyone could recommend a USB one that would work writing ST images from Linux or Win10 I'd appreciate it.

I really, really need to do the mandatory fixes on this board now that I've got it mostly working and there's obvious issues Grabbed some more goodies from the Exxos Store including the resistor pack needed for the DMA pullup fixes, a 4700uF cap replacement kit and some various other bits and bobs.

I have a third ST in addition to this one and my 16MHz/4MB/RGB2HDMI project. I may pull the CPU, pop in a socket and try the accelerator there to see if there's any difference in regards to the ACSI port working. It does have a damaged floppy connector on the board though where someone ripped off the cable, but I might be able to work around that. I was going to use that system as a donor for a H5 project somewhere down the line, but it might serve some use sooner.

[Elethiomel]

I was previously using mcopy to copy programs to blank ST floppy images and uploading them to the CosmosEx floppy emulator. I was getting some issues with the disk not reading. Switching over to mounting the floppy images via loopback on Linux and just copying the programs I need in there seems to work a lot better.

[derkom]

The CosmosEx boots AOK via the virtual HDD when the original ROMs and 68000 CPU are fitted. With the original ROMs removed and the ST536 in place, no boot, but I do get the desktop.

I ran into the same with my Stacy project. CosmosEx boots just fine in 68000 mode, but isn't detected on the ACSI bus in 68030 mode. I never got around to investigating if this was a problem specific to the CosmosEx, or if it was a general ACSI problem.

[Badwolf]

The oscillator appears to be soldered on to the underside of the ST536 as part of the manufacturing process. I'm assuming the various birdseed surrounding it sets its operating frequency. I'll see if I can find a point on the board while it's running with something that looks like a clock.

Aha. In that case I assume the 536 disables the instruction cache on all STRAM accesses. That would probably explain it. Doubtlessby better with FASTRAM loaded (assumping GB6 is set to load to AltRAM).

Cheers,

BW.

[Elethiomel]

The CosmosEx boots AOK via the virtual HDD when the original ROMs and 68000 CPU are fitted. With the original ROMs removed and the ST536 in place, no boot, but I do get the desktop.

I ran into the same with my Stacy project. CosmosEx boots just fine in 68000 mode, but isn't detected on the ACSI bus in 68030 mode. I never got around to investigating if this was a problem specific to the CosmosEx, or if it was a general ACSI problem.

Ouch. OK, It looks like no IDE and no ACSI currently. I have an STM32 ordered because I saw a great video on STM2ASCI on BW's channel about it. I might see if I can bodge something together that works on my other system and then try it on the 536 to see if the problem is isolated to the CosmosEx.

[Elethiomel]

The oscillator appears to be soldered on to the underside of the ST536 as part of the manufacturing process. I'm assuming the various birdseed surrounding it sets its operating frequency. I'll see if I can find a point on the board while it's running with something that looks like a clock.

Aha. In that case I assume the 536 disables the instruction cache on all STRAM accesses. That would probably explain it. Doubtlessby better with FASTRAM loaded (assumping GB6 is set to load to AltRAM).

Cheers,

BW.

Here's where I am on the AltRAM side of things. I grabbed FASTRAM.PRG from https://github.com/agranlund/tftools/tr ... r/Releases, popped it in the AUTO folder of an ST image mounted via loopback and uploaded it to the CosmosEX.

I get a flowery D logo painted on the screen. Then the memory test runs and I finally get "Fastram v1.8 active". The system then hangs.

20220401_192303.jpg (437.84 KiB) Viewed 4309 times

I'm using the firmware from Exxos' "The LaST Upgrade Part 39 - TF536 ST EDITION". It's "REV 3 & 5 ALPHA FIRMWARE VST2A 144XL (IDE not supported, blitter will malfunction) - H4 / STF" https://www.exxosforum.co.uk/atari/last/ ... 4XL_H4.zip I assume this is the latest and greatest? The RAM I have is also the AS4C16M16SA-6TCN listed on that page.

In the DiagROM I get this when I do a Large Fast scan of fastmem-areas

Code: Select all

Scanning for memory on all fastmem-areas (no autoconfig mem will be scanned)


Checking memory from $04000000 to $0FFFFFFF - Press any key/mousebutton to stop

Checking Address: $04FFFC04      ---   Running in Fast-Scan mode!
Only one longword every 1k block is tested and no errors reported
Result can be aproximate! No shadowmem tests! Used to scan for memoryareas
Dead block = ALL bits checked failed, most likly no mem at all
Bad block = Some bits works, most likly bad memory with biterrors

Checked memory: 16384KB   Usable memory: 16384KB    NONUsable memory: 0KB       
Good Block start at $04000000

BusError Detected---------------------------------------
Debugdata (Dump of CPU Registers D0-D7/A0-A7):
$00000000 $00000001 $31CC00C9 $00000000 $00000000 $00000000 $0FFFFFFF $00000000 
$00FAA894 $0FFFFFF7 $00FA20F6 $001EF14C $001EF18C $001EF148 $001EEE36 $001EEC9E 

That looks somewhat promising. It's getting through exactly 16MB of RAM before hitting a BUS error. Maybe I have a dodgy joint on one of the RAM pins?
Maybe an edit of the firmware to expect only 16MB of AltRAM would be a good idea for now? Speaking of which, does anyone have a link to the firmware sources for this board? I've only found a link to the binaries on the LaST upgrade page and the terriblefire github only seems to have binaries too.

[rubber_jonnie]

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

[Badwolf]

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.

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.

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.

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.

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