6502.org

Posted: **Wed May 27, 2015 7:59 am**

Hi Jeff

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/p200 ... Manual.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).

I am discussing this on two other forums right now, so I can say that I have checked all parts of the read circuit with a scope and it's working, apart from VCO SYNC from the FDC, which stays low all the time. It's supposed to go high during reads, to switch the PLL from the 250khz signal to the RDD signal from the drive. The result bytes coming back from the drive are as follows

Code: Select all

C0 00 00 00 10 00 FF

..which seem to be saying (per upd765 data sheet)

C0 : SR0: abnormal termination because disk ready signal changed state (D6 / D7 = 1)
00 : SR1 - nothing
00 : SR2 - nothing
00 : SR3 - nothing
10 : ?
00 : ?
FF : ?

So I checked the RDY line on the FDC (pin 35) and it is held high all the time via a resistor to +5v (marked as 4709 on the schematic).

I'm now thinking the FDC is encountering an error condition prior to initiating the read, which might explain why I am never seeing VCO SYNC go high.

Since this thread was started to try to get an understanding of the generation of VCO SYNC, there is no context, which I will now provide. The machine is a Philips P2000C, a portable CP/M computer with a 9" screen and twin Teac FD55F drives. They are DSDD. I have boot disks that are readable on a PC using one of the FD55Fs and special software. The machine has a monitor which allows you to issue commands that test the drive (read track, write track, format track, etc) plus a number of memory view and edit operations. To get the result set above, I am asking it 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.

Regards
JonB

Posted: **Wed May 27, 2015 4:18 pm**

Hi JonB

so RDY is not used at all in this layout and together with a input of the 74LS175 input tied to VCC via the resistor as you mentioned. Strange but you can do that. So I ask myself, how can the uPD765 report that the RDY changed when in fact it should not be able to change. I would suspect that you have noise somewhere that induces spikes or whatsoever. Check VCC with the oscilloscope and check RDY (PIN 35 of uPD765) with the oscilloscope (this should have no spikes at all). I would put a small capacitor (100n) to PIN35 and GND and try again.

Cheers

Peter

Posted: **Wed May 27, 2015 9:10 pm**

Interesting point, Peter.. On the scope it looks unclean (at high resolution), with ~600Mv of difference between peak and trough. Lowest voltage I can see is 4.83, highest is 5.47. But that is still logic high as far as I know.

Let's see what a small cap will do for it. Hmm. 100nf to 0v actually makes the noise worse. I don't understand that at all.

But when you zoom the scope out to, say, 1v per division, RDY looks like a reasonably clean 5v.

Incidentally, the FDC's VCC is also clean, and +5 / +12v at the drive power connectors are likewise clean.

Posted: **Wed May 27, 2015 9:40 pm**

jonb wrote:

Hmm. 100nf to 0v actually makes the noise worse.

To me, that says the "ground" you attached the cap to isn't a good ground. (Either that, or else you haven't attached the ground on the end of the 'scope probe properly, but in that case none of the points you examine will be noise-free.)

I wonder why the cap-attach point is noisy.

Could there be a failure in the board itself -- a corroded plate-through, or something like that? If you haven't already, perhaps you should verify all the pertinent connections with an ohmmeter test.

You could 'scope the ground pin of the FDC chip while you're at it -- the actual pin, not the trace leading to it.

Posted: **Thu May 28, 2015 3:08 pm**

jonb wrote:

C0 : SR0: abnormal termination because disk ready signal changed state

cbscpe wrote:

how can the uPD765 report that the RDY changed when in fact it should not be able to change.

Perhaps there was no change, and the report is erroneous. In a tough troubleshooting situation it pays to question things.

Something that hasn't been questioned so far is the EPROM. It could be starting to lose its contents -- just the odd bit here & there. The resulting firmware failure could be grossly obvious or it could be extremely subtle. And in this case we rely on the firmware to

issue sequences of commands to the FDC, and
to query FDC status then evaluate & report that status.

I've seen 10 years listed as the spec for data retention on EPROMs -- and it's been much longer than 10 years since this particular EPROM was programmed! The spec is probably quite conservative, but even so...

Has anyone here experienced data loss in an old EPROM? I've twice seen cases which I thought could be explained by this, but circumstances didn't allow me to follow up (the ancient gear ended up being discarded, not repaired).

In this particular case, how can we correct (or at least verify) the problem? Thinking out loud here, ...

see if someone on the 'net has a copy of the EPROM contents. Or,
"Read the content of track 0 on side 1" entails several FDC commands, so try running them one by one. Disassemble the disk routines and give them a good eyeballing.
experiment with variations in temperature and supply voltage to see if the EPROM checksum can be made to vary. For this you'd need to remove the EPROM from the P2000C.
other ideas, anyone?

cheers,
Jeff

Posted: **Fri May 29, 2015 12:07 am**

Dr Jefyll wrote:

Something that hasn't been questioned so far is the EPROM. It could be starting to lose its contents...Has anyone here experienced data loss in an old EPROM? I've twice seen cases which I thought could be explained by this, but circumstances didn't allow me to follow up (the ancient gear ended up being discarded, not repaired).

I ran into that once in a machine controller for an injection molding machine that was built around 1990 and had firmware in a 27C64. It was around 2004 that the client starting noticing some aberrant behavior, seemingly random errors in the machine cycle. It turned out that the EPROM was going south. As luck would have it, the client had a 5-1/4 inch floppy disk which had a binary copy of the firmware. I was able to burn a new EPROM from that file. Last contact I had with them (c. 2010) the machine was still working fine.

Posted: **Fri May 29, 2015 12:32 am**

I try to refresh EPROMs while their data is still good. I have a few commercially made pieces of equipment with EPROMs which were still working after 20 years but I knew that it would be risky to not refresh them, so I did. If they had gone south, I would have no way to recover. I think I also kept hex file images of them when I read them to program the same data back in.

Posted: **Fri May 29, 2015 8:55 am**

Interesting. I've never witnessed EPROM failure before. If that's the problem I'm sunk, because there are not many people I know of who have these machines, and those that do are too busy or aren't answering my messages.

@Jeff, I started thinking along those lines and dumped the EPROM using the monitor. Just hacking a small C program to reconstitute it as a binary file (it's ASCII HEX right now). In case you were wondering why I didn't pull it and read it directly, it's because I don't think the chip type is supported by my programmer (based on my investigation with the terminal board's character ROM).

Then I will attempt to disassemble it (something I tried with the terminal board ROM with limited success). The IPL code should be easy enough to navigate. It's a simple CLI with various 1 and 2 character commands. The whole thing is only 4k. How hard can it be?

Posted: **Fri May 29, 2015 10:51 am**

OK, I have successfully dumped the three ROMS for the P2000C:

P2000CMainROM.bin - the IPL monitor.
P2000CTermROM.bin - the terminal board ROM.
P2000CTermCharROM.bin - the terminal board character generator ROM.

See attached...

P2000C_ROMs.zip: (10.42 KiB) Downloaded 52 times

Posted: **Fri May 29, 2015 6:01 pm**

Well, disassembling the code could lead to some new insights even if the EPROM isn't at fault -- so there's value in that, even though it takes a lot of effort. But another way to approach this is to merely compute the EPROM checksum, and see if it always remains consistent.

If some of the EPROM bits are changing, it'll be because the voltage on their capacitors has diminished to the point where it is "sitting on the fence" between a valid 1 and a valid 0. In this condition, almost anything could tip the balance one way or the other; for example, a minor change in temperature or supply voltage. If the EPROM is failing then presumably there are thousands of bits in this condition.

What you could try is manipulating the temperature and grabbing multiple copies of the EPROM contents to see if any of the bits change. So we're not actually focusing on FDC routines, and we don't have to understand them. But if you can observe any bits changing then that's definitely a red-hot clue.

Posted: **Sat May 30, 2015 9:05 pm**

The ROM performs a checksum at boot up, before showing the IPL prompt. The result is compared with 0FFE and 0FFF (16 bit value) and if it doesn't match it spits an error out. "BAD ROM", I think. That's what the service manual says, though I haven't read that part of the code. It's pretty obscure...

Posted: **Sat May 30, 2015 9:06 pm**

So...

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

*** WARNING Z80 MNEMONICS AHEAD. 6502 JUNKIES AVERT YOUR GAZE NOW ***

Code: Select all

;----------------------------------------------------
; 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
        CALL SETDCB
        LD DE, STEP
        CALL JUMP
        RET

        ;Calculate offset address
GETOFF: LD HL,(DPBADDR)
        ADD HL,DE
        RET

        ;Jump to command vector (offset in DE)
JUMP:   CALL GETOFF
        LD E,(HL)
        INC HL
        LD H,(HL)
        LD L,E
        JP(HL)
        RET

        ;Setup for read track
SETDCB: 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

Posted: **Sat May 30, 2015 9:08 pm**

What it does is use the low level P2000C BIOS driver routines whose vectors 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.

SETDPB - 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 RDS (read the specified sector), executed and got the familiar C0 00 00 00 00 00 00 (ST0: D5=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. Anyone care to have a look at the main rom in the zip file)? I got pretty confused!

This is a small proggie that allows me to call the three routines without reassembly. Just need to put the offset value into the LD DE,nn instruction using the monitor.

6502.org

uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output

Re: uPD 765 FDC Sync output