Hi,

I have an 9825A which has (apparently) clock problems. The following image shows the MasterClock signal (MClk) in the green trace. Obviously it does not look anything like a clock signal :-(

The yellow trace (squarish waveform) is the output of the the MC4024 (pin 6), so the first part of the MC4024 appears to work, but the second part or somthing else is causing mayhem. Any ideas?

The following diagram (by Tony Duell) shows where I took the measurements: The yellow arrow corresponds to the yellow trace, while the green arrow (pointing to Mclk) corresponds to the green trace.

Thanks

**vp

I assume you realise that the HP9825 clock is somewhat unconventional. U8a 'wobbles' the frequency of U8b, this 'spreads out' the RF noise from the system, and IIRC got it through some FCC-type approval.

I'd start by removing that unmarked electrolytic capacitor in my diagram. That should allow U8b to run at a fixed frequency. Then look at the output (green trace) again. Make sure your scope is not aliasing this signal (I have an major distrust of DSOs, particulalrly PC-based ones!).

U8 itself might be faulty, of course.

After spending lots of time with the clocks I have moved on to the bus logic (I am actually quite happy to be there, as I was afraid that the CPU hybrid was fried).

The problem here is that I get something that looks like bus activity, but not what I'd expect. Specifically, while I did get MRdy asserted at one point, I can no longer recreate the same behaviour.

Initially the system would produce this activity (with the RAM boards (one 8Kb and one 16Kb) and system ROM board connected):

(once) and then settle down to this:

After moving things around (to connect the keyboard) I got this. Notice that there is no activity on the bus lines.

Fearing that there was smthg wrong with the RAM, I left only the processor board and the system ROM:

Now there is bus activity. So I add one RAM board (the 8Kb),
update the DIP switches on the processor board and add the keyboard.

Now I do see activity on the MAD lines, and a Wr pulse, but no MRdy.
Is the RAM causing problems? Is the system expecting smth from the kayboard processor? Why did the MRdy get asserted in the earlier run? Strange!

**vp

I now suspect that the problem is with the system ROM module (on the 9825A its a huge plug in drawer). The traces I posted earlier indicate that the machine is stuck trying to access a memory location. Unfortunately the logic analyzer I am currently using only has 8 data lines, so I will have to use my HP1630D instead.

(so no colour screendumps, but many more channels :-)

**vp

Quote:

---

(so no colour screendumps, but many more channels :-)

---

Just take pictures with a digicam!

Marcus

vp-

(I previously had this machine in my possession when it was working.)

IIRC, you replaced the connector on the system ROM board because it was cracked. Did you check for hairline cracks in the traces on the board near the connector?

-kw

I had a quick look at the schematics last night. The MRdy signal is generated by the (dynamic) memory boards only, and is used to put the CPU into a wait state while the the DRAM is read (or during a refresh cycle, etc). It is not connected to the ROMs (either the ROM modules or the system ROM). If you suspect a problem with this signal, you can trace through that logic on the RAM board, it's all simple TTL, nothing custom.

I assume you realise that the schematic that is labelled 'HP9831 System ROM module' also applies to the 9825A. I have a 9825B (ROMs on one of the internal memory boards) and a 9831 (which has a System ROM plugged into the right hand side). Hence the title on that diagram.

Hi Katie,

I did not replace the connector, but I did check for electrical connectivity and it is making good electrical contact.

I am waiting for some parts in order to connect the system rom to my logic analyzer and then I'll be able to check the full address/data lines and make some sense of what the CPU is trying to do.

**vp

Yes the MRdy is only used by the RAM. You can see that in the first screendump, when the Wr signal is asserted, the MRdy is also asserted indicating that the memory cycle worked. Also in the 3rd screendump, I suspect that what I see is a RAM read cycle, but without the full bus I can only speculate (actually, I could possibly check high order MAD lines to see which part of the address space is being accessed, but I'd rather wait to connect the 1630 and see all the lines (I am waiting for some parts to allow me to connect the pods to the data lines -- just connectors and clips really, to save me soldering things).

My intent is to wire the EO, ALE, and MAD lines to the analyser and a PC-based computer and check to see whether I can access system ROM locations.

BTW is there a checksum in the system ROM, or somethig I can use to verify that the data I am reading are correct?

**vp

I managed to fire up my HP1630D logic analyzer and got much further in my investigation. I can trace the boot process from the time the POP (power on pulse) is asserted.

I see that the CPU is loading code from the system ROM and is executing it (uses the vector at 0x0020 to jump to address 0x1000 and does things that look reasonable, e.g. loads R4 from the keyboard).

I was lucky to have found the assembler manual for the 9835 on bitsavers, because the site down under had a disk crash and lost most of the 9825 stuff (I think they'll restore it eventually).

So the CPU is doing stuff, but the machine still looks dead [1]

Unfortunately looking at Tony's schematics I see that the SHIFT LOCK and the RESET keys behaviour is independent of the keyboard controller, so the fact that they sort of work does not say anything about the rest of the keyboard electronics.

I will have to look into the keyboard more carefully and try to see what is happening there.

Any ideas/suggestion, are welcome.

BTW this is the code I managed to disassemble (all addresses are in hex):

0020    e821    JMP 0021,I

     location 0021 contains 0x1000, so we jump to ...

1000    007f    LDA 007f

1001    300f    STA D

1002    3009    STA Pa     ; store 0 in Pa, to select kbd controller

1003    0005    LDA R5     ; read keycode register of kbd ctrl    

1004    f142    RAR 3

1005    7702    RLA 1007

      here we skip one instruction and jump to ...

1007    086c    LDB 006c

1008    00b3    LDA 00b3

1009    7440    RIA 1009

      this is a loop, which filled the memory of my logic analyzer

      with the same pattern, so the disassmbly stops here

**vp

[1]
blank display, no response to key presses, except for "Shift Lock" which
turns the appropriate LED on/off and RESET which pulls POP low. Also I
disconnect the I/O connector from the keyboard assembly (but leave the
power harness in place), when I power up the machine, all characters on
the display light up and a continuous beep is heard. I assume this is
normal as the keyboard assembly is waiting for the CPU to reset it?

Edited: 29 May 2006, 8:22 a.m.

I have typed in hundreds of pages of the ROM from the patent (and spend hours debugging it). I don't have my sources at my work, but if I recall correctly, it fetches the available RAM and zeros it.

By the way, when you write "here we skip one instruction and jump to ...", something surprising is happening:
The KBD-info read contains a bit indication the Display-size. The display-size is stored in a variable (a memory location), and is actually used in the display-routines. It can be 16 or 32.

So the loop filling the memory of your analyzer determines the RAM-size and zeros it. There will be differences between your ROM and the ROM in the patent, but I am sure they kept the RAM-checking!

I can provide commented ROM-Code, and I have a simulator (pre-alpha) the permits you to step through the execution. If you need any of those, I can provide them!

Good luck! Klaus

Can I make a somewhat cheeky request?

I would be interested in the commented ROM sources for the 9825. Any chance you could send them to me?

Thanks in advance.

I managed to get the lazy T prompt and the calculator works fine, with the exception of one of the RAM boards.

The 9825 had two RAM boards, a 16Kb and an 8Kb, strapped with the 16Kb first in memory.

Klaus's comments about the patent caused me to download the two patents for the 9825 from Eric's site http://www.brouhaha.com/~eric/hpcalc/patents/ (many thanks to Eric), so for the first time I actually had some clue what the code I was seeing was trying to do. Klaus was right about the memory check, although the code I was seeing is earlier in the listing, the

1008    00b3    LDA 00b3

1009    7440    RIA 1009

code is just a wait loop.

Anyway, once I knew about the wait loop, I programmed my logic analyzer to start recording at the 1st instruction after the loop, which allowed me to observe the memory test sequence.

Here was the big clue, while the CPU was trying to save a pattern in RAM, the MRdy was not asserted.

Hmmm, which made me think that there may be a problem with the RAM. I removed the 16K board and replaced it with the 8K board, and for the first time I got a prompt.

Looking at the 16K board, I saw a missing tantalum capacitor (those tiny blue ones). I do not suppose this can be the fault, but I wonder how important these things are.

Many thanks to Klaus and Tony.

Now I have to see why that 16Kb board is not working.

**vp

BTW you may be wondering why the machine did not work earlier when I was using just the 8Kb board. This is because I was working under the assumption that the 8Kb board was strapped to be the first board in memory, which was wrong. In the traces you can see that the MRDy is properly asserted in this case, but the machine would not boot because it had a 16Kb hole in its RAM.

The commented ROM I was talking about is the source in the patent. I just typed it into an ASCII-File (leaving out the cassette operating system and the extended math routines).
If you are still interested, I can send it to you.

Btw. do you have an idea how the addressing works? There is a RELA-signal that switches the addressing modes, but I don't know how this signal is being changed (I did not find an instruction for changing this).

A lot of time missing tantalum capacitors across a power plane occcured because they went dead short and then exploded into a puff of misery... Can you see the lead still sodered to the board? Pieces of the corpse scattered about the premises?

Also not all tantalums are in power supplies. It could be in a pulse forming or timing circuit and would be important. Otherwise a dead tantalum would probably not affect operation of the circuit (particularly if other caps are there to take up the slack)... the HP 65/67/97 card reader being a notable exception.

Quote:

---

The commented ROM I was talking about is the source in the patent. I just typed it into an ASCII-File (leaving out the cassette operating system and the extended math routines).
If you are still interested, I can send it to you.

---

That would be great. Plain text files are a lot more use to me than pdfs...