A ROM emulator for the 71B

[Sylvain Cote]

Hello Mark,
Great project!
Count me in for at least two units.
Sylvain

[mfleming]

I thought those who have expressed interest in this project might like a little background on how it is used, that is, how you might add or reorder ROM images in the MCU. It presently looks a good deal like Diego's Clonix system, only without the (Windows only) graphical front end. One creates a new arrangement by assembling and flashing the source and ROM image files.

A ROM image file is quite simple and easy to create from a typical .BIN file. It is just a text file with data declarations that I generate using a simple C program. An image file looks like

Code:


        radix hex
                ; HP-82481A AC Circuit Analysis Pac, #5061-7237, $75:1985
        db     000,000,000,0ee,043,069,072,063,075,069,074,020,008,0e2,000,000

Each data declaration line has 16 byte values taken from the .BIN file in sequential order. I just hacked something out in C but you could get fancy if you wish in any language of choice.

These ROM image files are included into the source file using directives to indicate where in Program Flash Memory they should reside. The PIC controller divides the 128 KB of flash into 8 Blocks of 16 KB each. The software lives in Block 0, so you have 7 Blocks into which to place ROM images. Note that every ROM image must begin on a Block boundary. That placement is done in this manner.

Code:


        org 0x4000
#include accap.inc
        org 0x8000
#include math2b.inc
        org 0x10000
#include finance.inc
        org 0x14000
#include edit.inc
        org 0x18000
#include ampistats.inc

Now the fun part! Since there are 7 Blocks of flash memory that can hold a ROM image, I have 7 descriptor slots that define where an image is stored and what size the image is. You control what ROM image is enumerated by poking a value to the card reader I/O address and then cycling the 71B off and on. Poking a value of "0" means no ROM is enumerated, while a value between "1" and "7" refers to one of the descriptor slots. This power cycling sequence should be familiar to those with real ROMs. If you are replacing a ROM in a front port, you need to cycle power with the port empty before putting in a new ROM in the same port.

Given the timing constraints imposed by a hard real time system, I had to also constrain the size and placement of ROM images. So, a 16 KB image can go into any of the 7 flash Blocks (not to be confused with a descriptor slot, though that's easy to do!). A 32 KB image must be based on an even flash block (2, 4, or 6) and will occupy two flash Blocks. A 64 KB image can only be based at Block 4 and occupies Blocks 4 through 7. An image size of 48 KB is not supported - it must be treated as a 64 KB image.

The content of a descriptor slot is a bit complicated so I won't go into it here. Suffice to say it's easily generated from the ROM size and flash block location. I've been doing it by hand myself, but a program could be written to generate the data needed. In fact, I'm finishing up a serial monitor that allows you to upload ROM images and describe the layout of ROM images in flash. More on that later if interested.

Using the emulator once it's loaded up with images is quite simple. Freshly installed, it enumerates no ROM. Using the example layout given earlier, you would plug in the MATH:2B ROM with the sequence

Code:


POKE "2C000", "2"
f ON
ON

Replacing that ROM with the Finance ROM would be

Code:


POKE "2C000", "0"
f ON
ON
POKE "2C000", "3"
f ON
ON

Pretty easy, no?
~Mark

[EmmanuelC]

Really amazing ! Do not hesitate to build&sell, we all want it (+1 please)! :-)

[Harald]

Thanks for the insight Mark! This is a great achievement!

[Sylvain Cote]

Mark,
If I understand correctly, fully used valid combinaisons are:

• 7 x 16K
• 5 x 16K & 1 x 32K
• 3 x 16K & 2 x 32K
• 1 x 16K & 3 x 32K
• 3 x 16K & 1 x 64K
• 1 x 16K, 1 x 32K & 1 x 64K
  

Do you plan to support more than one ROM image mapped at the same time ?
Sylvain

[mfleming]

That's correct! As long as you follow the placement rules any of those combinations would be correct. I believe I have all of the .BIN ROM images listed in your Compendium, but if you know of others, I can generate image files for them as well.

Enumerating multiple ROMs is pretty unlikely due to timing constraints, but it's not completely out of question with clever enough coding I suppose. The reason is that ROMs compare a given PC or DP address with their own address range in parallel while of course the emulator must do so in sequence which chews up quite a few precious instruction cycles. Things would be completely different if only the 71 CPU presented an address high nibble first.

As I mentioned earlier, with the proper placement constraints I'm hoping I can also support a hard configured ROM. That to me would be the last major feature to add - all else being frosting and candles.

~Mark

[Etienne Victoria]

Hi Mark !

Congratulations for this great project !

Count me in for 1 if it becomes available.

Thanks

Etienne

[Dave Frederickson]

(11-09-2020 01:08 AM)mfleming Wrote:  I believe I have all of the .BIN ROM images listed in your Compendium, but if you know of others, I can generate image files for them as well.

There's Matthias' list.
http://www.hp-collection.org/71database.html

Some of these are EPROM images, but they can be converted to ROM images if necessary.

[Moggul]

Wow! Amazing development.

Count me in for a couple of units when you are ready to sell them...

[mfleming]

(11-08-2020 11:59 PM)Sylvain Cote Wrote:  (snip)
Do you plan to support more than one ROM image mapped at the same time ?
Sylvain

A quick update on development progress, and another picture to answer your question. I took some time to reexamine the means of determining how a Saturn address is mapped to a ROM image in flash. I can now enumerate all ROMs and support a hard configured ROM like that for Forth. Have a look at that VER$ output line!



