Repairing an old 520STm

Troubles with your machine? Just want to speak about the latest improvements? This is the place!

Moderators: Mug UK, Zorro 2, Greenious, spiny, Moderator Team

SteveBagley
Captain Atari
Captain Atari
Posts: 176
Joined: Mon Jan 21, 2013 9:31 am

Repairing an old 520STm

Postby SteveBagley » Tue Jan 13, 2015 12:24 pm

I mentioned this briefly in exxos's speed booster thread but I am trying to repair an old STm I bought off eBay a couple of years ago.

The machine had obviously been in the attic for a long time and the power connector and modulator where heavily rusted, so I can removed them and connected it to an ATX psu to see if It would boot. It didn't (I had it hooked up to a mono monitor), so I left it and used the motherboard for demonstration purposes in lectures (and the occasional appearance on the YouTube channel Computerphile).

However, I decided to try again to get the machine working the other day and so hooked up a logic analyzer over the CPU. To my surprise, the machine was attempting to boot fine -- I could see the CPU access ROM and get the start address etc., and by analysing the shifter even set the palette. I also noticed that HSYNC stayed around 15kHz -- which explained why I wasn't seeing anything on the mono monitor.

I could also see some Bus errors firing (normal during TOS boot) but then the CPU asserted HALT and the machine freezes (presumably early enough that the computer isn't moved into hi-res).

Hooking up a colour monitor, I get this pattern pretty much repeatably on screen eventually (occasionally there might be a variation in lower part as if the image was shifted if I reset and it starts on a green and purple screen from a power on -- although not an immediate power-on).

Image

I'm wondering if this is a RAM problem. I've ruled out the ROMs and SHIFTER by switching them into a good STm where they work fine and will do the same with the MMU and GLUE when my PLCC extractor arrives (i've already reseated them to no effect).

I guess I ought to obtain a diagnostic cart as well and see if that reveals anything.

Grateful for any advice, but I'll also update this with any progress.

Steve

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: Repairing an old 520STm

Postby exxos » Tue Jan 13, 2015 1:04 pm

If its not the MMU or GLUE then there is only RAM or the CPU left. If you have a small metal screwdriver you can lever out the MMU & GLUE. I gave up with IC extractors, probably due to them being cheap ones as the ends are so soft they just bend and it just puts a gash over the chip. I just use a small screwdriver and ease it up these days. If done gently it won't break the corners off the socket.

Problem with RAM issues, is so many chips to chop and change. IIRC the ST will boot with 256K RAM, maybe even 128K. So you can chop some chips out higher in the RAM map. Or cut the MAD lines and ground them on the RAM to isolate some chips. If you need some chips I have loads pulled from STFMs.

If you haven't already, just scope the RAM data and address lines, see if any of them are not pulsing. Also if you have 1MB fitted, for some reason I have found some ST MMU's do not work above 512K. I don't know if I was just unlucky with MMUs that day, or the very early MMU's did not support more than 512K RAM. IIRC I had similar issues with 1MB to 4MB also. Though I never saw many ST's to prove it either way.
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

User avatar
troed
Atari God
Atari God
Posts: 1438
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Repairing an old 520STm

Postby troed » Tue Jan 13, 2015 1:46 pm

SteveBagley wrote:Hooking up a colour monitor, I get this pattern pretty much repeatably on screen eventually (occasionally there might be a variation in lower part as if the image was shifted if I reset and it starts on a green and purple screen from a power on -- although not an immediate power-on).


It's a very strange pattern. It's apparently 40 bytes in length (repeats four times over a 160 byte scanline) which makes it difficult to attribute to physical memory issues IMHO. It also goes from (close to) 0x007 to 0x700. Can't see what would create that.

Sorry - no real insight - I just find it very odd.

I wonder what TOS clear screen code looks like. A movem.l d0-d7/a0-a1,(a2)+ in loop would be 40 bytes and if the _source_ for the registers would be memory (not unusual, I have dcb.l 0,16 in my code that I use as a clear buffer sometimes) would be corrupted I guess you could get a pattern like that. A bit far-fetched though.

/Troed

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: Repairing an old 520STm

Postby exxos » Tue Jan 13, 2015 2:00 pm

troed wrote:It's a very strange pattern. It's apparently 40 bytes in length (repeats four times over a 160 byte scanline) which makes it difficult to attribute to physical memory issues IMHO. It also goes from (close to) 0x007 to 0x700. Can't see what would create that.
/Troed


:lol: Yeah there is a pattern, I wasn't looking "wide enough" to spot it, Though, I was just thinking, how often can you mention a pattern on a corrupted video screen without being committed 8)
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

SteveBagley
Captain Atari
Captain Atari
Posts: 176
Joined: Mon Jan 21, 2013 9:31 am

Re: Repairing an old 520STm

Postby SteveBagley » Tue Jan 13, 2015 3:07 pm

Tried this ST's GLUE and MMU in another machine which worked fine so I think we can rule them out.

Had a look at MAD0-7 in the analyser -- looked fine. Put the analyser across the MMU's RDAT,WDAT and LATCH as well as ROM0,1,2 .If you look at these traces it stops from being primarily ROM2 to primarily RDAT/WDAT which I suspect is a series of a bus errors (writes 7 words to the stack), followed by another exception (writes 3 words to the stack). 10 words is 20 bytes which may well explain the pattern on screen…

Image

So my suspicion is there's probably something wrong with the RAM somewhere -- although given the stability of the screen image, I suspect it is in the lower RAM locations. I've some 256k 30-pin SIMMs lying around and an old Laserwriter motherboard with some spare 30-pin simm sockets on it, so I'll give that a whirl.

Steve

SteveBagley
Captain Atari
Captain Atari
Posts: 176
Joined: Mon Jan 21, 2013 9:31 am

Re: Repairing an old 520STm

Postby SteveBagley » Tue Jan 13, 2015 3:10 pm

exxos wrote::lol: Yeah there is a pattern, I wasn't looking "wide enough" to spot it, Though, I was just thinking, how often can you mention a pattern on a corrupted video screen without being committed 8)


My first thought was to try and decode it back to words…

Steve
(who once had to debug some software by beeping a pointer value out of the speaker bit by bit since anything else we tried to debug it crashed!)

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: Repairing an old 520STm

Postby exxos » Tue Jan 13, 2015 3:16 pm

SteveBagley wrote:Tried this ST's GLUE and MMU in another machine which worked fine so I think we can rule them out.

Had a look at MAD0-7 in the analyser -- looked fine. Put the analyser across the MMU's RDAT,WDAT and LATCH as well as ROM0,1,2 .If you look at these traces it stops from being primarily ROM2 to primarily RDAT/WDAT which I suspect is a series of a bus errors (writes 7 words to the stack), followed by another exception (writes 3 words to the stack). 10 words is 20 bytes which may well explain the pattern on screen…

So my suspicion is there's probably something wrong with the RAM somewhere -- although given the stability of the screen image, I suspect it is in the lower RAM locations. I've some 256k 30-pin SIMMs lying around and an old Laserwriter motherboard with some spare 30-pin simm sockets on it, so I'll give that a whirl.

Steve


Strange that /AS simply stops dead for a long time. Have you tried changing the ROM's ? Assume the CPU simply stops running instructions at some point causing a time out (bus error).
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

SteveBagley
Captain Atari
Captain Atari
Posts: 176
Joined: Mon Jan 21, 2013 9:31 am

Re: Repairing an old 520STm

Postby SteveBagley » Tue Jan 13, 2015 3:32 pm

exxos wrote:Strange that /AS simply stops dead for a long time. Have you tried changing the ROM's ? Assume the CPU simply stops running instructions at some point causing a time out (bus error).


That's normal -- GLUE waits 64 cycles for DTACK to be asserted (or rather AS to be unasserted, according to Suska's VHDL) before it generates a bus error by asserting /BERR, AS is asserted for 8.29us which is a shade over 64 cycles.

ROMs are actually from the one that works at the moment. It ends up in a repeated Bus Error, some other error cycle, then HALTs the CPU (I suspect it fills the stack and overwrites the exception vector and causes a double bus error).

TOS deliberately causes a Bus error early in the start up code so I think that's what I'm seeing here -- it's just going crazy rather than continuing to run the TOS code.

Steve

User avatar
exxos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4933
Joined: Fri Mar 28, 2003 8:36 pm
Location: England
Contact:

Re: Repairing an old 520STm

Postby exxos » Tue Jan 13, 2015 4:05 pm

I guess the only thing left is to start changing the lower DRAM's. It is odd that the shifter outputs colours. normally when I get ram problems its vertical black lines down the screen. Number of black lines can be related to number of problem data lines. I think address errors can cause the problems like yours, though not totally sure.

You could also check with a meter that all the address and data lines from the RAM are actually connected together. Might be a short or a broken PCB track somewhere. does the board look like its been tampered with on the underside ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - various clutter

http://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
http://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.
http://ataristeven.exxoshost.co.uk/Steem.htm Latest Steem Emulator

User avatar
paul92706
Atari God
Atari God
Posts: 1469
Joined: Mon Apr 25, 2011 4:28 am
Location: Orange, CA

Re: Repairing an old 520STm

Postby paul92706 » Wed Jan 14, 2015 8:05 pm

exxos wrote:
SteveBagley wrote:Tried this ST's GLUE and MMU in another machine which worked fine so I think we can rule them out.

Had a look at MAD0-7 in the analyser -- looked fine. Put the analyser across the MMU's RDAT,WDAT and LATCH as well as ROM0,1,2 .If you look at these traces it stops from being primarily ROM2 to primarily RDAT/WDAT which I suspect is a series of a bus errors (writes 7 words to the stack), followed by another exception (writes 3 words to the stack). 10 words is 20 bytes which may well explain the pattern on screen…

So my suspicion is there's probably something wrong with the RAM somewhere -- although given the stability of the screen image, I suspect it is in the lower RAM locations. I've some 256k 30-pin SIMMs lying around and an old Laserwriter motherboard with some spare 30-pin simm sockets on it, so I'll give that a whirl.

Steve


Strange that /AS simply stops dead for a long time. Have you tried changing the ROM's ? Assume the CPU simply stops running instructions at some point causing a time out (bus error).

i also noticed that /AS stop dead telling us there is no valid address's being floated, and the ROM has also stopped being enabled (stating Read/Write cycle has stopped), also did you notice when /AS was deasserted that's when the Bus error occurs?
Last edited by paul92706 on Wed Jan 14, 2015 8:15 pm, edited 1 time in total.
Atari Falcon CT60/CTPCI 14MB+ 512mb ATI9250 + NetUSBee
Atari Falcon030 CF 4gb + NetUSBee+ 14MB Ram
Atari TT030 2meg STRAM/16meg TTRAM + Nova Adaptor +Maxtor SCSI HD + DaynaPort Pocket SCSI

User avatar
paul92706
Atari God
Atari God
Posts: 1469
Joined: Mon Apr 25, 2011 4:28 am
Location: Orange, CA

Re: Repairing an old 520STm

Postby paul92706 » Wed Jan 14, 2015 8:11 pm

SteveBagley wrote:
exxos wrote:Strange that /AS simply stops dead for a long time. Have you tried changing the ROM's ? Assume the CPU simply stops running instructions at some point causing a time out (bus error).


That's normal -- GLUE waits 64 cycles for DTACK to be asserted (or rather AS to be unasserted, according to Suska's VHDL) before it generates a bus error by asserting /BERR, AS is asserted for 8.29us which is a shade over 64 cycles.

