MegaST2 with constant resets

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

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

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

MegaST2 with constant resets

Postby Arne » Sun Mar 22, 2020 11:31 am

Hi all,

I got a little problem with a Mega ST2. Its mainboard got additional sockets for PSG, MFP, FDC, 74LS373/244 on MemoryDataBus and the upper (unpopulated) RAM bank.
Right now it is booting fom the two TOS 1.02 ROMs but stays in a reset loop. On ST-High it displays a white screen and as soon as the FDD is accessed it reboots.
With the help of a LA I have been able to track down the code line this reset happens.

Image

Code: Select all

FC0B50  6102                L0067:BSR.S     2(PC)                L0068
FC0B52  4E71                      NOP                           
FC0B54  23DF000003C4        L0068:MOVE.L    (A7)+,$3C4.L       
FC0B5A  48F9FFFF00000384          MOVEM.L   A0-A7/D0-D7,$384.L 
FC0B62  4E68                      MOVE      USP,A0             
FC0B64  23C8000003C8              MOVE.L    A0,$3C8.L           
FC0B6A  700F                      MOVEQ     #$F,D0             
FC0B6C  41F9000003CC              LEA       $3CC.L,A0           
FC0B72  224F                      MOVEA.L   A7,A1               
FC0B74  30D9                L0069:MOVE.W    (A1)+,(A0)+         
FC0B76  51C8FFFC                  DBF       D0,-4(PC)            L0069
FC0B7A  23FC1234567800000380      MOVE.L    #$12345678,$380.L   
FC0B84  7200                      MOVEQ     #0,D1               
FC0B86  1239000003C4              MOVE.B    $3C4.L,D1           
FC0B8C  5341                      SUBQ.W    #1,D1               
FC0B8E  6116                      BSR.S     22(PC)               L006A
FC0B90  23FC0000093A000004A2      MOVE.L    #$93A,$4A2.L       
FC0B9A  3F3C0001                  MOVE.W    #1,-(A7)           
FC0B9E  42A7                      CLR.L     -(A7)               
FC0BA0  4E41                      TRAP      #1
FC0BA2  6000F48C                  BRA       -2932(PC)            L0004
FC0BA6  1E39FFFF8260        L006A:MOVE.B    $FFFF8260.L,D7     
FC0BAC  CE7C0003                  AND.W     #3,D7               
FC0BB0  DE47                      ADD.W     D7,D7               
FC0BB2  4280                      CLR.L     D0                 
FC0BB4  1039FFFF8201              MOVE.B    $FFFF8201.L,D0     
FC0BBA  E148                      LSL.W     #8,D0               
FC0BBC  1039FFFF8203              MOVE.B    $FFFF8203.L,D0     
FC0BC2  E188                      LSL.L     #8,D0               
FC0BC4  2040                      MOVEA.L   D0,A0               
FC0BC6  D0FB702C                  ADDA.W    44(PC,D7.W),A0       L006E
FC0BCA  43F900FC0DFA              LEA       $FC0DFA,A1         
FC0BD0  3C3C000F                  MOVE.W    #$F,D6             
FC0BD4  3401                L006B:MOVE.W    D1,D2               
FC0BD6  2448                      MOVEA.L   A0,A2               
FC0BD8  3A3B7022            L006C:MOVE.W    34(PC,D7.W),D5       L006F
FC0BDC  30D1                L006D:MOVE.W    (A1),(A0)+         
FC0BDE  51CDFFFC                  DBF       D5,-4(PC)            L006D
FC0BE2  51CAFFF4                  DBF       D2,-12(PC)           L006C
FC0BE6  5449                      ADDQ.W    #2,A1               
FC0BE8  D4FB701A                  ADDA.W    26(PC,D7.W),A2       L0070
FC0BEC  204A                      MOVEA.L   A2,A0               
FC0BEE  51CEFFE4                  DBF       D6,-28(PC)           L006B
FC0BF2  4E75                      RTS                           


It is the BRA at location FC0BA2 which branches right to the start of TOS which is

Code: Select all

FC0030  46FC2700            L0004:MOVE      #$2700,SR
FC0034  4E70                      RESET


And there the reset happens.
As far as I can interpret the code above the CPU saves the current CPU state in the so called processor state save area at $380..$3EA.
But due to the reset I cannot inspect it.

Any idea how to track down the source of that error?

Thanks, Arne
Image

czietz
Hardware Guru
Hardware Guru
Posts: 1133
Joined: Tue May 24, 2016 6:47 pm

