+- 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: FRAM71B (/thread-6287.html)
RE: FRAM71B - Dave Frederickson - 01-22-2017 05:30 PM
(01-22-2017 10:18 AM)Erwin Wrote: You can try this with POKE "2C012"; "109100" and then try to FREE it.Hi Erwin,
This is interesting. The problem appears to be with F-Block 0 as it can't be FREEPORT'ed either and I suspect this affects all subsequent Chips.
I think you found a bug, or at least a caveat. This could be why it is advised to use F-Blocks 0 and 1 last.
(01-22-2017 02:02 PM)Erwin Wrote:(11-01-2016 09:26 AM)Erwin Wrote: I found the basic program R64KCOPY (chu06) but it is to get the checksum from existing ROMs in a port ...maybe some could use it too - regards Erwin
I'm not sure if this program is useful anymore. Per a note by Joe Horn on my copy of the ROMCOPY doc, "Checksums are fully automatic in Rev. E".
Note that this program is for computing IRAM checksums in preparation for creating a ROM image. ROM chips all have checksums of "01".
Code:
>titanchk datacq.bin
TITAN ROM Test V1.10
Unpacking data...
ROM Chip 1 = 01 -> Ok
ROM Chip 2 = 01 -> Ok
ROM Chip 3 = 01 -> Ok
ROM Chip 4 = 01 -> Ok
Checksum(s) ok!Regards Dave
RE: FRAM71B - Erwin - 01-22-2017 06:55 PM
(01-22-2017 05:30 PM)Dave Frederickson Wrote:(01-22-2017 10:18 AM)Erwin Wrote: You can try this with POKE "2C012"; "109100" and then try to FREE it.Hi Erwin,
This is interesting. The problem appears to be with F-Block 0 as it can't be FREEPORT'ed either and I suspect this affects all subsequent Chips.
I think you found a bug, or at least a caveat. This could be why it is advised to use F-Blocks 0 and 1 last.
(01-22-2017 02:02 PM)Erwin Wrote: maybe some could use it too - regards Erwin
I'm not sure if this program is useful anymore. Per a note by Joe Horn on my copy of the ROMCOPY doc, "Checksums are fully automatic in Rev. E".
Note that this program is for computing IRAM checksums in preparation for creating a ROM image. ROM chips all have checksums of "01".
Code:
>titanchk datacq.bin
TITAN ROM Test V1.10
Unpacking data...
ROM Chip 1 = 01 -> Ok
ROM Chip 2 = 01 -> Ok
ROM Chip 3 = 01 -> Ok
ROM Chip 4 = 01 -> Ok
Checksum(s) ok!
Regards Dave
Hi Dave,
do you tried out similar configurations with the FRAMB? About the R64KCOPY I think we talk about different programs? The result with the program I did with the DATA-ACQ ROM module in SLOT 1 - my workaround for the FRAMB configuration :-)
Code:
LEX3421 78008
BIN3421 7BAED 7542.5
TCONV 7BDE6 7923.0
FMTLEX 7BFF1 8184.5
KEYSLEEP 7C4BF 8799.5
MERGEBUF 7C55F 8879.5
UTILITY 7C9CE 9447.0
STATUS 7E676 13115.0
FRONT 801E9 16628.5
CK1 816B3 19289.5
STRIP 816E8 19316.0
MONITOR 859D4 27882.0
CK2 8B72E 39831.0
SETUP 8B763 39857.5
LOG 90325 49554.5
REPORT 93676 56123.0
TRANSFER 9637D 61886.5
VERIFY 97608 64260.0
csum 1: 30 LEX3421
csum 2: 33279 FRONT
csum 3: 79684 CK2
csum 4: 128542 VERIFYregards
Erwin
RE: FRAM71B - Dave Frederickson - 01-22-2017 07:06 PM
Erwin,
You may have discovered a bug, but I've already demonstrated your configuration with the Data Acq ROM installed using ROMCOPY Rev E.
http://hpmuseum.org/forum/thread-6287-post-63381.html#pid63381
For what reason do you need R64KCOPY or an old version of ROMCOPY?
Regards Dave
RE: FRAM71B - Erwin - 01-22-2017 07:21 PM
(01-22-2017 07:06 PM)Dave Frederickson Wrote: Erwin,Hi Dave,
You may have discovered a bug, but I've already demonstrated your configuration with the Data Acq ROM installed using ROMCOPY Rev E.
http://hpmuseum.org/forum/thread-6287-post-63381.html#pid63381
What what reason do you need R64KCOPY or and old version of ROMCOPY?
Regards Dave
the history is, that I had the old version and the old documentation for it. In the new ROMCOPY it is not necessary to know the checksums. But I want to know how to deal with the unknown XFN and correct the wrong program code. Joe's directory is in many ways very helpful, like the other tools here. The PILBox, pyILPER, FRAM71B, Compendium, ROMs, ... my calculator gets a 'new life' :-) and more useful, looks like for many people too.
Usually I did only small BASIC programs or calculations on my calculator. I use the CFIT prog but also the MMAXPOLY for curve fitting. With the new possibilities I want to make a little project with my HP3421A (only have to change die small battery for the config data). But the verification and calibration program is growing slowly at the moment.
best regards
Erwin
RE: FRAM71B - Hans Brueggemann - 01-23-2017 08:29 PM
(01-22-2017 05:30 PM)Dave Frederickson Wrote: This is interesting. The problem appears to be with F-Block 0 as it can't be FREEPORT'ed either and I suspect this affects all subsequent Chips.
I think you found a bug, or at least a caveat. This could be why it is advised to use F-Blocks 0 and 1 last.
remember that F_Blocks 0 and 1 (aka SYSRAM area) are hardware write-protected. CLAIMPORT and FREEPORT (!) require write access to function properly, so you need to set jumper CN2-4 before writing to that memory area.
RE: FRAM71B - Dave Frederickson - 01-23-2017 09:11 PM
(01-23-2017 08:29 PM)Hans Brueggemann Wrote:(01-22-2017 05:30 PM)Dave Frederickson Wrote: This is interesting. The problem appears to be with F-Block 0 as it can't be FREEPORT'ed either and I suspect this affects all subsequent Chips.
I think you found a bug, or at least a caveat. This could be why it is advised to use F-Blocks 0 and 1 last.
remember that F_Blocks 0 and 1 (aka SYSRAM area) are hardware write-protected. CLAIMPORT and FREEPORT (!) require write access to function properly, so you need to set jumper CN2-4 before writing to that memory area.
Doh! Can you clarify the function of J1: ENA_SYSRAM? The manual states that if it is set then the output of the SYSRAM area (F_0x00000 – F_0x1FFFF) is enabled, but that doesn't seem necessary if F-Blocks 0 and 1 are used for ROM or RAM. It appears that J1 affects addressing.
Dave
RE: FRAM71B - Hans Brueggemann - 01-24-2017 09:03 AM
As to the function of J1:ENA_SYSRAM:
All F_Blocks 0..15 are be accessed through FRAM71's internal MMU. you tell the MMU "what goes where" by setting the respective config nibbles in the config area.
F_Blocks 0,1 therefore work identically to all other F_Blocks. however, they also respond to a direct SYSRAM-area (H_0x00000 .. H_0x1FFFF) access, if J1 is set. if J1 is not set, they only respond to access via MMU.
RE: FRAM71B - Dave Frederickson - 01-24-2017 04:34 PM
(01-23-2017 08:29 PM)Hans Brueggemann Wrote: remember that F_Blocks 0 and 1 (aka SYSRAM area) are hardware write-protected. CLAIMPORT and FREEPORT (!) require write access to function properly, so you need to set jumper CN2-4 before writing to that memory area.
Hi Hans,
How was I able to FREEPORT the device and load the 64k Data Acq Module into F-Blocks 0 & 1 without enabling SYSRAM Write (CN2-4)? Consider that I use ROMCOPY to load a ROM image into an IRAM and that I only use CN2-4 when POKEing an alternate O/S or the Diag ROM into SYSRAM.
http://hpmuseum.org/forum/thread-6287-post-63381.html#pid63381
The LEDs on my modules are quite visible so I would have noticed if I had inadvertantly moved the jumper.
Regards Dave
RE: FRAM71B - Erwin - 01-24-2017 06:15 PM
(01-23-2017 08:29 PM)Hans Brueggemann Wrote:(01-22-2017 05:30 PM)Dave Frederickson Wrote: This is interesting. The problem appears to be with F-Block 0 as it can't be FREEPORT'ed either and I suspect this affects all subsequent Chips.
I think you found a bug, or at least a caveat. This could be why it is advised to use F-Blocks 0 and 1 last.
remember that F_Blocks 0 and 1 (aka SYSRAM area) are hardware write-protected. CLAIMPORT and FREEPORT (!) require write access to function properly, so you need to set jumper CN2-4 before writing to that memory area.
Hi Hans,
thank you for the explanation - I see and its in the handbook of yours too, page 10. I did it in this way and its running. The DATA-ACQ ROM is in this area while setting the J2-4. Then I reinstalled it (OFF position) and made some bank switching I got a memory lost. Is it necessary to keep the J2-4 in the ON position cause the LED is shining also in the POWER OFF state of the calculator.
I'll try a fresh installation in the next days, cause i did too much experiments and so I'm not sure if it is about some of them. It give me the possibility to check my 'configuration book'.
In the meantime I made a rough update of my document (not final!) but better than nothing :-) Configuration examples FRMA71B
regards
Erwin
RE: FRAM71B - Hans Brueggemann - 01-24-2017 07:33 PM
(01-24-2017 04:34 PM)Dave Frederickson Wrote: Hi Hans,
How was I able to FREEPORT the device and load the 64k Data Acq Module into F-Blocks 0 & 1 without enabling SYSRAM Write (CN2-4)? Consider that I use ROMCOPY to load a ROM image into an IRAM and that I only use CN2-4 when POKEing an alternate O/S or the Diag ROM into SYSRAM.
http://hpmuseum.org/forum/thread-6287-post-63381.html#pid63381
The LEDs on my modules are quite visible so I would have noticed if I had inadvertantly moved the jumper.
Regards Dave
i have no clue. when doing
POKE"2C000","909100"
OFF/ON
POKE"30000","CAFE"
PEEK$("30000",4),
the result is indeed "0000", as expected when CN2-4 is not set.
then,
set CN2-4
POKE"30000","CAFE"
clear CN2-4
PEEK$("30000",4),
gives "CAFE", again, as expected.
also, a FREEPORT(5) exits silently, but doesn't overwrite any contents in F_0x00000 and also doesn't reduce MEM. so, on my FRAM71B, CN2-4 seems to work as advertised.
i'm running HW105_V607 (like all FRAM71Bs out there). can you do a quick check with above code on your module? just switch over to TOP FRAM in order not to spoil your BOT configuration.
RE: FRAM71B - Hans Brueggemann - 01-24-2017 07:51 PM
(01-24-2017 06:15 PM)Erwin Wrote: Is it necessary to keep the J2-4 in the ON position cause the LED is shining also in the POWER OFF state of the calculator.
if you are going to use SYSRAM area as ROM, then you have CN2-4 set while you are "filling" that area with images. once the images are loaded there, jumper CN2-4 can (and should) be removed to conserve battery power. leaving CN2-4 on all the time will increase "OFF"-current to 0.5 mA and "eat" a fresh set of batteries in about 4000 hrs (or about 1500 hrs when using Panasonic eneloops).
RE: FRAM71B - Dave Frederickson - 01-24-2017 08:18 PM
(01-24-2017 07:33 PM)Hans Brueggemann Wrote:(01-24-2017 04:34 PM)Dave Frederickson Wrote: Hi Hans,
How was I able to FREEPORT the device and load the 64k Data Acq Module into F-Blocks 0 & 1 without enabling SYSRAM Write (CN2-4)? Consider that I use ROMCOPY to load a ROM image into an IRAM and that I only use CN2-4 when POKEing an alternate O/S or the Diag ROM into SYSRAM.
http://hpmuseum.org/forum/thread-6287-post-63381.html#pid63381
The LEDs on my modules are quite visible so I would have noticed if I had inadvertantly moved the jumper.
Regards Dave
i have no clue. when doing
POKE"2C000","909100"
OFF/ON
POKE"30000","CAFE"
PEEK$("2C000",4),
the result is indeed "0000", as expected when CN2-4 is not set.
then,
set CN2-4
POKE"30000","CAFE"
clear CN2-4
PEEK$("2C000",4),
gives "CAFE", again, as expected.
also, a FREEPORT(5) exits silently, but doesn't overwrite any contents in F_0x00000 and also doesn't reduce MEM. so, on my FRAM71B, CN2-4 seems to work as advertized.
i'm running HW105_V607 (like all FRAM71Bs out there). can you do a quick check with above code on your module? just switch over to TOP FRAM in order not to spoil your BOT configuration.
Hi Hans,
POKE"2C000","109100" > Okay. A little different because I want a 64k IRAM.
ON/OFF > Okay. Reports around 83k RAM.
POKE"30000","CAFE" > Okay.
PEEK$("30000",4) > Gives "8D72", not "CAFE". Expected behavior.
SET CN2-4
POKE"30000","CAFE" > Okay.
PEEK$("30000",4) > Gives "CAFE".
FREEPORT(5) works as expected.
Remove CN2-4 and PORT(5) is write-protected as expected.
Now here's the embarrassing part, did I really copy the Data Acq ROM to the IRAM? That configuration is lost and now I'm not so sure.
In any case, thanks, Hans, for the reminder about write protection on Banks 0 and 1.
Regards, Dave
RE: FRAM71B - Erwin - 01-25-2017 06:54 PM
(01-24-2017 08:18 PM)Dave Frederickson Wrote: Hi Hans,
POKE"2C000","109100" > Okay. A little different because I want a 64k IRAM.
ON/OFF > Okay. Reports around 83k RAM.
POKE"30000","CAFE" > Okay.
PEEK$("30000",4) > Gives "8D72", not "CAFE". Expected behavior.
SET CN2-4
POKE"30000","CAFE" > Okay.
PEEK$("30000",4) > Gives "CAFE".
FREEPORT(5) works as expected.
Remove CN2-4 and PORT(5) is write-protected as expected.
Now here's the embarrassing part, did I really copy the Data Acq ROM to the IRAM? That configuration is lost and now I'm not so sure.
In any case, thanks, Hans, for the reminder about write protection on Banks 0 and 1.
Regards, Dave
Hi both,
I tried this memory block too. Set the J4-2 and
Code:
POKE"2C000","109100" > for 64k IRAM and then DATA-ACQ ROM.
ROMCOPY DATACQ:TAPE TO :PORT(5);ROMSIZE=65536 [ENTER]
>SHOWPORT
0.05 16384 2
5 65536 1
0 4096 0
0.01 4096 0
0.02 4096 0
0.03 4096 0
>
>RUNMEMBUF
Port Dev Seq Size Addr Type
0 0 0 4 30000 0
0 1 0 4 32000 0
0 2 0 4 34000 0
0 3 0 4 36000 0
0 5 0 16 F0000 2
5 0 0 64 D0000 1Code:
>RUNSETUP
Reading the HP3421...
Edit File Verify Quit?F
Get New Save Main?M
Edit File Verify Quit?Q
DoneCode:
Peek$("D0000",8) shows ”B3DDDDDE”
Then: POKE"D0000","0000000" > remove IRAM ends with 'illegal access' cause of HW protecting possibility?
POKE"2C000","50D100" > for 64k IRAM to ROM.
Peek$("2C000",8) shows ”50D10000” but type is still on '1' cause of the error before and maybe cause of the hard configured write protectionSo I opend open J4-2 ON7OFF
Code:
>RUNMEMBUF
Port Dev Seq Size Addr Type
0 0 0 4 30000 0
0 1 0 4 32000 0
0 2 0 4 34000 0
0 3 0 4 36000 0
0 5 0 16 F0000 2
5 0 0 64 D0000 2Code:
>VER$
HP71:2CDCC RCPY:E HPIL:1B INST:A TCNV:A FMT:ATesting DATA-ACQ-ROM is OK again. So it seems this is a possible way to use this space and it is still there. Testing 'memory lost' - program is running so it's all OK.
best regards
Erwin
RE: FRAM71B - Hans Brueggemann - 01-25-2017 07:47 PM
(01-25-2017 06:54 PM)Erwin Wrote: peek$("D0000",8) shows ”B3DDDDDE”
Then: POKE"D0000","0000000" > remove IRAM ends with 'illegal access' cause of HW protecting possibility?
no. FRAM71B doesn't report back to HP-71B as to whether there was an illegal access happening. it simply accepts the command, but doesn't execute on it. so, whenever you get such a message, it's the HP-71B's internal sanity check that reports an illegal access.
RE: FRAM71B - dayd - 02-01-2017 10:20 PM
Taking the MEMBUF idea a bit further I made a little program to help configure
the FRAM71.
HERE