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 (https://lisalist2.com/index.php/topic,266.0.html)
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)
(reserved for future use)
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 ?
QuoteI 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.
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)
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.
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
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.
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 :(
Quote from: pintoguy on December 10, 2025, 11:40:26 AMSomething 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.
Thanks Alex. I suspected something of that nature. Seems a bit odd though (pun intended) to waste half of the RAM, no ?
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.
Thanks for the valuable info. This is why I really enjoy this board so much!
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 !
QuoteI 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?
Oh thanks James for your thorough post. I have a few comments and answers
QuoteHaving 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
mmm, I must be too much of a HDD guy thinking that you could have faulty memory location in a RAM chip, and perfectly good ones at the same time on the same chip. So, writing OK at $FCC017 implies that you will write OK at $FCC001 ? As I told you, I write and read back OK at $FCC017, but can only write up to $7F at $FCC001. Past $80, I always read back 00
QuoteThe FDC code will zero the command byte (that you wrote to FCC001) when it executes the command.
Even after I write in service mode, and read straight back ?
QuoteIn any case, good work finding the FDC code listing and working through it!
Thanks !
QuoteAFAIK, the only listings available are for the 400K versions of the 3.5" drive version of the I/O Board ROM
Yes, that's the one I saw on bitsavers (https://bitsavers.org/pdf/apple/lisa/firmware/IO_ROM_88_Listing_Dec83.pdf)
QuoteWhen error 57 occurs, are both FCC017 and FCC011 returning 01?
No, FCC011 returns 00
OK, so after a long hiatus, I'm reviving this thread. I was able to change the two RAM chips on the IO board, and it did not solve the Error 57 issue. I am afraid to admit that I had made a mistake initially, thinking that the error code at FCC017 was 1. In fact, it is 16 (10 in hexadecimal), which indicates failure to leave track zero location. Upon observing the FDD during boot, I see that the head always seeks in and out, whereas in does not with a good IO board. I suspect that the SNS signal coming to pin 11 of U3B-LS3s3 is what's often called TRK0, and it likely goes low when the head hits track zero, and high otherwise. This is what happens with the good board (5V on pin 11 after boot up), but 0.2V on the bad board. My tentative conclusion is that the LS323 shift register is defective. Does this make sense to any of you ?
Thanks in advance
QuoteQuoteHaving 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
mmm, I must be too much of a HDD guy thinking that you could have faulty memory location in a RAM chip, and perfectly good ones at the same time on the same chip. So, writing OK at $FCC017 implies that you will write OK at $FCC001 ? As I told you, I write and read back OK at $FCC017, but can only write up to $7F at $FCC001. Past $80, I always read back 00
$FCC001 is special, more detail below.
Absolutely one could have one bad bit in a RAM chip, but there is lots of other circuitry involved, so confirming that other locations read/write correctly gives some confidence the rest of the circuitry is working. Since something is broken, it isn't 100% confidence.
QuoteQuoteThe FDC code will zero the command byte (that you wrote to FCC001) when it executes the command.
Even after I write in service mode, and read straight back ?
Yes. The FDC's 6504 is a separate processor that is running separate code (stored in the I/O Board ROM). The 68000 communicates commands with it via the shared RAM. When the 6504 sees a command, it sends a semaphore to the 68000 CPU so the CPU knows the command was received and to start waiting for the result.
Commands are written to $FCC001.
Valid FDC commands have the high bit set. So writing a value from $00 to $7F won't be acted on by the 6504, so the value will remain stored at $FCC001.
If the high bit is set when a value is written to $FCC001, the 6504 will asynchronously (ie. even if the 68000 is busy or halted) grab the parameters passed, and indicate the command was received by clearing the value at $FCC001. After that it will check if the command is valid and perhaps do something and perhaps return some value(s) for the 68000 to examine later.
Quotethe error code at FCC017 ... is 16 (10 in hexadecimal), which indicates failure to leave track zero location. Upon observing the FDD during boot, I see that the head always seeks in and out, whereas in does not with a good IO board. I suspect that the SNS signal coming to pin 11 of U3B-LS3s3 is what's often called TRK0, and it likely goes low when the head hits track zero, and high otherwise. This is what happens with the good board (5V on pin 11 after boot up), but 0.2V on the bad board. My tentative conclusion is that the LS323 shift register is defective. Does this make sense to any of you ?
The SNS (Sense) signal is used by the floppy disk drive to communicate a variety of things:
- disk-in-place
- write protect
- track 0
- eject button pressed (Twiggy drives)
Which item is to be reported by Sense is selected by the FDC using PhiA and HeadSelect.
Since one doesn't need to check those signals at the same time that data is being read, SNS and RDATA are connected together for 3.5" floppy drive variants, saving a pin. In a 2/5 they are connected together by the Lite Adapter. Twiggy drives keep these signals separate.
When the 1/5 I/O Boards were converted from Twiggy drives to 3.5" drives, R47 is removed to reduce the load on SNS/RDATA... does the problem board have R47 intact? ... I see earlier in the thread you reported it has been removed, but I'll leave this thought in for some future troubleshooter.
The speculation that "U3B is bad" seems plausible to me; however, I think it is a less common failure mode for a bad TTL chip to affect an input in such a way. I suggest working the signal back towards the drive... it may be a broken trace or bad contact rather than U3B itself.
For additional info, is the disk-in-place signal also broken? eg. after reset, does the FDC wait for a floppy to be inserted before moving the carriage?
Thanks very much James. There is a lot of info there that will take time for me to digest. In the meantime, here is some more info and progress.
1) It did not make much sense to me that SNS signal at pin 11 of LS232 could be different on a good (High) vs bad (low) board, since it comes from a good FDD. This could only happen if pin 11 was shorted, and I checked that it was not. BUT, and as you pointed out, I realized that SNS and RDA signals are connected in the LisaLite adapter. Upon following RDA to pin 13 of LS174, I did find that it was shorted. I quickly replaced that chip, convinced that would solved the problem, and it kind of did: Error 57 went away when a floppy was not inserted, but it remained when it was. The code now changed to 0D (13 in decimal: timeout while looking for track zero). So we are facing the second layer of the onion.
I checked that the FDD spins and actuates, but on the bad board, the head homes to track zero (OD), but instead of staying there, it reverses course and goes all the way to the ID before timing out. I scoped the RDA signals upon reset on my good (top) and bad boards (bottom), and they are clearly different (below). At faster scope scan rate, I can clearly see data with the good board, and none with the bad one. So the FDD is clearly not seeing track zero, even though I know it is good, and that it seems to actuate OK. Somehow the data signal seems to be corrupted.
(https://i.imgur.com/PIIqOil.jpeg)
(https://i.imgur.com/7Y6jjRe.jpeg)
Thanks again James for spending the time to educate me on a number of Lisa-FDD related things. Your explanations made a great deal of sense. Great shout out to "Adrian's Digital Basement" Lisa youtube series that had a similar Error 57. His video (https://www.youtube.com/watch?v=HMEDMvb4IjM) helped me a lot too.
In replies to your questions:
Quotedoes the problem board have R47 intact?
No, it's not there
QuoteI suggest working the signal back towards the drive..
As far as I can tell, RDA and SNS traces seems to be clean from connector J9 all the way to chips LS174 and LS259
Quoteis the disk-in-place signal also broken? eg. after reset, does the FDC wait for a floppy to be inserted before moving the carriage?
No, the actuator starts moving immediately
Also, in case it helps, the FDD motor starts spinning ~5s after reset on the good, and ~4s after reset on the bad board
Quote... following RDA to pin 13 of LS174, I did find that it was shorted. I quickly replaced that chip, convinced that would solved the problem, and it kind of did: Error 57 went away when a floppy was not inserted, but it remained when it was. The code now changed to 0D (13 in decimal: timeout while looking for track zero). So we are facing the second layer of the onion.
As you've found and fixed a bad part, but not yet resolved the error implying further parts are bad, I'm thinking the board suffered some kind of trauma (such as a floppy connector plugged in backwards or who knows what). In that case, all of the signals connecting to the floppy drive come into suspicion.
The trace showing (I think) that the SNS signal is now active (no longer stuck low) may clear U3B from the earlier suspicion of shorting the pin, but it may still be bad in a different way.
Another possible cause of the FDC not being able to get Track 0, Disk-in-place, etc. is some problem in the circuitry that selects which item to sense.
U2F 8T97 is a part that is often replaced due to a different symptom (when the I/O Board isn't responding to some access requests with DTACK).
I suggest you scope the outputs of U2F on pins 3, 5, 7, 9 to check they are active when the FDC is trying to control the drive. In particular, pin 3 driving Ph0 (aka PhiA) is involved in selecting the SNS source.
Also, U3F LS04 pin 12 drives the head select signal which is involved in selecting the SNS source.
Finally,
U4F LS244 U3F LS04 pin 6 (or maybe it is 8 for the lower drive, I don't recall) drives the drive enable signal which is involved in selecting the SNS source.
edit: as all of the above are buffers, you might use the second scope channel to compare the input and output of each buffer and confirm the signal is propagating through.
edit 2: as pointed out later in the thread, the drive enable signals don't come from U4F LS244, but U3F LS04. Thanks to Alex for offering to take the blame, but it was actually my mistake that he replied to.
Quote from: sigma7 on May 19, 2026, 03:07:12 PMFinally, U4F LS244 pin 6 (or maybe it is 8 for the lower drive, I don't recall) drives the drive enable signal which is involved in selecting the SNS source.
The lower drive is drive 1 and the upper drive is drive 0, so the lower drive enable pin is going to be LS244 pin 6. I got this backwards on LisaFPGA and was wondering why the drive wasn't working, so now it's permanently burned into my head!
OK, thanks. And yes, I had already suspected a problem with polarity of the FDD connector, but dismissed it because it's more likely to damage the FDD than the IO board, but who knows. I also looked at Ph0-3 signals pre- and post-buffers and did not see anything majorly wrong, but I'll look again.
You mention pins 6 or 8 of LS244. Are you talking about DR0-DR1 selection ? If it is, shouldn't it be pins 6 or 8 of LS04 at U3F. Or could it also be MT0-MT1 at pins 7 or 9 of LS244 at U4F ?
Quote from: pintoguy on May 20, 2026, 12:02:36 PMYou mention pins 6 or 8 of LS244. Are you talking about DR0-DR1 selection ? If it is, shouldn't it be pins 6 or 8 of LS04 at U3F. Or could it also be MT0-MT1 at pins 7 or 9 of LS244 at U4F ?
Yeah sorry, you're right. DR0 and DR1 are on pins 8 and 6 of the LS04, and MT0 and MT1 are on pins 7 and 9 of the LS244.
So signals HDS, DR0-1, MT0-1 and Ph1-3 all look OK. However, PH0's waveform has the proper shape, but low-ish voltage past the buffer (pin3) at ~1V. Pre-buffer (pin 2) is OK at 5V. On my good board, all PH0-3 voltages to the actuator are ~3.5V (0-p). So it looks like I need a new 8T97. This is the second time for me.
Thanks again James and Alex.
PS: @Alex, I hate to always point out little details from your posts, as you're giving SO much to this community, but in your Lisa 2-5 schematics (https://github.com/alexthecat123/Lisa-PCBs/blob/main/2-5%20I-O%20Board%20Schematic.pdf), I think you still have R47 in the IO Board, when it has been removed from the Lisa 1 board
Quote from: pintoguy on May 20, 2026, 01:39:02 PMPS: @Alex, I hate to always point out little details from your posts, as you're giving SO much to this community, but in your Lisa 2-5 schematics (https://github.com/alexthecat123/Lisa-PCBs/blob/main/2-5%20I-O%20Board%20Schematic.pdf), I think you still have R47 in the IO Board, when it has been removed from the Lisa 1 board
I guess that schematic should be more accurately called "Lisa 1 and Lisa 2/5 I/O Board Schematic". Given that my replica I/O boards have a footprint for R47, it still has to be present on the schematic, but you just don't populate that component on the 2/5. You're totally correct that I could've named it better to avoid the confusion!
QuoteI guess that schematic should be more accurately called "Lisa 1 and Lisa 2/5 I/O Board Schematic". Given that my replica I/O boards have a footprint for R47, it still has to be present on the schematic, but you just don't populate that component on the 2/5. You're totally correct that I could've named it better to avoid the confusion!
Small detail. Again, this board wouldn't be the same without you.
And yes, a new LS367 did the trick and my board works great now. Thanks again to yourself and James. I am always in awe at the breadth and depth of knowledge that you guys bring to this community, and I learned so much from you ! And thanks for giving your time to the small guys like us :)