Re: MegaST2 with constant resets

Postby czietz » Sun Mar 22, 2020 11:42 am

Does your logic analyzer have enough sample memory to capture what happens before you end up in the routine that saves the crash dump to memory? What your seeing is the handling of an unexpected exception, e.g., bus error, address error, illegal instruction. For example, I once helped repair an ST with 6 ROMs, where one ROM was defective. Therefore, as soon as TOS first called a function in that ROM at boot, it crashed with an illegal instruction. This fault essentially looked like what you're currently seeing.

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

Re: MegaST2 with constant resets

Postby Arne » Sun Mar 22, 2020 12:11 pm

It's got 2GBit for all 32 channels combined. But due to the trap #1 I am afraid this will lead me to some "unexplored country" :wink:
I have tried TOS 1.04 ROMs: reset loop. I could take a LA snapshot with 1.04, too.
Just tried the following:
  • insert cartridge with SuperMon
  • Deaktivated cartridge
  • Switch on ST
  • activate cart as soon as white screen is displayed
  • doesn't display white screen but stays in reset loop
  • as soon as I deactivate the cart it returns to the before mentioned reset loop
It boot the diag cart software. DMA, RAM, Timing, MIDI and Serial test run fine. But FDD test gives me WriteProtection
errors though the disk is not. Will investigate that.

BTW: are the ROMs MaskROMs or OTPs?
Image

czietz
Hardware Guru
Hardware Guru
Posts: 1133
Joined: Tue May 24, 2016 6:47 pm

Re: MegaST2 with constant resets

Postby czietz » Sun Mar 22, 2020 1:58 pm

I don't know how complex your LA's trigger conditions can be. Maybe you could trigger on address $FC0B50 and /AS=low, thus capturing the entry to the exception plus the stuff that came immediately before. That would tell you what exactly triggered the exception.

Can you do a ROM checksum test with the diag cart?

The original Atari ROMs are mask ROMs. Therefore, with them, a contact problem in the socket is more likely than an actually broken ROM. The ST I mentioned above had EPROMs, though, where one had gone bad.

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

Re: MegaST2 with constant resets

Postby Arne » Sun Mar 22, 2020 2:55 pm

Trigger condition could (!) work but it's Chinese stuff. So you never know.

Checksums for 1.02 and 1.04 on that particular machine.

Code: Select all

ROM checksum test
TOS in ROM: although six ROMs are shown, there may actually be only two.
Version 1.2 German PAL
     checksum   crc
H2     805B     FC39       cs error
H1     FB03     FC39       cs error
H0     FA34     756F
L2     D11B     BF64       cs error
L1     106A     BF64       cs error
L0     0E7E     9F49       cs error
Fail at cycle:000001

ROM checksum test
TOS in ROM: although six ROMs are shown, there may actually be only two.
Version 1.4 German PAL
     checksum   crc
H2     EA64     2CC5       cs error
H1     E375     2CC5       cs error
H0     E375     C9A2       cs error
L2     4F1D     D3E6       cs error
L1     3D4F     D3E6       cs error
L0     3D4F     E68A       cs error
Fail at cycle:000001


Right now it doesn't boot at all. I'm on the verge of scrapping this piece of junk.
Image

mlynn1974
Captain Atari
Captain Atari
Posts: 322
Joined: Mon Mar 03, 2008 10:33 pm
Contact:

Re: MegaST2 with constant resets

Postby mlynn1974 » Sun Mar 22, 2020 6:37 pm

I've checked Atari ST Internals and the TOS documentation looks totally different. At FCOBA2 we have:

Code: Select all

move.w #7,-(a7) ; R/O, hidden and system files

in the call autoexec program function.

I would be tempted to change the TOS chips if possible. Could it be possible that you are getting bogus data from the FDC or DMA chip?
Please don't scrap it - I'd love a MegaST.
Still got, still working: Atari 4Mb STe, 520STFM, 2.5Mb STF.
Hardware: Cumana CSA 354, Ultimate Ripper, Blitz Turbo, Synchro Express II (US and UK Versions).

czietz
Hardware Guru
Hardware Guru
Posts: 1133
Joined: Tue May 24, 2016 6:47 pm

Re: MegaST2 with constant resets

Postby czietz » Sun Mar 22, 2020 8:39 pm

mlynn1974 wrote:I've checked Atari ST Internals and the TOS documentation looks totally different. At FCOBA2 we have:

Code: Select all

