Threaded Mode | Linear Mode

Dave Frederickson · 02-21-2015, 10:53 PM

The v430 manual doesn't list the new feature from item 3 in your email from Feb 12, that the same FRAM space can be assigned to multiple chips.

The last build looks good so far. It appears that when configuring devices using multiple chips that the chips must all be the same size.

Dave

Hans Brueggemann · (This post was last modified: 02-22-2015 06:31 PM by Hans Brueggemann.)

dave, thanks for the feedback, that's great news!

1) found a minor bug just an hour ago during my final testing and seem to have fixed it now. doesn't affect bankswitching or memory management, hence no update at this point (will post update here after a final test round, probably end of this week).

2) as for the bankswitching description in the manual, yes, it lacks "focus" and will probably get more detail, but may take another two weeks or so.

3) i still have to look at using chips with different sizes in one module.

4) as for the 16k vs. 32k memory requirements of the IL-ROM, i had totally forgotten about the note in the educalc article, so, yes, seems that the HPIL-ROM is sometimes configured into a 32 kByte address space, although the DIAG-ROM still reports only 32 kNibble. is there any further read on that anomaly?

5) afaik, bob had the idea to run an image of the HPILROM in FRAM71 to overcome the bugs found in HPILROM 1A. although the image runs fine, it can't "talk" to the IL-processor of the HPIL-module, probably because the module is locking the mailbox area to the processor. i tried to disable the ROM of the module by disconnecting it from DIN, but that disabled the IL-processor as well. question to the hardware guys 'n gals here: is there a way to only disconnect the ROM inside the HPIL-module from DIN and keep the processor connected?

hans

Dave Frederickson · (This post was last modified: 02-23-2015 04:28 PM by Dave Frederickson.)

Here's a Pratical Example of Utilizing FRAM71.

Port 5: 192k RAM
Port 5.01: 32k IRAM for LEX files
Port 5.02: 16k SC FORTH ROM
Port 5.03: 32k JPC ROM
Port 5.04: 32k Math ROM (F_0xD0000) / Curve Fitting ROM (F_0xE0000)
Port 5.05: 16k RAM
SYSROM: 64k Service ROM

The only physical modules plugged into the 71B are the FRAM71 and HP-IL. Port 5.04 demonstrates the new bank-switching feature. 32k of address space can be switched between the Math ROM and the Curve Fitting ROM as shown below simply by changing one nibble in the configuration string.

This utilizes 448k of FRAM. In this configuration, 368k is the maximum amount of usable memory that I can get at once.

Code:

>POKE"2C000","931415161718999AEBDCDDAF"

>VER$

HP71:2CDCC RCPY:E HPext:B FTH:1A EDT:A KBD:B JPC:F01 HPIL:1B MATH:1A

>

>POKE"2C000","931415161718999AEBDCDEAF"

>

>VER$

HP71:2CDCC RCPY:E HPext:B FTH:1A EDT:A KBD:B JPC:F01 HPIL:1B FIT:A

>SHOWPORT

0.05  16384  2

5.01  32768  1

5.02  16384  2

5.03  32768  2

5.04  32768  2

0      4096  0

0.01   4096  0

0.02   4096  0

0.03   4096  0

5    196608  0

5.05  16384  0

>MEM

 229726 

>PCAT ALL

workfile   BASIC     0 01/01/00 00:00

HPILROM    LEX   16361 08/07/84 12:00 0.05

PEEKUTIL   LEX     351 01/01/00 00:03 5.01

DESAL      LEX     718 01/01/00 00:10 5.01

ROMCOPY    LEX    1727 01/01/00 00:11 5.01

EXTFILES   LEX     502 01/01/00 00:11 5.01

UNPRIV     LEX     105 01/01/00 00:12 5.01

ROMDUMP    BASIC   117 01/04/00 19:25 5.01

FILE2SYS   BASIC   156 01/01/00 13:13 5.01

COPYSYS    BASIC   139 01/01/00 13:15 5.01

CNVDMP     BASIC   168 01/01/00 01:02 5.01