ROMs are actually from the one that works at the moment. It ends up in a repeated Bus Error, some other error cycle, then HALTs the CPU (I suspect it fills the stack and overwrites the exception vector and causes a double bus error).

TOS deliberately causes a Bus error early in the start up code so I think that's what I'm seeing here -- it's just going crazy rather than continuing to run the TOS code.

Steve

hmmm, everytime the /AS is asserted means there is a new address being floated or making the address valid, and the /Dtack should be in that cycle, towards begining of State 7, well depends if its a Read or Write Cycle. To make it easier to decode, capture the /DTack
Atari Falcon CT60/CTPCI 14MB+ 512mb ATI9250 + NetUSBee
Atari Falcon030 CF 4gb + NetUSBee+ 14MB Ram
Atari TT030 2meg STRAM/16meg TTRAM + Nova Adaptor +Maxtor SCSI HD + DaynaPort Pocket SCSI

SteveBagley
Captain Atari
Captain Atari
Posts: 176
Joined: Mon Jan 21, 2013 9:31 am

Re: Repairing an old 520STm

Postby SteveBagley » Wed Jan 14, 2015 11:43 pm

paul92706 wrote:hmmm, everytime the /AS is asserted means there is a new address being floated or making the address valid, and the /Dtack should be in that cycle, towards begining of State 7, well depends if its a Read or Write Cycle. To make it easier to decode, capture the /DTack


