HP Forums

Full Version: HP71 memory module question
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

I know that the integrated soft configurated RAM of a 1LP2 Centipede chip has 2K nibbles (#800). Configure this RAM not on a size boundary (#800) is failing (for example try to config at #4FC00 instead of #4F800). Fail mean, the module will be configured on the next lower address matching with the size boundary, in the case of our example #4F800.

The HP28C has the possibilty to add additional RAM (RAM module chips from the HP71B) at #50000 (soft configured). I also expected that the configure address must also be boundary of it's size. So HP71B chips with 4KB and 32KB will work, because #50000 is a size boundary of 4KB and 32KB. But not a 64KB chip. But I found an old article about upgrading the HP28C to 64KB.

IMHO this will only work when

- the HP71B RAM module hasn't the boundary limitation (Saturn bus)

or

- a HP71B 64KB RAM module is build internally by 4KB or 32KB modules linked together

Any ideas?

TNX

Christoph

The front-port 64K RAM modules for the 71B are configured as though they are two 32KB (64Knibble) chips, so the size of each chip is #10000 hex. They should work OK on the 28C since one will be configured at #50000 and the other at #60000.

The card-reader-port modules work similarly; the 32KB, 64KB, 96KB, and 128KB modules look to the 71B as one, two, three, or four 32KB chips, respectively.

I vaguely recall seeing a writeup somewhere stating that this was done due to the 71B firmware being able to handle ROMs of 64KB, but RAMs only up to 32KB. Or something like that.

Hi Eric,

Do the 64Kb to 128kb (or even the 160kb) modules have one interface IC per 32k RAM, or only one that manages all the RAM chips?

J-F

Many TNX for the information.

Background: I recently had another look at the French "VOYAGE AU CENTRE DE LA HP48c/s". I don't understand any French word ;( , but there nice pictures inside. :) On page 16 there's a picture about memory configuration, explicitly naming a 6KB and a 34KB HP28C version.

I know a lot more about this machine now then on my first "reading". So my interest on the "obscure" 6KB model was waked up. After some tries I found the subroutine at #00F11 (ROM 1CC) allocating the additional memory. With Eric's information that every module has max. 32KB everthing works fine. The HP28C firmware request memory with C=ID until it get C=0. So an upgraded HP28C with 66KB has two additional seperated 32KB modules inside with no conflict with the size boundaries.

For a real emulation inside Emu28 I have to spend a dataset for every additional memory module with it's state and base address. Currently I only emulate/simulate one memory module with a maximum size of 128KB (max size specified in the HP71 HDS) with the extention that this module can be placed on every 32KB boundary. This is only a simulation because a real HP28C with 66KB has two 32KB modules which can be unconfigured seperately.

At the moment I'm a little bit undecided. In general I try to simulate the calculator hardware as close as possible (here the necessary for four datasets to hold the information of four RAM modules (4*32=128)) on the other side the current implementation with one big module is much simpler and has the same effect, getting the requested RAM available for the OS. But everybody with my actual knowledge level know, that this is impossible with the real hardware! On on side I claim to publish an emulator (I don't want to worm up the discussion about emulator and simulator definition here), on the other side the easier implementation is just a functional simulation of the extented RAM > 32KB.

Especially Eric and JFG as developers of similar software, what's your opinion about the topic above?

Regards

Christoph

Hi Christoph and Eric,

On my Emu71, I definitively took the easiest way: implement the memory with big 32k or 64k chips, without trying the reproduce the low-level details. For instance, Emu71 uses a single 32kb "chip" for the main memory, instead of the 4x4kb modules- each 4kb module being in turn made of 4x1kb 1LG8 chips - of the real hardware.

In the same way, keyboard and display are not simulated at low level in Emu71, but only at intermediate level (memory buffers). On the other hand, I think that it's very important to simulate the I/O environment, namely the HPIL devices, which are integral parts of the system.

This is my way of thinking calculator emulator/simulator: the exact internals don't matter, as long as no realistic user program (i.e. program that a user can key in, this includes I/O access and of course machine code) can make the difference, so any previous written software can be run on the emulator/simulator.

My Emu41/Emu71 don't even try to reproduce the look of the HP41/HP71, but they run most known software or modules (not all, for instance service modules only partially run - but they are not what I consider as realistic program).

Kind regards to both.

J-F


Edited: 7 Mar 2006, 4:19 p.m.

In the card-reader-port RAM modules, they use one interface chip per 32KB of RAM. I'm not sure about the front-port 64KB module, as I only have one and am not inclined to disassemble it.

I think either approach is reasonable. If you make it less like the real hardware (for the sake of efficiency or simplicity), it might be worthwhile to describe the differences in the documentation.

Hi Christoph!

Just ask if there could exist a user or a program that is able to detect that this is "only" an emulation (or a fake) and not the real HW. Then - I assume your statement "what runs on my emulators will do so on real HW too" still holds true - how many routines that work on real HW will fail on your EMUs??? IMHO an emulation does the same as one distinct layer of a real thing, the question is which stratum at what cost and for what gain. And I regard a robust firmware-interpreter as a good emulator.

Ciao.....Mike

The phrase "functional simulation" describe not everything. When you only look onto the memory with it's address area and size the program will not see any difference. It exactly behave like on the real machine. The main difference is on configuration and unconfiguration of memory modules > 32KB or multiple 4K modules. The HP28C OS see no difference with it's implementation, so it's working. But there's a difference when the user program try to unconfigure only one memory module, which doesn't work like expected.

We can of course say, nobody (also the HP28C OS) will unconfigure the extended memory modules, there's just no need for it. Furthermore I don't know anybody who's programming the HP28C in assembly, the 30 or 40 ROM entry-points I published for the 28C 1CC ROM aren't for sure not enough for serious assembler programming. Finally, hi HP calculator enthusiasts, is there somebody out there, having a memory upgraded HP28C?

The memory extension implementation in Emu28 is something like when you ask a hill climber why he's climbing onto top of a hill: "Because it's there!"

But to end the discussion, I yesterday changed implementation by adding two memory controllers which behave hopefully exactly like in the original calculator. On the next version of Emu28 creating a new document will support 4, 32 and 64KB additional RAM. These are exactly the combinations which have been sold end of 80-ties. The combinations of 4+4=8KB or 32+4=36KB are possible by the hardware emulation (with a modified state file) but not enabled in the frontend.

Regards

Christoph

Your approach "as close as possible to the real HW" results in 'high-quality'-emulators, just an other HW-platform for existing OS' and possibly future enhancements. In contrast, my NutEm is only a firmware interpreter and does not emulate the errors of the Nut chip. I do not know if other HP41-emulators do so.

Ciao.....Mike