[FRAM71] Pre-Production Batch

[Hans Brueggemann]

all,
i'm glad to announce that the pre-production batch of FRAM71 finally made it into the "wild". there's a bunch of early adopters out there now who expressed their wish to publicly pool their findings. so, here is the thread where all info should go about experiences / bugs / updates around FRAM71, and let me start it off by attaching the latest version of the manual.


best regards,
hans

2015-10-04: Firmware update V511 "NASHVILLE"
Release Note:
V511 finally fixes a spurious bug where configuration would not be properly reset when configuring more than 8 modules.
Highly recommended, this is the last update before the upcoming V600.
Applicable User's Manual: FRAM71_V511_HW104 "NASHVILLE"
My sincere thanks go to Bob Rosperi for his excellent presentation in Nashville, and to Dave Frederikson for his invaluable support.

2015-07-19: Understanding the HP-71B memory allocation routine

2015-07-19: FRAM71 Configuration Sheet
Configuration sheet from manual in *.doc format. (thx to Bob Prosperi for the suggestion)

2015-07-05: FlashPro_Cable document update
graphics added to clarify cable connections. (thx to Michael Lopez for the hint)

2015-06-11: How to setup FlashPro4/5 in case of warnings
This Post tells you how.

2015-05-16: Firmware update V510
Release Note:
V510 fixes a bug where the internal configuration latches wouldn't get properly reset when multiple chips where removed from the configuration area at the same time. in V510, all internal configuration latches get reset during the first DIN phase after either [ON], INIT:1, INIT:3, or a configuration request [++] by the DIAGNOSTIC module. the reset is indicated by a brief flash of the LED.
Applicable User's Manual: FRAM71_V501/2_HW104

2015-05-16: Firmware update V502
Release Note:
V502 removes a limitation of V501 where CHIP_0 has to be configured LCIM in order to make it visible to the HP-71B (this limitation exists with V501 only, V43x does not have this limitation).
Applicable User's Manual: FRAM71_HW104_SW502_b.PDF
Users should only upgrade to V502 if they need CHIP_0 to be configurable as part of a multi-chip module.
All V5xx firmwares now allow for on-the-fly change of F-base addresses (i.e., under program control, without power cycling the HP-71B)

2015-03-06: Firmware update V430
Release Note:
NEW: support bank-switching of multiple FRAM memory blocks into same HP-71B address space
NEW: Firmware support for upgrading FRAM71 to 1 MByte of FRAM
CHANGED: now, 15 out of 16 x 32kB F-Blocks available (up from 13 in V421)
CHANGED: automatic F-Block assignment removed to improve configuration flexibility
REMOVED: REDEYE-support, due to lack of public interest ;o)
(note that this is a major firmware upgrade. read the fine updated manual for details. highly recommended for all users who do not plan to use REDEYE support.)


2014-12-21: Firmware update V421
Release Note:
in V420, FRAM71's write-protect flags of soft-ROM-declared RAM modules have no effect. POKE from the POKELEX lexfile can change contents of those ROMs.
in V421, write-protect flags now block all write-attempts to soft-ROM areas. POKE from the POKELEX lexfile executes "silently", but does not alter contents.
(note that this is a minor fix which does not affect/enhance "standard" use cases. users who have no means to update their FRAM71 should contact me through e-mail for options.)

[Dave Frederickson]

So you have a bunch of ROM images for the 71 that you'd like to load into your FRAM71, but you don't have an RS-232 to HP-IL interface and your '98 machine is in the garage. How to copy those ROM images to a LIF image so that they can be loaded with a PIL-Box?

1. Copy all the ROM.bin and IRAM.rom images you want in a LIF image, HPDir, and the below batch file into a subdirectory.

Code:

@echo off
HPDir -initialize -lif -9122 ROMS.lif
if exist *.bin copy *.bin *.#E21C > nul
if exist *.rom copy *.rom *.#E21C > nul
echo.
for %%f in (*.#E21C) do (
        echo %%~nf :
        HPDir -add ROMS.lif %%f
        echo.
        if %%~zf == 16384 HPDir -attrib -aux 800100800000 ROMS.lif %%~nf
        if %%~zf == 32768 HPDir -attrib -aux 800100000100 ROMS.lif %%~nf
        if %%~zf == 65536 HPDir -attrib -aux 800100000200 ROMS.lif %%~nf
)
del *.#E21C

2. Double-click the batch file. A 9114 compatible LIF image will be created containing all of the ROM images.
3. Verify with HPDir:

Code:

>hpdir roms.lif
                           SYS  FILE   NUMBER   RECORD     MODIFIED    PUB OPEN
FILE NAME             LEV TYPE  TYPE  RECORDS   LENGTH DATE       TIME ACC STAT
===================== === ==== ===== ======== ======== =============== === ====
71DIAG                  1 98X6 #e21c      256      256 00-<?>-00 00:00
HPILROM-1A              1 98X6 #e21c       64      256 00-<?>-00 00:00
HPILROM-1B              1 98X6 #e21c       64      256 00-<?>-00 00:00
JPC-1E                  1 98X6 #e21c      128      256 00-<?>-00 00:00
SURVEY                  1 98X6 #e21c       64      256 00-<?>-00 00:00
WB71                    1 98X6 #e21c      128      256 00-<?>-00 00:00
JPC-D                   1 98X6 #e21c      128      256 00-<?>-00 00:00
AMPISTAT                1 98X6 #e21c      128      256 00-<?>-00 00:00
CIRCUIT                 1 98X6 #e21c       64      256 00-<?>-00 00:00
CURVEFIT                1 98X6 #e21c      128      256 00-<?>-00 00:00
DATAACQ                 1 98X6 #e21c      256      256 00-<?>-00 00:00
DATACOMM                1 98X6 #e21c       64      256 00-<?>-00 00:00
DATAMNGT                1 98X6 #e21c      128      256 00-<?>-00 00:00
FORTHROM                1 98X6 #e21c       64      256 00-<?>-00 00:00
FORTH41                 1 98X6 #e21c       64      256 00-<?>-00 00:00
HP71DEMO                1 98X6 #e21c       64      256 00-<?>-00 00:00
MATHROM                 1 98X6 #e21c      128      256 00-<?>-00 00:00
TEXTEDIT                1 98X6 #e21c       64      256 00-<?>-00 00:00
ZENWAND                 1 98X6 #e21c       64      256 00-<?>-00 00:00
JPC-F01                 1 98X6 #e21c      128      256 00-<?>-00 00:00
FINANCE                 1 98X6 #e21c       64      256 00-<?>-00 00:00

53248 of 626688 bytes free.

or ILPer:

Code:

   NAME    S TYPE   LEN    DATE    TIME 
71DIAG       ROM   65536 01/00/00 00:00 
HPILROM-1A   ROM   16384 01/00/00 00:00 
HPILROM-1B   ROM   16384 01/00/00 00:00 
JPC-1E       ROM   32768 01/00/00 00:00 
SURVEY       ROM   16384 01/00/00 00:00 
WB71         ROM   32768 01/00/00 00:00 
JPC-D        ROM   32768 01/00/00 00:00 
AMPISTAT     ROM   32768 01/00/00 00:00 
CIRCUIT      ROM   16384 01/00/00 00:00 
CURVEFIT     ROM   32768 01/00/00 00:00 
DATAACQ      ROM   65536 01/00/00 00:00 
DATACOMM     ROM   16384 01/00/00 00:00 
DATAMNGT     ROM   32768 01/00/00 00:00 
FORTHROM     ROM   16384 01/00/00 00:00 
FORTH41      ROM   16384 01/00/00 00:00 
HP71DEMO     ROM   16384 01/00/00 00:00 
MATHROM      ROM   32768 01/00/00 00:00 
TEXTEDIT     ROM   16384 01/00/00 00:00 
ZENWAND      ROM   16384 01/00/00 00:00 
JPC-F01      ROM   32768 01/00/00 00:00 
FINANCE      ROM   16384 01/00/00 00:00

If you don't have a FRAM71 you can try out the ROM images with Emu71.

Dave

[Dave Frederickson]

After a ROM image is copied to a FRAM71 IRAM, is there any reason to reconfigure the IRAM to ROM? That is, other than Diag ROM behavior. Either will survive a Memory Lost.

[Paul Berger (Canada)]

I have the soft part of FORTH and the Math "ROM" in IRAM and I see no reason to change that that way if I want to "swap" ROMs I can just delete the contents and copy in the new one. Its easy to have the contents on a diskette and have a little BASIC program to do the copying.

[Dave Frederickson]

Once you've copied an image to IRAM in FRAM71 you can reconfigure the IRAM to be ROM. This better mimics the real hardware, but is there any reason to do this? Perhaps some tidbit of code checks to see if the module is indeed a ROM?

[rprosperi]

(12-13-2014 11:01 PM)Dave Frederickson Wrote:  Once you've copied an image to IRAM in FRAM71 you can reconfigure the IRAM to be ROM. This better mimics the real hardware, but is there any reason to do this? Perhaps some tidbit of code checks to see if the module is indeed a ROM?

Reconfiguring the IRAMs to ROM will protect the port contents from errant code romping thru memory. For example when playing with Forth (or even some unknown LEX files) I've trashed the contents of IRAM ports, but the "ROM" ports are preserved as-is. Basically this really just saves the time needed to ROMCOPY the port's content back to what it was, but it takes a lot less time to just POKE the revised FRAM config string to make them ROM one time, than rebuilding the IRAMs each time it gets destroyed.

[Hans Brueggemann]

(12-14-2014 12:40 AM)rprosperi Wrote:  Reconfiguring the IRAMs to ROM will protect the port contents from errant code romping thru memory. For example when playing with Forth (or even some unknown LEX files) I've trashed the contents of IRAM ports, but the "ROM" ports are preserved as-is. Basically this really just saves the time needed to ROMCOPY the port's content back to what it was, but it takes a lot less time to just POKE the revised FRAM config string to make them ROM one time, than rebuilding the IRAMs each time it gets destroyed.

exactly this. while FREE PORT (5.xy) mimics the freed RAM portion into soft configured ROM and hence protects its contents from a MEMORY LOST, it can't protect its contents against alterations that result from POKE operations. using FRAM71s configuration area to re-define portions of RAM to soft configured ROM sets FRAM71s internal read-only flag on that area which gives a better protection against overwrites, albeit not perfect, as the configuration area itself remains unprotected. also, doing POKE into an IRAM area will work without notice, while trying to POKE into a ROM-declared RAM area will result in "ILLEGAL ACCESS".


hans

[J-F Garnier]

Although I missed the first batch of FRAM71, Sylvain Côté was so kind to lend me his module for some time, so since today I have a new toy to play with!

My first comments and observations:

(12-14-2014 12:40 AM)rprosperi Wrote:  Reconfiguring the IRAMs to ROM will protect the port contents from errant code romping thru memory.

Changing the module type from IRAM to ROM without precautions can produce several side effects and strange errors, especially if there are Basic programs inside. The right, secure way to create a ROM module is to use ROMCOPY.
It is also possible to manually compile each Basic program by hand by running each.

(12-14-2014 12:30 PM)Hans Brueggemann Wrote:  ... using FRAM71s configuration area to re-define portions of RAM to soft configured ROM sets FRAM71s internal read-only flag on that area which gives a better protection against overwrites

Is really this internal read-only flag implemented? I tried to POKE (with the special, unrestricted POKE function from JPC ROM) into a ROM-declared area, and the memory was actually changed.

J-F
(Edited: changed 'unprotected' to 'unrestricted' for clarification)

[Dave Frederickson]

(12-20-2014 07:15 PM)J-F Garnier Wrote:  

(12-14-2014 12:40 AM)rprosperi Wrote:  Reconfiguring the IRAMs to ROM will protect the port contents from errant code romping thru memory.

Changing the module type from IRAM to ROM without precautions can produce several side effects and strange errors, especially if there are Basic programs inside. The right, secure way to create a ROM module is to use ROMCOPY.
It is also possible to manually compile each Basic program by hand by running each.

I believe we're looking at two different situations here. The first has to do with copying ROM images to a FRAM71 IRAM and the difference between leaving the memory configured as IRAM or reconfiguring it as ROM. The second situation is what you describe which is to create a ROM image. In that case ROMCOPY is the correct method as it creates an image with the proper checksums.

Note the caveat in Note 6 on p.12 of the manual. Soft-configured ROMs should be configured the same as the physical module. So while I'm unaware of any undesired side-affects, that means that a 32K ROM, which is physically two 16K ROMs, should be configured in FRAM71 as two 16K Chips. The image can be copied to a single 32K Chip, however the ROM test in the Diag ROM will fail calculating the checksums.

Dave

[Dave Frederickson]

(12-20-2014 07:15 PM)J-F Garnier Wrote:  The right, secure way to create a ROM module is to use ROMCOPY.

For those not familiar with ROMCOPY here're a couple of reference documents:

• ROMCOPY Syntax
• RCOPYDOC
  

Use of ROMCOPY comes with warnings so understand what you're doing and take the proper precautions.

Thanks to Joe Horn for the above documents.

Dave

[J-F Garnier]

(12-20-2014 08:34 PM)Dave Frederickson Wrote:  

(12-20-2014 07:15 PM)J-F Garnier Wrote:  Changing the module type from IRAM to ROM without precautions can produce several side effects and strange errors...

I believe we're looking at two different situations here. The first has to do with copying ROM images to a FRAM71 IRAM and the difference between leaving the memory configured as IRAM or reconfiguring it as ROM. The second situation is what you describe which is to create a ROM image. In that case ROMCOPY is the correct method as it creates an image with the proper checksums.

Yes, you're right, my comment was unclear. It is perfectly correct to load a ROM image (with ROMCOPY) in IRAM then change the module type to ROM. This is what I'm used to do also in Emu71.
My comment was about using the ROM type to protect a IRAM built manually by program entry or normal COPY.
Note that this has to do not only with wrong checksum (that will not harm in normal use), but with Basic programs 'compiling' - actually the right term here is 'chaining', meaning the calculations of the GOTO/GOSUB targets.

[Hans Brueggemann]

(12-20-2014 07:15 PM)J-F Garnier Wrote:  Is really this internal read-only flag implemented? I tried to POKE (with the special, unrestricted POKE function from JPC ROM) into a ROM-declared area, and the memory was actually changed.

J-F

thanks for digging this up, J-F!
i tested the write protection flags against the standard POKE only. ouch.
there is a firmware update to V421 available at the start of this thread which fixes this issue.

hans

[Dave Frederickson]

(12-21-2014 06:28 PM)Hans Brueggemann Wrote:  2014-12-21: Firmware update V421
Release Note:
in V420, FRAM71's write-protect flags of soft-ROM-declared RAM modules have no effect. POKE from the POKELEX lexfile can change contents of those ROMs.
in V421, write-protect flags now block all write-attempts to soft-ROM areas. POKE from the POKELEX lexfile executes "silently", but does not alter contents.
(note that this is a minor fix which does not affect/enhance "standard" use cases. users who have no means to update their FRAM71 should contact me through e-mail for options.)

I found two NIB FlashPro4 programmers on eBay for $25 ea.

What's In the Box


With a few cable parts an adapter can be made, or the included cable can be modified.


Let's rock and roll!


Dave

[Hans Brueggemann]

In a recent e-mail, Dave Frederickson pointed out to me that it would be nice to be able to access all 512kB of FRAM, by using some sort of bank switching scheme. i find this idea quite intriguing and FRAM71's FPGA still has ample amount of free logic available (as per V.421) to handle such a task. alas... i'm short on ideas of how to implement that to gain maximum use from such a feature. when looking at the used FRAM address space (nibble addresses),
00000-1FFFF is reserved for diagnostic/alternate O/S,
20000-2BFFF is unused,
2C000-2C01F is reserved for Memory Configuration,
2C020-2FFFF is unused,
30000-FFFFF is reserved for the 0..12 configurable Memory Chips.
that gives basically the range 20000-2BFFFF as a possible candidate for bankswitching.
so, what can we do with that? is it worth a try in the light of the amount of FRAM already available?
what's your take on this, valued users?

hans

[rprosperi]

(02-07-2015 06:55 PM)Hans Brueggemann Wrote:  In a recent e-mail, Dave Frederickson pointed out to me that it would be nice to be able to access all 512kB of FRAM, by using some sort of bank switching scheme. i find this idea quite intriguing and FRAM71's FPGA still has ample amount of free logic available (as per V.421) to handle such a task. alas... i'm short on ideas of how to implement that to gain maximum use from such a feature. when looking at the used FRAM address space (nibble addresses),
00000-1FFFF is reserved for diagnostic/alternate O/S,
20000-2BFFF is unused,
2C000-2C01F is reserved for Memory Configuration,
2C020-2FFFF is unused,
30000-FFFFF is reserved for the 0..12 configurable Memory Chips.
that gives basically the range 20000-2BFFFF as a possible candidate for bankswitching.
so, what can we do with that? is it worth a try in the light of the amount of FRAM already available?
what's your take on this, valued users?

hans

Dave and I have been discussing this for a while... and it grew out of wondering why the full 512KB wasn't accessible. Clearly FRAM71 has the means to do it, so why doesn't it do so? There had to be a reason, we reasoned. And I guess that lead to your discussion.

I have yet to find anything serious that exceeds FRAM71's current abilities, but also haven't tried yet. Still, I would say that yes, it's worth it. I've never owned any calculator* with which I haven't run into a memory limit, whether doing "serious" work, or just experimenting/playing. Before Clonix/NOV and the CL were made, who would have ever guessed that a 41 could ever need more that 4 modules? Now, 4, 5, or 6 are just the basic OS/system build, before adding-in app roms.

From your notes above, it appears one could create a bank-switched scheme with a 16KB window in the available address space, and while a 32KB window would be more convenient to, for example, swap-in/out ROM images or IRAMs, this is still useful.

Just some feedback to stimulate discussion.

* Notable exception - I've never filled my 50g 2 GB SD card

[Paul Dale]

A truly write protected module image?
Thinking maths here but anything that fits.


- Pauli

[Dave Frederickson]

(02-07-2015 06:55 PM)Hans Brueggemann Wrote:  In a recent e-mail, Dave Frederickson pointed out to me that it would be nice to be able to access all 512kB of FRAM, by using some sort of bank switching scheme. i find this idea quite intriguing and FRAM71's FPGA still has ample amount of free logic available (as per V.421) to handle such a task. alas... i'm short on ideas of how to implement that to gain maximum use from such a feature. when looking at the used FRAM address space (nibble addresses),
00000-1FFFF is reserved for diagnostic/alternate O/S,
20000-2BFFF is unused,
2C000-2C01F is reserved for Memory Configuration,
2C020-2FFFF is unused,
30000-FFFFF is reserved for the 0..12 configurable Memory Chips.
that gives basically the range 20000-2BFFFF as a possible candidate for bankswitching.
so, what can we do with that? is it worth a try in the light of the amount of FRAM already available?
what's your take on this, valued users?

It's not the system address space I was suggesting be utilized, but the FRAM memory itself. Currently the 512k FRAM is divided into 16-32k "Chips", 13 of which are available for configuration as RAM or (truly write-protected) ROM. Two are reserved for the SYSRAM feature and the last is unused. What I'm suggesting is that another configuration register, like the 0x2C000 register, perhaps at address 0x2C020, but only 16 bits in length, be created. Each bit would correspond to a 32k Chip in FRAM and if set, that Chip would be "Enabled". The rules would be:

1. Up to 13 bits can be set at one time, corresponding to Chips 12 - 0.
2. The two least significant bits are reserved for SYSRAM and are always zero
   

By manipulating the bits the "active" Chips can be switched making different ROM configurations possible without reloading an image. It should be possible to load an alternate O/S into the 64k SYSRAM and configure the other 14-32k Chips into RAM or ROM.

For example, if 0x2C020 is loaded with 0xF000 and that would enable the 0xF0000 block of FRAM. This would be mapped into Chip 12 and 32k ROM1 could be load into it. If 0x2C020 were loaded with 0x8000 that would enable the 0xE0000 block of FRAM and 32k ROM2 could be load into it. The significant difference is that the set bits in 0x2C020 determine which blocks of FRAM get mapped to Chips, so 0xE0000 become Chip 12, also. By manipulating the bit in 0x2C020 either ROM1 or ROM2 can be enabled.

Another example, load 0x2C020 with 0xFFF8 enabling 13 blocks of FRAM starting at 0x30000 and load 0x30000 with ROM1. Load 0x2C020 with 0xFFFB enabling 13 blocks of FRAM starting at 0x20000 with the 32k block at 0x30000 disabled. Memory at 0x20000 gets mapped to Chip 0 and ROM2 can get loaded into FRAM at 0x20000. Now 14-32k blocks of FRAM can be utilized for RAM or ROM, with the limitation of only 13 of those being enabled at one time.

The FRAM configuration registers at 0x2C000 would need to be moved to the NVRAM in the FPGA, if they're not already there.

Does that make sense? It's important to understand that FRAM memory would get mapped to Chips which then get mapped to 71B address space by the 71's O/S during the power-on memory configuration.

Dave

[Michael Fehlhammer]

I have to admit that I didn't really understand Dave's sophisticated considerations, probably it's too late at night right now, but I'd like to contribute a very simple argument why bank switching would be helpful:
I am pretty sure that most of the FRAM71 users have been 71b power users before and own a lot of physical modules, like math and curve fitting, for example, and they certainly use the IL module. These three modules consume 2 * 32k + 48k = 112k of address space, right? If I plug in these modules, 112 (more) kiloBytes of FRAM cannot be used.
If I had a bankswitching mechanism, I could make use of the "hidden" RAM pages.

[Dave Frederickson]

(02-10-2015 02:19 AM)Michael Fehlhammer Wrote:  I have to admit that I didn't really understand Dave's sophisticated considerations, probably it's too late at night right now, but I'd like to contribute a very simple argument why bank switching would be helpful:
I am pretty sure that most of the FRAM71 users have been 71b power users before and own a lot of physical modules, like math and curve fitting, for example, and they certainly use the IL module. These three modules consume 2 * 32k + 48k = 112k of address space, right? If I plug in these modules, 112 (more) kiloBytes of FRAM cannot be used.
If I had a bankswitching mechanism, I could make use of the "hidden" RAM pages.

Correct. Other RAM and ROM's subtract from the FRAM available to the 71B. All 512k of FRAM can't be accessed all at once because of the 71B's 512k addressing limitation. What I think could be done via bank-switching is to disable blocks of FRAM for one configuration and enable different blocks for another configuration. The 71 would configure only the enabled blocks. I would think that it's possible to bank-switch all 16 blocks of FRAM. In reality there's probably something I don't understand about the FRAM71 architecture preventing this.

[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