I've done that previously and DTACK functions as expected -- I' captured AS, DTACK and BERR and it looked like I expected from reading the manual (and identical to traces I made on a MEGA before christmas). I've also captured CMPCS and some of the data lines on the SHIFTER, and saw TOS set the palette so I'm fairly certain that the CPU is getting to the point where TOS uses a bus error to finish the configuration of memory.

Steve

User avatar
paul92706
Atari God
Atari God
Posts: 1469
Joined: Mon Apr 25, 2011 4:28 am
Location: Orange, CA

Re: Repairing an old 520STm

Postby paul92706 » Thu Jan 15, 2015 4:37 am

SteveBagley wrote:
paul92706 wrote:hmmm, everytime the /AS is asserted means there is a new address being floated or making the address valid, and the /Dtack should be in that cycle, towards begining of State 7, well depends if its a Read or Write Cycle. To make it easier to decode, capture the /DTack


I've done that previously and DTACK functions as expected -- I' captured AS, DTACK and BERR and it looked like I expected from reading the manual (and identical to traces I made on a MEGA before christmas). I've also captured CMPCS and some of the data lines on the SHIFTER, and saw TOS set the palette so I'm fairly certain that the CPU is getting to the point where TOS uses a bus error to finish the configuration of memory.

Steve

Hmmm, strange how TOS uses a bus error to finish the config of memory, maybe something is going on in the memory, like exxos says maybe a short/broken trace?? a few months ago i had a major problem with my Falcon motherboard and i debugged it with a logic analyzer and pretty much analyzed it to where it fetched and executed data from ROM chip, but i never seen where TOS used a bus error to finish config of memory, then again they are both different systems, but the Architect should be the same. I would most definitley get a good microscope and start looking around for broken traces or short circuits or broken solder joints, also do continuity test on all address/data traces. Also by looking at your picture above, of your monitor displaying those vertical lines of color, looks like the outter white boarder is correct, looks like the inner square is wrong, hmmm i am thinking ROM or Shifter, but you mentioned you checked those IC's already, do a trace and continuity check to make sure those signals are going to there destinations on all those signals on both ROM and Shifter. hope you find the bugg!
Atari Falcon CT60/CTPCI 14MB+ 512mb ATI9250 + NetUSBee
Atari Falcon030 CF 4gb + NetUSBee+ 14MB Ram
Atari TT030 2meg STRAM/16meg TTRAM + Nova Adaptor +Maxtor SCSI HD + DaynaPort Pocket SCSI

