HP-71B MultiMod ROM Emulator User Manual

[mfleming]

As anyone who has worked on a term paper (or other) knows, there comes a time after many reviews when you can no longer see its defects. So I'm posting the MultiMod user manual now as something of a near finished product. There are some appendices that need completion and some missing images, but they're not needed at the moment. Hopefully as promised this draft will give you an idea of how you work with a completed ROM emulator board.

I'm still ironing out how files will be structured in the root directory, and some procedures may need a slight tweak as things are finishing up. Support software is working on Windows 10, but I hope Linux can be added as a host in the near future.

I'll follow the thread arrangement others use and put any updated manual or associated file in this first post.

Feedback welcome!
~Mark

[twoweims]

Ok. Just take my money. Please.

[Sylvain Cote]

Mark,

I did a first pass reading and I have not completely double checked with the Hardware IDS but if you follow the H-IDS, then there is an error at page 6:

this line

Code:

   -------[ROM ID code]--------  Flag  Addr  Chip ; Comment
DB 0x0a, 0x00, 0x01, 0x00, 0x08, 0x00, 0x20,    1 ; 16K forth
//  32K  resv   ROM   n/d  Last  Not-last

should be

Code:

   -------[ROM ID code]--------  Flag  Addr  Chip ; Comment
DB 0x0b, 0x00, 0x01, 0x00, 0x08, 0x01, 0x20,    1 ; 16K forth
//  16K  resv   ROM   n/d  Last  Last

There are other errors in the example, if I have understood correctly of course.

From what I can deduce, the only reason the Flag field exist is because you need a way to specify the hard-coded ROM, otherwise the [Nibble 4 : Last Chip] field should be enough.

Sylvain

5-nibble ID code as described in Hardware IDS

Nibble 0 : Address Space Size

Code:

Value     Memory Size
-----  ----------------
  F        1K      512
  E        2K       1K
  D        4K       2K
  C        8K       4K
  B       16K       8K
  A       32K      16K
  9       64K      32K
  8      128K      64K
  7      256K     128K
-----  -------  -------
Value  Nibbles   Bytes

n/s = not specified

Nibble 1 : Reserved

Nibble 2 : Device Type

Code:

   0 : RAM
   1 : ROM
2..E : Assorted Memory Types
   F : Memory Mapped I/O

Nibble 3 : Device Class

Code:

Memory : 0..F : Unassigned
MM I/O :    0 : HP-IL Mailbox
MM I/O : 1..F : Unassigned

Nibble 4 : Last Chip

Code:

bit 3 : Last chip in module
bit 2 : Last chip in sequence
bit 1 : Unassigned
bit 0 : Unassigned

Edit: rework Address Space Size table to add byte sizes

[mfleming]

Hi Sylvain,

To quote Chico Marx, "Who you gonna believe, me or your own eyes?" The configuration string shown works in real hardware. One of the interesting things I've learned during this project is that the available documentation on the 71B is not just incomplete but in some cases wrong, or at least ambivalent and open to interpretation. The EOM flag in nib 5 marks the end of all resources, right? Wrong. It marks the end of a module, but who would think of more than one module per port, right? FRAM71. The 71 actually sends out an ID command following an EOM as a check to see if anything else is out there - consider it a hardware sanity check. I've also seen it send an Unconfigure command after setting an invalid DP address just to see if the hardware target doesn't respond to a read afterwards. Very clever, those developers.

My early misunderstanding of the discovery process resulted in an infinite ID/CONFIGURE loop. Big fun!

Yes, the remaining fields in a table entry are used as markers as well as holding precomputed values to speed command processing (the Addr field is populated during boot).

[Sylvain Cote]

Hello Mark,

I found it strange that HP documentation was wrong with something that important, but you are the expert here not me.

That settle the nibble 4 and the Flag field, but what about the nibble 0, the size nibble ?
Should the 16K module not have the 0x0b value ?

The documentation is clear for the address field, so no problem with that.

Sylvain

[mfleming]

A question of nomenclature that confused me early on. When speaking of ROM sizes, the size is usually given in kilobytes but the size nib in the configuration string specifies the size in kilonibbles so a 16KB ROM is 32Knib (0xA).

[Sylvain Cote]

(01-18-2021 04:01 PM)mfleming Wrote:  A question of nomenclature that confused me early on. When speaking of ROM sizes, the size is usually given in kilobytes but the size nib in the configuration string specifies the size in kilonibbles so a 16KB ROM is 32Knib (0xA).

