LisaList2

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

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

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.

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?

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.

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

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

Quote from: sigma7 on Yesterday at 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!