HP Forums
FRAM71 : Configuration Spreadsheet [2021-01-31] - Printable Version

+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: FRAM71 : Configuration Spreadsheet [2021-01-31] (/thread-16256.html)

Pages: 1 2

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Hans Brueggemann - 02-06-2021 06:49 AM

FRAM71: if J1 and J2 are inserted at the same time, is it harmfull to the hardware ?
THIS IS HARMFULL and WILL DAMAGE YOUR HP-71B.
See the “Nashville” 2015 manual or any manual prior to “Denver” 2016, chapter 7.x. This was one reason why FRAM71 got a redesign into FRAM71B.

if J1 and CN2-5 are inserted at the same time, is it harmfull to the hardware ?
No, not at all harmfull, but may slightly increase current consumption.

if no, how the firmware will react to it?
freeze it ?
No

Hardwire is active and part of SYSRAM is active (0x10000 to 0x1FFFF) ?
yes, but not visible to your HP-71B. This situation causes both FRAM71(B) and HP-71B to simultaneously access the memory bus, but FRAM71(B) bus outputs are designed to be weaker than the HP-71B’s bus drivers. Hence, HP-71B always “wins”.

if CN2-3 and J1 are inserted at the same time
is it harmfull to the hardware ?
No

if no, how the firmware will react to it ? (my take will be that CN2-3 take precedence)
see “Nashville” chapter 7.3, “Denver” chapter 8.3

if CN2-3 and CN2-5 are inserted at the same time
is it harmfull to the hardware ?
No
if no, how the firmware will react to it ? (my take will be that CN2-3 take precedence)
Yes

if CN2-3, J1 and CN2-5 are inserted at the same time
is it harmfull to the hardware ?
No
if no, how the firmware will react to it ? (my take will be that CN2-3 take precedence)
Yes

More generally, in what order the FPGA code evaluate the jumpers.
CN2-3 always takes precedence.

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Sylvain Cote - 02-13-2021 08:09 PM

Hello Hans,

First, thank you for your previous answers, very much appreciated.

While doing the final testing before releasing the spreadsheets with validation, I stumbled upon something unexpected or forgotten.
The following behavior has been there all along since the original FRAM71 and still is in FRAM71B.
When I try to create a virtual module with different module size, it creates something of a problems, see the following testing results ...
Code:
        |                        |                  |        | ---[ SHOW  PORT ]--- | --------[ MEMBUFF  OUTPUT ]-------- | 
Module  | Test                   | POKE "2C000",... | MEM(5) | Port   Size    Type  | Port  Dev  Seq  Size  Addr   Type   | Comment
------- | ---------------------- | ---------------- | ------ | ----  ------  ------ | ----  ---  ---  ----  -----  ------ | --------------------------------
Code:
FRAM71B | #01 → 96 = 32+32+32    | "13149500"       |  98299 |   5    98304  1:IRAM |   5    0    0    96   D0000  1:IRAM | Expected
FRAM71B | #02 → 48 = 16+16+16    | "2324A500"       |  49147 |   5    49152  1:IRAM |   5    0    0    48   48000  1:IRAM | Expected
------- | ---------------------- | ---------------- | ------ | ----  ------  ------ | ----  ---  ---  ----  -----  ------ | --------------------------------
FRAM71B | #03 → 80 = 32+32+16    | "1314A500"       |  65531 |   5    65536  1:IRAM |   5    0    0    64   E0000  1:IRAM | Unexpected
        |                        |                  |        |   5    16384  1:IRAM |   5    0    1    16   48000  1:IRAM | 
------- | ---------------------- | ---------------- | ------ | ----  ------  ------ | ----  ---  ---  ----  -----  ------ | --------------------------------
FRAM71B | #04 → 80 = 32+16+32    | "13249500"       |  32763 |   5    32768  1:IRAM |   5    0    0    32   E0000  1:IRAM | Unexpected
        |                        |                  |        |   5    16384  1:IRAM |   5    0    1    16   40000  1:IRAM | 
        |                        |                  |        |   5    32768  1:IRAM |   5    0    2    32   D0000  1:IRAM |

In tests #01 and #02:
  • I have create a virtual port with three identical FRAM chip size
  • the HP-71 only sees one virtual chip instead of the individual chips.
In tests #03 and #04:
  • I have create a virtual port with two identical FRAM chip size and one different FRAM chip size
  • depending on how those FRAM chips are mapped the HP-71 only sees two or three chips instead of a single virtual chip
  • this creates an issue when these chips are mapped to the port number, they get the same port number.
If I expand my test #03
  • MEM(5) // display 65531 that is the size of the combined two 32K chips
  • CLAIM :PORT(5) // transfer the 64KB virtual chip from IRAM to MAIN RAM
  • RUN MEMBUF shows
    Code:
    Port  Dev  Seq  Size  Addr   Type  
    ----  ---  ---  ----  -----  ------
      5    0    0     64  30000  0:MAIN
      5    0    1     16  68000  1:IRAM
  • MEM(5) // display 16379 that is the size of the last 16K chip
  • CLAIM :PORT(5) // transfer the 16KB virtual chip from IRAM to MAIN RAM
  • RUN MEMBUF shows
    Code:
    Port  Dev  Seq  Size  Addr   Type  
    ----  ---  ---  ----  -----  ------
      5    0    0     64  30000  0:MAIN
      5    0    1     16  50000  0:MAIN
    if I go the reverse route by freeing port 5
  • FREE :PORT(5) // transfer the 64KB virtual chip from MAIN to IRAM
  • MEM(5) // display 65531 that is the size of the combined two 32K chips
  • RUN MEMBUF shows
    Code:
    Port  Dev  Seq  Size  Addr   Type  
    ----  ---  ---  ----  -----  ------
      5    0    1     16  30000  0:MAIN
      5    0    0     64  E0000  1:IRAM
  • FREE :PORT(5) // transfer the 16KB virtual chip from MAIN to IRAM
  • MEM(5) // display 65531 that is the size of the combined two 32K chips
  • RUN MEMBUF shows
    Code:
    Port  Dev  Seq  Size  Addr   Type  
    ----  ---  ---  ----  -----  ------
      5    0    0     64  E0000  1:IRAM
      5    0    1     16  48000  1:IRAM

What I find strange here is that we have two different behavior, one for identical chip size and one for different chip size.
Also the second one introduce an issue from the 71B OS perspective, multiple port with the same number.

Sylvain

PS: Testing has been done with a FRAM71 (2015 production) and with a FRAM71B (2021 production)

PPS: for the FRAM71/FRAM71B newbies here, this is an edge case and should not derail you from using this great module. Cool

edit 1 : typos
edit 2 : PPS added

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Dave Frederickson - 02-13-2021 11:30 PM

What's the firmware version of your FRAM71?

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Sylvain Cote - 02-14-2021 12:06 AM

(02-13-2021 11:30 PM)Dave Frederickson Wrote:  What's the firmware version of your FRAM71?
Should be v5.02, I would have to check, but I am having the same behavior with the FRAM71B that I received 2 weeks ago.

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Dave Frederickson - 02-14-2021 12:55 AM

After referring to the IDS, I believe all chips in a sequence must be the same size, or more precisely, have the same Chip ID.

Dave

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Sylvain Cote - 02-14-2021 02:16 AM

(02-14-2021 12:55 AM)Dave Frederickson Wrote:  After referring to the IDS, I believe all chips in a sequence must be the same size, or more precisely, have the same Chip ID.
I understand that and this is what we are partly seeing, but it seems that what I am trying to convey is not clear, let me try to explain it again, maybe this it will be more clear.

a) if we decide to see each individual chip then MEMBUF in the example #03 should give us the following report:
Code:
|                        |                  |        | ---[ SHOW  PORT ]--- | --------[ MEMBUFF  OUTPUT ]-------- | 
| Test                   | POKE "2C000",... | MEM(5) | Port   Size    Type  | Port  Dev  Seq  Size  Addr   Type   | 
| ---------------------- | ---------------- | ------ | ----  ------  ------ | ----  ---  ---  ----  -----  ------ | 
| #03 → 80 = 32+32+16    | "1314A500"       |  32768 |   5    32768  1:IRAM |   5    0    0    32   E0000  1:IRAM | 
|                        |                  |        |   5    32768  1:IRAM |   5    0    1    32   D0000  1:IRAM | 
|                        |                  |        |   5    16384  1:IRAM |   5    0    2    16   48000  1:IRAM | 
| ---------------------- | ---------------- | ------ | ----  ------  ------ | ----  ---  ---  ----  -----  ------ |
The above option still creates an issue with multiple simultaneous ports 5.00.

b) otherwise if we decide to only see one virtual chip, then MEMBUF in example #03 should give us the following report:
Code:
|                        |                  |        | ---[ SHOW  PORT ]--- | --------[ MEMBUFF  OUTPUT ]-------- | 
| Test                   | POKE "2C000",... | MEM(5) | Port   Size    Type  | Port  Dev  Seq  Size  Addr   Type   | 
| ---------------------- | ---------------- | ------ | ----  ------  ------ | ----  ---  ---  ----  -----  ------ | 
| #03 → 80 = 32+32+16    | "1314A500"       |  81920 |   5    81920  1:IRAM |   5    0    0    80   C0000  1:IRAM | 
| ---------------------- | ---------------- | ------ | ----  ------  ------ | ----  ---  ---  ----  -----  ------ |

Currently we have a split personality behavior,
a) if you define multiple chips of the same size, then the module expose one virtual chip made of multiple FRAM chips, but
b) if you define multiple chips with a mix of size, then the module expose several virtual chips made of multiple sequential FRAM chips of the same size, if any.

We are discussing semantic here, because for sure I can reproduce the 80KB configuration by aggregating five 16KB chips to create one virtual 80KB chip.

The reason I am discussing this issue, is that I want to correctly do the calculations, the ports assignation and the warnings in the spreadsheet to reflect the module behavior as much as possible.

Sylvain

edit: typo

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - twoweims - 02-14-2021 03:00 AM

Please forgive a stupid question from a new FRAM user...

I think I understand the problem, but why would I want to ever create an 80KB IRAM 32+32+16 as opposed to making it 96KB 32+32+32? Doesn't half of the last chip get essentially wasted?

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Sylvain Cote - 02-14-2021 03:46 AM

(02-14-2021 03:00 AM)twoweims Wrote:  Please forgive a stupid question from a new FRAM user...
I am asking sometime (often?) stupid questions and I am not a new FRAM71 user, so let says that there are no stupid questions Wink

(02-14-2021 03:00 AM)twoweims Wrote:  I think I understand the problem, but why would I want to ever create an 80KB IRAM 32+32+16 as opposed to making it 96KB 32+32+32? Doesn't half of the last chip get essentially wasted?
Actually I have used a 80KB module because it covered both module versions, but in reality we are trying to replicate the original HP ROM sizes.
I would have to check in the old papers, but I think they were available in multiple of 8K between 8K and 64K.

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Sylvain Cote - 02-14-2021 03:53 AM

(02-14-2021 02:16 AM)Sylvain Cote Wrote:  The reason I am discussing this issue, is that I want to correctly do the calculations, the ports assignation and the warnings in the spreadsheet to reflect the module behavior as much as possible.
After doing some thinking, I will add a validation against using multiple chip sizes in a module.
With the current behavior, having multiple ports with the same port number layering one of top of the other will only confuse users.
This means that the release of the updated spreadsheets with validation are delayed by a couple of days.

edit: typo

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Dave Frederickson - 02-14-2021 05:04 AM

(02-14-2021 03:53 AM)Sylvain Cote Wrote:  After doing some thinking, I will add a validation against using multiple chip sizes in a module.

I believe this is consistent with the IDS.

However, you've uncovered an interesting behavior that perhaps could be exploited. Smile

Dave

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Sylvain Cote - 07-31-2021 04:27 AM

Finally, an updated version of the FRAM71/B Configuration Spreadsheet is available HERE.
I have released the Numbers version, the Excel version is currently being created and will be release in August.
Sylvain

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Massimo Gnerucci - 07-31-2021 06:44 AM

(07-31-2021 04:27 AM)Sylvain Cote Wrote:  Finally, an updated version of the FRAM71/B Configuration Spreadsheet is available HERE.
I have released the Numbers version, the Excel version is currently being created and will be release in August.
Sylvain

An excellent job, as usual, Sylvain.
Can't wait for the Excel version ;)

Thank you.

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Hans Brueggemann - 08-01-2021 11:17 AM

thank you sylvain, a piece of art (again)!

(02-14-2021 03:00 AM)twoweims Wrote:  ..., but why would I want to ever create an 80KB IRAM 32+32+16 as opposed to making it 96KB 32+32+32? Doesn't half of the last chip get essentially wasted?

there's one thing in your HP-71B which is even more precious than FRAM space: the available address space. in return for wasting FRAM space (which yours truly wasted in the first place because of using a 32 kB container concept), you save 16kB of address space for an extra plug-in module.

RE: FRAM71 : Configuration Spreadsheet [2021-01-31] - Sylvain Cote - 08-08-2021 09:51 PM

A new version (20210808A) of the FRAM71/B Configuration Spreadsheet is available HERE.
It includes an updated version of the Apple Numbers spreadsheet and the first version of the Microsoft Excel spreadsheet.
Have fun! Cool ... as usual, if you find bugs or inconsistencies please reports those here.
Sylvain

Edit: for each software (Numbers & Excel) there is two files, one standard and one with the test suites in it. Unless you want to see the configuration edge cases, you should use the standard version.