move.w #7,-(a7) ; R/O, hidden and system files



I didn't look at the ST Internals, but I assume this is a disassembly of TOS 1.00. Of course that would be totally different from TOS 1.02.

czietz
Hardware Guru
Hardware Guru
Posts: 1133
Joined: Tue May 24, 2016 6:47 pm

Re: MegaST2 with constant resets

Postby czietz » Sun Mar 22, 2020 8:42 pm

I'm a little bit puzzled how the checksums and CRCs are the partly the same for different ROMs. Maybe something with the chip select signals for the ROMs, i.e., ROM2, ROM1, ROM0? Is this a two or a six chip machine? Can you check if it's configured correctly for either two or six ROM chips?

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

Re: MegaST2 with constant resets

Postby Arne » Sun Mar 22, 2020 9:18 pm

czietz wrote:
mlynn1974 wrote:I've checked Atari ST Internals and the TOS documentation looks totally different. At FCOBA2 we have:

Code: Select all

move.w #7,-(a7) ; R/O, hidden and system files



I didn't look at the ST Internals, but I assume this is a disassembly of TOS 1.00. Of course that would be totally different from TOS 1.02.

Yes of course - some people just cannot read.

czietz wrote:I'm a little bit puzzled how the checksums and CRCs are the partly the same for different ROMs. Maybe something with the chip select signals for the ROMs, i.e., ROM2, ROM1, ROM0? Is this a two or a six chip machine? Can you check if it's configured correctly for either two or six ROM chips?

It's a 2-ROM mainboard. It has just 2 sockets with the original 0-Ohm resistors. The 74LS11 is soldered in. But I could monitor /ROM0 and /ROM1 for activity. All /ROMx have continuity to the 74LS11.

I have recognized that the FDD write-protect error happens with a Sony and a TEAC FD-235HF but not with an Epson SMD300 and a NEC FDD.
On a 520STFM that error won't happen with the Sony and TEAC. 8O
So I think the results of the diag cart aren't that reliable.

To rule out cut tracks/bad solder joints between CPU and ROM I removed the ROMs and installed a TOS 2.06 card. It now boots to the desktop but FDD accesses result in "Data on drive A: defective" message boxes. Motor spins and LED turns on and off as expected. So DriveSel0 and MotorOn signals seem to work. Diag cart's DMA test runs fine so I assume that the tracks to the DMA are fine. I checked the connections between FDC, 7406, PSG and Shugart bus. Monitored the bus activity while the ST is running on all lines of those ICs. Looks fine. As I can now boot into desktop I started SuperMon from the cart. It can access given tracks/sectors on FDD. If I set it to read from side 0 or from side 1 SideSelect of the PSG is always low. Swapped PSG... no change. Setting the SideSel via the diag cart's built-in monitor works though.
Image

mlynn1974
Captain Atari
Captain Atari
Posts: 322
Joined: Mon Mar 03, 2008 10:33 pm
Contact:

Re: MegaST2 with constant resets

Postby mlynn1974 » Sun Mar 22, 2020 11:35 pm

I understand that TOS 1.02\TOS 1.04 might be slightly different from TOS 1.0 but it least the comments in that document give me a bit of context where the error occurred even if it's a couple of dozen bytes out i.e. Floppy reading code. That gave me a clue it might be a problem with the FDC\DMA chip.

If the FDC chip is socketed can it be replaced with a known working WDC1772 just to rule it out?

Out of interest, is it a long button MegaST or a short button MegaST?
All the long button STFs I've seen use Epson SMD 300 drives.
Last edited by mlynn1974 on Sun Mar 22, 2020 11:37 pm, edited 1 time in total.
Still got, still working: Atari 4Mb STe, 520STFM, 2.5Mb STF.
Hardware: Cumana CSA 354, Ultimate Ripper, Blitz Turbo, Synchro Express II (US and UK Versions).

mlynn1974
Captain Atari
Captain Atari
Posts: 322
Joined: Mon Mar 03, 2008 10:33 pm
Contact:

Re: MegaST2 with constant resets

Postby mlynn1974 » Sun Mar 22, 2020 11:35 pm

Double post.
Still got, still working: Atari 4Mb STe, 520STFM, 2.5Mb STF.
Hardware: Cumana CSA 354, Ultimate Ripper, Blitz Turbo, Synchro Express II (US and UK Versions).

czietz
Hardware Guru
Hardware Guru
Posts: 1133
Joined: Tue May 24, 2016 6:47 pm