F2R        BASIC   160 01/01/00 01:07 5.01

MCOPY94    LEX     932 01/01/00 01:00 5.01

START      BASIC    34 01/01/00 00:07 5.01

FORTHROM P LEX    3445 02/23/84 12:00 5.02

EDTEXT     BASIC  6790 02/23/84 12:00 5.02

EDKEYS     KEY      54 02/23/84 12:00 5.02

EDLEX      LEX    2557 02/23/84 12:00 5.02

DBGLEX     LEX     141 02/23/84 12:00 5.02

KEYBOARD   LEX    1277 02/23/84 12:00 5.02

JPCF01     LEX   25933 09/02/07 20:20 5.03

ML         BASIC    55 09/02/07 20:20 5.03

CurveFit   LEX      41 01/12/84 12:00 5.04

CFIT       BASIC 14219 01/12/84 12:00 5.04

OPTIMIZE   BASIC  5068 01/12/84 12:00 5.04

MODELS     BASIC  5789 01/12/84 12:00 5.04

PCENTCHI   BASIC   727 01/12/84 12:00 5.04

FITLEX     LEX     415 01/12/84 12:00 5.04

FITLIB     BIN    5545 01/12/84 12:00 5.04

CFKEYZ     KEY      83 01/12/84 12:00 5.04

Paul Berger (Canada) · 02-22-2015, 11:49 PM

(02-22-2015 06:30 PM)Hans Brueggemann Wrote: dave, thanks for the feedback, that's great news!

5) afaik, bob had the idea to run an image of the HPILROM in FRAM71 to overcome the bugs found in HPILROM 1A. although the image runs fine, it can't "talk" to the IL-processor of the HPIL-module, probably because the module is locking the mailbox area to the processor. i tried to disable the ROM of the module by disconnecting it from DIN, but that disabled the IL-processor as well. question to the hardware guys 'n gals here: is there a way to only disconnect the ROM inside the HPIL-module from DIN and keep the processor connected?

hans

Unfortunately you cannot just disconnect DIN as you noted above it is still required to assign I/O addresses to the interface hardware. I have seen the inside of the module however I don't remember if there was an obvious separation between the ROM and the HPIL interface hardware and if it where, it would require some delicate and possibly irreversible surgery. It is very likely that the ROM in the module uses chips of the same design as the system ROMs and as such would have a facility to disable them and it may even be accessible either as a pad on the modules board or may even be brought out to the OD pin on the module. Even if it was brought out there it would not normally contact anything as the connector pad for OD at the HPIL position is located behind all the other contact pad.

If your replacement ROM was configured ahead of the ROM in the HPIL module, then the keywords in the replacement ROM would be found ahead of the original always, this is why the manual for the dual adapter advises you to put the newest version of the module in the bottom slot of the dual adapter. The problem is the FRAM is installed in the card reader port so will always be found after the HPIL module.

Dave Frederickson · (This post was last modified: 02-27-2015 06:11 AM by Dave Frederickson.)

The FRAM71 manual has some important notes at the end of the Memory Configuration chapter. Note 6 states that memory for ROM images should be configured the same as the physical module. 32k ROM's, like the Math ROM, are comprised of 2-16k ROM's. That means that a FRAM71 Chip shouldn't be configured as a single 32k ROM. While this appears to work, the Diag ROM reports a checksum error with the Math ROM configured this way.
Firmware v430 sports a new feature allowing the same FRAM address space to be assigned to multiple chips. It should be possible to configure one 32k block of FRAM as two 16k ROM's, in accordance with Note 6.

When the config string is set to "24A4" the setting DISPLAY IS PRINTER is lost. Restoring the setting:

Code:

>SHOWPORT

0.05  16384  2

0      4096  0

0.01   4096  0

0.02   4096  0

0.03   4096  0

5     32768  0

This appears to configure the Chip as Port(5) as required. The Diag ROM reports 2-32k nibbles of RAM at 0x30000 as expected.

Code:

>FREEPORT(5)

0.05  16384  2

