Philips P2000C terminal board fault

[jonb]

Hi

Does anyone know anything about the P2000C terminal board or could advise me on what to check to diagnose it? At the moment I have a stable picture with an odd but regular pattern. It's like the CPU is not running (although it is, I can see the address lines pulsing. I've got the service manual here but I'm not sure what to test (it seems to have lots of circuit descriptions but no troubleshooting info).

This might be more a sort of general purpose "diagnose problem with non running computer" question, because the P2000C's terminal board is a computer in its own right. It has a Z80A, rom, character ROM, MC6845 video controller, memory, stacks of discrete logic.

I checked the ROM and it does look OK. I can see the error messages at the end of it. Have not tried to disassemble it yet. The character ROM is a 4k x 8 bit 2632 ROM chip for which there is no datasheet. This could be a typo in the service manual. If the board is run without the character ROM the screen shows pinstripes.

I think that, because I have a clean, steady picture that reacts to the loss the character ROM, I can assume the video controller is OK.

I'm not sure where to go from here. Here's a link to the service manual; the terminal board description starts at section 3.3.

http://electrickery.xs4all.nl/comp/p200 ... Manual.pdf

What sanity checks can I try to diagnose the problem?

[jonb]

Screen pattern. Looks regular, sort of.

Ignore the dark bars, it's the refresh vs the iPad camera. The picture is solid, but there are some tiny dots buzzing around (well, they are lines, about a character wide). You can see them if ou look carefully, they look faded in the picture.

[jonb]

This might help. I circled some of the flickering interference lines.

[1024MAK]

General Z80 fault finding:-
Check the supply voltages (including checking the ground connections)
Using your 'scope, check that

• /RESET is high (pin 26)
• /BUSRQ and /BUSAK are high (pins 25 and 23)
• /HALT (pin 18)

then check that the following are pulsing

• clock (pin 6)
• /M1 (pin 27)
• /RD (pin 21)
• /MREQ (pin 19)
• /REFSH (pin 28)

also worth checking

• /WR (pin 22)
• /IORQ (pin 20)
• /WAIT (pin 24) this is normally high unless there is a slow device being accessed.
• /INT and /NMI (pins 16 and 17) should normally be high unless the other hardware is requesting an interrupt service.

Then test the /CS or /CE pins on the EPROM chip.

Mark

[jonb]

Hi Mark, thanks for helping out! Here are the results (with a logic probe / multimeter):-

+5v -12v +12v are all present at the board power connector.
Z80 is seeing 4.95v at pin 11.

• /RESET is high (pin 26) YES
• /BUSRQ and /BUSAK are high (pins 25 and 23) YES and YES
• /HALT (pin 18) LOW

then check that the following are pulsing

• clock (pin 6) PULSE
• /M1 (pin 27) PULSE
• /RD (pin 21) PULSE
• /MREQ (pin 19) PULSE
• /REFSH (pin 28) PULSE

also worth checking

• /WR (pin 22) HIGH
• /IORQ (pin 20) HIGH
• /WAIT (pin 24) this is normally high unless there is a slow device being accessed. HIGH
• /INT and /NMI (pins 16 and 17) should normally be high unless the other hardware is requesting an interrupt service. HIGH and HIGH

Then test the /CS or /CE pins on the EPROM chip. (/CE) - PULSE

I could almost assume it is doing "something". However, the first thing it should be doing is sending a couple of characters to the mainboard - this is the handshake that causes the machine to start bootup and read CP/M from the floppy. Perhaps it is getting stuck before then (initialise video controller perhaps).

The terminal's ROM image is attached, in case you fancy disassembling it.

[jonb]

Disassembly of the ROM file. Doesn't make a lot of sense to me, and no, not because I don't understand Z80, it just does not look like a sensible program.



But then I assume it started at 0000h:

Code: Select all

0000 c31000    jp      0010h
0003 b1        or      c
0004 8b        adc     a,e
0005 2031      jr      nz,0038h
0007 2e33      ld      l,33h
0009 3003      jr      nc,000eh
000b 00        nop     
000c 47        ld      b,a
000d 2e57      ld      l,57h
000f 75        ld      (hl),l
0010 c32800    jp      0028h
0013 00        nop     
0014 00        nop     
0015 00        nop     
0016 00        nop     
0017 00        nop     
0018 00        nop     
0019 00        nop     
001a 00        nop     
001b 00        nop     
001c 00        nop     
001d 00        nop     
001e 00        nop     
001f 00        nop     
0020 00        nop     
0021 00        nop     
0022 84        add     a,h
0023 0e3c      ld      c,3ch
0025 0ebc      ld      c,0bch
0027 0e08      ld      c,08h
0029 af        xor     a

So we can see it jumps immediately to 0010h, which then jumps to 0028h which is in the middle of an instruction (ld c, 08h) which is nonsense.

[dp11]

The disassembler has lost synchronisation because of the data before 0028h.

[1024MAK]

/HALT (pin 18) being LOW means the Z80 has HALTed. It then just does NOPs (no operation cycles) to maintain RAM refresh (for DRAM) while it waits for either /RESET, /INT or /NMI. A likely cause is the ROM code detecting an error, or a memory fault. But do recheck the /HALT pin in case it was a one off error.

The zero page can contain a jump table, or short routines that are positioned to take advantage of the fixed interrupt vector or the Z80 RST jumps. Often not all of this area is valid machine code. This area is often jumped over by the reset / start up routine. So whenever there is a jump, disassemble from the jumped to address...

Mark

[jonb]

Yes, /HALT is LOW.

However, if it is really HALTed, why are some of the address lines pulsing? It should be executing NOPs internally.

Oddly, both NMI and INT are both high. I need to read up on how these signals should behave. Do they stay high throughout an interrupt routine or pulse once for an interrupt?

All rather strange. A7 is low but other lines are pulsing. /CE on the ROM is pulsing, but none of the data lines are.

Actually A7, A8, A9 and A13, A14, A15 are fixed low. All other addres lines are pulsing. So I might conclude there is an issue with A7-A9 lines (as I think the top lines are not necessarily indicative of a problem if the CPU is accessing lower memory). A10, A11 and A12 are pulsing so the gap at A7-9 is worrying.

[1024MAK]

First, after every instruction fetch, /REFSH pluses low and at the same time address lines A0 to A6 will have the refresh address on them (a 7 bit number that increments at least once every instruction cycle). The address is actually the contents of the I and R registers. At this time A7 reflects the contents of bit 7 of the R register and A8 to A15 come from the I register. Unless set by the program, bit 7 of the R register (and therefore of the refresh address) will be zero.

When HALTed, IIRC, the Z80 still performs an instruction fetch, it just discards the result. Hence why it is said to be doing NOPs.

Unless and until external logic circuits drive either /INT or /NMI, these should be pulled high. /INT is suppose to be level sensitive. While /NMI is edge triggered. With both, different hardware can produce various pluses, some hardware will hold the /INT line low until the CPU acknowledges the interrupt.

So this would explain the signals.

The Z80 should only HALT when it executes a HALT instruction.

Programs / programmers either use this to get the CPU to wait for an interrupt, or to halt execution in the event of an error that cannot be handled.

However, if the CPU tries executing garbage code, it may come across a HALT instruction.

Mark

Edit: tidy up

[1024MAK]

More on Z80 HALT here(PDF).

Mark

[jonb]

The databus is fixed and showing 01100011 or 63H.

Wouldn't it show 76h (HALT opcode) if the CPU had encountered a HALT?

[jonb]

NMI routine at 66h

Code: Select all

0066 ff        rst     38h
0067 b7        or      a
0068 cd7f01    call    017fh
006b 3a0180    ld      a,(8001h)
006e b7        or      a
006f 2810      jr      z,0081h
0071 cd6003    call    0360h
0074 3a0481    ld      a,(8104h)
0077 b7        or      a
0078 ca6b00    jp      z,006bh
007b cd6f09    call    096fh
007e c37400    jp      0074h
0081 cd8600    call    0086h
0084 18ee      jr      0074h
0086 210782    ld      hl,8207h
0089 cb66      bit     4,(hl)
008b c8        ret     z

008c cba6      res     4,(hl)
008e 210080    ld      hl,8000h
0091 cb96      res     2,(hl)
0093 7e        ld      a,(hl)
0094 d341      out     (41h),a
0096 cbee      set     5,(hl)
0098 cbd6      set     2,(hl)
009a 7e        ld      a,(hl)
009b d341      out     (41h),a
009d c9        ret     

[1024MAK]

The description of what happens during HALT is on page 28 of this Zilog document (PDF).

In your ROM listing, at the start of the /NMI routine, at address 0x0066 the first instruction is RST 38 (called restart 38). This puts the PC on the stack and then jumps to address 0x0038. Address 0x0038 is the start of the /INT routine if the Z80 is in mode 1 interrupt mode.

In your first ROM disassembly, the jump to address 0x0028...

