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