0      4096  0

0.01   4096  0

0.02   4096  0

0.03   4096  0

5     32768  0

Port(5) didn't get freed. Not giving up, yet.

Code:

>POKE"2C000","A4A4"

>SHOWPORT

0.05  16384  2

0      4096  0

0.01   4096  0

0.02   4096  0

0.03   4096  0

5     16384  0

5.01  16384  0

>FREEPORT(5)

>SHOWPORT

0.05  16384  2

5     16384  1

5.01  16384  1

0      4096  0

0.01   4096  0

0.02   4096  0

0.03   4096  0

Two ports freed with one command. Wasn't expecting that behavior.

Code:

>POKE"2C000","24A4"

>SHOWPORT

0.05  16384  2

5     32768  1

0      4096  0

0.01   4096  0

0.02   4096  0

0.03   4096  0

Okay. There is now a 32k IRAM comprised of 2-16k RAM's. The Diag ROM reports the port as 2-32k nibble RAM's and the P/I RAM test passes both RAM's.
DISPLAY IS again had to be reassigned.

Code:

>SHOWPORT

0.05  16384  2

5     32768  1

0      4096  0

0.01   4096  0

0.02   4096  0

0.03   4096  0

>

>COPY ROMCOPY:TAPE

>ROMCOPY MATHROM:TAPE TO :PORT(5)

ERR:Device Not Found

>CLAIMPORT(5)

ERR:Device Not Found

Now the port isn't being detected. Can't to get this new feature to work.

Dave

Hans Brueggemann · (This post was last modified: 02-27-2015 04:10 PM by Hans Brueggemann.)

(02-27-2015 05:20 AM)Dave Frederickson Wrote: The FRAM71 manual has some important notes at the end of the Memory Configuration chapter. Note 6 states that memory for ROM images should be configured the same as the physical module. 32k ROM's, like the Math ROM, are comprised of 2-16k ROM's. That means that a FRAM71 Chip shouldn't be configured as a single 32k ROM.

This is an ambiguity in the manual. the recommendation to configure ROM images the same way as their physical counterpart is given for only one reason: avoid the diagnostic module throwing an error on 32KB images where it expects them to be 2 x16 kB images. As J-F pointed out, the diagnostic module is looking at 16kB checksums and hence doesn't properly recognize 32KB chips w/o adjusting the checksums.
Practically, if the user doesn't care about the diagnostic module giving checksum errors on ROM images, it makes more sense to configure the images into single chips of 32K, because FRAM is segmented into 32K memory blocks. More so, as two (=64K) blocks of precious FRAM space get used up when configuring a ROM image to 2 x 16K.

(02-27-2015 05:20 AM)Dave Frederickson Wrote: Firmware v430 sports a new feature allowing the same FRAM address space to be assigned to multiple chips. It should be possible to configure one 32k block of FRAM as two 16k ROM's, in accordance with Note 6.

FRAM space is segmented into 32K blocks, which can't be changed. when trying to configure "24A4", HP-71B will indeed detect one RAM module consisting of two chips, each with a size of 16K, and SHOWPORT reports it as 5 32768 0. However, FRAM71's MMU is mapping the first chip ("24") to F_0x40000, and the second one ("A4") on top of it, i.e., also at F_0x40000. FRAM71 can't assign multiple chips to the same F-Block in a _consecutive_ manner, but only on top of each other. that means that a chip which is configured to a particular F-Block will be mirrored by all chips that are configured to the same F-Block.
Note that firmware V42x.has an automatic block-assignment feature that prevents this behavior.

(02-27-2015 05:20 AM)Dave Frederickson Wrote: Port(5) didn't get freed.

With said "24A4" configuration, the memory configuration routine of the HP-71B will execute FREEPORT(5) on the first chip by writing the magic number into H_0x30000, which is, for our example "24A4", = F_0x40000 in FRAM. Then, FREEPORT will clear the newly acquired memory, thus overwriting the magic number in chip_0 while seemingly erasing chip_1. therefore, SHOWPORT will not find any FREEd port.