Code: Select all

0x0028  08  EX AF,AF'  exchange registers with shadow registers
0x0029  AF  XOR A      clear accumulator and clear carry flag

I don't know for sure if the PC is advanced before the Z80 has HALTed, but I think it may do. If so, the data read from memory will be the data at the address after the HALT instruction.

I hope some of this helps

Mark

[jonb]

Yes, it helps a great deal, thanks!

I had worked out the RST thing and the code starts to look sensible from there. Sort of.

I did try to invoke an NMI by zeroing the /NMI line and it upset the screen a little. Lost vsync and started rolling. Same image though.

Should we assume the ROM is sane? It's a standard EPROM but there wasn't a label over the window. The character anD mainboard ROMs both have Philips stickers with a copyright message on them. The processor has a sticker with a red cross marked on it. Also "0.1". I wonder if it is borked, and someone marked it thus?

Anyway I could swap it out when the "El Cheapo" desoldering station arrives.


Cheers
JonB

[1024MAK]

Jon, don't leap to conclusions yet. I have no idea why the Z80 has been marked this way. So far the Z80 appears to at least be doing something.

Right, I've just started browsing through the service manual. It gives a lot of information, but it is hard work piecing together how the system works.

I did notice that the DRAM is the type that requires three supply voltages. So as this type of DRAM chip (uPD416C-5, equivalent to the more common 4116 DRAM used in the ZX81 16k RAM packs and ZX Spectrum plus many other computers) are known to sometimes fail. So please test the voltages on the pins of one of the uPD416C-5 DRAM chips. Also check to see if any of the DRAM chips are noticeably hotter than the others.

Pin 1 VSS -5V
Pin 8 VDD +12V
Pin 9 VCC +5V
Pin 16 GND 0V

Mark

[jonb]

Sorry, only speculating. You're right, shouldn't do no jumping.

Will check the RAM voltages presently, but I do know that the power supply to the board is all present & correct.

[bprosman]

//Little offtopic
@Jonb,

Actually curious what el-cheapo desoldering station you have ordered and how it works for you.

Kind regards, Bram

[jonb]

Check here viewtopic.php?f=41&t=5594&p=112229#p112214 and after reading my first post scroll a bit.

[jonb]

@Mark: I fixed the mainboard and it's booting into CP/M using a PC running HyperTerm with the serial port connected to the internal port used by the terminal board. There were two issues - a blown Zener diode in the FDD PLL circuit (spotted by Bryce@CPCWIKI) and a damaged 74LS74 that provides the WCLK pulse to the FDC (spotted by me and my lovely new Rigol scope). Counterintuitive that a signal used for writes should affect reads, but I found a version of the datasheet that said its needed when reading too.

Anyway, hurrah, another lovely old machine (partially) resurrected!

Now I am going to look at the terminal board again, starting with those RAM voltages. It's quite important to get this working because apart from making it a full repair, the P2000C's configuration utilities seem to be using special control codes that none of my terminal emulators recognise, so I can't set it up properly. Besides, the P2000C's terminal does high resolution graphics (which I expect are what all those control codes are doing, trying to draw boxes round menu items).

I did try to see if anything was running hot, couldn't feel any excess heat anywhere. I have some spare 4116 Chips lying around... Hmm.. Have I got enough chip sockets, though? It is probably not worth swapping them all out right now, but when you have a desoldering station to hand...

If you have any more ideas do let me know. Cheers!

JonB

[richardtoohey]

Can't help you but

Anyway, hurrah, another lovely old machine (partially) resurrected!

for that and your persistence.

[1024MAK]

Well done Jon

If you suspect the DRAM, you could program a test "ROM" (using EPROM or EEPROM maybe). With the Z80, it is not difficult to put together short test programs (no working RAM required as long as you don't use the machine stack, interrupts, subroutines or such like) and it has enough registers that you can even write more complex test programs or even simple applications that can run without any main RAM.

From reset, the Z80 starts at address 0x000. So program this short bit of code to start with:

Code: Select all

ORG 0
START  DI          Disable maskable interrupts
START2 LD A,0
       OUT(n),A    output to port n (suggest printer port)
       LD B,FF
LOOP1  DJNZ LOOP1  slight delay
       LD A,FF
       OUT(n),A    output to port n (suggest printer port)
       LD B,FF
LOOP2  DJNZ LOOP2  slight delay
       JP START2

This will repeatedly send 0, then FF to the chosen I/O port. If you have a printer port or similar, it should be possible to see the regular pattern. If you do see this with a 'scope (or logic probe), then you know that the Z80, some of the address bus and the data bus are working okay

Mark

[jonb]

DRAM voltages look good.

[jonb]

Unfortunately, I can't see any ports to write to, so I will attempt this:

Code: Select all

;----------------------------------------------------
; Project: termtest.zdsp
; Main File: termtest.asm
; Date: 03/06/2015 08:59:29
;
; Created with zDevStudio - Z80 Development Studio.
;
;----------------------------------------------------
        ORG 0
START:  DI              ;Disable maskable interrupts
START2: LD HL,02000h    ;End of ROM / start of RAM
        LD C,0          ;Initialise value counter
LOOP0:  LD A,C
        LD(HL),A        ;Copy counter to current address
        LD B,0FFh
LOOP1:  DJNZ LOOP1      ;slight delay
        INC C           ;Next counter (will wrap at FFh)
        INC HL          ;Next address
        LD A,H          ;Check H
        OR A            ;Is it zero? (Wrapped)
        JP Z,CMPL       ;Yes, check L
        JP LOOP0        ;No, loop round
CMPL:   LD A,L          ;Check L
        OR A            ;Is it zero?
        JP Z,LOOP0      ;No, loop round
        JP START2       ;Yes, restart loop from 02000h

It's just going to write a count into every RAM address continuously. I can then check the address and data lines for pulsing. Bonus if anything changes on the display..

(Edit: Oh. I've got no 2764 EPROMS. Can I use a 27128, I wonder? With mods, of course.)

[jonb]

I burned to a 27128 and whacked it into the socket, because the pinouts are the same (except for A13 which is NC on the 2764).

All data and address lines are pulsing, and I think they are counting. I haven't yet worked out how to get the Rigol to record the waveforms, so I can't be sure I am getting the right number of pulses per address line - for example I expect A(n) to have twice as many pulses as A(n+1), but I can't see how to measure it yet.

What I want to do is trigger on A0 and record it and A1 to see if they really are counting properly. Where is the menu option for that on this scope, anyone know?

Anyway.. the screen is blank, which I think means the controller hasn't been initialised. Of course, because my program is just looping through memory. So, tentatively, I am going with the assumption that the CPU is OK. So far...

[jonb]

Quick check of the RAM chips. There are two banks of D416 (16kx1bit) DRAMs.

D416.JPG (23.27 KiB) Viewed 2041 times

All of the CAS / RAS lines are pulsing. Not sure how I tell if data is coming out, but I checked the D(out) lines in both banks. The results are

Code: Select all

         
Data   : 01234567
Bank 0 : nppnnlll    <- Video refresh memory
Bank 1 : nppnnlll    <- Attribute memory

(n=no signal, p=pulsing, l=low, h=high)

This does rather point to a memory problem although it is suspicious that both banks are showing exactly the same pattern. That said, there is a sort of regular pattern on the display (refer to the OP), although not every character cell is identical.

[1024MAK]

The Z80 CPU will be producing addresses on the address bus for instruction fetches, memory refresh, and the memory writes that your program does. So without having the trace on the 'scope synchronised, the screen will be a bit of a mess of hard to understand waveforms.

Use the 'scope in the storage mode.

To start with I suggest you trigger on /REFSH (active low signal), then once you have got the trigger setting to lock onto this signal, you should be able to see address lines A0 to A6 counting. The count goes zero to 127 and then restarts at zero. So A0 should be changing at a rapid rate with the higher address lines going at a slower rate.

Once you have sorted that, have a go at triggering on /M1 (active low signal). This goes low whenever the Z80 CPU carries out an instruction fetch (but not for any data that the instruction requires from memory). So you should be able to see the addresses aimed at the ROM and the data on the data bus from the ROM.

Mark

[jonb]

Use the 'scope in the storage mode.

Don't know how to - yet. The "Storage" button is for loading / saving files to a USB device. I think I need record, with trigger, but how to get that is anyone's guess!

[jonb]

Here's another trace.

Yellow is !RFSH, blue is A0, cyan is A1.

I don't know what it is saying. I expected twice as many A0 pulses as A1s, because it is cycling through memory.

[1024MAK]

That image looks like you do have the 'scope in "storage" mode.
If you look at the two address lines, every time the yellow trace (/REFSH) is low, they are counting up. Of course I was slightly confused due to the magneta coloured trace...

The DRAM chips are that manufacturers version of the 4116 DRAM chip. In most Z80 systems the data out and data in pins are connected together. So if you monitor one, you will see write and read data.

Mark