I have the board programmed with Forth (16K), Math2b (32K), JPC rev E (32K), and the Forth-hrd ROM (32K). There are no longer any placement restrictions as before. It's really nice to have all the features and BASIC extensions in J-F's two ROMs. Forth will be interesting to play with as well. Anyone care to describe their favorite use for this development ROM?

Happy Thanksgiving!
~Mark

[Sukiari]

I think one of the big barriers to entry for the 71b owner isn't the device itself, which can be had for a fraction of the cost of a new iPhone. It's that all the neat gadgets and ROMs are priced at 2-5x the cost of the device itself. In an ideal future we'd have some sort of SD-card based interface where ROMs and storage space can be allocated and a microcontroller would take care of the details. I think there's still a lot of interest in these kinds of devices, nothing modern really scratches the same itch.

[mfleming]

Don't go giving me ideas

A pil-box is a neat solution to the lack of devices, assuming you have an hp-il module. The lack of ROMs at an affordable price was killing me, hence the roll your own path. The cost so far has been reasonable, and the challenge has been a lot of fun!

[Harald]

I can't wait to get one!

[Dave Frederickson]

Hi Mark,

Can you provide a feature comparison between the ROM Emulator and the FRAM71B whose revival has been recently announced?

Can the 71B Diag ROM be emulated?

Dave

[mfleming]

Hi Dave,

I wouldn't put this in the same class as a FRAM71, but let's compare specs.

The FRAM71 has 512 KB of non-volatile random-access memory which can be enumerated as ROM or RAM. It can serve up hard-configured ROM at E0000h and at 00000h as a system takeover ROM. It can cover the entire 20 bit address space of the Saturn CPU.

The - what shall I name it? - can enumerate 112 KB of ROM, including hard-configured ROM at E0000h and 00000h. It does not provide any RAM.

I assume the Diag ROM is a takeover ROM, so yes it could be emulated using the same shorting plug arrangement as the FRAM71.

The FRAM71 does require some mastery of the configuration process, but it is quite powerful. The whatever-you-call-it will likely be configured and updated the same way as a Clonix module. I'm consulting Diego on the best approach. The one I favor at the moment is a batch file or shell script driven by a simple text list of BIN files that will assemble the code and flash the processor. The programs needed to assemble and flash are available on Windows, Mac, and Linux so your development platform should be supported (MS-DOS on HP200LX excluded ).

If there's a particular feature you're interested in, let me know and I'll see if it is possible to implement. I'll rule out RAM right away, at least for this project.

~Mark

[J-F Garnier]

If Mark could squeeze his design into a front port module, it could be a simple (and easily reversible) way to turn every 1BBBB machine into a 2CDCC version... and beyond.

J-F

[wbvreeuwijk]

Hi Mark,

This looks awesome. Sign me up when you start selling either the PCB, kit, or pre-build units.
After having worked with Clonix, I was looking for something similar for the HP-71B.

Gr. Bas.

[KimH]

Mark, this is VERY cool!

As a fan of the TITAN I would ask to be put on your list when/if you decide to keep one. I am so ready getting to play with your final product once you are ready to take orders.

(11-27-2020 12:00 AM)mfleming Wrote:  

(11-08-2020 11:59 PM)Sylvain Cote Wrote:  (snip)
Do you plan to support more than one ROM image mapped at the same time ?
Sylvain

A quick update on development progress, and another picture to answer your question. I took some time to reexamine the means of determining how a Saturn address is mapped to a ROM image in flash. I can now enumerate all ROMs and support a hard configured ROM like that for Forth. Have a look at that VER$ output line!



I have the board programmed with Forth (16K), Math2b (32K), JPC rev E (32K), and the Forth-hrd ROM (32K). There are no longer any placement restrictions as before. It's really nice to have all the features and BASIC extensions in J-F's two ROMs. Forth will be interesting to play with as well. Anyone care to describe their favorite use for this development ROM?

Happy Thanksgiving!
~Mark

[Kevin71B]

Very cool project Mark. I'd like to purchase 2 of these when/if you get to the point of making something available.

-Kevin

[mfleming]

A quick update for the curious. I'm finishing up a user manual for the ROM emulator which should provide details on how to program ROM images. I'll post the draft manual soon in a separate thread when I think it's in a reasonably intelligible condition. One of the first rules of product development is to never, ever, let an Engineer write a user manual. Those darn Engineers always tell you what they did rather than what you want to do. Hopefully this won't be quite that bad.

I also confirmed J-F's mention that the HPIB-1A ROM can be overridden according to his instructions. That's a pretty useful bit of information to know! Sadly though, I can't provide a system takeover ROM capability due to the amount of time the ROM emulator takes to recover from deep sleep.

(01-11-2021 04:37 PM)J-F Garnier Wrote:  <snip>
But the true cause of this update is that it was part of my "Ultimate HP-71 ROM Extension" project, that was to provide, in a single extension for the physical HP-71:
- the Math Pac 2,
- the JPC ROM,
- the FORTH/Assembler,
- a large part of the User Library keywords (ULIB).
<snip>

J-F, your Ultimate ROM has been realized! In addition to enumerating all of the above ROMs and hard ROM, the "hidden" ULIB52 ROM can be switched in and out as needed. Or any other 8K utility ROM you might want on tap - handy if you'd just like to copy a few LEX files to RAM without leaving the whole ROM set in your catalog & lex chain.

~Mark