[HP 71B] Software for FRAM71 users

[dayd]

Taking the MEMBUF idea a bit further I made a little program to help configure the FRAM71. Each time I reconfigure the FRAM71 I do a peek at 2C000 then run MEMBUF, looking for where is what I want to modify(?).
By running MEMDIS and looking at my actual FRAM Blocks configuration table, I have a quicker view of the actual memory state to determine the needed poke(s).
MEMDIS reads the header of IRAM and ROM memory, recognize IRAM identifiers (shown as “i“), HC ROMs (shown as “HC“ when in place at E0000 and “!” else where). It will display the name of the first file on IRAM chips or just 3 dots if empty.
It is intended to be use with some display so set your delay at 0,0 in that case, and for using without one, you can still remove blank lines from the code.
If, flirting with the limits, you need know the amount of addressable space left, just uncomment the line 280.
DESAL or similar keywords (HTA$,REV$) have to be installed and information can be found at:
JF Garnier's website
or at:
Joe Horn's website
or elsewhere…
You can also found Desal in the FRAM71 Tool Kit.

I’m a newbie with the 71b (started around charismas 2016) and not aware of a lot of particulars so take it as a beta version to be tested and excuse my basic... If it is useful for you, please report any bug (some probably still exist at this point, v.0.8) or rapture you may encounter!



Revisions:
v.0.8: First release, here.
v.0.9:

- Changed calculation of Maximum Addressable Space Left.
- Added detection of blank IRAMs configured as HC ROM at E0000.
(ROM blocks with no name (empty) still remain undetected as HC ROM)

v.1.0:

- Changed addressable space left calculation, at Dave's request,
to reflect independently room for RAM and room for ROM/IRAM.
Results can be off by 3KB from theoretical space for easiest practical use.
- Minor display bug removed.
- Notes in MEMDISH file

edit 1: fixed links
edit 2: v.0.9 Update and revision notes
edit 3: v.1.0 Update and revision notes

[dayd]

During development, I came across what might be a big bug in the JPC ROM (F04) in the RED$ function. With an empty string, at runtime the function through an error ‘String Overflow’. If you type directly RED$("") it freezes the computer and then INIT:1 does a CLAIM PORT on all the IRAMs at once, erasing all content of course! The same does not append with the DEVAL Lex file only. I removed the function from the code.

[Dave Frederickson]

Hi André,

In line 280 you use a constant of 384, presumably as the maximim kbytes of FRAM that can be used, but this isn't always the case. Whether or not the HP-IL module or a HC ROM is installed will affect the amount of FRAM that can be used. Also, FRAM71 HW104 can access 8k more FRAM than FRAM71B in certain configurations. See http://www.hpmuseum.org/forum/thread-4551.html
Note that the topic of this thread is Maximum RAM (MAIN) Memory but total FRAM utilization is also counted.

Regards Dave

[dayd]

Hi Dave,
thanks for testing.
the HP-IL module and HC ROM are taken into account during the scan in the U variable. 384 came from 512K minus 64K OS, 32K 20000 to 2FFFF and 32K at F0000 to FFFFFF. I’m not sure if there is a case scenario where some of this last part is available.

Best regards, André

[Dave Frederickson]

Hi André,

F0000-FFBFF is available for use, which in FRAM71B terms is one 16k device. See Cases 1 & 2 in the link. FFC00-FFFFF is the Configuration "Garbage Dump", see S/W IDS, Vol. 1, Sect. 2.1 & 2.8 and is RESERVED so you need to subtract 1k from the available memory space. Also, if an HC ROM is configured then everything above E0000 is used or unavailable.

Regards Dave

[dayd]

I looked into it, so correct me if I’m wrong:

Max addressable space, by 4k steps = 512 - 64 OS - 32 CR - 4 garbage = 412 KB
If HP-IL : -16 KB
If HC (and HC part only) -60 KB

thanks
regards, André

[Dave Frederickson]

Close. An HC ROM is only 32k but the system sets aside everything above E0000. See the IDS Sect 2.6.

[rprosperi]

(02-02-2017 01:24 AM)Dave Frederickson Wrote:  Close. An HC ROM is only 32k but the system sets aside everything above E0000. See the IDS Sect 2.6.

You can also see this on p.25 in the Forth manual, indicating that F0000-FFC00 is "Reserved for Debugger". The IDS and some early notes in the PPC Journal from Jim de Arras clarifies that this is true only if there is an HC ROM present at E0000 (means either the Forth/Assem ROM or the 41Trans ROM). The Debugger these notes refer to was never released; the one that actually was released is implemented as normal LEX files and does not load here - seems the plan changed.

Of course if there is an HC ROM at E0000 (32KB) it's corresponding SC ROM (16KB) must also be present, and should be removed from available address space as well.

Thanks for the new MEMDIS program to explore André, looking forward to checking it out this weekend.