That make sense, my error, sorry.
I will reread the document tonight and will came back here if I have more questions.
Thanks!

[mfleming]

One of the documentation "errors" that bit me was the timing information in the H/W IDS. It states that Tacc, "*STR low to data-out valid" (p. 9-4), is a maximum of 200 ns. Not so with the earliest Saturn chip, as confirmed by J-F with an oscilloscope. Seems the chips that are in early Titans were a bit slow to serve up data on the bus. The timing specs in the IDS were probably written with newer Saturns in mind.

At one point I tried sampling the bus early in the strobe cycle rather than at midpoint. My code worked fine with a newer 71B (2724A). On an older model (2406A) the data was not yet valid so the code usually, not always, saw a NOP. On the occasions when it saw something random: Bang. Crash. Battery pull.

[Sylvain Cote]

Hello Mark,

After reading your manual several times, this is what I understand.

Sylvain

Summary:

• The module Flash size is 128KB
  
  • The module Flash is divided into 8 blocks (aka chips)
  • Each chip has a size of 16KB
    
• Chips are numbered from 0 to 7
  
  • Chip #0 first 8KB address is reserved for module firmware
  • Chip #0 last 8KB address can host an optional user's ROM image (called hidden ROM)
  • Chips #1 to #7 is available to host user's ROM images
    
• Chip numbers with their associated addresses
  
  • Chip #0 address is 0x00000
    
    • Chip #0 first 8KB address is 0x00000
    • Chip #0 last 8KB address is 0x02000
      
  • Chip #1 address is 0x04000
  • Chip #2 address is 0x08000
  • Chip #3 address is 0x0c000
  • Chip #4 address is 0x10000
  • Chip #5 address is 0x14000
  • Chip #6 address is 0x18000
  • Chip #7 address is 0x1c000
    
• ROMs
  
  • ROM order follow ROM enumeration (table entry) order
  • Expected ROM size are: 16KB, 32KB or 64KB
  • Aggregate ROM size is supported (ex: 48KB ROM built by creating a multi-chip configuration: 16KB+32KB or 16KB+16KB+16KB)
  • 0xE0000 hard-wired ROM must be flagged as such and assigned to chip 6 and 7
  • Chips listed after ROM enumeration has been stopped are ignored, except for chips 6 and 7 when flagged hard-wired ROM
    
• Control Address Values (0x2C000)
  
  • 0 : unmap chips #0 to #7
  • 1 : map chips #1 to #7
  • 3 : map chips #0 to #7
    
• Configuration Values:
  
  • SIZE : expected chip size
    
    • 0x0A : 16KB ROM image
    • 0x09 : 32KB ROM image
    • 0x08 : 64KB ROM image
      
  • RESV : reserved
    
    • 0x00 : not used
      
  • TYPE : supported device type
    
    • 0x01 : ROM
      
  • CLAS : device class
    
    • 0x00 : not used
      
  • LAST : last chip in module
    
    • 0x00 : not the last chip in module
    • 0x08 : last chip in module
      
  • FLAG : ROM enumeration & hard-wired ROM control
    
    • 0x00 : continue ROM enumeration
    • 0x01 : stop ROM enumeration
    • 0x02 : hard-wired ROM
      
  • ADDR : lookup value, automatically computed by the firmware
    
    • 0x00 : default value (any value here will be overridden by the module firmware)
      
  • CHIP : chip number (0..7)
    
• Configuration File:
  
  Code:
  

  org 0x1000
