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?