(02-27-2015 05:20 AM)Dave Frederickson Wrote: Two ports freed with one command. Wasn't expecting that behavior.

Here, "A4A4" vectors two single-chip modules to the same F-Block.the FREEPORT(5) magic number gets mirrored into port(5.01) and consequently SHOWPORT finds two FREEPORTs.

(02-27-2015 05:20 AM)Dave Frederickson Wrote: Now the port isn't being detected.

FRAM71's best feature is also its worst: It doesn't forget anything inside disabled/unused F-Blocks unless "explicitly ordered" to do so. FREEPORT magic numbers get easily forgotten when changing memory configuration but may unexpectedly come back to life once you revive a previously disabled F-Block. typical symptoms are less-than-expected memory reported by MEM, as well as ports(x.xx) that can neither be FREEd, nor CLAIMed (guess how i know...)

To get portions of FRAM71's memory back to a known state, erase all magic numbers that may still be hiding in the F-Blocks that you are going to use:
1) configure two 32kByte modules at F_0x40000: "94950....0"
2) OFF
3) Close jumper CN2:2 "DIS_OUT_wh_CONF"
4) [ON]/[/],3 --> MEMORY LOST
5) OFF.
6) open jumper CN2:2 "DIS_OUT_wh_CONF"
7) ON
8) MEM --> 82 kByte
Then, configure the chips a desired:
1) "24A50...0" for one 32K RAM module consisting of two 16K chips, located at F_0x40000 and F_0x50000
2) OFF / ON
3) FREEPORT(5)
4)...

Hans

Dave Frederickson · (This post was last modified: 02-27-2015 06:19 PM by Dave Frederickson.)

Thanks, Hans.

Can you elaborate on Feature 3) from the Feb 12 email which states: you may assign the same FRAM space (base) to multiple chips, or should I just wait for the update to the FRAM71 manual?

If anyone writes a tutorial for FRAM71, the first two lessons should be:

RTFM. Which, contrary to what may have been learned somewhere else, stands for Read The FRAM71 Manual.
Disaster Recovery. Force conditions which require the use of CN2-2 and CN2-3 and learn how to recover from disaster. It'll be less stressful this way rather than not knowing what to do when a fat-fingered configuration string is POKE'd and the 71B locks up.

Dave

Dave Frederickson · 03-03-2015, 10:13 PM

Feature Request: In a future hardware rev, would it be possible to have 1 MiB of FRAM so that more ROM's could be bank-switched?

Hans Brueggemann · (This post was last modified: 03-04-2015 05:15 PM by Hans Brueggemann.)

(02-27-2015 04:32 PM)Dave Frederickson Wrote: Can you elaborate on Feature 3) from the Feb 12 email which states: you may assign the same FRAM space (base) to multiple chips

this is actually not a feature but a side-effect, and probably not useful at all. it is just saying that it is ok to assign different chips to the same F-Block, i.e., the same F-Block will be mirrored in multiple address spaces. if, for example chip_0 is assigned as ROM to F-Block_0, and chip_1 is assigned as RAM to F-Block_0, then you can circumvent the write protection of the ROM by writing to chip_1 instead. However, the SYSRAM area has a different write-protection to prevent that.

hans

Hans Brueggemann · (This post was last modified: 03-04-2015 05:37 PM by Hans Brueggemann.)

(03-03-2015 10:13 PM)Dave Frederickson Wrote: Feature Request: In a future hardware rev, would it be possible to have 1 MiB of FRAM so that more ROM's could be bank-switched?

upcoming FW430 will be nuking the fridge and "1MByte-Ready", but there will be no hardware spin. Instead, the inclined user may (at his own risk, that is) simply solder an identical FRAM chip on top of the existing one, paralleling all signals except /CE. /CE then gets a connection to one of the FPGA's spare I/Os, and another spare I/O will hold a jumper to manually select either "top" or "bottom" FRAM and supply your HP-71B with an "alter ego".
this hardware-hack is possible with all FRAM71s with HW103 and up.
please don't ask for more than 1MByte though, because i'm running out of I/Os ;o)

