Interpreting uPD765 FDC result bytes

[Bryce]

From the 34way header is fine.

Bryce.

[JonB]

Hi Bryce


I don't have a PDF editor so I am going to have to refer you to the full document:


http://electrickery.xs4all.nl/comp/p2000c/doc/P2000C-SystemRefServiceManual.pdf


I really would have preferred to paste the schematics into a new PDF.


Anyway, the main board schematics start at page 134 and the FDC description including detail of PLL, FDC and timing starts on page 87.


The diagram on page 134 shows the board layout; the PLL and FDC connector are at bottom right on the bit of the PCB sticking out. The full schematics are on pages 87-90, and the full FDC circuit is on page 89 (with PLL bottom left).


Regards
JonB

[JonB]

I've got my desoldering station and spent a few minutes swapping the FDC out. I put it into a 6128 (socketed of course!), and it worked perfectly. So the FDC itself is not the problem here. And here's me hoping it was! Drat and blast....

[JonB]

OK, first off I want to look at the 74LS00 that is matching the RDD and VCO SYNC signals together, then the 250khz signal:


[attachimg=2]

I get some odd looking waveforms.. Let me show you.


This is the RDD input at 7414 Pin 12. Looks like there is some data there.


[attachimg=1]


The VCO input at test point 416 (7414 pins 1 and 2) is just noise at a very low voltage. When I attempt to read the disk, there is a tiny amount of activity but not enough to call it a TTL signal. Here's the best picture I have of it.


[attachimg=3]


The output of the first gate at pin 11 looks suitably dodgy.



[attachimg=5]


My first question is this: Shouldn't the output of this gate be clean (like the RDD signal but better shaped)?

[JonB]

Here we have the index mark at pin 17 of the FDC

[JonB]

Well.. I swapped out the LS7400 and I'm sorry to say it is not the cause of the problem.


Worth a try though..

[JonB]

Hate to do this, but ** BUMP **


I'm out of ideas.

[Bryce]

Hi JonB,
          sorry, I was away for a few days. I took a look at the schematics now. Can you tell me what signal you are getting on pin 12 and pin 13 of the 74LS14 (IC 7434). This is the gate that should be "squaring-off" the data signal.

Bryce.

[JonB]

Hello Bryce


The RDD signal is shown in the yellow trace in one of my previous posts (this one Interpreting uPD765 FDC result bytes). It's taken at test point 421 which is pin 12 of the 7400 (basically the same point you mention). As you can see it does appear to have data.


Now I am on holiday I have lots more time to investigate, so I should be able to give better answers.


Cheers
JonB

[Bryce]

Yes, but the signal on pin 13 is much more important. If that's a flat line or permanently 5V, then the 74LS14 is dead. We (you) have to trace the signal from it's source to it's end point to find out where things are going wrong.

Bryce.

[JonB]

Pin 13 is the RDD input signal. I have looked at that an there is a pulse coming in from the drive. Hang on, I'll get a trace for you...

[JonB]

ignore, i got all the attachments mixed up

[JonB]

OK, here we go. In the following images, the blue line is the trace at IC7434 pin 13 (input, RDD signal from drive), and the yellow trace is at pin 12 (output of first gate).

Not reading. Lots of noise there!

[attach=2]

Reading. You can see the negative pulses from the drive and the resulting output from the first gate, but there does appear to be quite a lot of noise in the output.
[attach=3]

Let's have a closer look. See the noise at the top of the yellow waveform? This doesn't look like a sane output. I thought it was supposed to clean the signal right up...

[attach=4]

So can we conclude that IC7434 is damaged? It's a Schmitt trigger (something I am just reading about) and from what I see of the datasheet, the output is all wrong. In fact, electrically it looks like a resistor from these traces, because it appears to be attenuating the input signal without shaping it. Isn't it supposed to invert the input signal as well?

[JonB]

OK, this looks more promising.


Same traces as before, but I can see now the LS14 doing its job.


[attach=2]


This is the result of me desoldering it and fitting an IC socket. Dry joint?

[JonB]

I was just reviewing the thread, and the error reported by the FDC is that the RDY signal changed state (presumably unexpectedly). So I thought I'd have a look round the RDY circuit.


[attach=2]


Now, this is pin 35 on the FDC and it is an input (to the FDC), yet here we see it feeding the input of a 74LS175 flip flop. Pin 4, actually, which the datasheet says is D0 but it is marked as 1D on the schematic. In fact the markings on the schematic don't match the chip much at all.. Hmm. So I went to the board, and both this chip and the one below it are missing, but there is no evidence of desoldering. The pads are all intact and all full of solder, as if it was flow soldered at the factory like that.


Time to do some continuity checks, but honestly I would expect to see some - any - evidence (like scratches round the pads, or visible holes instead of filled-in pads) that these chips had been removed after manufacture.


I checked the amendment documents, of which I see only two on the "electrickery" web site that holds all the documentation (here: Documentation for the Philips P2000C computer). There isn't an updated schematic that shows these missing chips removed..

[JonB]

