Different HP-71Bs



#23

Here you can see two different HP-71. The lower one is a standard 2CDCC version, the upper is not working yet, but I have a similar item (optically), that is running 0AAAA ROM.

Just to list a few differences between the standard and the upper item:

  • Normal keyboard template is plastic, upper is metal.
  • Normal keyboard has blue labels “CRL”, “ |< ”, “ >| ”, “ERRM”, “CMDS”, “1 USER”. All these labels are missing in the upper unit (as in my 0AAAA Prototype).
  • Normal keyboard has yellow second-functions labels, the upper unit has orange second-functions labels.
  • Normal keyboard has light brown numerical pad, the upper unit has grey numerical pad (as my 0AAAA Proto).
  • Normal mainboard is labelled “00071-xxxxx, the upper mainboard with “00044-xxxxx”. Was there a idea of a HP-44?
  • Normal board has 5 brown daughterboards (memory?) labelled “5180-2939”, the upper unit only has one daughterboard and is labelled “5180-2912”
  • Normal unit has zebra stripe contact between keyboard and power-board (like in the HP-41 Fullnut), the upper contact is made by a flaw cable glued on both side (maybe that´s why the calc is not working).
  • On the mainboard of the upper unit is a hand note “3- 04-26-1 25”. What might this mean?
  • In the HP-IL Port of the upper unit there is a not functional resistor (brown-black-black-golden-brown) soldered from Pin1 and 5.
  • Plastic backside of the upper unit is prepared to cover a metal plate
  • The upper unit doesn’t have a serial number.

Tony? Can you repair this calculator and might it be worth?


#24

We had heard that the 71B was called the "44" for awhile in the early '80s. Could you show us a picture of the keyboard?

Thanks,

Jake


#25



#26

I have an HP71 service manual... I also have fixed a fair few of them...

Now, to comment on your machines. The lower one is a fairly normal late-production version with the zerbra strip between the 2 PCBs. Most have the 2CDCC ROMs. This is the rarer version in the UK, most were more like the upper one.

I was going to say your upper one was a standard early-producion model. But it's not. Look at the memory hybrids (lower PCB, between the plug-in ports). Production machines, either version, have 4 off 4K RAM hybrids and 1 off 64K ROM hybrid. You only have 1 hybrid. And you have the (white) jumper to the left of them. This is shown in the service manual schematics, but never commented on. However, it's clear what it does, it completes the configuration chain (this will make sense if you know the saturn bus hardware) if you only have one RAM hybrid fitted. It appears there was going to be a 4K RAM version, which AFAIK never went into production. I wonder if you've found one!

Now, with 1 hybrid, you either have just RAM, or just ROM, I think. This may be why your machine doesn't work. RAM is entirely soft-configured, it would therefore be worth sticking a 4K RAM module into one of the front ports and seeing what happens. More likely, though, it's the ROM that's not present. This may have been a development machine for testing ROM code from an external emulator box or something.

I will see if I can find the numbers of your hybrids in my service manual. I am a little puzzled that you claim all 5 hybrids in your later machine are the same. I am sure one is 'odd', being the ROM.

FWIW, the 71 was orignally going to be called the HP44, I think. I've seen documentation mentioning it by that number.


#27

Hi Tony

You are right, the lower of the middle hybrids seems to be different from the others... But I wonder, that in the "special" unit the hybris is exactly in the same position. I tried to use a 4k / 32k memory, but the system did not power up. Also with my "DEMO-ROM" the unit does not semms to get power (I think, this is the main problem).

Matthias

PS: I have the HP-71B Internal Design Specification I-III. Is this what you call the service manual?


#28

No, the service manual is not the IDS. I have the IDS as well (the 3 software volumes, the hardware volume, and the HPIL volume, also the IMS for the Forth ROM). Cna you tell I have half a bookshelf of HP71 internals documentation..

The service manual overlaps quite a bit with the hardware IDS. The schematics are in both, for example. The hardware IDS contains more info on the Saturn bus, and on the physical dimensions of the modules -- stuff you would need to make add-ons for the 71. The service manual contains info on using the diagnostic ROM, which I don't have, info on actually taking the machine apart, things like that.