Can you explain the meaning of the 2 lines of hex just after the VER$ display? I see that the initial portion is the config string, but not certain yet of the portions after the dot, and the 2nd line.

Also, you may be a 71 newbie, but you've come a long way quickly.

Thanks.

[dayd]

(02-02-2017 01:39 AM)rprosperi Wrote:  Of course if there is an HC ROM at E0000 (32KB) it's corresponding SC ROM (16KB) must also be present, and should be removed from available address space as well.

Thanks for the new MEMDIS program to explore André, looking forward to checking it out this weekend.

Can you explain the meaning of the 2 lines of hex just after the VER$ display? I see that the initial portion is the config string, but not certain yet of the portions after the dot, and the 2nd line.

Also, you may be a 71 newbie, but you've come a long way quickly.

Thanks.

Thanks Bob,

The jumpers on the FRAM71B are hard, to me, to put in place with my big fingers, so for unplugging an HC/SC ROM, I just remove the SC part. The HC part remain in place at E0000, doing nothing beside occupying the space. That’s the case in screenshot above.

This two lines are the configuration string - PEEK$(“2C000”,32) - and the corresponding address 2C00 0 or 2 or 4 etc. and after the dot 2C01 0 or 2 etc…
Let’s say I want to swap the JPC ROM with the CIRCUIT ROM, my table says I put the JPC (D type) on the FRAM block 0, the Circuit (E type) in F_block D and Memdis shows the D block 0 (D0) at the first 6 so I poke “2C006”,”00” and “2C006”,”ED” OFF/ON.
A bad poke can lead to losing the content of various F_block at once that why the line below the string and the dot are there.
Below 8 chips the second part of the configuration string never stays at 0 and fills some 1s. I use this behavior in the code see if there is something connected and then only, display this lines.

have a good WE, André

[Dave Frederickson]

(02-02-2017 03:31 AM)dayd Wrote:  Let’s say I want to swap the JPC ROM with the CIRCUIT ROM, my table says I put the JPC (D type) on the FRAM block 0, the Circuit (E type) in F_block D and Memdis shows the D block 0 (D0) at the first 6 so I poke “2C006”,”00” and “2C006”,”ED” OFF/ON.

Per every ROM application manual, power must be cycled between module swaps and the FRAM71 manual states that those rules apply. After the POKE"2C006","00" power must be cycled for the "removal" to be detected.

[J-F Garnier]

(02-01-2017 10:22 PM)dayd Wrote:  During development, I came across what might be a big bug in the JPC ROM (F04) in the RED$ function. With an empty string, at runtime the function through an error ‘String Overflow’. If you type directly RED$("") it freezes the computer and then INIT:1 does a CLAIM PORT on all the IRAMs at once, erasing all content of course!

You found a new bug in the JPC ROM ! Amazing that it remained unknown for such long time.
I may try to fix it.

J-F

[dayd]

(02-02-2017 05:14 AM)Dave Frederickson Wrote:  

(02-02-2017 03:31 AM)dayd Wrote:  Let’s say I want to swap the JPC ROM with the CIRCUIT ROM, my table says I put the JPC (D type) on the FRAM block 0, the Circuit (E type) in F_block D and Memdis shows the D block 0 (D0) at the first 6 so I poke “2C006”,”00” and “2C006”,”ED” OFF/ON.

Per every ROM application manual, power must be cycled between module swaps and the FRAM71 manual states that those rules apply. After the POKE"2C006","00" power must be cycled for the "removal" to be detected.

I agree, I missed an OFF/ON in the sentence. One exception though, when I swap the 32KB HC part without removing the jumper, I proceed directly in that case. (FORTH <> T41 or T41 <> FORTH for the HC part only)

[dayd]

(02-02-2017 07:57 AM)J-F Garnier Wrote:  You found a new bug in the JPC ROM ! Amazing that it remained unknown for such long time.
I may try to fix it.

J-F

Great!
I couldn’t believe it and ended up erasing all my files twice, lol.
Another thing that I find odd, without being a bug is that HTA$ doesn’t return an empty string for ”000000”, ASC$(HTA$(“000000”)) returns “…” (Same behavior with Desal, if I remember correctly).That messes with DISP USING.

Thanks J-F,
André

[J-F Garnier]

(02-02-2017 02:21 PM)dayd Wrote:  Another thing that I find odd, without being a bug is that HTA$ doesn’t return an empty string for ”000000”, ASC$(HTA$(“000000”)) returns “…”

This is the normal behaviour of HTA$ and ASC$: HTA$ returns the string CHR$(0)&CHR$(0)&CHR$(0) (which is NOT a null string), and the non-ASCII CHR$(0) characters are not removed by ASC$ but replaced by a period "." . Not two bugs the same day !

Regarding the (real) RED$ bug, it was introduced in the JPC ROM X (or Ex), and is present in all versions F.
Also the bug happens with RED$(" "), CENTER$(""), CENTER$(" ").
RED$ and CENTER$ work fine in JPC ROM D (and previous versions), as well as in the original DESAL Lex.
The JPC ROM version X fixed a lot of bugs, but this is the first known bug *introduced* by version X.

J-F

[dayd]

(02-02-2017 05:15 PM)J-F Garnier Wrote:  

(02-02-2017 02:21 PM)dayd Wrote:  Another thing that I find odd, without being a bug is that HTA$ doesn’t return an empty string for ”000000”, ASC$(HTA$(“000000”)) returns “…”

This is the normal behaviour of HTA$ and ASC$: HTA$ returns the string CHR$(0)&CHR$(0)&CHR$(0) (which is NOT a null string), and the non-ASCII CHR$(0) characters are not removed by ASC$ but replaced by a period "." . Not two bugs the same day !

No like I said that's not a bug on the HTA$ function, but try this :
DISP USING "1A,1A,1A";"-","","-"
- -
ok, and :
DISP USING "1A,1A,1A";"-",HTA$("00"),"-"
--

??
regards, André

[J-F Garnier]

(02-02-2017 05:38 PM)dayd Wrote:  DISP USING "1A,1A,1A";"-",HTA$("00"),"-"
--

same than DISP USING "1A,1A,1A";"-",CHR$(0),"-" (i.e. not related to HTA$ :-)
J-F

[dayd]

Posted update 0.9 according to this thread, see Post #1
best regards, André

[Dave Frederickson]

Hi André,

I like the way this is coming along.

Feature Request:
In EduCALC Tech Note #4 it states that the 71 often allocates 32k for the HP-IL module. (What!)

First of all, this is false. What is observed is that there is a decrease of 32k in available address space when the HP-IL module is installed. Also, there are valid memory configurations that produce a configuration warning when device is FREEPORT'ed.

This is because the 71 configures RAM and ROM/IRAM in two separate configuration tables. So while MEMDIS may report 32k of address space available, it might be split between ROM and RAM.

As a challenge, I'd like to see MEMDIS report separately the available memory in the two address spaces.

Regards Dave

[dayd]

Hi Dave,

(02-03-2017 04:27 PM)Dave Frederickson Wrote:  I like the way this is coming along.

Thank you.

(02-03-2017 04:27 PM)Dave Frederickson Wrote:  Feature Request:
In EduCALC Tech Note #4 it states that the 71 often allocates 32k for the HP-IL module. (What!)

First of all, this is false. What is observed is that there is a decrease of 32k in available address space when the HP-IL module is installed. Also, there are valid memory configurations that produce a configuration warning when device is FREEPORT'ed.

I would love to see the configurations you’re talking about.

(02-03-2017 04:27 PM)Dave Frederickson Wrote:  This is because the 71 configures RAM and ROM/IRAM in two separate configuration tables. So while MEMDIS may report 32k of address space available, it might be split between ROM and RAM.

As a challenge, I'd like to see MEMDIS report separately the available memory in the two address spaces.

I don’t think that’s the purpose of MEMDIS, here’s why:
- I don’t think that having the address space full of ROMs or Lex files is a good thing for the stability of the system. Beyond a point more RAM will just bring more chances to have a corrupted chain file.
- I paid attention to keep the code as straight forward as I could in order to have a quick output, with all the necessary information and minimal requirement. The functionality you’re talking about involves memorizing all the block sizes in order to do the calculations, which has to be done without the help of the Math module or others Lex files, and in the same way as the OS does. That possible but the app will inevitably grow for an information that in my actual own opinion, do not worth it.
- I’m already looking into another application which, IF I have the time to work on it, will bring such a possibility… So that said, I’m also interested in learning how the OS works.

With an HC ROM configured, the amount of available space for RAM or ROM/IRAM, is more or less the same, depending on device sizes.

I would love to hear from FRAM71 users to know if the app is actually useful.

Best regards, André

[Dave Frederickson]

(02-04-2017 08:39 PM)dayd Wrote:  

(02-03-2017 04:27 PM)Dave Frederickson Wrote:  Also, there are valid memory configurations that produce a configuration warning when device is FREEPORT'ed.

I would love to see the configurations you’re talking about.

Very well.

Code:

>POKE"2C000","939495969798999A9B9C9DAE00"

Cycle power

>SHOWPORT
0.05  16384  2
0      4096  0
0.01   4096  0
0.02   4096  0
0.03   4096  0
5     32768  0
5.01  32768  0
5.02  32768  0
5.03  32768  0
5.04  32768  0
5.05  32768  0
5.06  32768  0
5.07  32768  0
5.08  32768  0
5.09  32768  0
5.10  32768  0
5.11  16384  0
>FREEPORT(5.11)

WRN:Configuration

Explain why this happens.

Regards Dave