Re: MegaST2 with constant resets

Postby czietz » Mon Mar 23, 2020 10:07 am

Like I already said: The code snippet starting at address $FC0B50, which Arne posted, is the exception handler. By itself, it has nothing to do with "floppy reading code". It is, of course, possible that the exception (bus error, ...) is caused by something related to the floppy. But it can also be something entirely different. I would need to see that happens before the exception handler is invoked.

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

Re: MegaST2 with constant resets

Postby Arne » Mon Mar 23, 2020 10:23 am

czietz wrote:I would need to see that happens before the exception handler is invoked.

And that is currently a problem. As I wrote earlier yesterday it won't boot i.e. as I found out later: it won't boot with my LA-PCB (to attach the grabber cables) anymore. D0-D13 + D15 all rise just to 2V. D14 looks fine. Same for all other signals I checked.
Without that PCB it can boot to desktop (2.06) or loops (1.0x).

Would it help to proceed as this:
  • return to 1.02 setting
  • as soon as it boots (=white screen on ST-High) I activate the diag cart
  • on reset it should jump into diag cart software
  • use diag cart's monitor to investigate the processor save state area

BTW: on one occasion yesterday evening it hung with 33 bombs (vector #33 is the Trap #1 vector). Probably doesn't mean anything.

Edit: investigated Dx lines with LA-PCB attached. They don't look too bad I think:
Image

In the AUTO mode of the scope I just saw a saw-tooth pattern running through so I thought signals don't rise to 5V anymore. My fault.
Last edited by Arne on Mon Mar 23, 2020 10:35 am, edited 1 time in total.
Image

czietz
Hardware Guru
Hardware Guru
Posts: 1133
Joined: Tue May 24, 2016 6:47 pm

Re: MegaST2 with constant resets

Postby czietz » Mon Mar 23, 2020 10:29 am

Arne wrote:Would it help to proceed as this:
  • return to 1.02 setting
  • as soon as it boots (=white screen on ST-High) I activate the diag cart
  • on reset it should jump into diag cart software
  • use diag cart's monitor to investigate the processor save state area


Never tried that. I'm not sure whether the diag cart will overwrite this memory area while starting. But it might be worth a try. If you see the magic number $12345678 at address $380, you know that the information held there is still valid.

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

Re: MegaST2 with constant resets

Postby Arne » Mon Mar 23, 2020 10:40 am

Using the Examine memory command

Code: Select all

R 380
yields

Code: Select all

00
as result. :( Sh*t
Image

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

Re: MegaST2 with constant resets

Postby Arne » Mon Mar 23, 2020 11:32 am

As I still cannot find any problem with that LA-PCB I removed it and used the plain TOS 1.02 setting to monitor D4 (as an example).
Constantly pressing the [Single] button on my scope I was able to see a pattern - at least I think so - on about 10+ loops.

Just after reset (at the beginning of the loop) D4 looks like this:
Image
D4 clearly rises above 2V.

But just prior to the reset it looks like this:
Image

Saw-tooth like pattern sometimes barely rising to 1.6V.

PSU is an external ATX that can output up to 25A on the 5V rail - fresh out of the box.
5V measured directly at the CPU pins 14 & 16 shows a meagre 4.88V.
Image

czietz
Hardware Guru
Hardware Guru
Posts: 1133
Joined: Tue May 24, 2016 6:47 pm

Re: MegaST2 with constant resets

Postby czietz » Mon Mar 23, 2020 5:25 pm

This sawtooth pattern could be a pull-up resistor slowly pulling up the data line when it's not actively driven. I would compare with another ST/MegaST whether that's normal.

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

Re: MegaST2 with constant resets

Postby Arne » Mon Mar 23, 2020 6:12 pm

Yes, you are probably right. But I don't dare to touch the system now. LA is back in business and I got the reset loop with 1.02 again. Unfortunately the LA SW does not trigger on $FC0B50. But as I said before: it's Chinese stuff. The SW does have its quirks.
Image

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

Re: MegaST2 with constant resets

Postby Arne » Mon Mar 23, 2020 7:50 pm

So, regarding your request to trigger for $FC0B50 I am a step forward.
The LA refused to successfully trigger for $FC0B50, so I triggered for /RESET again with a large amount of samples ahead.
I saved them as a TXT (1.7GB) and searched it for $FC0B50. And found it :-)
The sequence I see with addresses accessed and /AS = 0 are:

RW = Read Word
WW = Write Word

RW $200000 /DTACK asserted
RW $200002 /DTACK asserted
RW $001682 /DTACK asserted
WW $00167E /DTACK asserted
WW $001680 /DTACK asserted
RW $00002C /DTACK asserted
RW $00002E /DTACK asserted
RW $FC0B50 /DTACK asserted

As it's populated with 2MB the $200000/200002 accesses are probably originating from the TOS RAM test. $167E/1680 are probably undocumented TOS internal variables. But $2C is the Line-F handler :!: WTF... 8O
Image

czietz
Hardware Guru
Hardware Guru
Posts: 1133
Joined: Tue May 24, 2016 6:47 pm

Re: MegaST2 with constant resets

Postby czietz » Mon Mar 23, 2020 8:38 pm

$00167E etc. is the CPU pushing the exception frame to the stack. Then it fetches the exception vector. Since this is the line-F handler, we can deduct that the CPU tried to execute code from $200000 and $200002, found $FFFF (or something else starting with $F) there and then took the line-F exception. Can you see how it got to $200000 in the first place?

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

Re: MegaST2 with constant resets

Postby Arne » Mon Mar 23, 2020 8:55 pm

Makes sense. In case of all ST with < 4MB TOS RAM test will always read $FFFF (pull-ups) at some point. But why should it try to execute code? If it helps I could swap /LDS and /UDS (as we are dealing with 16bit accesses anyway) for FC0 and FC1.
Anyway: the addresses accessed prior to $200000 are word addresses $1FFFFE, $1FFFFFC, $1FFFFA, $1FFFF8,... and so on.
Image

czietz
Hardware Guru
Hardware Guru
Posts: 1133
Joined: Tue May 24, 2016 6:47 pm

Re: MegaST2 with constant resets

Postby czietz » Mon Mar 23, 2020 9:02 pm

Arne wrote:If it helps I could swap /LDS and /UDS (as we are dealing with 16bit accesses anyway) for FC0 and FC1.


Yes, then we would see if it's actually executing code from there. Maybe it's also already executing code from $1FFFFE, $1FFFFFC, $1FFFFA, $1FFFF8, ... I.e., for some reason the CPU has "run away". When this happens, (nonsensical) instructions are being executed until one is encountered that causes an exception (line-F, illegal instruction, ...). I've seen this happen in the past.

EDIT: Note that such a situation is extremely tedious to debug in my experience: You might have to backtrack hundreds of nonsensical instructions until finding the one that caused the "run-away".

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

Re: MegaST2 with constant resets

Postby Arne » Mon Mar 23, 2020 9:45 pm

Last message for today: you were right. Accesses to $200000 and before contain FC[1..0] = $2 -> User code!
Image

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

Re: MegaST2 with constant resets

Postby Arne » Tue Mar 24, 2020 8:37 am

Latest results are (addresses accessed from last meaningful (IMHO) to crash site):

Code: Select all

         FC[1..0]      R/W

$FC3184      2         R
$FFFA10      1         W
$00167E      1         R
$001680      1         R
$001682      1         R
$1FFB38      2         R
$1FFB3A      2         R
$1FFB3C      2         R
$1FFB3E      2         R
$1FFB40      2         R
$1FFB42      2         R
$1FFB44      2         R
...
$200002      2         R


Code: Select all

FC317A  08B90005FFFFFA11    L01D1:BCLR      #5,$FFFFFA11.L
FC3182  4E73                      RTE
FC3184  48E7C080            L01D2:MOVEM.L   A0/D0-D1,-(A7)      <<<<<<<<<<<<<<<<
FC3188  202D0E8A                  MOVE.L    3722(A5),D0


So it reads (16bit) from ROM at $FC3184 but not the next word needed for this instruction at $FC3186!
I guess here things start going haywire!
Image

czietz
Hardware Guru
Hardware Guru
Posts: 1133
Joined: Tue May 24, 2016 6:47 pm

Re: MegaST2 with constant resets

Postby czietz » Tue Mar 24, 2020 9:01 am

The access to $FC3184 is a prefetch, i.e., while the CPU is still processing the previous instruction(s). You can see that it handles the RTE (popping 3 words off the stack). Therefore, we know that the return address for the RTE was read back wrong and that got the CPU to jump to $1FFB38. This is, BTW, at the end of the MFP Timer-C interrupt handler, which handles the 200 Hz interrupt.

But I cannot explain the cause. Normally I would say bad RAM, but you already ruled that out with the diagnostic cartridge.


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 8 guests