; ROMs enumerated as 16K chips
ROM1
  Code:
  

      ;  SIZE, RESV, TYPE, CLAS, LAST, FLAG  ADDR  CHIP ; Entry info.,    size, chips #,    comment
    DB 0x0A, 0x00, 0x01, 0x00, 0x08, 0x00, 0x00, 1    ; FORTH 16KB ROM, 16KB, chip 1,     module: part 1 of 1, continue ROM enumeration, :PORT(5.00)
    DB 0x09, 0x00, 0x01, 0x00, 0x08, 0x00, 0x00, 2    ; MATH  32KB ROM, 32KB, chip 2 & 3, module: part 1 of 1, continue ROM enumeration, :PORT(5.01)
    DB 0x0A, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 4    ; JPC   32KB ROM, 16KB, chip 4,     module: part 1 of 2, continue ROM enumeration, 
    DB 0x0A, 0x00, 0x01, 0x00, 0x08, 0x01, 0x00, 5    ; JPC   32KB ROM, 16KB, chip 5,     module: part 2 of 2, stop     ROM enumeration, :PORT(5.02)
    DB 0x0A, 0x00, 0x01, 0x00, 0x08, 0x00, 0x00, 5    ; ignored,        16KB, chip 5,     (place holder)
    DB 0x0A, 0x00, 0x01, 0x00, 0x00, 0x02, 0x00, 6    ; FORTH 32KB HDR, 16KB, chip 6,     hard-wired: part 1 of 2, 32KB ROM first half,  HP-71B address 0xE0000 to 0xE7FFFF
    DB 0x0A, 0x00, 0x01, 0x00, 0x00, 0x02, 0x00, 7    ; FORTH 32KB HDR, 16KB, chip 7,     hard-wired: part 2 of 2, 32KB ROM second half, HP-71B address 0xE8000 to 0xEFFFFF
    DB 0x00, 0x00, 0x00, 0x0C, 0x02, 0x00, 0x00, 0    ; MMIO address,         chip 0,
  Code:
  

  org 0x04000 
    #include forth1b.inc      ; load FORTH 16KB ROM image in module address 0x04000 to 0x07FFF
org 0x08000  
    #include math2b.inc       ; load MATH  32KB ROM image in module address 0x08000 to 0x0FFFF
org 0x10000
    #include jpc05.inc        ; load JPC   32KB ROM image in module address 0x10000 to 0x17FFF
org 0x18000
    #include forth1bhrd.inc   ; load FORTH 32KB ROM image in module address 0x18000 to 0x1FFFF (hard-wired ROM)
end

Edit 1: typos
Edit 2: integrated Mark comments
Edit 3: clarifications

[mfleming]

Hi Sylvain,

Excellent summary! I should include something like this in the Appendix. Here are a couple of comments.

Quote: [*]ROMs

• ROM order follow chip number in the module (from 0 to 7)
  

The ROM order of enumeration follows the order of entries in the table. There's also no constraint on the order of chip numbers in the table. So, if you wanted to swap the order of appearance of the MATH and JPC ROMs, just swap the two table entries and change the FLAG value of each. The second entry would have JPC starting at chip 4 (flash block 4) and the third entry would have MATH starting at chip 2 (flash block 2). I was thinking a picture of the mapping between virtual "chips" and physical flash blocks might help.

Quote: [*]ROMs

• Expected ROM size are: 16KB, 32KB or 64KB
  

This should really be expected chip size. If you build a ROM from a sequence of 16K chips then it can be any multiple of 16KB. You could build a 48KB ROM from three 16KB chips, or from one 32KB and one 16KB chip if you want!

Quote: [*]ADDR : address of some sort, data is inconsistent, explanation not found in the manual

This is a lookup value used when mapping a 71B address to an address in flash memory. I used to do it by hand but realized it was a certain source of error if others had to do it. The value is now computed when the processor starts.

The table/include format is pretty flexible. If you think in terms of the hardware, chips and such, then it's a bit easier to see what you're doing with the table. Reordering the table for MATH and JPC would be like rewiring the Daisy-In/Daisy-Out signal between chips. The ROMs are still in the same place on the board, you've just moved them around with the wiring order. I hope the manual conveys everything needed to use the MultiMod board. Don't want a whole lot of questions later

Edit: I should warn against changing the MMIO entry. You can probably guess why...

[Sylvain Cote]

Hello Mark,

(01-20-2021 02:44 AM)mfleming Wrote:  Excellent summary! I should include something like this in the Appendix. Here are a couple of comments.

Thanks! (you can take mine if you want)

(01-20-2021 02:44 AM)mfleming Wrote:  

(01-20-2021 01:36 AM)Sylvain Cote Wrote:  

• ROM order follow chip number in the module (from 0 to 7)

The ROM order of enumeration follows the order of entries in the table. ...

Understood, I will update my summary to reflect this.

(01-20-2021 02:44 AM)mfleming Wrote:  

(01-20-2021 01:36 AM)Sylvain Cote Wrote:  

• Expected ROM size are: 16KB, 32KB or 64KB

This should really be expected chip size. If you build a ROM from a sequence of 16K chips then it can be any multiple of 16KB. You could build a 48KB ROM from three 16KB chips, or from one 32KB and one 16KB chip if you want!

I know, I will update my summary to show a ROM with multiple chips of 16K.

(01-20-2021 02:44 AM)mfleming Wrote:  

(01-20-2021 01:36 AM)Sylvain Cote Wrote:  

• ADDR : address of some sort, data is inconsistent, explanation not found in the manual

This is a lookup value used when mapping a 71B address to an address in flash memory. I used to do it by hand but realized it was a certain source of error if others had to do it. The value is now computed when the processor starts.

If it is calculated by your code, then I think you should just say to put 0x00 in that field, this will remove questions from a beginner.

(01-20-2021 02:44 AM)mfleming Wrote:  Edit: I should warn against changing the MMIO entry. You can probably guess why...

Mmmm, I wonder ... LOL

Question: for the place holder lines in the table, what should be put there to make it neutral, like default values for that type of line.

Sylvain

[jwhsu]

Nice manual. A minor point, but there appears to be a typo on page 8 in the line "The Math2B ROM for example spans chips 2 and 3, so it uses the origin address of chip 3 (0x08000)." Should it be chip 2?

[mfleming]

(01-20-2021 01:23 PM)Sylvain Cote Wrote:  

(01-20-2021 02:44 AM)mfleming Wrote:  Excellent summary! I should include something like this in the Appendix. Here are a couple of comments.

Thanks! (you can take mine if you want)

I will! Thanks.

Quote:

(01-20-2021 02:44 AM)mfleming Wrote:  This is a lookup value used when mapping a 71B address to an address in flash memory. I used to do it by hand but realized it was a certain source of error if others had to do it. The value is now computed when the processor starts.

If it is calculated by your code, then I think you should just say to put 0x00 in that field, this will remove questions from a beginner.

Good idea.

Quote:Question: for the place holder lines in the table, what should be put there to make it neutral, like default values for that type of line.

Sylvain

An invalid value for the size nib, 6 or less, would be rejected during enumeration. Although I do some sanity checks while processing the table, these 8-bit controllers lack the RPM (Read Programmers Mind) instruction, so I ultimately have to rely on proper care being taken when setting up the table. OTOH, part of the fun might be seeing what happens if you enumerate the same ROM multiple times - backup first

(01-20-2021 01:43 PM)jwhsu Wrote:  Nice manual. A minor point, but there appears to be a typo on page 8 in the line "The Math2B ROM for example spans chips 2 and 3, so it uses the origin address of chip 3 (0x08000)." Should it be chip 2?

Corrected. That's what I mean by being blind to defects after a while.

Thanks for the feedback!
~Mark

[Sylvain Cote]

(01-20-2021 04:08 PM)mfleming Wrote:  

(01-20-2021 01:23 PM)Sylvain Cote Wrote:  Question: for the place holder lines in the table, what should be put there to make it neutral, like default values for that type of line.

An invalid value for the size nib, 6 or less, would be rejected during enumeration. Although I do some sanity checks while processing the table, these 8-bit controllers lack the RPM (Read Programmers Mind) instruction, so I ultimately have to rely on proper care being taken when setting up the table. OTOH, part of the fun might be seeing what happens if you enumerate the same ROM multiple times - backup first

So, could these be reasonable default place holder values:

Code:

; SIZE , RESV , TYPE , CLAS , LAST , FLAG , ADDR , CHIP
  0x0A , 0x00 , 0x01 , 0x00 , 0x08 , 0x01 , 0x00 , 0x05

or this ?

Code:

; SIZE , RESV , TYPE , CLAS , LAST , FLAG , ADDR , CHIP
  0x0A , 0x00 , 0x01 , 0x00 , 0x00 , 0x00 , 0x00 , 0x00

Sylvain

edit: added the second option

[Sylvain Cote]

MultiMod Preparation Table Alternate Version

[mfleming]

Now that I like and shall adopt. I'll post a mapping diagram I made on the morrow. Processing a chip 0 is a recent addition with not a lot of guards around it yet, so best to avoid unless you really mean it. Added mainly to make J-F's Ultimate ROM. That definitely should be the default setting of a board, unless you want the 41 Translator substituted...

Mapping with MATH and JPC entries swapped

[Sylvain Cote]

Mark, great mapping diagram, visually translate the configuration table perfectly.