Before somebody asks 'why haven't I scanned this for the MoHPC CD-ROMs', well, I have no scanner. A friend of mine at HPCC did spend considerable time scanning some of my HP service manuals, only to find that Dave Hicks didn't want them in whatever format said friend produces. Said friend was somewhat annoyed about this (as was I), so we rather gave up at this point. Things like the complete HP75 internals docs (service manual + ROM source + commentary) remain unscanned, therefore.

Since adding RAM doesn't get the machine to work, I would suspect you've got no ROM in the system -- the hybrid on your lower PCB is in fact RAM. Which means my guess of it being a test machine for ROM code could well be right. Please be aware that the system ROM _could_ be connected via any of the front ports, or the card reader port, or the HPIL port. In other words it could be a plug-in external device.

You could desolder the ROM hybrid from a working 71B and connect it to one of the ports to see what happens. Not a lot of point in doing so, actually, but if you want something to fiddle with...


#29

I have the ROM Image of my 0AAAA. You mean if I burn it into a EPROM and put it into my HHP 32kRAM/EPROM the machine should probably work?


#30

Alas not. The HHP module is soft-addressed -- that is, the start address is set by software when
the machine is turned on. For this to work, the processor has to be able to find that
software, so the system ROM is hard adressed -- its address is fixed my hardware. (Incidentally, part of the Forth/Assembler and HP41 emulator modules is hard-addressed, you can't copy these into EPROM and get it to work in, say, an HHP module).
You need the real HP ROM hybrid, which you could then wire to one of the ports on the 71.


#31

Matthias

I would be careful about wiring the ROM straight and direct into the 44 (if you ever would). The daisy chain is looped over so it may not work (the jumper passes the daisychain in the internal loop).

BTW, I have a copy of the key pages in the service manual which are different from the HDS.

KimH


#32

I am pretty sure the system ROM, being hard-configured, is not in any of the daisy-chains.


#33

Hello Tony,

sorry, but from my understanding of the Saturn bus you're wrong.

IMHO every chip connected to the Saturn bus, hard- and soft- configured are in the daisy chain. When the CPU request for an address, the request goes to the first chip in the daisy chain. If the requested address isn't in the address area of the peripheral chip, the request goes to the next chip in the daisy chain. If there is now a chip in the daisy chain where the address fits, the chip return the requested data and stops the daisy chain. This is the reason for the covered memory technology. If there are two or more software-configurable chips using the same address, only the first one in the daisy chain answers (has highest priority). Unconfigurated chips don't answer and give the daisy chain signal immediately to the next chip in the queue. So you see it doesn't matter if the chips are hard- or soft-configured. Normally hard-configured chips are at the end of the daisy chain allowing the use of the covered memory technique.

This technique works also on the CONFIG, C=ID and UNCNFG commands. Every unconfigurated chip answers the CONFIG and C=ID control command and every software configured chip answers the UNCNFG control command.

Regards

Christoph

Update April 29/05:

Further discussions in this thread showed that I'm wrong.

Edited: 29 Apr 2005, 10:41 a.m. after one or more responses were posted


#34

Are you sure about this? My understanding of the Saturn bus was that the daisy chain was only used for cofiguration (the CONFIG, C=ID, UNCNFG commands). And that it's the responsibility of software to ensure no two soft-addressed chips get the same address.

A system as you describe would be fairly useless. For obvious reasons the internal devices are at the CPU end of the daisy chain. So they would have a higher priority than any plug-in device, which would mean you couldn't use such a plug-in to 'take over' from the internal ROM.

There's a OD line on 2 of the ports (my memory says port 3 and the HPIL module port) which will disable internal ROMs. It is therefore possible for a module in those ports to take over the system, but this has nothing to do with the configuration chain.

OK, time for me to check the schematics again. I am pretty sure I noticed there was no daisy chain going through the system ROM hybrid last time I looked, though.


#35

Quote:
Are you sure about this? My understanding of the Saturn bus was that the daisy chain was only used for cofiguration (the CONFIG, C=ID, UNCNFG commands). And that it's the responsibility of software to ensure no two soft-addressed chips get the same address.

What I had in mind was the "An Advanced Scientific Graphing Calculator" article from Aug 1994 Hewlett-Packard Journal http://www.hpcalc.org/hp48/docs/misc/hpj-48gx.zip. There the last sentence on page 8 ... "In the CPU bus definition the devices are chained, with the result that devices closest to the CPU on the chain have the first opportunity to respond to bus requests. In consequence, if two devices are configured with overlapping address ranges, the one closer to the CPU on the chain effectively hides the more distant one." ...

Then I had a closer look into Chapter 4.2 of the "Clarke - CPU/LCD DRIVER/MEMORY CONTROLLER" documentation. After this the world isn't so clear any more. You're right in the case that the daisy lines are mainly necessary for the configuration. But when two devices using the same address area, I think the daisy lines are responsible for the priority. But one thing mentioned there, "Hard Configured" devices may have DAISYOUT and DAISYIN lines and then behave like configured soft devices or may have no daisy chain lines.

Furthermore you wrote the software is responsible not to configure two or more devices on the same address. This makes sense on the HP71B but not on a HP48GX. The Saturn CPU has an adress area of 512KB.

  • HP48GX ROM 512KB
  • 128KB RAM
  • 128KB Slot1
  • 128KB Slot2 (1 page, rest maybe banked)
  • 32B I/O

So the CPU must address at least 896KB.

Quote:
A system as you describe would be fairly useless. For obvious reasons the internal devices are at the CPU end of the daisy chain. So they would have a higher priority than any plug-in device, which would mean you couldn't use such a plug-in to 'take over' from the internal ROM.

Sorry, I'm not agree. That's the trick that the ROM has the lowest priority. The ROM is hard configured, you have no chance to disable it. But when it has lowest priority (at the end of the daisy chain), soft configured devices may use an address area of the ROM and when you want to access the underlying ROM you unconfigure the soft configured devices at this address (explained in the article I mentined above). But of course on the HP71B is no need for the covered technology.

Quote:
There's a OD line on 2 of the ports (my memory says port 3 and the HPIL module port) which will disable internal ROMs. It is therefore possible for a module in those ports to take over the system, but this has nothing to do with the configuration chain.

OK, time for me to check the schematics again. I am pretty sure I noticed there was no daisy chain going through the system ROM hybrid last time I looked, though


That's possible that system ROM hybrid has no daisy lines (see above) and has the possibility to be deactived by other hardware lines.

But perhaps I'm wrong that the daisy chain line are responsible for the module priority order after configuration. But I don't know any other hardware lines which can do this?

Regards

Christoph, c dot giesselink at gmx dot de


#36

Quote:
In the CPU bus definition the devices are chained, with the result that devices closest to the CPU on the chain have the first opportunity to respond to bus requests. In consequence, if two devices are configured with overlapping address ranges, the one closer to the CPU on the chain effectively hides the more distant one."

That's because the memory controllers inside the Yorke (and perhaps others) don't actually strictly adhere to the Saturn bus protocol. They have additional arbitration between them that is independent of the configuration daisy chain, though wired in parallel to it, such that if they overlap they arbitrate which one responds. So it is a chain, but a different one than on a normal Saturn bus (e.g., HP-71B, HP-28C).


#37

TNX for the clarification of this topic, so forget my entire mail in this posting thread.

Regards

Christoph

#38

Tony is correct, the daisy chain only controls configuration. Hard-configured chips do not use it.

The daisy chain is only used for configuration access. On reset, all soft-configured chips reset their internal "configured" state flip-flop, which causes them to deassert their daisy chain output.

The startup code (which must be in hard-configured memory, or it wouldn't be accessible) activates the daisy chain input on one chain. Then it issues configuration commands. Only the first chip on the chain responds, because its daisy in is asserted and none of the others are. Once the CPU configures it, it asserts its daisy out, so the next chip can be configured. Once an entire chain is configured, the software moves on to configuring the next chain (if there is another).

Normal (non-configuration) memory accesses do not involve the daisy chains at all. Thus a hard-configured chip does not have any reason to be in the configuration daisy chain. It is always configured, so even if it was in the chain all it would do is have its daisy out always be in the same state as its daisy in.

The daisy chain is not directly involved in selecting chips for normal read and write accesses. The CPU sends out the address in nibble-serial fashion (using one of two data pointers), then sends a read or write command using a data pointer. (It doesn't have to send the read or write command for every access if it just wants to continue sequential acces from the current address in one of the data pointers.)

When the command is given, all configured chips (soft- or hard-configured) compare the address against their configured range to decide whether to respond. The state of the daisy-chain input does NOT affect this process. It is the responsibility of software to ensure that no two devices are assigned overlapping address ranges. (Actually during the config process this can happen, but only to get devices "out of the way", and the code will never try to read or write data to devices in that state.)

#39

Hi Matthias,

Could you run the following program on your working 0AAAA HP-71B?:

10 A=HTD("1DCCE")
20 FOR I=A TO A+50 STEP 2
25 M=HTD(PEEK$(DTH$(I),1))
26 M=M+HTD(PEEK$(DTH$(I+1),1))*16
30 DISP CHR$(M);
40 NEXT I
It gives the date stamp of the mainframe ROM. For example, a 2CDCC version gives:
Tue Mar  5, 1985  12:10 pm
So I could update my version history on:

http://membres.lycos.fr/jeffcalc/bug71.html

J-F


#40

It´s really true, Jean-Francois. The outo´put is as following:

s\ asaßC........................ (points because I do not have all characters on my PC keyboard.)

I checked the program about 5 times and it seems to be correct.


#41

As Patrice said, it may mean that the date stamp is not at the same place, or even was not present in this early version.

Thanks for your effort!

J-F


#42

No problem.
Please let me know, when you have another solution.... (as short as this one).

Matthias


#43

Matthias, you can try this program (it is not optimized), it takes a few hours to scan the rom.

It scan the rom from B$ to E$ looking for the pattern P$ and pause at first match.

If you know the compil stamp is in the second part of the rom, use b$="10000".

To test it, use b$=1dcc0" on a 2CDCC it must match the year

The pattern is in hex with ? when a digit is unknown.

"02139383?302" is looking for the year " 198? "
"?3?3A3?3?3 is looking for a time pattern "99:99"

10 DIM R$[300] ! TO READ THE ROM
20 B$="00000" ! BEGINING ADDRESS FOR SCAN
30 E$="1FFFF" ! E= END ADDRESS
40 P$="02139383?302" ! P= PATTERN TO SEARCH FOR
50 P=LEN(P$)
60 B=HTD(B$)
70 E=HTD(E$)
80 L=256 ! SIZE OF PART OF ROM TO READ
90 FOR A=B TO E STEP L
100 DISP DTH$(A)
110 R$=PEEK$(DTH$(A),L+P)
120 ! SEARCH P IN R
130 FOR C=1 TO L
140 F=1
150 IF P$[F,F]=R$[C+F-1,C+F-1] THEN 170
160 IF P$[F,F]<>"?" THEN 210
170 F=F+1
180 IF F<=P THEN 210
190 DISP DTH$(A+C);" ";R$[C,C+P-1]
200 PAUSE
210 NEXT C
220 NEXT A
230 END

Patrice

#44

Bonjour Jean François,

Comme matthias ne trouve pas la date de compil à l'endroit indiqué, ne crois tu pas que la date de compil pourrai être ailleurs dans les premières versions de la rom et qu'il faudrait plutôt chercher une séquence en hexa?

As Matthias has not found the time stamp of the ROM, I think it is somewhere else and that it would be better to scan the Rom looking for a particilar hex string.

Patrice


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP-71Bs on eBay or Big Profit !! 71B lover 12 965 03-08-2002, 01:56 AM
Last Post: Glenn McEnroe

Forum Jump: