LisaList2

Also, in case it helps, the FDD motor starts spinning ~5s after reset on the good, and ~4s after reset on the bad board

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 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

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.

Yep, I'm working with MacEffects and Joe's Computer Museum, and whatever doesn't sell at VCF will be split 50/50 between them for sale on their sites! Once those sell out, I'm planning on doing another batch too.

Quote from: AlexTheCat123 on May 18, 2026, 04:51:39 PMJLC just finished manufacturing the boards, so they should be shipped out pretty soon. Hopefully they'll be here by VCF; it's going to be really close!

I just added a neat feature that very few people will probably ever have a use for, but it comes in handy for me sometimes with LOS experimentation, as well as with Xenix's hard drive size limits. If you connect one of the pins on the GPIO header to 3.3V, then the FPGA will intercept any reads to address FCC030 and always return 88 instead of A8, making software think that it's running on a 2/10 instead of a 2/5. Pretty neat, right?

Sorry, I completely forgot to respond to you! It's looking like about $300. I really wanted it to be cheaper, but the prices of chips have gone up quite significantly since my last order. Take the FPGA for instance. When I placed my first order back in November, it was $20 apiece, but now it's like $50. And many of the other chips have increased by similar proportions too. It sucks!

Will there be any available for shipment to folks who are not planning to attend VCF?

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:

[ul]

• disk-in-place
• write protect
• track 0
• eject button pressed (Twiggy drives)

[/ul]

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?

Quote

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

$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.

Quote

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 ?

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.

JLC just finished manufacturing the boards, so they should be shipped out pretty soon. Hopefully they'll be here by VCF; it's going to be really close!

I just added a neat feature that very few people will probably ever have a use for, but it comes in handy for me sometimes with LOS experimentation, as well as with Xenix's hard drive size limits. If you connect one of the pins on the GPIO header to 3.3V, then the FPGA will intercept any reads to address FCC030 and always return 88 instead of A8, making software think that it's running on a 2/10 instead of a 2/5. Pretty neat, right?

Quote from: bmwcyclist on May 12, 2026, 12:55:58 PMDid I miss where the price was posted?

Sorry, I completely forgot to respond to you! It's looking like about $300. I really wanted it to be cheaper, but the prices of chips have gone up quite significantly since my last order. Take the FPGA for instance. When I placed my first order back in November, it was $20 apiece, but now it's like $50. And many of the other chips have increased by similar proportions too. It sucks!

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

Did I miss where the price was posted?