hans

Dave Frederickson · (This post was last modified: 11-04-2015 01:00 AM by Dave Frederickson.)

(03-04-2015 05:28 PM)Hans Brueggemann Wrote:
(03-03-2015 10:13 PM)Dave Frederickson Wrote: Feature Request: In a future hardware rev, would it be possible to have 1 MiB of FRAM so that more ROM's could be bank-switched?

upcoming FW430 will be nuking the fridge and "1MByte-Ready", but there will be no hardware spin. Instead, the inclined user may (at his own risk, that is) simply solder an identical FRAM chip on top of the existing one, paralleling all signals except /CE. /CE then gets a connection to one of the FPGA's spare I/Os, and another spare I/O will hold a jumper to manually select either "top" or "bottom" FRAM and supply your HP-71B with an "alter ego".
this hardware-hack is possible with all FRAM71s with HW103 and up.
please don't ask for more than 1MByte though, because i'm running out of I/Os ;o)

hans

Excellent!

I found FRAM chips at Verical for $26USD ea. plus only $4.05 shipping in the U.S.

Hans Brueggemann · (This post was last modified: 03-06-2015 06:17 PM by Hans Brueggemann.)

FRAM71_V430 firmware released. see top of this thread for updates.

my sincere thanks to all you folks on the forum and especially to Dave Frederickson for helping to improve FRAM71!

hans

Dave Frederickson · 03-14-2015, 09:18 PM

Works so far. Smile

**rprosperi** · 03-15-2015, 02:00 AM

(03-14-2015 09:18 PM)Dave Frederickson Wrote: Works so far.

Excellent news! Looking forward to it. That's more than enough memory to load all the HP released 71 ROMs . Maybe more than all the common 3rd-party ROMs too.

**Gene** · 03-15-2015, 02:04 AM

How many total roms are there?

HP made ?

Third parties made ?

Where is this info stored in an easy to read / follow manner?

**rprosperi** · 03-15-2015, 02:08 AM

(03-15-2015 02:04 AM)Gene Wrote: How many total roms are there?

HP made ?

Third parties made ?

Where is this info stored in an easy to read / follow manner?

The most complete list I recall seeing was posted here (last summer?) by Sylvain. Search the archives, should be quick to find. If not here, it was in an email, which I can dig for if you strike out searching.

Dave Frederickson · 03-15-2015, 02:19 AM

I haven't seen dumps of the 0AAAA, 1AAAA, or 2CCCC system ROM's. Or, if anyone has any 3rd party ROM dumps they'd be willing to share, here's a good place. Smile

Hans Brueggemann · (This post was last modified: 03-15-2015 01:27 PM by Hans Brueggemann.)

(03-14-2015 09:18 PM)Dave Frederickson Wrote: Works so far.

Whoa, awesome job, dave!
btw..., currently working on V500, which will allow for immediate F-BLOCK address-switching under program control without the need for power-cycling.

Example:

Code:

1) HP-71B is configured "939" & A$  (A$ may be  "4"..."F")

2)  10 A = HTD(A$) 

    20 FOR ROM = 0 to number of ROM images

    30 B = A + ROM @ B$ = DTH$(B)

    40 POKE "2C000", "939" & B$ 

    50 copy image from external device to H_adr$ = "40000"

    60 NEXT ROM

    70 END

3) adjust configuration as required

4) power-cycle

makes sense?

hans

(edited: line 50 of code)

Dave Frederickson · 03-15-2015, 02:55 PM

(03-15-2015 09:01 AM)Hans Brueggemann Wrote:
(03-14-2015 09:18 PM)Dave Frederickson Wrote: Works so far.

Whoa, awesome job, dave!
btw..., currently working on V500, which will allow for immediate F-BLOCK address-switching under program control without the need for power-cycling.

Example:

Code:

1) HP-71B is configured "939" & A$ (A$ may be "4"..."F") 2) 10 A = HTD(A$) 20 FOR ROM = 0 to number of ROM images 30 B = A + ROM @ B$ = DTH$(B) 40 POKE "2C000", "939" & B$ 50 copy image from external device to H_adr$ = "40000" 60 NEXT ROM 70 END 3) adjust configuration as required 4) power-cycle

makes sense?

hans

(edited: line 50 of code)

Thanks, Hans.

I have to say that having 1MByte of memory is a very cool feature. Move one jumper and the 71B has a completely different ROM/RAM configuration. What I'd like to know is, with 10 pre-production FRAM71's out there, am I the only one who's even updated the firmware? Perhaps we just need more units out there, which brings up the next topic: Batch Two Status

How is batch two coming?
How many units do you plan to produce for batch two?
Are you still accepting orders? How many are spoken for?
Have you considered offering the 1MByte upgrade as an option?
I suggest the programming header added to the standard configuration. I think that's why some folks haven't updated their firmware.

V500
I have no issues cycling power, so to me this sounds like a power-user feature.

How is a configuration cycle triggered? I know that FREEPORT and CLAIMPORT are one method, but they're not programmable.
If the goal is to not have to cycle power to change configurations, then what's with step 4)?

Dave

Sylvain Cote · 03-15-2015, 03:34 PM

(03-15-2015 02:08 AM)rprosperi Wrote:
(03-15-2015 02:04 AM)Gene Wrote: How many total roms are there?

HP made ?

Third parties made ?

Where is this info stored in an easy to read / follow manner?

The most complete list I recall seeing was posted here (last summer?) by Sylvain. Search the archives, should be quick to find. If not here, it was in an email, which I can dig for if you strike out searching.

Here is my list ...

Code:

Product                          ROM Image       Size   Version

-------------------------------  --------------  -----  --------------------

HP-71 Demo ROM (c) HP 1984       HP71DEMO-A.ROM  16 KB  DEMO:A

82401A  Interface Loop           HPILROM-1A.ROM  16 KB  HPIL:1A

82401A  Interface Loop           HPILROM-1B.ROM  16 KB  HPIL:1B

82479A  Data Acquisition Pac     DATAACQ-A.ROM   64 KB  INST:A TCNV:A FMT:A

82480A  Mathematics              MATHROM-1A.ROM  32 KB  MATH:1A

82481A  AC Circuit Analysis      CIRCUIT-A.ROM   16 KB  CIRC:A

82482A  Finance Pac              FINANCE-A.ROM   16 KB  FIN:A

82483A  Surveying Pac            SURVEY-A.ROM    16 KB  SURV:A

82484A  Curve Fitting Pac        CURVEFIT-A.ROM  32 KB  FIT:A

82485A  Text Editor              TEXTEDIT-A.ROM  16 KB  EDT:A

82488A  Data Communications Pac  DATACOMM-A.ROM  16 KB  DC:A

82489A  AMPI Statistics Pac      AMPISTAT-A.ROM  32 KB  AMPISTAT:A

82490A  HP-41 Translator Pac     FTH41-1A_1.ROM  16 KB  FTH41:1A EDT:A

                                 FTH41-1A_2.ROM  32 KB  From E0000 to E7FFF

82478A  Forth Assemby/Debugger   FORTH-1A_1.ROM  16 KB  FTH:1A EDT:A KBD:B

                                 FORTH-1A_2.ROM  32 KB  From E0000 to E7FFF

DATAMNGT by Jim Donnelly         DATAMNGT-B.ROM  32 KB  DATA:B

ZENWAND Zengrange BarCode Wand   ZENWAND-1A.ROM  16 KB  WAND:1A DHSS:1A

JPC-ROM Journal Paris Chapter    JPC-E1.ROM      32 KB  JPC:E1 EPRM:C ECPY:F

JPC-ROM Journal Paris Chapter    JPC-F01.ROM     32 KB  JPC:F01

AMPROM1 AMP House ROM1           AMP-ROM1.ROM    32 KB  n/a

AMPROM2 AMP House ROM2           AMP-ROM2.ROM    64 KB  R2:5.0A