9825T ROM failure
#1

I have a 9825T (which is a 9825B with additional RAM and ROM) with build-in Plotter/General IO/Extended IO and String/Advanced Programming ROM. The latter one is not functional. I assume, the IC part numbers are 1818-1273 and -1274 soldered on position U36 and U26.
On the memory board (not CPU board) there is a switch "32K/64k" which obviously enables this ROM pair. When disabled, the ROM is not detected, when enabled the machine hangs. Also, when I plug in a String/AP ROM-module (from another 9825A), this is not detected. Does anybody have a similar configuration and can check what happens when the 32K/64K switch is in the 32k-position? Any idea what is the cause of the malfunction is welcome.

Achim

#2

Hi Achim,

The problem may not be in your ROMs. The main difference between the 9825B and 9825T is the addition of a second RAM board. The 9825B with only the standard "A24" memory/ROM board can be configured to have either 32K RAM with General IO & Plotter or 22.9K RAM with all the ROMs enabled (this due to the way memory is mapped), depending on which way the DIP switch is set. The 9825T adds the "A25" memory option, but it is still controlled by the DIP switch on the A24 board. The way the 9825T adds another 29.5K of RAM is with special circuitry that maps RAM on that card to the ROM address space, and then on a cycle-by-cycle basis determines whether a given address is a RAM access or ROM access. The address space of the 9825 architecture is 32K 16-bit words, or 64K bytes, yet in the 9825T they manage to fit 61K of RAM and nearly 32K of ROM all in that space by their clever method of sharing part of the space between ROM & RAM.

I would recommend removing the A25 memory (not sure what the actual part number is), which is the card without the Plotter & RAM DIP switches (which will basically give you a 9825B), and see if you can access the ROMs with the switch not in the 32K position. That should at least assist in isolating whether you have a problem with the ROMs or with the RAM board. Also, I doubt seriously that the 9825T can properly access 9825A plug-in ROMs anyway due to the address-space-stealing method used to add the extra RAM. Good luck, and let us know how things turn out.

Alex K.

The Calculator Museum Web Page

http://www.calcmuseum.com

#3

Thank you, that clarifies something. Well, I already removed the A25 board but the failure remains. From your explanations I wonder why I can access the full 62K RAM with both boards plugged in, although the switch is in the 32k position. Could it be that some of the "upper" RAM is defective? I had a faulty RAM in the lower 32k. But that fault led to a reduced free memory not to a hangup. And the upper RAM wasn't detected.
After replacing the RAM the lower RAM as well as the upper are completely scanned. LIST 9999 gives 61812.
Do you have schematics of the 9825T? I only have those of the 9825A patent.

Achim

#4

Hmmmm,

No schematics, unfortunately. Sure would be nice to have a full set (for _any_ of the desktops). It could be that from a memory scanning point of view, the routine that figures out how much memory is present doesn't pay attention to that switch position. The main function of the switch appears to be to tell the A24 board whether or not to enable the ROMs beyond General I/O and Plotter. Maybe all the switch does when you put in the A25 board is to enable the other ROMs on the Board, and doesn't affect the RAM. It really does sound like you have a bad ROM chip or something bad in the decode logic (I'd put my money on the ROM since I've had a few of those go bad elsewhere). Per my last posting I don't think you can simply use a ROM from a 9825A.

Alex K.

The Calculator Museum Web Page

http://www.calcmuseum.com

#5

A faulty rom sounds like a death sentence. Any means to save such a machine? Do rom-dumps exist for any of the desktops?

Andreas

#6

I don't think that ROM dumps exist for most of the 9800 series desktop machines because HP didn't usually use industry standard ROM devices. In many cases HP was "ahead of the curve" and developed their own ROM technology. I've seen this in both HP Journal articles and by talking to people who used to work at HP. In some of them, the ROM chips do more than just the ROM function, they have address latching and/or decoding. In other cases, it may be possible to make a pinout adapter for an industry-standard ROM to fit in the spot of a bad one. I have a 9830A with a bad ROM and would sure like to fix it, and it would also be great to be able to get the Option ROMs copied for the earlier machines, but I haven't found anybody who has successfully done those things (so far). Without schematics for the 9800 series (which don't seem to exist), it would be difficult to reverse-engineer (although Tony D. may be able to help out here, Tony ????? ).

An exception is the HP85 series, while the ROMs themselves are special, there is the "Programmable ROM Drawer" device available that uses 2764 devices (with a bunch of external circuitry to emulate the address latching/decoding/etc. inside the ROM chip), and Vassilis Prevelakis has a bunch of the ROM images on his great website.

Alex K.

The Calculator Museum Web Page

http://www.calcmuseum.com

#7

I've not (yet) dumped the ROMs from most of my 98xx machines -- I have done the later version of the 9815, which as it used an industry-standard CPU (6800) and reasonably-standard 8K byte ROMs (similar to one of the Rockwell devices, but IIRC there was an internal address latch!), it wasn't hard.
The 9825 shouldn't be too bad. The early machines did have HP custom ROMs with multiplexxed address and data buses (IIRC), there were standard-ish ROMs in later machines and in some of the modules (which contained an bit of TTL for the address latch, etc).
The 9810/20/30 are more strange, but it should be possible. One ongoing project is to make a board that replaces one or more of the CPU boards in such a machine and which allows another computer access to the memory (this is entirely possible, and the point of replaicing a CPU board is that it works on all the machines). Then you could test RAM, dump ROMs, etc.
Doing this needs a good set of schematics (I have them), and a fair understanding of how the machine works (I am working on this).

#8

Yesterday I checked the RAM by creating a large (60k) array and filling it with pseudo-random numbers. I could read all values back correctly. So the adressing seems ok.
On the other hand I found out, that also the build in Extended I/O is not functional. So all ROMs with adresses >=40000(oct) are involved in the malfunction (i.e. String, Adv. Ürog., Extended I/O).
A plug-in Matrix ROM from a 9825A works! It's in the adress range below 40000. Also the Flex.Disk Drive ROM seems to work, although I havn't a 9885A to check it out.
For further investigation it would be helpfull to know the adressing logic of the ROM. Any hints?
To find out if the 9825T ROMs are the same as in the plug-in modules I would need the HP part numbers of the latter. Has anyone yet opened a String/AP/ExtIO ROM module? One would have to brake the case or drill out the rivets :-(

Achim

#9

The problem sure sounds like it is in the addressing and not in the ROMs themselves. It is interesting that you get the hangup when the DIP switch is in the 64K position whether or not the additional RAM board is there or not. The RAM board has the logic for the address-sharing scheme that maps RAM & ROM, so the problem doesn't appear to be with the remapping. Schematics would sure be handy so you could see if the decode for ROMS >40000 is going somewhere else! (which would be my guess)

In the standard 9825B, you can't have both the Systems Programming and the Matrix ROMs plugged in at the same time (and you don't get the Systems Programming ROM functionality from the internal ROM set), but the 9825T enables the on-board Systems Programming ROM _and_ allows you to plug in a Matrix ROM in a front slot. Not sure this is at all related to your problems but it is interesting to note how the 9825T re-maps things.

Alex K.

www.calcmuseum.com

#10

I have found what I think is the schematic -- the 09825-69524 PCB. It's one of the hand-drawn HPCC ones, of course, so signal names and component locations may not agree with anything from HP.
Anyway, theere are 10 ROMs on the board -- the diagram implies they're pinned out as 2332As, but they may have internal address latches. Each is 4K*8 bits, they're arranged in 5 banks of 4K*16 bits.
Anyway, the address ecoder is not exactly simple, but the 32K/64K DIP switch seems to disable the 'Option B ROM) (this is enabled by U49b ('00), which is then driven from U50d ('04), from output b3 of a '155 (U46)).
I would start by checking that this cirucit is doing what you expect -- if for some reason the ROM is stuck in the enabled state, then it's going to crash the machine. Other than that, I would suspect the ROMs themselves (maybe one has failed in a nasty way).



Possibly Related Threads…
Thread Author Replies Views Last Post
  A prime failure Jan 17 5,536 12-06-2013, 08:02 PM
Last Post: Michael de Estrada
  IR printer failure Andrew Nikitin 7 2,415 11-05-2013, 11:25 AM
Last Post: Andrew Nikitin
  HP 2225D+ RAM failure/replacement Luca 4 1,884 09-10-2013, 01:46 PM
Last Post: Luca
  HP85 Programmable ROM cardtridge 82929A-service ROM not working- inaki 2 1,836 04-25-2013, 08:08 AM
Last Post: inaki
  17bii failure db (martinez, ca.) 5 1,969 01-16-2013, 03:12 PM
Last Post: Jeff O.
  shelf life time of a ROM, EEPROM, EPROM vs Mask Rom Guido (Canada) 6 2,911 01-11-2013, 04:09 PM
Last Post: Thomas Falk
  Big ROM - 41 System DEMO ROM Ángel Martin 5 2,514 10-16-2012, 05:28 AM
Last Post: Ángel Martin
  Expected lifetime and failure modes of vintage 15C? Eric Zoob 30 6,720 03-22-2012, 12:02 PM
Last Post: Juan J
  Classic HP LED failure diagnosis aj04062 2 1,273 09-17-2011, 05:28 PM
Last Post: aj04062
  HP-48G IR Test Failure aj04062 7 2,173 07-10-2011, 09:22 PM
Last Post: Paul Berger (Canada)

Forum Jump: