HP71 memory config observations

[Christoph Giesselink]

Last year, just before the Allschwil meeting, I stumbled over an issue installing a single 64KB RAM chip in Emu71/Win. I talked about this with J-F at the meeting and later I made some analysis and shared my results by Email with him.

Here's a summary of these observations:

The main issue with a a single chip 64KB RAM module is, that it always configured at address #20000 instead of the awaited #30000.

The 32KB page from #20000-#2FFFF is normally reseverd for the IO-RAM, internal RAM of the chipset and module IO mapping like HP-IL mailbox or card-reader interface. So this should not happen.

I analysed the reason why a single 64KB RAM chip is located at #20000.

The official C=ID description tells us, that 64 KNib is maximum RAM and 256KNib is maximum memory for a single chip. What are the consequences of this definition?

The RAM configuration on a 71B starts with the largest RAM chip at #30000.

1) HP71B with no additional RAM

PORT0: #30000-#37FFF (16KB)

2) HP71B with 32KB(1) additional RAM in Port1

PORT1: #30000-#3FFFF (32KB)
PORT0: #40000-#47FFF (16KB)

3) HP71B with 64KB(1) additional RAM (single chip) in Port1

should be:

PORT1: #30000-#4FFFF (64KB)
PORT0: #50000-#57FFF (16KB)

but is:

PORT1: #20000-#3FFFF (64KB)
PORT0: #50000-#57FFF (16KB)

The reason is very simple. Each memory must be located on a boundary of it's size, so a

#30000
CONFIG

on a single 64KB chip will locate the chip on #20000, because #30000 is not a boundary of 64KB. The next valid 64KB boundary is #20000!

When you try to configure a single 128KB chip at #30000 with

#30000
CONFIG

the config location is #00000. Emu71/Win v1.08 still runs because I map the ROM last. This of course maybe an incorrect emulation.

In December I made further tests on a real HP71 about the memory configuration.

In the early times of the Emu71 development and many years later I wasn't able to write LEX files to do some internal hardware tests. About two years ago a began writing LEX files to discover secrets of the HP-IL mailbox communication.

With this knowledge now, I checked the arbitration when two or more memory modules are configured at the same address on a HP71B. I used a HP71B 1BBBB with an IL Module 1B, no other external modules equipped.

Port 0.03 IRAM, FREE PORT(0.03)

#48000-#487FF (begins with IRAM header)
#48800-#48FFF
#49000-#497FF
#49800-#49FFF

I done a

#48000 UNCNFG
#48800 CONFIG

and had a look at the content at #48800. If I recognize the IRAM header at #48800, the module prior located at #48000 has a "higher priority" then the module originally located at #48800. On the real machine I see the 1KB chip with the IRAM header at #48800, so the earlier module in the configuration queue get the address page.

Now with both 1KB chip configured at #48800, a

#48800 UNCNFG

unconfigure both chips! This is a difference to Emu48 with the covered memory technology which only unconfigure the module with the higher priority.

2nd example, I configured the 1KB memory from the main memory at #48000 (IRAM FREE PORT(0.03)) new at #2E000-#2E7FF.

#48000 UNCNFG
#2E000 CONFIG

At #2E000 I saw the IRAM header, but at #2E100 I saw the hard configured I/O RAM. The conclusion is, the hard configured modules have also a higher priority than the soft configured ones when the address areas overlap.

Final test to confirm that a memory module is always located on a boundary of it's size:

#48000 UNCNFG
#487FF CONFIG

The IRAM header is at #48000, so confirmed.

Emu71/Win v1.08 and earlier are wrong in some cases:

• area #20000-#2F000 can completely mapped by RAM
• the last module in the configuration queue is mapped in the address space and not the first one
• UNCNFG only unconfigured the first matching module, not all
  

As result of these oberservations I made a fix in Emu71/Win v1.09beta1.

I haven't checked all possibilities of memory configuration, so I can image that there are still some issues where my emulation differ to the original calculator.

These changes have of course no influence on normal calculator operation. The only usage of mapping memory modules to the same address I know, is in the memory configuration sequence to get all ID's of the equipped modules. I haven't seen any read access to such an address with multiple module configurations so far. At the end of this process, the memory configuration is reset by the RESET command.

There's still one test remaining, where I'm afraid of it. Putting a 4KB RAM module in port1, a 32KB RAM module in port2, unconfigure the RAM's, put the DASIY-IN of both modules to high and then doing a C=ID. What's the result? Will both moduled still work after they put a different nibble sequence on the Saturn bus?

Christoph

[Hans Brueggemann]

christoph, not sure as to whether i've fully groked your findings. so, one question comes to my mind:
if there is such a single-chip 64KB RAM configured at 0x20000 (which makes sense from a configuration-routine viewpoint in order to configure all RAM in a contiguous fashion), what's going to happen if you try to read a card with the card reader? will that card overwrite the 0x2C000 window?
if yes, then i'd assume that there was never a plan to allow for 64KB single-chip RAMs, and hence trying to enable the emulator to accept such a configuration is probably a moot point anyway.

as for pulling the "DIN" on both RAMs high at the same time, i'd guess that the response to ID would lead to some "interesting" and undefined result on the bus... during its initial development phase, FRAM71 didn't have any protective bus resistors (rest assured, FRAM71(B) owners, all your modules are equipped with these). therefore, it was the strongest device on the bus and of course reliably locked down the calculator as soon as it collided with other devices on the bus. preferably with the system ROMs, that is. nevertheless, my HP-71Bs survived all these accidents. can't speak for the RAM modules, though.

[Dave Frederickson]

From the HP Journal:
Since the RAM configuration begins at address 30000 and since all RAM chips must be 512 x 2^n bytes (n = 0, 1, . ., 6) ...

So if n=6 we get 32k bytes as the maximum chip size.

Dave

[Christoph Giesselink]

Hi Hans,

configuring a single-chip 64KB RAM was just a try in Emu71 v1.08 to see whats happen. First I was wondering about the address #20000 and even more that Emu71 was still working.

The primary goal was to check the memory mapping emulation of Emu71, especially the case of multiple modules configured at the same address. The MMU emulation of Emu71 v1.08 and earlier more or less base on my experiences with the bus arbitration of the Clarke and Yorke chips used in the latest generations of "Saturn CPU" calculators. The actual tests showed, that the real HP71 behave different to my expected results und so that the memory mapping emulation in Emu71 v1.08 is wrong in some cases.

Quote:what's going to happen if you try to read a card with the card reader? will that card overwrite the 0x2C000 window?

I don't have a card reader so I can't verfiy this. But first I don't know if the card reader or FRAM71 are soft or hard configured. In the case of hard configured memory mapped I/O I expect that such a module has a higher priority than any other soft configured module at the same address. But for the case, such a module in the Port5 slot is soft configured, I expect that any other module located at 0x2C000 will have a higher access priority.