Troubleshooting self-test Error 57

[sigma7]

This is a preliminary draft of this topic, there may be some mistakes/errors...


Reviewing the Rev H Boot ROM Listing, error 57 equates to EDISK, with the comment "disk error"; it appears to be limited to floppy disk controller errors.

Searching the code for EDISK, we find it at address $1152 (that's offset $1152 from the start of the ROM, shown as 1152 in the left column of the listing), and at $1186, and at $14C6

So there are 3 possibilities for where this error might be generated/detected.

The ROM version display and the timing of the error message help narrow down which is happening...

1) $1186 -- The I/O ROM version is displayed on the screen by the code at $111A, which writes the "/" character to the screen after the CPU Board ROM version (eg. "H"), then reads the I/O ROM version from the FDC shared RAM, and writes that to the screen. If the attempt to get the I/O ROM version fails with a bus error, execution will redirect to DSKVCT so nothing will be displayed after the "/".

A bus error will occur if the 8T97 at U2F does not assert /DTACK when accessing the shared RAM. See this topic for suggestions for troubleshooting bus errors: Troubleshooting Bus Errors

If /DTACK is generated correctly, but the shared RAM is not working properly, or the FDC did not successfully write its ROM version number into the shared RAM, then the I/O ROM version shown may be incorrect or even random.

If service mode is available, one can test the shared RAM manually via reads and writes to odd addresses from FCC001 to FCC1FF. The end of this range is used for the Lisa Parameter RAM, and the 6504 stack, and the beginning of the range is used for FDC operation (values, commands, etc.) so for random writes, using the middle of the range is least likely to cause any hiccups.

The I/O Board RAM chips are two of the few static sensitive devices on the Lisa circuit boards, so they are among the parts most likely to be found faulty.

2) $1154 -- After displaying the I/O ROM version, the self test checks to see if the FDC has asserted DSKDIAG (U3E-11), which is done after the 6504 successfully goes through its reset sequence. DISKDIAG on the schematic is controlled by the 6504 with writes to the equates BOOTL and BOOTH in the IO_ROM listing. DSKDIAG is set low by /RESET. The 6504 writes to BOOTH (setting DSKDIAG high) when ready to interact with the 68k.

If the FDC is not working, then the state of DSKDIAG will remain low after reset. If the FDC is working or semi-working, then you should be able to see the state of this signal be low upon reset, then go high shortly after. If it is stuck low, then the 6504 circuitry may have some kind of problem.

The Boot ROM Listing suggests the 68k waits 15 seconds for DSKDIAG to go high, so if the amount of time between seeing the I/O ROM version on screen and the error appearing is much less, then the error is likely from $14C6.

3) $14C6 -- After finding that DSKDIAG is high, the 68K:

• checks the startup status from the FDC as stored at $FCC017 is $00 (via code at $1156),
  
• attempts to write $55 and read it back back at $FCC003 in the FDC shared RAM (via code at $1162), and
  
• issues the disable interrupts command to the FDC (via code at $1D46);
  

If any of those fail, error 57 is generated.

The startup status retrieved from $FCC017 will not be $00 if the FDC detected an error upon reset; see error numbers extracted from the I/O ROM listing below (note the pic shows decimal numbers, not hexadecimal as used in Service Mode).

If the keyboard is working, then one could use service mode to do these checks manually to see which one is failing.

eg. enter service mode and type

1fcc017 1<return>   (to read 1 word from FCC017, the status byte where error codes are returned)

2fcc003 55<return>  (to write 1 byte to FCC003, the command byte where commands are issued to the FDC)
1fcc003 1<return>   (to read 1 byte from FCC003)

[sigma7]

(reserved for future use)

[pintoguy]

Thanks James. This is another very valuable and precious piece of info from you.

I have error 57 with a bad IO board that goes away with a known good board. I followed your procedure and read $01 at $FCC017, indicating "Invalid Command" if I understand correctly. I checked that I can write $00 at that address using the service mode.

What piece of hardware on the board could this incriminate ?

[sigma7]

I have error 57

Before speculating about what invalid command implies, I'd like to confirm which stage (1,2,3) of the self-test generates the error:

1) Do you see a version code after the "/" in the menubar?
2) If so, does error 57 show up soon after, or do you have to wait a while (eg. 10 seconds or more)?

If you haven't tried gently cleaning the edge connector contacts on the I/O Board, I'd do that first, and then insert & remove it a few times to wipe the contacts.

[pintoguy]

Thanks James

1) Yes, I see the full version code H/A8
2) Error 57 shows up with no delay, almost immediately after the start of the IO test
3) Yes, I have tried to gently clean the edge connector. I have also swapped most (all?) the socketed chips with my good board with no luck. I might try again just to be sure

Also, I am able to boot off the Profile. There is also life in the FDD, and if I try to boot off it, there is seek activity but seemingly no read, and I get error 23 (read error)

[sigma7]

Interesting that it appears to mostly function but reports an invalid command which I take to mean a problem in writing some bit during the self-test.

I suggest testing that (for the FDC) all bits can be read back after writing and not tied to another.

eg. Write (and confirm success via read back) to FCC017 some patterns such as these values:
FF
00
F0
0F
55
AA
3C
C3

The object is to verify that each bit can be set and cleared independently of the other 7. Which should detect a broken trace or bad contact, a stuck bit, or two bits shorted together.

[pintoguy]

I was able to write and read back all these values (see screenshot below).

Something I'm missing though is that all of the even RAM addresses keep changing (even with the good board). It's probably obvious to you, but I'm still a bit too new to this.

I bought a few 18pin 4x1k RAM replacements chips just in case.

Thanks again

[pintoguy]

So I did a complete swap of all the socketed chips, only five in my case (341-0290-B ROM, 6504, P6A, 8530, 6522 keyboard, all from a good IO board) with no luck. Interestingly, the COP421 from the faulty board is not socketed.

Also of note, this faulty board is almost immaculate. The batteries must have been removed very early on, and there is no trace of corrosion on the board.

[pintoguy]

Latest update: I realize that this board must have been from a Lisa 1 in a past life, as R47 was removed and R41 was still there. The IO ROM is the proper one for a 2-5. I was hopeful that cutting off R41 would do the trick..... but it didn't

[AlexTheCat123]

Something I'm missing though is that all of the even RAM addresses keep changing (even with the good board). It's probably obvious to you, but I'm still a bit too new to this.

Don't worry, that's completely normal. The bus coming out of the floppy controller is only 8 bits wide and it's hooked to the odd byte going to the CPU, so the even byte is essentially just random garbage whenever you try to access the floppy controller. Try writing to the even byte; you'll notice that your writes don't stick and it comes back random again.

[pintoguy]

Thanks Alex. I suspected something of that nature. Seems a bit odd though (pun intended) to waste half of the RAM, no ?

[AlexTheCat123]

To be clear, none of the floppy controller's RAM is being wasted. Every single byte is being used. It's just that when data is sent to the 68K, only one byte is sent per 16-bit word. So yeah, I guess some of the 68K's address space is being wasted, but it's not much (the FDC RAM is pretty tiny) and it's not like they needed the extra space for anything anyway. This strategy was actually really common at the time when interfacing 8-bit peripherals with 16-bit (or 32-bit) CPUs and there was even an instruction in the 68K (MOVEP) that would automatically handle the skipping of one byte per word when moving multiple-byte quantities. Pretty cool that the 68K had an instruction dedicated to this exact use case, it goes to show how common it was! Other things on the I/O board like the VIAs work the exact same way. Peripherals generally don't have a very big address space compared to things like RAM, so any 68K address space that you're wasting is pretty negligable.

[pintoguy]

Thanks for the valuable info. This is why I really enjoy this board so much!

[pintoguy]

I think I've made some progress. I do not pretend that I understand assembly language, but the IO ROM 88 code from bitsavers indicates that there is a validity test performed on the command passed by the 68k processor. This command GOBYTE seems to be stored at address FCC001, and the valid command values seem to be 80-89. So I went ahead and tried to write these 8x values at $FCC001 using the service mode, and they do not stick. I can write low numbers (0x), but not high. So I'll wait until I get my eBay replacement RAMs (AM9114DPC - I hope they're equivalent), and will report. Thanks again to James and Alex for their help !

[sigma7]

I think I've made some progress. I do not pretend that I understand assembly language, but the IO ROM 88 code from bitsavers indicates that there is a validity test performed on the command passed by the 68k processor. This command GOBYTE seems to be stored at address FCC001, and the valid command values seem to be 80-89. So I went ahead and tried to write these 8x values at $FCC001 using the service mode, and they do not stick.

That is useful information, but the implication is positive rather than negative.

Having established that the FDC RAM seems to work ok by your previous tests, we can be semi-confident that the values you wrote went into the FDC RAM.

The fact that the values that have the high bit set don't remain is actually a good thing. The FDC code will zero the command byte (that you wrote to FCC001) when it executes the command. So you've discovered that the FDC is in fact running and attempting to execute the commands that it is receiving.

In any case, good work finding the FDC code listing and working through it!

AFAIK, the only listings available are for the 400K versions of the 3.5" drive version of the I/O Board ROM. The changes for the 800K version are minor, but I have not seen a formal disassembly listing. The Twiggy version for the 1/5 I/O Board is substantially different, and again I have not seen an Apple assembler/disassembler listing.

Chapter 6 of the Hardware Manual describes the I/O Board. Most of the chapter is regarding the FDC.

Pages 6-13 through 6-30 describe the commands that can be sent to the FDC; you could look there for an overview of the commands, but reading the actual code is where you'll find the most important details.

Note that the Hardware Manual documents the system mostly as shipped with Twiggy drives, so some of the FDC details are not applicable once a Lisa is converted to use a 3.5" floppy drive. For example, the 3.5" drive does not use the "Clamp" command as it automatically does so when the disk is inserted.

Note that the shared FDC RAM is addressed as 0, 1, 2, 3... by the 6504, and to the 68K, these same bytes are every other byte offset from the base address of the FDC RAM, ie. FCC001, FCC003, FCC005, FCC007...

So to convert a RAM address in the FDC listing to the 68K address, multiply by 2, and add FCC001.

The 68K can't access the FDC's ROM or I/O space directly, but one can download arbitrary program code into the FDC shared RAM and have the FDC run it to access the ROM and I/O by proxy.

According to the listing, FCC011 is "ERRSTAT", and FCC017 is "DrvError" which I expect have differing meanings in some cases, but I don't recall any details.

When error 57 occurs, are both FCC017 and FCC011 returning 01?