How do you determine a 71B memory-mapped I/O device address?

[mfleming]

Question for those more familiar with 71B Basic, assembly, or O/S internals. I'm trying to determine how a 71B accessory like a bar code wand would determine what address it's MMIO device has been assigned. I assume the accessory enumerates an MMIO device and a separate ROM device for supporting code. Having the code examine its own internal registers for the base address is a bit circular since the code would need to know where to look!

Finding where the ROM code has been located would be a matter of looking for the ROM header signature in known locations. Would the same approach be used to find an MMIO address range? The only other alternative I can imagine would be using O/S entry points to examine the device structure the O/S builds. Sounds terrifyingly complicated.

Any hints, tips, pointers, document references, code fragments, etc. would be sincerely appreciated!
~Mark

[Giuseppe Donnini]

The best place to start, in my opinion, would be Nathan Meyers article "Soft Configuration Enhances Flexibility of Handheld Computer Memory", published in the July 1984 issue of the Hewlett-Packard Journal (p. 10-13).

The most advanced and detailed treatment can be found in the HP-71 Software Internal Design Specification. Chapter 2 of the first volume, entitled "System Startup and Memory Configuration", gives a general overview, while all the gritty details can be gleaned from the actual source code and its comments in the third volume (starting at address #10192h).

[rprosperi]

(03-31-2021 12:21 AM)Giuseppe Donnini Wrote:  The best place to start, in my opinion, would be Nathan Meyers article "Soft Configuration Enhances Flexibility of Handheld Computer Memory", published in the July 1984 issue of the Hewlett-Packard Journal (p. 10-13).

The most advanced and detailed treatment can be found in the HP-71 Software Internal Design Specification. Chapter 2 of the first volume, entitled "System Startup and Memory Configuration", gives a general overview, while all the gritty details can be gleaned from the actual source code and its comments in the third volume (starting at address #10192h).

I've read the former article (many times!) and I don't think it addresses the device MMIO allocation/scheme with much detail (if any), its focus is more on configuring ROM/RAM blocks in the various ports.

As for the 2nd paragraph, this is indeed terrifyingly complicated, but is also likely the only source in actual documentation. Perhaps JFG or Hans know and can save the day...?

[Giuseppe Donnini]

(03-31-2021 01:07 AM)rprosperi Wrote:  I've read the former article (many times!) and I don't think it addresses the device MMIO allocation/scheme with much detail (if any), its focus is more on configuring ROM/RAM blocks in the various ports.

Well, one sub-paragraph (on page 13) is entitled "Configuring memory-mapped I/O devices", but you are right in pointing out that it does not contain much detail.

[rprosperi]

(03-31-2021 01:23 AM)Giuseppe Donnini Wrote:  Well, one sub-paragraph (on page 13) is entitled "Configuring memory-mapped I/O devices", but you are right in pointing out that it does not contain much detail.

Touché, Giuseppe!

I have read this article endless times, and have found my recall for the details is as bad as for any other single article. The high-level takeaways can be grasped after 1-2 readings, but the details never seem to stick...

[Sylvain Cote]

I just read IDS Vol2 Chapter 4 and it seems pretty straightforward.
First it is written that the card reader MMIO is hard configured at address 2C000 to 2C01F.
Next, if I have understood correctly you must define a new chip that would respond to the configuration routine as MMIO instead of RAM or ROM.
Pages 4.1 to 4.6 gives a good explanation.

[mfleming]

Yes, enumerating an MMIO device using a properly formatted CONFIG string isn't the problem. I've done that, and a single such instance is assigned the address at the bottom of the appropriate address range. The problem is, how does an external program determine that address? What if multiple such MMIO devices are enumerated? If I were writing a Basic or assembly program to access that set of device registers, how would I know where the registers were mapped? Just picking a fixed address the way the card reader does seems arbitrary, and wouldn't support multiple concurrent devices.

Quite a puzzle

Edit: The best analogy is a RAM module, which has a specific port address you can use to free, merge, or copy to/from the RAM. There doesn't seem to be an equivalent for an MMIO device. I've scoured the two IDS documents for a clue as to how you might actually use a set of device registers. Seems you'd have to embed their dynamically assigned address in a separately enumerated ROM.

[J-F Garnier]

Hi Mark,
(I'm curious of what you have in mind to ask such a question - I may have an idea :-)

The soft-configuration MMIO address allocation is similar to memories. The MMIO are configured starting at 20000 and a system buffer is created to hold the configuration addresses and the MMIO class as reported by the C=ID opcode.
Then, when an application (the HP-IL ROM for instance) wants to address a MMIO device it can manage, it scans the buffer to find a MMIO device of the corresponding class (HP-IL mailbox is device class 0).
See the FNDMBX (find mailbox) routine in the HP-IL ROM.

A list of the MMIO classes is defined here pages 7-8.
BTW, I don't know what was the memory controller device, I thought it could be the device used in the HHP and CMT memory modules, but never found any evidence for it.
So if you plan to create a soft-configured MMIO device, use a MMIO class different from 0 and 2, and get its assigned address from the configuration buffer by looking at your class id.

Or, if you want to keep it simple, use a hard address like the card reader does, You can use the range 2C1xx-2CFxx for instance. Don't use any address in 2Dxxx, 2Exxx, 2Fxxx.

J-F

[mfleming]

Thanks J-F, looks like some good intro information. I think the long term need for a soft address is apparent But short-term I'd like to make the MultiMod serial port available to programs. Hans had a serial port in his FRAM71 for a while, but later dropped it. I assume because no one was interested in the PEEK/POKE gymnastics needed to use the port, and maybe a serial port application didn't jump out to anyone.

As an educational exercise I'd like to write some LEX to add commands like 'SERINI', 'BAUD 9600' or 'SERIAL(19200, "8N1", 0)' to provide high level access to the port. One of the things the serial port could be used for is illustrated in an HP-41 GPS Module. There's certainly room above the MultiMod for a small GPS unit that can be powered from an unregulated DC power source.

There's a list of can-this-be-done items I have to work through first though, and having a MMIO device is one of them.