Another thing I don't understand is why the Shugart /RDY signal (on line 34 of the FDD cable) is marked as "2-Side" and appears to feed FDC WP/2-side pin via the LS244 (IC7454) buffer. Maybe it is using the drive's RDY to indicate the drive isn't double sided when the FDC requests a read on side 2 with a 1 sided drive is connected. But RDY should also be connected to the RDY line of the FDC I would have thought.


WP/2-Side is showing a signal, though...


[attach=2]


A pair of little pulses then a big one which is 1.2mS wide.


Perhaps the FDC's RDY it is being forced high by the resistor pack (4709, shown below), which would mean it is seeing a ready drive all the time?


[attach=3]


Edit: Yes, it is. Pin 35 of the FDC is showing high all the time. So I think the status "ready signal changed" is misleading.

[JonB]

I had a thought.



To get the result set above, I am asking the P2000C's monitor to read the content of track 0 on side 1 of the disk. It never completes the operation. And I now think it is because something else, prior to reading, is failing. In the FDC data sheet it explains how a read should be conducted. You issue recalibrate command (moves head to drive zero), then seek to the track to read, then read. So I think that, although it is seeking and recalibrating (head moves), there is an error or missing signal somewhere that prevents the read command being called by the monitor.


When you issue the read track command to the monitor, it executes the command continuously until you hit the escape key. When reading a higher track (say, Track 10), it zeros the head prior to each iteration of the command. I think this is the FDC recalibrate command being executed. Then, the dead seeks to track 10. After this, the error state is reported. So I would be checking the result the seek operation next.


It's a pity I don't have the monitor source, because with that I could work out what FDC operations the "read track" command is using, and perhaps where it fails.

[JonB]

OK, it's "pseudo-random parts swap" time.


I've swapped out the following ICs:


IC7414 74LS00, used in the input to the data separator.
IC7451 upd765, the FDC itself.
IC7454 74LS224, used to buffer the incoming FDD control lines (2,26,28,34), including RDY.
IC7452 74LS04, inverter that is used all over the place, including FDD control lines.


None of this has made any difference, I'm still getting the same error codes back when trying to read a disk.


Odd question, but is anyone reading this, or am I posting to myself?

[Bryce]

I'm still reading, but I'm really beiginning to think that you are either testing the drive wrong or the drive itself has failed. Have you tried the drive in a different system? Have you tried a different drive in this system?

Bryce.

[CraigsBar]

Odd question, but is anyone reading this, or am I posting to myself?

I am..  Not that I can help much.

[JonB]

I'm still reading, but I'm really beiginning to think that you are either testing the drive wrong or the drive itself has failed. Have you tried the drive in a different system? Have you tried a different drive in this system?

Bryce.

Thanks Bryce, I really did think I was going mad... 


Anyway...