User avatar
Arne
Atari Super Hero
Atari Super Hero
Posts: 507
Joined: Thu Nov 01, 2007 10:01 am

Re: Repairing an old 520STm

Postby Arne » Thu Jan 15, 2015 8:19 am

paul92706 wrote:(...) but i never seen where TOS used a bus error to finish config of memory, then again they are both different systems, but the Architect should be the same.

Using a bus-error for detecting RAM's top is a pretty intelligent solution. Due to it the 3MB solutions work without problems. F030 use the MEMSIZE pins. I tried to fake 8MB ST-RAM with a 14MB card and some VHDL logic. Seems there is no other chance than patching TOS 4.x. And even then I am not sure if Falcon's MCU may still generate refresh signals for RAM > 8MB.

User avatar
stimpy
Captain Atari
Captain Atari
Posts: 305
Joined: Mon Aug 22, 2005 2:47 pm
Location: Somerset, UK
Contact:

Re: Repairing an old 520STm

Postby stimpy » Thu Jan 15, 2015 12:06 pm

Have you got the copy of ST Internals with the TOS listing in the back? I spent many hours single stepping hardware through that code, and yes it uses BERR to work out the memory size. The problem could be somewhere else, can you grab the address before the crash and inspect TOS code to see what it was doing?
Netus-Bee,Repairs,Upgrades,EtherNEC,Eiffel

SteveBagley
Captain Atari
Captain Atari
Posts: 176
Joined: Mon Jan 21, 2013 9:31 am

Re: Repairing an old 520STm

Postby SteveBagley » Thu Jan 15, 2015 2:19 pm

stimpy wrote:Have you got the copy of ST Internals with the TOS listing in the back? I spent many hours single stepping hardware through that code, and yes it uses BERR to work out the memory size.


That's exactly what I'm using as reference :) (well a PDF of it as my paper copy is long gone now :( ).

The problem could be somewhere else, can you grab the address before the crash and inspect TOS code to see what it was doing?


I know it sets the palette correctly, since I captured the shifter at one point. I can't really capture anything else since I only have 8-inputs to the analyser.

I'm fairly certain now there's a bit error in the first 128k of memory, since looking through the full capture before the bus error, alongside TOS seems to show it writing the 42 words into memory, and then reading them back but failing. At which point it, subtracts $20000 from A0 (which contains $20000, effectively clearing A0). It then attempts to do a movem.l d0-d3,-(a0) which of course fails, in a bus error. Just need to find what's not working…

Steve

SteveBagley
Captain Atari
Captain Atari
Posts: 176
Joined: Mon Jan 21, 2013 9:31 am

Re: Repairing an old 520STm

Postby SteveBagley » Fri Jan 16, 2015 7:01 pm

Progress -- I have seen the desktop…

Briefly as it reset and a lot of bombs most of the time.

I desoldered the RAM chips yesterday from the motherboard and today attached two 512k SIMMS (which have been lieing around the house since I upgraded my STe in the 1990s!) using some SIMMS sockets I grabbed off an old LaserWriter motherboard, and a lot of ribbon cable.

The machine boots now, and pressing a key causes a beep as you'd expect, but it always ends up bombing out. I suspect this is down to my SIMM adapter since it is Heath Robinson in the extreme, and/or the SIMMS.

I also managed to short the inductor on the memory power supply which produce some nice smoke so I'll need to replace that.

Steve


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests