FRAM71B
11-01-2016, 01:42 PM
Post: #41
 rprosperi Senior Member Posts: 3,424 Joined: Dec 2013
RE: FRAM71B
(11-01-2016 10:48 AM)Erwin Wrote:  When I initialize the PORT 5.05 with 64KB (POKE "2C012"; "109100") ... my last module it is not configured as IRAM when i do the FREE PORT without an error. The SHOWPORT shows type "0" instead of "1", and I couldn't ROMCOPY (error: Device Not Found) So I configured it as ROM (POKE "2C012"; "50D100") and tried the ROMCOPY but with the "verify" error.

I think the issue could be where your 64KB block is located. Although you declare that 64KB FRAM F_Block near the end of your config string, the '71 initialize routine (in the OS) allocates larger memory blocks in lower addresses, regardless of which port they are physically (or in the case of FRAM logically) located.

Most likely, the init routine configured your RAM blocks in this order:

1. Main RAM (5.00)
2. 64KB Block (to hold the image, after converting to IRAM) (5.01)
3. Other 32KB blocks for holding other images. (5.02, 5.03, etc.)

The easiest way to check this is with the MEMBUF program and SHOW PORT commands. In fact for each new config you create, I suggest you run these 2 commands to see the actual memory map; it is not always what you expect it to be.

Run MEMBUF immediately after your initial start with the new config, then after you FREE the various PORTs, and it should be easy to track what is happening.

Also, re-read the article here for a detailed explanation of the memory configuration process.

--Bob Prosperi
11-01-2016, 02:14 PM
Post: #42
 Erwin Member Posts: 120 Joined: May 2015
RE: FRAM71B
(11-01-2016 01:42 PM)rprosperi Wrote:
(11-01-2016 10:48 AM)Erwin Wrote:  When I initialize the PORT 5.05 with 64KB (POKE "2C012"; "109100") ... my last module it is not configured as IRAM when i do the FREE PORT without an error. The SHOWPORT shows type "0" instead of "1", and I couldn't ROMCOPY (error: Device Not Found) So I configured it as ROM (POKE "2C012"; "50D100") and tried the ROMCOPY but with the "verify" error.

I think the issue could be where your 64KB block is located. Although you declare that 64KB FRAM F_Block near the end of your config string, the '71 initialize routine (in the OS) allocates larger memory blocks in lower addresses, regardless of which port they are physically (or in the case of FRAM logically) located.

Most likely, the init routine configured your RAM blocks in this order:

1. Main RAM (5.00)
2. 64KB Block (to hold the image, after converting to IRAM) (5.01)
3. Other 32KB blocks for holding other images. (5.02, 5.03, etc.)

The easiest way to check this is with the MEMBUF program and SHOW PORT commands. In fact for each new config you create, I suggest you run these 2 commands to see the actual memory map; it is not always what you expect it to be.

Run MEMBUF immediately after your initial start with the new config, then after you FREE the various PORTs, and it should be easy to track what is happening.

Also, re-read the article here for a detailed explanation of the memory configuration process.

Hi,

thank you, I see it in the end of the article so I have to take care to put the larger ROMs first. I understand that the smaller ROMs at the end are not a problem for the system, the 64KB is to big. I'll give this a try next weekend and change the whole configuration and give here feedback about this ...

Thanks Erwin
11-01-2016, 03:39 PM (This post was last modified: 11-02-2016 03:21 PM by Dave Frederickson.)
Post: #43
 Dave Frederickson Senior Member Posts: 1,650 Joined: Dec 2013
RE: FRAM71B
(11-01-2016 10:48 AM)Erwin Wrote:  When I initialize the PORT 5.05 with 64KB (POKE "2C012"; "109100") ... my last module it is not configured as IRAM when i do the FREE PORT without an error. The SHOWPORT shows type "0" instead of "1", and I couldn't ROMCOPY (error: Device Not Found) So I configured it as ROM (POKE "2C012"; "50D100") and tried the ROMCOPY but with the "verify" error.

This was described in 3. in this post:
http://hpmuseum.org/forum/thread-6287-po...l#pid62269

Understand that ROM's and IRAM's get configured after RAM. When you FREEPORT a module it moves within the address space from RAM to a higher address with the other ROM's and IRAM's. In some max RAM configurations this will cause a configuration warning just like configuring more RAM than can be addressed.

Configuring the module as ROM will, by definition, prevent it from being written.

(11-01-2016 02:14 PM)Erwin Wrote:  ... I see it in the end of the article so I have to take care to put the larger ROMs first.

That's not necessary. The 71's configuration routine takes care of that.

That said, I had no issues configuring FRAM71B as above.
Code:
>PEEK$("2C000",32) D3E4D5D69718191A9B50D10000000000 >RUN MEMBUF Port Dev Seq Size Addr Type 0 0 0 4 70000 0 BUILT-IN RAM 0 1 0 4 72000 0 BUILT-IN RAM 0 2 0 4 74000 0 BUILT-IN RAM 0 3 0 4 76000 0 BUILT-IN RAM 5 4 0 128 30000 0 MAIN RAM 0 5 0 16 80000 2 HPILROM 5 0 0 16 88000 2 FTH41 ROM 5 1 0 32 D0000 2 MATHROM 5 2 0 32 C0000 2 JPC ROM 5 3 0 32 B0000 1 FRAM71 TK 5 5 0 64 90000 2 DATACQ ROM > Dave 11-22-2016, 10:53 PM (This post was last modified: 11-22-2016 11:07 PM by physill.) Post: #44  physill Junior Member Posts: 4 Joined: Oct 2015 RE: FRAM71B I hope this is the right place to post this question. If not let me know. Thanks. I am unable to get around an Invalid Arg error in line 120 of SERTOSYS as shown on page 23 of the FRAM71B manual. I am using a PilBox (with the PIL-Box Bridge, ILPer and Video Interface) to attempt to load the file HP-71B_OS2CDCC_ROM.BIN to the FRAM71B to allow use of the 2cdcc operating system. Communication between the HP-71B hardware and the virtual components is working. 10 ! SERTOSYS SERIAL TO SYS 20 DIM A$[64]
30 INPUT "SYSWRT ENABLED? Y/N";V$@ IF V$="N" THEN GOTO 20
40 DISP "START *.DMP UPLOAD"
50 S$="00000" 60 E$="1FFFF"
70 S=HTD(S$) 80 E=HTD(E$)
90 FOR I=S TO E STEP 64
100 ENTER :2 ;A$@ IF I=S+64 THEN DISP "WRITING..." !:2 = 82164A Note that I am using ENTER :4 for the HDRIVE1.DAT file on ILPER 110 I$=DTH$(I) 120 POKE I$,A$130 ! PRINT I$;": ";A$140 NEXT I 150 DISP "DONE" @ BEEP 160 END HP-71B_OS2CDCC_ROM.BIN is a file from one of the many pages I have obtained HP71 info from, perhaps a post on MoHPC. It was part of a link or ZIP file that contains the .BIN files for most if not all of the ROMs for the HP71b. SERTOSYS uses variables I$ and A$to contain a counter and the data read from the 2CDCC hex dump file, respectively. The values that are put into the variables I$ and A$on the first pass through the loop appear to be valid. Using the program HexEdit to view the contents of HP-71B_OS2CDCC_ROM.BIN and comparing to the value placed into variable A$ appears to show that the correct data is in the variable.

Line 120 POKE I$, A$: The HP-71b reference manual (error 11) implies that the correct data type is being used but lies outside the domain of definition of that function (POKE) The HP-IL manual (error 255056) implies that the error message is due to either the argument being out of the allowable range or the argument has a Directory Entry or Length that is improper. I am not really sure what is going on.

I do not have much experience with file operations on the HP71b and have never actually used any HP-IL peripheral hardware which may have educated me on how files are actually manipulated on the hardware.

I would appreciate any help that can be offered. I have not had any issues with the SERTORAM program on page 17 of the FRAM71b manual. Using that program educated me on how the ENTER statement works and I have been able with trial and error get various ROM images loaded onto the FRAM71b.

Thank you for the info on bank switching and other involved topics that I have yet to get to. I find this forum to be most helpful.

Mark W Smith
11-23-2016, 12:34 AM
Post: #45
 Dave Frederickson Senior Member Posts: 1,650 Joined: Dec 2013
RE: FRAM71B
(11-22-2016 10:53 PM)physill Wrote:  I am unable to get around an Invalid Arg error in line 120 of SERTOSYS as shown on page 23 of the FRAM71B manual. I am using a PilBox (with the PIL-Box Bridge, ILPer and Video Interface) to attempt to load the file HP-71B_OS2CDCC_ROM.BIN to the FRAM71B to allow use of the 2cdcc operating system. Communication between the HP-71B hardware and the virtual components is working.

Hi Mark,

The issue here is that SER2SYS was written for use with the RS-232 interface and the hex dump needs to be in ASCII not binary. HP-71B_OS2CDCC_ROM.BIN, which came from Sylvain's HP-71B Compendium, is intended for use with the Emu71 emulators.

With help from Paul Berger and Bob Prosperi, the utilities in the FRAM71B manual were modified to work with the PIL-Box and hex dumps in the format described in the Emu71/Win manual. Those utilities along with Paul's excellent MEMBUF, can be found in the FRAM71 Tool Kit: http://www.hpmuseum.org/forum/thread-4844.html

The 71B Compendium, http://www.hpmuseum.org/forum/thread-5286.html, has the hex dump in the format to be used with the PIL-Box and Sylvain's loader or the Tool Kit utilities.
Code:
-> HP-71B_SYSTEM_ROM.LIF          ILPER: LIF Mass Storage File / FRAM71    -> OS2CDCC    ASCII  135K      71B OS Version 2CDCC Memory Dump    -> OS2CDCCL   BASIC   159      71B OS Version 2CDCC Memory Dump Loader

HTH, Dave
11-24-2016, 05:55 PM
Post: #46
 physill Junior Member Posts: 4 Joined: Oct 2015
RE: FRAM71B
Thank you Dave. Your advice was most helpful. Unfortunately, the FRAM71B is acting up since I had it in sysram writing mode when I was trying to configure memory blocks. Was in a hurry and did something dumb.

Mark W Smith
11-24-2016, 06:17 PM
Post: #47
 Dave Frederickson Senior Member Posts: 1,650 Joined: Dec 2013
RE: FRAM71B
(11-24-2016 05:55 PM)physill Wrote:  Was in a hurry and did something dumb.

Welcome to the FRAM71 Club!
12-30-2016, 12:26 PM (This post was last modified: 03-08-2017 06:45 PM by Erwin.)
Post: #48
 Erwin Member Posts: 120 Joined: May 2015
RE: FRAM71B
Hi,

now in the holidays I had time enough to play with the FRAM71B. I made a documentation about my configurations and put it on the DROPBOX for download. I want to give a little back for the great work of the community, especially – Sylvain Cote, Dave Frederickson, Bob Prosperi, Hans Brueggemann, Christoph Giesselink.

One thing I had not solved yet was the implantation of a 64KB ROM - but comes time, comes solution :-)

The document is my personal one to check each single step, maybe its helpful for others. I took care of the writing, but maybe there are some faults in the transcription - feedback is welcome.

Link: FRAM71B_Configuration_Docu

EDIT 2017-01-06
• first correction of typos
• unsolved 64KB DATACQ - workaround with physical ROM

EDIT 2017-03-08
• solved 64KB DATACQ installation, correct DOKU
best regards
Erwin
12-30-2016, 02:49 PM
Post: #49
 rprosperi Senior Member Posts: 3,424 Joined: Dec 2013
