HP 9845 C with 280 option startup failure

[Tony Duell]

> 
> I recently acquired a HP 9845C option 280 (was looking for it for a 
> really long time).

I don't know all the option codes for the 9845. I assume at least this 
has a 98770 colour monitor nad the high-speed (bit-slice) language 
processor option.

Firstly, try contacting the HPCC secretary, Dave Colver (I think the 
details are on the HPCC web site, http://www.hpcc.org/ , if not, ask me). 
If you ask him nicely, he might send you a reverse-engineered schematic 
for the 9845. This is for a 9845B with the high-speed lagnuage processor 
and the 98780 enhanced mono monitor, so it's not directly applicable to 
your machine, but it might be a start. Be warned that it's over 200 pages 
long (that is _just_ a schematic).

The HP service manual is on http://www.hpmuseum.net, along with a manual 
for the colour monitor. These do not seem to cover the high-speed 
language processor at all, and they are boardswapper guides with no 
schematics or even pinouts. But you probably should read those too.

I would love to see inside the colour monitor (that is, I'd like to pull 
one apart and really examine the boards. I am told there are some 2901's 
in there for the video processor. The 98780 mono monitor has an HP 64 pin 
ASIC for this.

> 
> The machine is in an overall good condition, however it hangs during 
> memory test ("MEMORY TEST IN PROGRESS"), even after cleaning all board 
> connectors, resocketing all ROMs & repeated control-stop's. Before 

Hmmm... Probably toally irrelevant, but there's a signal from the monitor 
to the I/O processor -- basically a frame-rate interrupt, that IIRC has 
to be present for the bus arbitration to start up properly. If you run 
the machine without a monitor there's a turn-on fixture that you have to 
plug into the LH monitor connector (on the video interface PCB) to 
provide this. 


> entering nirvana the printer outputs a couple of memory addresses. 
> Although lots of defects may be responsible, I assume there is a 
> combination of both a bad RAM chip and a ROM failure, since a RAM defect 
> alone should (?) not crash the system during the test.

Maybe... Maybe not...

How much do you know about the buses of this machine? It's not at all 
simple. There are 2 processors -- the PPU (Peripheral Processor Unit) on 
the left side and the LPU (Language Processor Unit) on the right side. 
Each processor has buffers/latches on the board that connect it to one of 
2 buses (I think HP called them X and Y, I call them L and P for obvious 
reasons). The L bus carries all the memory on the LH boards, and the ROMs 
in the RH drawer. The P bus carries all the memroy on the RH board and 
the ROMs in the LH drawer (I think I've remembered all that correctly). 
Also, the test side of the video display does DMA from main memory via 
the buffers on the PPU board, it transfers a line of text at a time to 
buffer storage on the interface PCB and thnece to the text board in the 
monitor.

What I am wondering is that if there's a bus problem, or the arbitration 
logic (which is spread between the 2 processor boards) is playing up, you 
could get some really odd failures.

 
> The printout looks like this:
> 
> 000000 100112 052525
> 000000 110112 052525
> 000000 120112 052525
> 000000 130112 052525
> 
> I guess the first number is the block ID, the next is the memory address 
> within the block, and the last number is the test pattern, each in octal 
> representation.
> 
> Does anyone have an idea
> 
> - how to really interpret the memory test printouts and

Alas not, and I don't think there's anything in the service manual. The 
schematic would at least relate addresses and bits to actual chips.

> 
> - how to check the ROMs for bad data?
> 
> Maybe there is anyone out there who did the job to read out the contents 
> of his 9845 ROMs (they are all in sockets) for a direct comparison. 

I haven't done yet. What I can tell you is that these are not totally 
standard ROMs, they have internal address latchs (the buses on the 9845, 
like that of the 9825, being multipexed address and data). You ahve to 
deassert and reassert the chip select line after changing the address to 
latch the new address in.

I hope the above is a start. I'll carry on thinking about it.

-tony