I have tried both drives in drive 1 slot (DS0) with and without the terminator resistor pack fitted and on both drive connectors (the cable is soldered to the board but it's got two edge connectors fitted for drive 1 and 2 (DS0 / DS1 repsectively). It doesn't make any difference, I am still getting C0 00 00 00 10 00 FF with every read track, and also with write track as well.


Using IMGDSK I created a copy of the P2000C system disk downloaded from some web site a while ago on a fresh floppy (3M, new old stock). The parameters are: Double Step=DISABLE, 300Khz = 250Khz. The new disk is readable using 22DSK144.COM (another great disk utility) using the PH2 (Philips P2012) settings. This is with one of the P2000C's drives plugged into a PC (AT spec, Win98 only and running in DOS mode), configured as a 3.5" 720k disk. Not only can I read the new disk with this, but I can also read every one of the old disks that came with the machine. Or rather, I can read the directories; I haven't tried pulling actual data off any of them yet, but I have formatted and written to another NOS disk, and read it back.


So I would have to say that given I can use one of the FD55Fs in the PC successfully, and that same drive doesn't work in the P2000C, the only conclusion to be drawn is that the disk drive is OK.

[JonB]

Just to be sure, I have connected another set of 3.5" floppies to the P2000C. Had to desolder the old drive cable and fit a set of header pins, then I could plug the 34 way female IDC connector straight into it. I copied a disk image using the known working settings on IMGDISK and verified with 22DSK144 and attempted to read it with the P2000C.


No joy.


I have a pair of dual drive BBC micro units too (they are the same spec) but I'm pretty sure they won't work either.


[Edit: Nope, they don't work. So that is a total of eight different drives I've tried with it. Must be the board.]

[Bryce]

Sorry, but I've really run out of ideas, without having the device here it's difficult to diagnose it any further

Bryce.

[JonB]

Well, this is fun. Here is some test code for the FDC.

Code Select Expand



;----------------------------------------------------
; Project: floptest.zdsp
; Main File: floptest.asm
; Date: 30/05/2015 12:20:09
;
; Created with zDevStudio - Z80 Development Studio.
;
;----------------------------------------------------
CONST   equ     0F606h  ;Console status
CONIN   equ     0F609h  ;Console input
CONOUT  equ     0F60Ch  ;Console output
LIST1   equ     0F60Fh  ;Printer output
COMOJP  equ     0F612h  ;Com output
COMIJP  equ     0F615h  ;Com input


DPBADDR equ     0FFD0h  ;Driver parameter block address
DPBDRV  equ     00h     ;Drive
DPBTRK  equ     01h     ;Track
DBPSEC  equ     03h     ;Sector
DPBHEAD equ     04h     ;Head (0 or 1)
DPBRWB  equ     05h     ;Read/Write buffer address
DPBLEN  equ     07h     ;Buff length -1 (after read; before write)


RDS     equ     09h     ;Read sector routine addr
WRS     equ     0Bh     ;Write sector routine addr
STEP    equ     0Dh     ;Seek to track routine addr
RECAL   equ     0Fh     ;Recalibrate head routine addr
BOOT    equ     011h    ;Boot routine addr
LISTAT  equ     013h    ;List status routine addr
PRTAB   equ     015h    ;Print table addr
PRWAIT  equ     017h    ;Print wait time in 4sec units
PRSTAT  equ     018h    ;Printer status byte; 0=err
PRCONT  equ     019h    ;If 0, no message if printer not ready (?)
BOOTDR  equ     01Ah    ;Boot drive (0, FF or 1)
DSKFLG  equ     01Bh    ;Internal disk flag
DMSTAT  equ     01Ch    ;DMA shadow byte
HDERSU  equ     01Dh    ;XEBEC err routine addr
DSKTR   equ     01Fh    ;00, C9 = Standard track numbering
                        ;24, C9 = old Philips track numbering
PRSCR   equ     021h    ;Print screen routine addr
MSWBYT  equ     023h    ;0 if ROM, 2 if RAM
JMPC3   equ     024h    ;C3 for jump (?)
TINEX   equ     025h    ;Address of external timer interrupt
KSTAT   equ     027h    ;Key status, 0 if no key currently pressed
KBYTE   equ     028h    ;Last depressed key
CLOCK   equ     029h    ;60hz clock (counter?), 4 bytes long
RESULT  equ     02Dh    ;Floppy result bytes, 7 bytes, starts at FFC4




RWBUFF  equ     08000h  ;disk buffer




        org 4000h
        LD DE, STEP
        call JUMP
        RET


        ;DEFB "GETOFF"
GETOFF: LD HL,(DPBADDR)
        ADD HL,DE
        RET


        ;DEFB "JUMP"
JUMP:   CALL GETOFF
        LD E,(HL)
        INC HL
        LD H,(HL)
        LD L,E
        JP(HL)
        RET


        ;Setup for read track
SEEK:   ;DEFB "READ TRACK STARTS"
        LD HL,(DPBADDR)
        LD (HL),00h     ;Drive 0
        INC HL
        LD(HL),0AH      ;Track 10
        INC HL
        INC HL
        LD(HL),05H      ;Sector 5
        INC HL
        LD(HL),00h      ;Head 0
        INC HL
        LD DE, RWBUFF
        LD(HL),D
        INC HL
        LD(HL),E
        INC HL
        LD(HL),0FFh
        INC HL
        LD(HL),00h
        RET     


[JonB]

What is does is use the low level P2000C BIOS driver routines that are stored on the Driver Parameter Block (DPB). You can see the form of the DPB in the block of equates at the top of the file. There are a couple of helpers:

GETOFF - get offset from DPB start address, given an offset in DE. Return offset in HL.
JUMP - Call subroutine whose address is located at the DPB offset given in DE.

In case you are wondering why they are separate, I will be using GETOFF to get/set the DPB values that aren't vectors.

SEEK - Sets up a sector address in the DPB (I wrote this before GETOFF so it doesn't use it).

So, first I called RECAL and the heads were moved to TRACK 0. Result bytes were 20 00 00 00 00 00 00 00 (ST0, D5 "Seek End"). All good, then.


Then I amended the command to a STEP. I moved the head to track 10 as shown in the SEEK code. The head moved (to 10) and I examined the result bytes in the DPB. They were 20 20 00 00 00 00 00. Which means ST0: D5=Seek End (good), ST1: D5=Data Error (bad).


Finally, I amended the command to read the specified sector, executed and got the familiar C0 00 00 00 00 00 00 (ST0: D6/7=Drive RDY state change).

What I find a little odd is that STEP should be giving any result in ST2 at all. The FDC datasheet shows that when you do a seek, it moves the head but the result bytes are unchanged. Yet here we see an update to the first and second result bytes, which I find odd. Maybe the BIOS seek routine is trying to acquire some data... so I will disassemble it to find out, if I can locate it (the address is not in ROM, as it gets copied out at bootup). I think FF03h. Edit, STEP is one of the ROM resident commands, at 027Ch. Likewise, RECAL at 0299h and RDS is in upper RAM at FD45h.


Edit 2: Although the datasheet's command summary table says seek doesn't give results, the description states that if the disk is not ready at the start of command execution, it will set ST0 D7/D6 to 0/1 (abnormal termination of command) and D3 to 1 (Drive Not Ready flag) which would be 48h.