RE: FRAM71B
(12-30-2016 12:26 PM)Erwin Wrote:  Hi,

now in the holidays I had time enough to play with the FRAM71B. I made a documentation about my configurations and put it on the DROPBOX for download. I want to give a little back for the great work of the community, especially – Sylvain Cote, Dave Frederickson, Bob Prosperi, Hans Brueggemann, Christoph Giesselink.

One thing I had not solved yet was the implantation of a 64KB ROM - but comes time, comes solution :-)

The document is my personal one to check each single step, maybe its helpful for others. I took care of the writing, but maybe there are some faults in the transcription - feedback is welcome.

Link: FRAM71B_Configuration_Docu

best regards
Erwin

Quite an impressive document Erwin!

It will take some time to review in detail, but from a quick glance it appears to be very thorough. Your use of SHOWPORT and MEMBUF at each step makes it very clear to see what is happening, and will be very helpful for folks learning to use more advanced features of FRAM71.

Thanks for creating and sharing this beautiful and useful document!

Happy New Year!

--Bob Prosperi
12-30-2016, 06:57 PM
Post: #50
 Dave Frederickson Senior Member Posts: 1,650 Joined: Dec 2013
RE: FRAM71B
Very nice, Erwin.

I do see a slight mistake, however. What you describe in paragraphs 5.9 and 6.9 is "conventional" bank switching, not on-the-fly. On-the-fly bank switching:
• Is intended for backup purposes (not switching ROM's)
• By definition, does not require a power cycle
• Is invoked when only a Chip's address nibble is changed
• Requires the use of PEEK$/POKE commands as the file chain is broken See Han's example: http://www.hpmuseum.org/forum/thread-251...l#pid30686 Technical Description: http://www.hpmuseum.org/forum/thread-251...l#pid30720 You should have no issues loading a 64k ROM image but you might need to add the ;ROMSIZE=65536 option to ROMCOPY. Dave 12-30-2016, 07:55 PM Post: #51  Sylvain Cote Senior Member Posts: 1,038 Joined: Dec 2013 RE: FRAM71B Hello Erwin, I fully agree with Robert, impressive document! Thank you for sharing it. Sylvain 01-05-2017, 07:57 PM Post: #52  Erwin Member Posts: 120 Joined: May 2015 RE: FRAM71B (12-30-2016 06:57 PM)Dave Frederickson Wrote: Very nice, Erwin. I do see a slight mistake, however. What you describe in paragraphs 5.9 and 6.9 is "conventional" bank switching, not on-the-fly. You should have no issues loading a 64k ROM image but you might need to add the ;ROMSIZE=65536 option to ROMCOPY. Dave Hi Dave, you are right - it's not on the fly - I will correct this terms in the document. I tried the ROMSIZE option (described in the fact sheet to the ROMSIZE-LEX) in the past but it was not working of me - I have to do some more tests on this. Erwin 01-17-2017, 09:07 AM (This post was last modified: 01-17-2017 09:15 AM by dayd.) Post: #53  dayd Junior Member Posts: 40 Joined: Mar 2016 RE: FRAM71B I got it! My FRAM71B arrived and I played with it a bit I have no ROM modules so what an upgrade! Here’s my initial setup: Code: HP71:1BBBB FTH41:1A EDT:A MATH:1A JPC:F04 HPIL:1B KBD:C SHWP:A ALARM:B Beep:A ULIB:c RCPY:E FRAM71B 512k configuration string: D3E4D5D69798991A1B9C9D0000000000 RAM : 148k (144045 + files 7321 = 151366) IRAM : 96k Lex files, Backups + ROMs F-ROM : 112k T41, Math, JPC H-ROM : 80k (OS + HPIL) OS RAM : 32k (CR/FRAM + Devices + ... at 20000) total : 468k 512 KB space = 468 KB + 12k main ram not filled at 7A000 + 32k at F0000 Mapped FRAM blocks: 11 Module HP 4k : 1 Port Dev Seq Size Addr Type Comment 64 00000 OS 32 20000 CR Port, FRAM config & others 5 6 0 96 30000 0 Main RAM fram 5 7 0 32 60000 0 Main RAM fram 0 0 0 4 70000 0 Main RAM internal 0 1 0 4 72000 0 Main RAM internal 0 2 0 4 74000 0 Main RAM internal 0 3 0 4 76000 0 Main RAM internal 1 0 0 4 78000 0 Main RAM module 0 5 0 16 80000 2 HPIL ROM 5 0 0 16 88000 2 SC T41 ROM 5 5 0 32 90000 1 IRAM testing 5 4 0 32 A0000 1 IRAM testing 5 3 0 32 B0000 1 IRAM Backup & Lex 5 2 0 32 C0000 2 JPC ROM 5 1 0 32 D0000 2 Math ROM 32 E0000 HC T41 ROM F0000 00000000000000000000000000000000 Code: Chip_# Addr. Configuration Description of LCIM Type Size Port ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_0 2C000 CONF D Chip_0 2C001 F-BLOCK 3 HC E0000 T41 ROM 1 ROM 32 n/a ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_1 2C002 CONF E Chip_1 2C003 F-BLOCK 4 16KB SC T41 ROM 1 ROM 16 5.00 ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_2 2C004 CONF D Chip_2 2C005 F-BLOCK 5 32KB Math ROM 1 ROM 32 5.01 ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_3 2C006 CONF D Chip_3 2C007 F-BLOCK 6 32KB JPC ROM 1 ROM 32 5.02 ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_4 2C008 CONF 9 Chip_4 2C009 F-BLOCK 7 32KB IRAM Backup & Lex 1 IRAM 32 5.03 ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_5 2C00A CONF 9 Chip_5 2C00B F-BLOCK 8 32KB Testing IRAM for rom 1 IRAM 32 5.04 ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_6 2C00C CONF 9 Chip_6 2C00D F-BLOCK 9 32KB Testing IRAM for rom 1 IRAM 32 5.05 ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_7 2C00E CONF 1 Chip_7 2C00F F-BLOCK A Main RAM 96KB 1 of 3 0 RAM 32 5.06 ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_8 2C010 CONF 1 Chip_8 2C011 F-BLOCK B Main RAM 2 of 3 0 RAM 32 5.06 ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_9 2C012 CONF 9 Chip_9 2C013 F-BLOCK C Main RAM 3 of 3 1 RAM 32 5.06 ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_A 2C014 CONF 9 Chip_A 2C015 F-BLOCK D Main RAM 32KB 1 RAM 32 5.07 ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_B 2C016 CONF 0 Chip_B 2C017 F-BLOCK 0 (future swappable rom) ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_C 2C018 CONF 0 Chip_C 2C019 F-BLOCK 0 (future swappable rom) ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_D 2C01A CONF 0 Chip_D 2C01B F-BLOCK 0 (future swappable rom or os) ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_E 2C01C CONF 0 Chip_E 2C01D F-BLOCK 0 (future swappable rom or os) ------ ----- ------------- -------------------------- ---- ----- ---- ---- Chip_F 2C01E CONF 0 Chip_F 2C01F F-BLOCK 0 1 F-block left for FRAM and OS config (at F_20000) ------ ----- ------------- -------------------------- ---- ----- ---- ---- I divided the main RAM, to be able to move things around more easily, without losing the content. Backup is not intended to be switched but just to protect some files (memory lost or corruption). What is the F0000 to FFFFF space reserved for? I did same testing with the samples configurations provided by Hans’ manual and when I add one more F block I get a warning. It’s not that I want to, but I’m curious, here some others question that I have: In Erwin’s pdf, sometimes, like in the beginning, IRAM identifiers are not erased by a poke, is there a reason? And my big question; what is the work around to free the ports programmatically? Thank you all for your involvement in the forum, it has been very helpful, André 01-17-2017, 03:01 PM Post: #54  rprosperi Senior Member Posts: 3,424 Joined: Dec 2013 RE: FRAM71B (01-17-2017 09:07 AM)dayd Wrote: What is the F0000 to FFFFF space reserved for? FFC00-FFFFF is reserved for OS configuration. According to the Forth (and F41 I think) Manual, when any HC ROM is present at E0000 (Forth or F41) the F0000-FFC00 block is reserved for a Debugger, which was never released. Similar comments can also be found in the IDS listings, but when IDS was released it appears the debugger was not ready (and then later abandoned) so there are no details. Note that this is NOT the same Debugger that was released later as a set of LEX files that could be loaded into normal RAM. --Bob Prosperi 01-17-2017, 05:07 PM (This post was last modified: 01-17-2017 05:10 PM by J-F Garnier.) Post: #55  J-F Garnier Senior Member Posts: 304 Joined: Dec 2013 RE: FRAM71B (01-17-2017 09:07 AM)dayd Wrote: And my big question; what is the work around to free the ports programmatically? (Warning: advanced information :-) The JPC ROM has provision for executing non-programmable functions, with the EXECUTE command. There is an additional difficulty: after executing CLAIM/FREE ports (that causes system reconfiguration), the current program is ended and the current program file is set to 'workfile'. But is is easy to manage it by adding a RUN command after the CLAIM/FREE to continue the program. For instance, create the TEST program file: 10 ! TEST 20 DISP "Doing EXECUTE..." 30 EXECUTE "FREE PORT(5) @ RUN TEST,40" 40 DISP "Done." J-F 01-17-2017, 09:11 PM Post: #56  Hans Brueggemann Member Posts: 147 Joined: Dec 2013 RE: FRAM71B (01-17-2017 03:01 PM)rprosperi Wrote: Note that this is NOT the same Debugger that was released later as a set of LEX files that could be loaded into normal RAM. ah, thanks! one more mystery solved! 01-22-2017, 04:22 AM Post: #57  dayd Junior Member Posts: 40 Joined: Mar 2016 RE: FRAM71B (01-17-2017 03:01 PM)rprosperi Wrote: According to the Forth (and F41 I think) Manual, when any HC ROM is present at E0000 (Forth or F41) the F0000-FFC00 block is reserved for a Debugger, which was never released. Similar comments can also be found in the IDS listings, but when IDS was released it appears the debugger was not ready (and then later abandoned) so there are no details. Thanks Bob, it’s very nice to have some background history, also. That’s probably because the 71b didn’t sell as the 41. I wonder how much man hours work it took to make an OS as the 71b, may it would explain why they dropped the debugger. (01-17-2017 05:07 PM)J-F Garnier Wrote: (Warning: advanced information :-) Indeed, powerful and reserved for extreme situations! It worked on my case, thank you. The ALARMLEX with SETALARM also execute commands from strings but that’s not as clean as your code. The JPC seems to be a ‘must have’ ROM (at least for me). Sorry to take so long to respond, best regards, André 01-22-2017, 09:34 AM Post: #58  Erwin Member Posts: 120 Joined: May 2015 RE: FRAM71B (01-17-2017 09:07 AM)dayd Wrote: In Erwin’s pdf, sometimes, like in the beginning, IRAM identifiers are not erased by a poke, is there a reason? Hi André, there is no reason - it was my very first full try with an easy proposal from Sylvain and I did it only one time and it was running. But I'll do it a second one and see what's the difference :-) regards Erwin 01-22-2017, 10:18 AM Post: #59  Erwin Member Posts: 120 Joined: May 2015 RE: FRAM71B (11-01-2016 03:39 PM)Dave Frederickson Wrote: Understand that ROM's and IRAM's get configured after RAM. When you FREEPORT a module it moves within the address space from RAM to a higher address with the other ROM's and IRAM's. In some max RAM configurations this will cause a configuration warning just like configuring more RAM than can be addressed. Configuring the module as ROM will, by definition, prevent it from being written. (11-01-2016 02:14 PM)Erwin Wrote: ... I see it in the end of the article so I have to take care to put the larger ROMs first. That's not necessary. The 71's configuration routine takes care of that. That said, I had no issues configuring FRAM71B as above. Code: >PEEK$("2C000",32) D3E4D5D69718191A9B50D10000000000 >RUN MEMBUF Port Dev Seq  Size Addr  Type   0   0   0     4  70000  0  BUILT-IN RAM   0   1   0     4  72000  0  BUILT-IN RAM   0   2   0     4  74000  0  BUILT-IN RAM   0   3   0     4  76000  0  BUILT-IN RAM   5   4   0   128  30000  0  MAIN RAM   0   5   0    16  80000  2  HPILROM   5   0   0    16  88000  2  FTH41 ROM   5   1   0    32  D0000  2  MATHROM   5   2   0    32  C0000  2  JPC ROM   5   3   0    32  B0000  1  FRAM71 TK   5   5   0    64  90000  2  DATACQ ROM >

Dave

Hi Dave,

The way you did it is running for me in the same way. But to put the DATA-ACQ module in this space it must be configured as IRAM and that is not possible. When I FREEd this space it does it without an error but it resides as RAM. You can try this with POKE "2C012"; "109100" and then try to FREE it. So maybe its not possible for 64k on the "end" of the FRAM? In the address space it is after the MAIN RAM.

I'm confused at the moment about this. No other have such problems solved? I'll try it in another sequence ... next time.

regards Erwin
01-22-2017, 02:02 PM
Post: #60
 Erwin Member Posts: 120 Joined: May 2015
RE: FRAM71B
(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 and needs a LEX-File "TRIM$" from STRINGLX. But in the basic program there is another LEX-file not present (XFN113004) - line 100 till 103 for the checksum - so it ends in an error. Looks like it was saved in the past without the necessary LEX present in the HP71. When the prog could be run I could get the data out of my DATCQ module. Now I found the solution - with the help of Joe Horn's great the O.L.D project to searcher the XFN number and get the function or command: OLD Project It is the 'HTA$' command. So the correction of the program looks like:
Code:
10 ! THIS PROGRAM COMPUTES CHECKSUMS FOR ROMCOPY FOR 64K IRAM 20 INPUT "Port?","5";P 21 P$=":PORT("&STR$(P)&")" 30 DIM A$[96] 31 I=1 40 A$=CAT$(I,P$) @ IF A$="" THEN 100 50 F$=TRIM$(A$[1,8]) @ B$=ADDR$(F$&P$) @ PRINT A$[1,8];" ";B$; 51 O1=HTD(B$) @ IF I=1 THEN O=O1-8 @ PRINT ELSE PRINT USING "X,5D.D";(O1-O)/2 52 IF O1-O>32768 AND O2=0 THEN O2=O1-O 53 IF O1-O>32768*2 AND O3=0 THEN O3=O1-O 60 I=I+1 @ GOTO 40 100 PRINT USING '"csum 1: ",6d,x,8a';30;HTA$(PEEK$(DTH$(O+8),18)) 101 PRINT USING '"csum 2: ",6d,x,8a';O2+22;HTA$(PEEK$(DTH$(O+O2),18)) 102 PRINT USING '"csum 3: ",6d,x,8a';O3+22;HTA$(PEEK$(DTH$(O+O3),18)) 103 PRINT USING '"csum 4: ",6d,x,8a';O1-O+22;HTA$(PEEK$(DTH$(O1),18)) 200 POKE DTH$(O+30),"00" 201 POKE DTH$(O+O2+22),"00" 202 POKE DTH$(O+O3+22),"00" 203 POKE DTH\$(O1+22),"00"

maybe some could use it too - regards Erwin
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)