FRAM71B
|
01-22-2017, 05:30 PM
(This post was last modified: 01-22-2017 05:48 PM by Dave Frederickson.)
Post: #61
|
|||
|
|||
RE: FRAM71B
(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 Regards Dave |
|||
01-22-2017, 06:55 PM
Post: #62
|
|||
|
|||
RE: FRAM71B
(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, 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 regards Erwin |
|||
01-22-2017, 07:06 PM
(This post was last modified: 01-23-2017 04:16 PM by Dave Frederickson.)
Post: #63
|
|||
|
|||
RE: FRAM71B
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-po...l#pid63381 For what reason do you need R64KCOPY or an old version of ROMCOPY? Regards Dave |
|||
01-22-2017, 07:21 PM
Post: #64
|
|||
|
|||
RE: FRAM71B
(01-22-2017 07:06 PM)Dave Frederickson Wrote: Erwin,Hi 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 |
|||
01-23-2017, 08:29 PM
Post: #65
|
|||
|
|||
RE: FRAM71B
(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. 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. |
|||
01-23-2017, 09:11 PM
Post: #66
|
|||
|
|||
RE: FRAM71B
(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. 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 |
|||
01-24-2017, 09:03 AM
(This post was last modified: 01-24-2017 09:04 AM by Hans Brueggemann.)
Post: #67
|
|||
|
|||
RE: FRAM71B
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. |
|||
01-24-2017, 04:34 PM
Post: #68
|
|||
|
|||
RE: FRAM71B
(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-po...l#pid63381 The LEDs on my modules are quite visible so I would have noticed if I had inadvertantly moved the jumper. Regards Dave |
|||
01-24-2017, 06:15 PM
Post: #69
|
|||
|
|||
RE: FRAM71B
(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. 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 |
|||
01-24-2017, 07:33 PM
(This post was last modified: 01-24-2017 07:54 PM by Hans Brueggemann.)
Post: #70
|
|||
|
|||
RE: FRAM71B
(01-24-2017 04:34 PM)Dave Frederickson Wrote: Hi Hans, 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. |
|||
01-24-2017, 07:51 PM
Post: #71
|
|||
|
|||
RE: FRAM71B
(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). |
|||
01-24-2017, 08:18 PM
Post: #72
|
|||
|
|||
RE: FRAM71B
(01-24-2017 07:33 PM)Hans Brueggemann Wrote:(01-24-2017 04:34 PM)Dave Frederickson Wrote: Hi Hans, 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 |
|||
01-25-2017, 06:54 PM
(This post was last modified: 01-25-2017 06:55 PM by Erwin.)
Post: #73
|
|||
|
|||
RE: FRAM71B
(01-24-2017 08:18 PM)Dave Frederickson Wrote: Hi Hans, 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. Code: >RUNSETUP Code: Peek$("D0000",8) shows ”B3DDDDDE” So I opend open J4-2 ON7OFF Code: >RUNMEMBUF Code: >VER$ Testing 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 |
|||
01-25-2017, 07:47 PM
Post: #74
|
|||
|
|||
RE: FRAM71B
(01-25-2017 06:54 PM)Erwin Wrote: peek$("D0000",8) shows ”B3DDDDDE” 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. |
|||
02-01-2017, 10:20 PM
Post: #75
|
|||
|
|||
RE: FRAM71B | |||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: