[HP 71B] Software for FRAM71 users

[dayd]

(02-04-2017 09:46 PM)Dave Frederickson Wrote:  Explain why this happens.

I can’t explain at this point, I can just guess. The IDS is pretty vague about the algorithm used in the configuration phase.
My guess is, it needs to attribute a temporary address in the same boundaries to move things around (like a 15-puzzle) and there is none. Did you try to free higher addresses first? (port 0.03 then 0.02, etc)

[rprosperi]

(02-05-2017 12:14 AM)dayd Wrote:  The IDS is pretty vague about the algorithm used in the configuration phase.

Indeed! "pretty vague" is about as positive a comment as one can make. I've found that to get anything useful out of reading the IDS, one needs to read the relevant portions many times, plus any/all related areas. It's a lot like Unix/Linux docs - it makes perfect sense if you already understand it.

For more info on 71B memory configuration, read this article: http://www.hpmuseum.org/journals/71b.htm

[Dave Frederickson]

Hi André,

It's much simpler than that, and Bob's right, you need look no deeper than the HP Journal for an explanation. The answer is simply that there's not enough address space to configure Port 5.11 as IRAM.

Here's the valid configuration:

Code:

>POKE"2C000","939495969798999A9B9C9DAE00"
Cycle power
>RUN MEMBUF
Port Dev Seq  Size Addr  Type
  0   0   0     4  E8000  0
  0   1   0     4  EA000  0
  0   2   0     4  EC000  0
  0   3   0     4  EE000  0
  5   0   0    32  30000  0
  5   1   0    32  40000  0
  5   2   0    32  50000  0
  5   3   0    32  60000  0
  5   4   0    32  70000  0
  5   5   0    32  80000  0
  5   6   0    32  90000  0
  5   7   0    32  A0000  0
  5   8   0    32  B0000  0
  5   9   0    32  C0000  0
  5   A   0    32  D0000  0
  5   B   0    16  E0000  0
  0   5   0    16  F0000  2

So from reading the HP Journal article what do we know?
1. RAM is configured first with the largest blocks first
2. ROM/IRAM is configured second
2.a 32k byte chips are configured down from the highest valid address
2.b. 16k byte chips are configured in the remaining space. Observation would indicate up from the next higher valid address from the end of RAM.
3. Devices are configured at addresses that are an even multiple of the Chip size.

From the FRAM71 manual, FRAM71 uses 32k chips so both 64k device and 16k devices will be configured at an even 32k address.

So if we FREEPORT(5.11), how would the 71 configure the memory?
1. Ports 5.0 thru 5.10 would get configured to the same addresses as before
2. Base RAM would get configured from E0000 to E7FFF
3. The HP-IL port gets configured at F0000-F7FFF
4. And there's no address space left for Port 5.11

Code:

>RUN MEMBUF
Port Dev Seq  Size Addr  Type
  0   0   0     4  E0000  0
  0   1   0     4  E2000  0
  0   2   0     4  E4000  0
  0   3   0     4  E6000  0
  5   0   0    32  30000  0
  5   1   0    32  40000  0
  5   2   0    32  50000  0
  5   3   0    32  60000  0
  5   4   0    32  70000  0
  5   5   0    32  80000  0
  5   6   0    32  90000  0
  5   7   0    32  A0000  0
  5   8   0    32  B0000  0
  5   9   0    32  C0000  0
  5   A   0    32  D0000  0
  0   5   0    16  F0000  2

WRN: Configuration

Regards, Dave

[Dave Frederickson]

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

(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 ...

This is just an extension of what MEMDIS already does.

(02-01-2017 10:17 PM)dayd Wrote:  If, flirting with the limits, you need know the amount of addressable space left, just uncomment the line 280.

If we're "flirting with the limits" then we need to know not just how much address space is left, but whether that space is RAM or ROM, as demonstrated in the previous post.

Regards, Dave

[dayd]

Hi Dave,

(02-05-2017 01:58 AM)Dave Frederickson Wrote:  So from reading the HP Journal article what do we know?
1. RAM is configured first with the largest blocks first
2. ROM/IRAM is configured second
2.a 32k byte chips are configured down from the highest valid address
2.b.16k byte chips are configured in the remaining space. Observation would indicate up from the next higher valid address from the end of RAM.
3. Devices are configured at addresses that are an even multiple of the Chip size.

1. RAM devices are configured in order by chip size (not device) then port.
   Size of device = size of internal chips * number of chips
   The buffer contains coded chips’ size and their number, not device size.
   HP-IL ROM device appears in the configuration buffer as one 16k chip.
   FRAM71 devices appeared as one chip per F.Block (a 64k module as 2x32k, a 16k as 1x16k chips)
2. a- 32k and higher, in higher address multiple of chip (not device) size.
   b- I observed the same behavior as you did
   
   So far you probably agree and are well aware of those details, I’m just trying to be specific.
3. Even multiple? Where’s that came from? That would mean that a 1x32k device couldn’t be configured at 40000 but could be at 30000 or 50000.
   Maybe I get confuse by English Language and you mean equal, probably… sorry.
   

(02-05-2017 01:58 AM)Dave Frederickson Wrote:  From the FRAM71 manual, FRAM71 uses 32k chips so both 64k device and 16k devices will be configured at an even 32k address.

As I didn’t had seen neither found such a statement in the manual and the buffer indicates 1x16k for FRAM 16k devices not 1/2x32k, I conducted some experiments to see how configuration routines attributes 16k or less chips in its third phase.
If what if found is correct, we can all forget about IDS chapter 2.4 description detail “The scheme of where each memory device is configured is fairly complex” because the last(?) piece of the puzzle is pretty simple:

RAM and ROM/IRAM can’t be mixed in the same 32k boundaries;

which means that the first (lower) ROM/IRAM address will always be type “X0000”.
That explain your Warning and why at Educalc they thought that the HP-IL needed 32k.
In my experiment I tried to push the HP-IL ROM in to an “X8000” address, well, I got a Warning and lost HP-IL ROM. When it got back after reconfiguration, it seemed to not have lost the buffer though, HP-IL parameters where still there.
I did that with HC ROM configured without its SC, so I still have to see how system behaves in the F0000 range but as there is no device that I know of under 4k, I can assume that the last 3K of available address space are lost.

regards, André

[Dave Frederickson]

HI André,

(02-05-2017 07:31 PM)dayd Wrote:  RAM and ROM/IRAM can’t be mixed in the same 32k boundaries;

which means that the first (lower) ROM/IRAM address will always be type “X0000”.
That explain your Warning and why at Educalc they thought that the HP-IL needed 32k.

That does appear to be the case, but where is that written? Note that EduCALC observed that the HP-IL module "often", but not always, appears to be configured as 32k. The reason is exactly the same as why the configuration warning occurred, above. When Port 5.11 was configured as IRAM it was then configured in the ROM/IRAM configuration buffer making less efficient use of the address space. If Port 5.10 is reduced to 16k then it should be okay to configure Port 5.11 as IRAM. What it appears is that Port 5.11 many times gets configured as 32k, just like the HP-IL module.

(02-05-2017 07:31 PM)dayd Wrote:  In my experiment I tried to push the HP-IL ROM in to an “X8000” address, well, I got a Warning and lost HP-IL ROM. When it got back after reconfiguration, it seemed to not have lost the buffer though, HP-IL parameters where still there.
I did that with HC ROM configured without its SC, so I still have to see how system behaves in the F0000 range but as there is no device that I know of under 4k, I can assume that the last 3K of available address space are lost.

It appears the HP-IL module is always configured on a 32k boundary. I wonder why that is?

(02-05-2017 07:31 PM)dayd Wrote:  

(02-05-2017 01:58 AM)Dave Frederickson Wrote:  From the FRAM71 manual, FRAM71 uses 32k chips so both 64k device and 16k devices will be configured at an even 32k address.

As I didn’t had seen neither found such a statement in the manual and the buffer indicates 1x16k for FRAM 16k devices not 1/2x32k, I conducted some experiments to see how configuration routines attributes 16k or less chips in its third phase.

What was I thinking?? 64k devices do get configured on 32k boundaries because they are made from 32k chips. 16k chips get configured on 16k boundaries.

Regards, Dave

[Christoph Giesselink]

(02-05-2017 10:09 PM)Dave Frederickson Wrote:  It appears the HP-IL module is always configured on a 32k boundary. I wonder why that is?

You're speaking about one HP-IL module only, install two and the 2nd HP-IL ROM is located on a 16k boundary.

[dayd]

(02-05-2017 10:09 PM)Dave Frederickson Wrote:  That does appear to be the case, but where is that written?

I didn’t see it written until I did in post#25.

(02-05-2017 10:09 PM)Dave Frederickson Wrote:  It appears the HP-IL module is always configured on a 32k boundary. I wonder why that is?

According to the rules we talk about, HP-IL ROM is always in a 16k boundary which can be addresses X0000 to X7FFF or X8000 to XFFFF but because HP-IL is lower in port number it gets its address attributed before others 16k or less chips, at X0000 and if there isn’t another 16k or less ROM/IRAM the next 16k boundary at X8000 to XFFFF cannot be filled (the loss of address space can be lower if HP-IL address is at F0000).
As passionate as you are about it, you probably already figure that out by now.

(02-05-2017 05:07 PM)Dave Frederickson Wrote:  If we're "flirting with the limits" then we need to know not just how much address space is left, but whether that space is RAM or ROM, as demonstrated in the previous post.

I’m having others matters to attend to for at least 3 weeks, but will look into it, when the time comes, if you really think that’s necessary. I will see if I can come up with a implementation compatible with the requirements (or, maybe a “Dave’ Special Sport Edition” of MEMDIS…? Chips size can also be useful information to anticipate next configuration).

(02-05-2017 01:27 AM)rprosperi Wrote:  

(02-05-2017 12:14 AM)dayd Wrote:  The IDS is pretty vague about the algorithm used in the configuration phase.

Indeed! "pretty vague" is about as positive a comment as one can make. I've found that to get anything useful out of reading the IDS, one needs to read the relevant portions many times, plus any/all related areas. It's a lot like Unix/Linux docs - it makes perfect sense if you already understand it.

For more info on 71B memory configuration, read this article: http://www.hpmuseum.org/journals/71b.htm

Lol, I agree, I couldn’t help myself and quoted the IDS (post#25) with a phrase that get me a bit nervous at the time…
Thank you for the link, that’s very useful information for those who read this thread looking for more insight.
By the way, IDS refers here to the Software Internal Design Specification for the HP-71 volumes that can be found in the Museum Document Sets

Best regards, André

[Dave Frederickson]

Hi André

(02-06-2017 09:26 PM)dayd Wrote:  

(02-05-2017 10:09 PM)Dave Frederickson Wrote:  It appears the HP-IL module is always configured on a 32k boundary. I wonder why that is?

According to the rules we talk about, HP-IL ROM is always in a 16k boundary which can be addresses X0000 to X7FFF or X8000 to XFFFF but because HP-IL is lower in port number it gets its address attributed before others 16k or less chips, at X0000 and if there isn’t another 16k or less ROM/IRAM the next 16k boundary at X8000 to XFFFF cannot be filled (the loss of address space can be lower if HP-IL address is at F0000).
As passionate as you are about it, you probably already figure that out by now.

Doesn't answer my question. This behavior is not limited to the HP-IL ROM. No matter what, ROM/IRAM configuration always starts on a 32k boundary.

Regards, Dave

[dayd]

(02-06-2017 10:11 PM)Dave Frederickson Wrote:  Hi André

(02-06-2017 09:26 PM)dayd Wrote:  According to the rules we talk about, HP-IL ROM is always in a 16k boundary which can be addresses X0000 to X7FFF or X8000 to XFFFF but because HP-IL is lower in port number it gets its address attributed before others 16k or less chips, at X0000 and if there isn’t another 16k or less ROM/IRAM the next 16k boundary at X8000 to XFFFF cannot be filled (the loss of address space can be lower if HP-IL address is at F0000).
As passionate as you are about it, you probably already figure that out by now.

Doesn't answer my question. This behavior is not limited to the HP-IL ROM. No matter what, ROM/IRAM configuration always starts on a 32k boundary.

Regards, Dave

This behavior is not limited to the HP-IL ROM: agreed.

Phase one of the distribution process;
RAM from bottom address 30000 to XX000
Phase two; ROM/IRAM 32k or more starting from the top addresses to bottom.
Phase Three; First 16k or less ROM/IRAM Starting (bottom to top) after the RAM but can be mixed with RAM in the same 32k boundary, so it takes the first available 16k boundary after that, which mathematically always will be at Y0000. If different than F0000, Y8000 is free for next 16k (or less) because phase two are 32k multiples.

regards, André

[Dave Frederickson]

Hi André,

(02-05-2017 07:31 PM)dayd Wrote:  RAM and ROM/IRAM can’t be mixed in the same 32k boundaries;

(02-06-2017 11:13 PM)dayd Wrote:  Phase Three; First 16k or less ROM/IRAM Starting (bottom to top) after the RAM but can be mixed with RAM in the same 32k boundary, so it takes the first available 16k boundary after that, which mathematically always will be at Y0000.

In Phase Three I believe you meant that RAM and ROM/IRAM can't be configured in the same 32k block. That is what's observed, but I was looking for an official explanation.

In the S/W IDS, Vol. 2, p.4-8 under the CONF60 routine a "Page" is defined as 10000H nibbles. Pages occupied or partially occupied by system RAM are marked as unavailable for configuring ROM. So, a Page can't contain RAM and ROM/IRAM. This is the official explanation I was looking for.

Regards Dave

[dayd]

(02-07-2017 12:06 AM)Dave Frederickson Wrote:  In Phase Three I believe you meant that RAM and ROM/IRAM can't be configured in the same 32k block.

Indeed Dave, that's what I meant, I will correct the typo.

(02-07-2017 12:06 AM)Dave Frederickson Wrote:  In the S/W IDS, Vol. 2, p.4-8 under the CONF60 routine a "Page" is defined as 10000H nibbles. Pages occupied or partially occupied by system RAM are marked as unavailable for configuring ROM.

Good catch! For my part I thought I didn't have Vol.2&3 but I finally found all volumes (3+3 ? ) and what a good surprise to see more details on same topic. There is other useful related information. I'm particularly curious about the process the OS uses to properly remove ROMs or IRAMs with Lex files because I have sometimes big memory losses when removing with just POKE”2C0xx”,”00” OFF/ON even with the last connected Fram Block and that's not just a Memory Lost but IRAMs Fram blocks that turn into RAM... The computer freezes with the poke in the screen. Last time was with the workbook71, the SC Forth-Assembler is particularly sensitive too.
Any ideas about that ?

[Dave Frederickson]

Hi André,

(02-07-2017 05:05 PM)dayd Wrote:  I'm particularly curious about the process the OS uses to properly remove ROMs or IRAMs with Lex files because I have sometimes big memory losses when removing with just POKE”2C0xx”,”00” OFF/ON even with the last connected Fram Block and that's not just a Memory Lost but IRAMs Fram blocks that turn into RAM... The computer freezes with the poke in the screen. Last time was with the workbook71, the SC Forth-Assembler is particularly sensitive too.
Any ideas about that ?

Since FRAM never forgets, IRAM's can reappear unexpectedly when FRAM71 is reconfigured. CN2-2 exists to fix these sorts of problems. To avoid this, additional steps are required to remove a FRAM71 memory device from the configuration.

See this post: http://www.hpmuseum.org/forum/thread-496...l#pid44130

Regards, Dave

[dayd]

Hi Dave, what a prompt response!
But that's not the issue here, I'm aware of that. What I meant by 'removing', it's just 'unplugging' (a ROM).

regards, André

[Dave Frederickson]

(02-07-2017 05:53 PM)dayd Wrote:  But that's not the issue here, I'm aware of that. What I meant by 'removing', it's just 'unplugging' (a ROM).

I thought I'd mention the above issue as I believe many problems are caused by unexpected leftover data in FRAM.

In trying to bank-switch the two HC modules OTF I also observed that the FORTH/Asm SC ROM is a little finicky. What I'd like to see is more robust behavior, but I think Hans will need to get involved to clarify the procedure or tweak the code.

Dave

[Hans Brueggemann]

for the FORTH related ROMs, there is one more caveat: as soon as you have invoked (for example) FORTH, there will be a FORTH file created. same should hold true for the HP41 ROM, but i'm not absolutey sure off top of my head. so, doing something like FORTH [ENTER] BYE [ENTER] and then trying to switch configuration over to the HP-41C emulator may result in a crash due to the presence of the (previously generated) FORTH file. haven't fully investigated it, but erasing that file before switching the config may avoid that issue. there isn't much that FRAM71 can do to make that process easier.

[Dave Frederickson]

The FORTHRAM files for the FORTH/Assembler and the 41 Translator have different names and cause no conflict. This can be verified with Emu71/Win or physical modules.

[Hans Brueggemann]

ah, ok.

[dayd]

I'm not at home at the moment, and last night every body went at the movies to see what appeared to me to be a weird piece. As I didn't want to live such an experience, I found my self alone for a couple of hours and grabbed the 71b to look at Dave's request. Thanks to HP excellent basic, I was able to easily integrate his request, see post #1 for v.1.0 . (I still may not be able to promptly respond in the next few days).