FRAM71B
|
11-01-2016, 01:42 PM
Post: #41
|
|||
|
|||
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
|
|||
|
|||
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. 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
|
|||
|
|||
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) Dave |
|||
11-22-2016, 10:53 PM
(This post was last modified: 11-22-2016 11:07 PM by physill.)
Post: #44
|
|||
|
|||
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
|
|||
|
|||
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 HTH, Dave |
|||
11-24-2016, 05:55 PM
Post: #46
|
|||
|
|||
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
|
|||
|
|||
RE: FRAM71B | |||
12-30-2016, 12:26 PM
(This post was last modified: 03-08-2017 06:45 PM by Erwin.)
Post: #48
|
|||
|
|||
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
EDIT 2017-03-08
Erwin |
|||
12-30-2016, 02:49 PM
Post: #49
|
|||
|
|||
RE: FRAM71B
(12-30-2016 12:26 PM)Erwin Wrote: Hi, 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
|
|||
|
|||
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:
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
|
|||
|
|||
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
|
|||
|
|||
RE: FRAM71B
(12-30-2016 06:57 PM)Dave Frederickson Wrote: Very nice, Erwin. 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
|
|||
|
|||
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 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
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
RE: FRAM71B | |||
01-22-2017, 04:22 AM
Post: #57
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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. 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
|
|||
|
|||
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 maybe some could use it too - regards Erwin |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: