[FRAM71] Pre-Production Batch

[Hans Brueggemann]

this is the memory organization in FRAM (i.e., internal addressing, _not_ HP-71B addresses):
1) 00000-1FFFF is reserved for diagnostic/alternate O/S,
2) 20000-2BFFF is unused,
3) 2C000-2C01F is reserved for Memory Configuration,
4) 2C020-2FFFF is unused,
5) 30000-FFFFF is reserved for the 0..12 configurable Memory Chips.

a. on start-up, HP-71B runs through a memory identification/assignment routine, identifying all memory on the bus by releasing an ID command while DIN of the port to be examined is high. after the first chip in the daisy chain has responded, it gets pre-configured by the HP-71B and in turn passes DIN=High on to the next chip on the daisy chain. this process repeats for a particular port, until there are no more chips responding to ID, or the max number of chips (16) on that daisy chain have been reached.
b. SYSROM (or, SYSRAM for that matter) gets not identified by the HP-71B, it's "assumed to be there" at 00000-01FFFF. FRAM71 maps its first two 32kB FRAM segments directly onto those addresses. SYSRAM is then selected by OD-ing (output-disabling) the calculator's SYSROM and at the same time output-enabling the SYSRAM area
c. FRAM71 does not use the internal FPGA-RAM for a simple reason: that RAM is volatile and hence would screw FRAM71's memory configuration as soon as your HP-71B loses power. a far more elegant way to keep the configuration is to store all neccessary values in FRAM itself, where it is kept safe for decades. but that comes at a price: the allocation of the configaration area ( 2C000-2C01F) fragments one of the 32kB blocks. that's why that block (or better to say, its remnants) is not available to the user. the configuration area is directly mapped to the cardreader address space, where it doesn't get cleared out by [ON]/[/],3, and where it is not interfering with any other system addresses, i.e., display area, IL mailbox (tried that accidentially -nasty surprise!), or the scratchpad at the far end of the address range.

i hope this clarifies a bit how FRAM71 is internally organized, and why 3 out of 16 32kB blocks are "gone". what i hear though is a request of having the FRAM memory chips readied with ROM images "behind the curtains" and then pick an appropriate set by setting the respective bits in the configuration area. is that correct? would that feature justify to kick out UART- and REDEYE- support?

thanks for your great input, guys!
hans