HP-41: Buffers (creation & managing)

[Geir Isene]

I haven't used buffers before, and decided to see if they could be useful for some of my projects. The ICEBOX ROM inherited several buffer functions from the TOOLBOX ROM; SHOWB, FINDB, BLNG?, MAKEB, BUF>R, R>BUF (the last two seems to be from the David Assembler ROM).

I try to create a buffer and fill it with data from registers, but somehow I just can't get it to work properly, and so I ask the gurus of this forum for some assistance.

I can't seem to get the buffer header right in register 00 to make it save the data properly. All it does is create a new buffer that shows up with a question mark in front of the ID#... and it keeps on creating more such odd buffers with the same ID# and with the "?" in front (like "?11").

Could someone write a baby-step howto on creating a buffer with let's say ID #11 and save the contents of 5 registers to it?

[Geir Isene]

Specifically, there is an issue with the header as described in the David Assembler manual. It gives the format of the buffer header:

Bit:         | 13 | 12 | 11 | 10 | 09 | 08 | 07 | 06 | 05| |04 | 03 | 02 | 01 | 00 |

Content : | ID | ID |   SIZE  |  buffer data --------------------------------------->|

Why the two IDs? And, is there anything in particular that needs to be in the "Buffer data" area of the header?

[Raymond Del Tondo]

Quote:

---

Why the two IDs? And, is there anything in particular that needs to be in the "Buffer data" area of the header?

---

IIRC one of the two IDs will be cleared by the system at turn-on, which means the buffer is marked as deleted. To retain the buffer, a suitable startup code in your ROM sets the buffer ID again.

[Geir Isene]

Right, but why two IDs?

Being home with a fever does have it's advantages. I did some more keying on my 41 and now understand that a buffer is properly created via the function R>BUF as long as the first ID number remains "1". So here is how I did it:

Loaded in Alpha: "15080000000000"

XEQ "HEX>NNN"

STO 00

XEQ "R>BUF"

And via CLRG, BUF>R, I verified that the buffer was saved with the content of registers 01-07 when the R>BUF was called. So: Problem solved.

But I still don't know why the first ID number has to be "1" and why SHOWB returns a "#" and the ID number of the first buffer and "?" and ID number on the subsequent buffers...

Buffers are within reach now, though :)

[Ángel Martin]

Buffers are tricky and treacherous, as you have already noticed. It's a combination of their inherent nature, plus some OS bugs (or idiosyncracies). Here's what I've learned (the hard way BTW, many hours of trial and error efforts):

1. Header register, located at the bottom in memory. Holds the buffer id and the buffer size info. Anything else is available for your usage - like I use it to store the POLAR/RECT flag in the 41Z.

2. Footer register, located at the top in memory. It must be non-zero, or the OS will ignore the buffer when resizing, packing, or creating another buffer (like XZYALM does, or even worse, when you try to access your own buffer).

3. The funcions R>BUF and BUF>R from the DavidAssembler are somehow limited in that they always use registers 00 and following to store the buffer contents. I don't know if they also include the "footer".

I wrote functions ZB>RG and RG>ZB to prompt for the storage register number - they are in the BUFFER rom, companion to the 41Z. Be aware that they expect buffer id#=8 and only handle 12 registers, the size of the complex stack buffer.

Also notice that the header register should not be RCL'd or STO'd again, because of the normalization.

4. I don't know why the BLIST function shows "#" sometimes and "?" some other times. Worse yet, sometimes it returns the "NO BUFFERS" message even when I know for a fact that there are (Complex stack, etc). I didn't study the function, which I believe was written by David Yerka.

Hope this helps, I've sent you in a separate mail the Buffer appendix from the 41Z manual, where it lists the buffer creation and handling routines.

Cheers,
'AM

Edited: 26 Nov 2010, 1:32 a.m.

[Geir Isene]

No mail... did you send it to g@isene.com?

Now, the only thing missing in the manual is an explanation for the PGTRAIL function. I have no idea what that does. When I try it, it only returns an "N" in Alpha, nothing else.

Also, did you get my e-mail regarding the possible NoV COMPANION module?

[Ángel Martin]

If memory serves I think PGTRAIL is al older implementation for OSREV. It's supposed to give you the ROM Page revision number (actually a letter) when you enter the page number as input (eg. 0,2,3). Does that jive?

Note: I tried it and it works as advertized. In fact it gives you the complete ROM id# string, which can be up to 4 chrs length (when you use it on the ROMS plugged on ports 1-4)

I'll reply to your email tonight :)

Edited: 26 Nov 2010, 7:53 a.m.

[Geir Isene]

Thanks :)

And: Yoohoo! The ICEBOX manual is now complete!

[Geir Isene]

BTW; Me getting an "N" upon executing "PGTRAIL" is because X contained "0" and Page zero yields an "N". The pages on my 41CX OS:

0 -> "N"

1 -> "F"

2 -> "L"

3 -> "EF2D" (Extended Functions v. 2D)

4 -> "@@@@" (PGTRAIL yields this 4*#64 when it can't find anything)

5 -> "TM2C" (Time module v. 2C)

6 -> "H11D" (HEPAX v. 1D)

[Ángel Martin]

Geir, I don't think the top char must be a "1". The Complex Stack buffer has "8" as such, but it's related to the behavior Raymond described above:

"The 41 (some early versions of the OS at least) may set the top digit (PT=13) to zero when it's turned on./ The OS then polls each of the ROMS to allow them to put the top digit back. After each ROM has had its go, the OS deletes any buffers that are not claimed (top digit remaining zero)".

That's why the buffer searching routines should use digit 12 instead, in case they're used during the power-up sequence and the OS had wiped the top digit already.

Have a look at the ZBHEAD, ZBVIEW and ZBLIST functions in the BUFFER rom. but make sure it's placed next to the 41Z or else it'll create havok (they use routines within the 41Z module, as a way to diagnose it).

Cheers,
'AM

Edited: 26 Nov 2010, 1:41 a.m.

[HrastProgrammer]

Right, but why two IDs?

I don't recall everything about buffers but IIRC there is only one ID in the form that enables a particular ROM to recover its buffer on startup. Let's say your ROM requires buffer with the ID 44. HP-41C will set this ID to 40 on startup (n0 buffers are marked as deleted), so your ROM should search for ID 40 and change it to 44 in order to recover the buffer.

Temporary buffers have 0n IDs, so they can be automatically deleted on startup (such IDs will be changed to 00 without a chance to recover).

[Geir Isene]

Thanks guys for being so helpful.