The Museum of HP Calculators

HP Forum Archive 20

[ Return to Index | Top of Index ]

Some 41CL Questions
Message #1 Posted by Gerry Schultz on 27 Dec 2011, 6:00 p.m.

Hi, now that Christmas is over, I thought I would put together some of my questions about the 41CL. I've been reading the 41CL Calculator manual and was wondering about a few things.

First, some observations. In the supplemental sheet sent along with the 41CL circuit board, it shows 0x0DF000 as holding IMDB.ROM which, I assume, is the 41CL Image Database. On page 51 of the manual, the memory map shows this range of Flash to be open. The same thing for the 0x0C9000 through 0x0CF000 and 0x0D1000 through 0xD7000. I want to mention this because if someone starts tinkering without reading the supplemental sheet and copies data into these address ranges thinking they are available, they could get a nasty surprise.

I’m confused about how memory is addressed in a 41C. I’ve read a lot of books about the 41C so I do understand some of its unique capabilities, but RAM vs. ROM addressing I’ve never quite followed. I know that 41C storage registers are addressed in 7-byte registers and program instructions are byte (or multi-byte) in size. The absolute addressing for RAM is 000 to 1FF as explained in W.A.C. Mier-Jedrezejowicz’s book “Extend your HP-41”, in chapter 8. Extended memory goes on up to 3EF(and filling in some memory gaps as well), as explained on page 547. For ROM memory, there are 16 4K memory pages with the first 8 covering the internal O/S, Extended Functions (CX only), HP Diagnostic module, Timer module (page switched with additional CX functions), Printer and HP-IL. The upper 8 pages cover the 4 I/O ports (page 190). Finally, the ROM M-code instruction bytes are 10-bits long with some instructions being 20-bits long.

One area of confusion is the 10-bit ROM vs. 8-bit RAM addressing. For HP-41 FOCAL programs in ROM, the two extra bits are not used, but M-code instructions use all 10 bits are used. Is this why M-code programs can only be run in ROM space and not RAM space? Also, how does the 41 assign a memory module to the RAM address space when plugged into an I/O port verses assigning ROM modules plugged into an I/O port to the ROM addressing space? It appears these upper 8 4K I/O pages can assigned to either memory space, so is there an MMU in a 41C doing these memory re-assignments behind the scenes?

An interesting statement on page 193 says: “Programs in ROM always run from lower addresses to higher addresses. This is the same direction as data addressing in RAM, but the opposite direction to programming addressing in RAM. ...The HP-41 has to know if a User code program is in RAM or ROM since the instructions are read in the opposite directions in the two cases. COPY has to reverse the instructions when copying a program from ROM to RAM.” How does the 41 do this? How does the 41 memory addressing ROM/RAM space map into the 41CL memory addressing space especially when one is 10-bits deep and the other is 8-bits deep?

Another area I’m confused about is Logical Addressing and Bank Switching. For instance, the function YMCLR in the 41CL manual, under logical address; L3, L2, L1, L0, - B arguments, what does that mean? At the bottom of page 39 of the 41CL manual, it says: “The 41C system uses a 16-bit (64K) program address, which is divided into sixteen pages of 4K each. For many of these pages, there can be up to four “banks”, which are selected under software control during program operation.” Which software control, the O/S or the program in ROM and what is being switched in and from where in relation to the 41C memory space? On the next page, “To accomplish this mapping, the MMU takes the upper four bits of the program address (which selects the page), plus the two bits which select the bank, and forms a special memory address.” Which 4-bits and 2-bits? The 4K ROM addressing are absolute addressing bits 0 through 11. So are bits 12 through 15 page addressing and bits 16 and 17 are page addressing or since absolute addressing bit 23 identifies Flash verses RAM, are these page and bank addressing bits 17 through 22?

I want to understand these issues clearly before I do too much to not hose my 41CL.

Thank you for your responses. Gerry

Re: Some 41CL Questions
Message #2 Posted by Diego Diaz on 27 Dec 2011, 11:30 p.m.,
in response to message #1 by Gerry Schultz

Hi Gerry,

Your post looks quite more like an exam than a "... mmm... I was just wondering about a few things..." :-)

Ok, not that I'm the most authoritative voice in here (that's even more true when talking about 41CL) but since none of the "gurus" seems to be around... I'll give it a go and will try my best in order to explain HP-41 addressing scheme.

"RAM vs. ROM addressing"

In short this is the very key of the subject, if you get a clear picture on the details that make RAM and ROM addressing *soooo* different you will more likely have got a pretty good understandig of the remaining questions.

First of all, referring to user RAM, Data/Storage registers, User program area... and all the many different ways to call HP-41 "read/write" registers, is IMHO the cause of most misundertandings.

These storage registers *ARE NOT* RAM, in the sense we can see RAM into most any other type of microprocessor controlled device. These registers are built and are accessed (and this is more important from the point of view of the questions you've brougth here) like a solid state storage *peripheral*.

The only "memory" which NUT processor can access to and read from is the 64K (16 pages 4K each) with a word length of 10 bits.

So called "user programs" (FOCAL) are just a sequence of bytes (8bits) organized into registers (7bytes each) quite like a "record" in a disk drive. When you hit the "R/S" key, you're just instructing the CPU to start reading this bytes sequence from the "record" thru a "Parser" (interpreter) which decides the parts of the CPU program in ROM (this is the "real program" the NUT processor can execute: M-code) that is needed to perform the requirements in the "user instruction".

The NUT processor can only execute instructions stored into its ROM area (these 64K). Further more it cannot even write in this area, this is why when some users got access to the realms of M-code, they coined anew instruction to allow writing in the "ROM" addressing space. The instruction itself is a NOP for the NUT processor... so, every device willing to handle such writing instruction (H'040, aka WROM) has to find its own way to achieve the task. This is how most RAM boxes work (W&W, ERAMCO, HEPAX...)

When the parsing from a given command (say XEQ "ABC") finds that such "ABC" corresponds to a FOCAL program located into ROM area (this is encoded in the FAT of the page where the program is located) then it simply treats it like if there were a sequence of bytes just as if it was located in the storage registers (aka user RAM).

Therefore, RAM modules and ROM modules are intrinsecally different, when you plug a RAM module you're just plugging another "peripheral drive" while ROM modules are placed into the 64K memory addressing space.

I'm not familiar (yet) with CL's "logical addressing" so I think that some others here will give you a better advice on the subject.

Regarding Bank-Switching, this is a technique that allows a "program" (read M-code program into ROM addressing area) to turn OFF a given bank and turn another one ON in the same address.

The porgram continues on the new memory bank as if it still was in the same address (in fact it is) so effectivelly doubling (or even quadrupling) the amount of mamory without requiring a wider address bus.

Again, as in the H'040 WROM instruction, the instructions used to perform the bankswiching ON and OFF wereNOP's for the NUT processor, so every module that requred Bank-Switching, had to built its own scheme and inplementation. Most of them are similar like the ones in the Advantage PAC, the IR printer, the CX EXT funcs, or the HEPAX (this last goes a bit further by using four banks in a single page), but some curiousities can be found like the W&W 64K RAM box (or its implementation in the 41CY) which handles BS in a slightly different way.

Hope this may be useful. Sure you'll find more details on the CL from other contributors soon.

All the best from the Canary Islands.


Re: Some 41CL Questions
Message #3 Posted by Howard Owen on 28 Dec 2011, 10:20 a.m.,
in response to message #2 by Diego Diaz

Thanks for that exposition, Diego! I learned a thing or two. :)

Re: Some 41CL Questions
Message #4 Posted by Ángel Martin on 28 Dec 2011, 3:21 a.m.,
in response to message #1 by Gerry Schultz

Now that was a crystal-clear explanation on the RAM-ROM subject from Diego, I finally understand some things :=)

I´m no expert on the CL inner design, but it has helped me to think of ¨logical¨ addresses as those the native 41C OS would recognize, using its nomenclature and conventions - whilst ¨physical¨ addresses are the real ones used by the NEWT processor on the CL board.

Similar concepts are the DATA addresses and the PROGRAM addrsses, which I associate to ¨41-style RAM¨ registers and ¨41-style ROM¨ respectively.

HTH, I found the CL manual to be very well written, so after a few of my own CPU cycles I´ve normally grasped most of it. There is a lot of innovation in there ¡ mostly transparent to the typical user, to Monte´s credit, so no doubt some effort will be required.

Best, ÁM

Re: Some 41CL Questions
Message #5 Posted by Monte Dalrymple on 28 Dec 2011, 2:09 p.m.,
in response to message #4 by Ángel Martin

Diego covered the RAM-ROM quite well, so I'll just comment on the logical versus physical issue.

The logical address space consists of the ROM and RAM addresses available in a normal 41C context. That is, the 64k x 10 bit program memory and 1k x 56 bit (7 byte) register memory. To the 41CL user these appear to operate identically to how they work in the 41C. But in the 41CL these address spaces happen to be mapped into a much larger physical memory space. This phycical memory space is 16M x 16 bits and is divided in half, with the lower half assigned to Flash and the upper half assigned to RAM. On the current 41CL boards the Flash is 1M x 16 and the RAM is 256K x 16.

The regular 41C register address space is mapped to a specific location in the physical RAM, starting at address 0x800000. The details of this mapping is covered in the 41CL manual.

The 41C program address space is normally broken into 4k pages, and most of these pages can also use bank-switching to contain four banks (but only one at a time). These pages (and each bank) are also mapped into a physical address, in either Flash or RAM. A number of the pages (those used for the OS) are mapped to specific Flash addresses. Those pages that are not specifically mapped by the hardware (the pages used for the OS) can be optionally mapped to any address in physical memory using the MMU. This mapping information used by the MMU is also stored in specific locations in the physical RAM memory, and is automatically accessed by the hardware to calculate where in physical memory to find the required data.

Operation of the MMU is conpletely transparent to the user. When you use a PLUG command to insert an image into a Port, what the software is really doing is programming the MMU to point that correspond page of logical memory at the location in physical memory where the image is located. From that point on when the 41C software reads from that page of logical memory, the data will actually be fetched from the correct location in physical memory.

The details about where things are located in physical memory is also contained in the 41CL manual. Most users should not need to be concerned with these details, though. That's what the PLUG commands are for.

As far as messing up the 41CL, I've tried to make it hard to do. But there are a couple of things that you do need to be careful of. First, don't plug a module into an address that is concurrently mapped by the MMU. This will lead to a bus fight, because in this case the 41CL hardware actually drives the bus with the data just like a physical module would do. Second, be very careful when erasing or programming the Flash. I originally did not plan to make Flash erase and write operations available to the user, but changed m mind before the Beta units went out because I wanted to provide a way to patch the software in the field if necessary. (And it's a good thing that I did, given the bugs that I managed to miss the first time around). But aside from these two cases, the 41CL should be fairly robust. Certainly a memory clear or battery removal will fix just about everything except a corrupted Flash memory.

I hope this helps, Monte

Edited: 28 Dec 2011, 4:00 p.m.

Re: Some 41CL Questions
Message #6 Posted by Frido Bohn on 29 Dec 2011, 9:39 a.m.,
in response to message #5 by Monte Dalrymple

Dear Diego and Monte,

Thank you for the clarification of how RAM and ROM are defined in the 41C and the 41CL, respectively.
However, there are some assumptions (or better concealed questions) which came up after reading the thread.

The flash memory of the 41CL can be erased except for the portion where the OS resides. This is the area from 0x000000 to 0x007000.
Consequently, the command "000000 (in ALPHA) YFERASE" would render the error message "OS AREA" as the first 32k are protected. Trying to "patch" the OS area by YFWR would lead to the same error message. However, are there any commands documented in the 41CL manual that could harm this area?

The content of the RAM of the 41CL (0x800000 and above) is restored to its initial status after power is turned off completely,
i.e. batteries are taken out for a while and a MEMORY LOST shows up after power on.

Contents of flash which are overwritten, e.g. by a new version, may survive the writing procedure and generate artifacts or a strange behaviour if plugged on a page because "writes to flash can only change a "1" to a "0" and never vice-versa" as stated in the 41CL manual. Therefore, it is recommended to erase that portion first and filling it with "1s" before re-writing it. (How to handle this, is extensively documented in the 41CL manual.)
Thus, the revision of a 4k module in flash means that 28k have to moved around more or less unnecessarily, only due to the 32k span of the erase command.
To overcome this situation, would it be possible to generate a "zero-ROM" or "NOP-ROM" (full of "1s") which is written first on the 4k sector of interest as a means of deletion before the actual piece of code (e.g. a revision of a module) is written onto it?

Thanks for your patience

Re: Some 41CL Questions
Message #7 Posted by Monte Dalrymple on 29 Dec 2011, 11:14 a.m.,
in response to message #6 by Frido Bohn

1. The OS area (0x000000 to 0x007FFF) is protected by an address check in the YFERASE and YFWR functions. Since these are the only two commands that could conceivably affect the OS area, it is in all cases protected from corruption. The Flash memory itself can be programmed to protect certain sectors. I don't use this feature because my Flash programmer does not support this. Unfortunately I bought a relatively inexpensive Flash programmer.

2. RAM contents are not retained without power. There is a capacitor on the 41CL board that will supply the RAM for about 20-30 seconds without batteries, but after that time the contents are unpredictable. However, the OS does initialize the 41C "register" area when the "Memory Lost" condition is detected. Extended memory is not initialized, and neither are the MMU contents.

3. The erase operation is the only way to clear a Flash sector. The 32K word erase is a feature of the Flash chips themselves. It would be much more convenient if the erase size were 4K, but it is what it is. Writing all ones to a page doesn't do anything, because it is essentially a "No Operation" for the Flash memory device. Any existing zeros in the page stay at zero. The same will be true of the ones already existing in the page. This is why I initially located the "XXXn" user mnemonics in separate sectors. But then there wasn't room for the solution book images in the Flash for the production boards. If I revise the board I will probably route more address lines to the Flash so that I can place a larger device on the board.

Hope this helps,

Re: Some 41CL Questions
Message #8 Posted by Monte Dalrymple on 29 Dec 2011, 11:22 a.m.,
in response to message #7 by Monte Dalrymple

I should note that if power is interrupted during a Flash erase or write, unpredicatable things can happen. Geoff had his OS area corrupted when this happened. That's why you should always use fresh batteries when working with Flash.

I personally use RAM to hold stuff, and only update the Flash when I really, really want to make something permanent.

My original plan was to use and FRAM, which is non-volatile, for the RAM. But that would have added $25 to the cost, because the technology is very expensive. It would also have added another 30uA to the standby power. That's is why I went with regular RAM.

Re: Some 41CL Questions
Message #9 Posted by Geir Isene on 29 Dec 2011, 6:09 p.m.,
in response to message #8 by Monte Dalrymple

This is precisely why the HP-41CL and the NoV-64 (or 32K or the 16K version) are great companions. I now use only my HP-41CL, and with my NoV-64 plugged in, I have constant memory HEPAX to save RAM, programs, XM files etc. to easily (without having to erase any flash or do any risky operations). Heaven I say.

Re: Some 41CL Questions
Message #10 Posted by Gerry Schultz on 29 Dec 2011, 6:58 p.m.,
in response to message #8 by Monte Dalrymple

Hi Diego, sorry for my delay in responding. I’ve been busy at work and haven’t had time to get back to this thread. I apologize if my “just a few questions...” seems more like an exam. I’m more of a hardware guy and I’m accustomed to the simple, flat addressing space of a PC. The RAM/ROM memory space was always a little weird in the 41 to me as RAM seems more assessable to the user than the ROM (storage registers, program space, key assignments, the curtain, etc) but all the heavy lifting is done by the uP on the ROM side. So, I’ve always thought of 41C RAM as primary as that’s the space I work in.

So, thank you for the explanation on the differences of RAM space verses ROM space in the 41C. I had never thought of RAM as a peripheral with the basic addressing space of the 41C being ROM. On Bank switching, it sounds to me like you’re saying the OS has nothing to do with it, but it’s implemented in individual application modules and are unique to the application, though similar. The alternate banks are located within the module itself and are self-contained.

Angel, thank you for your posting. I agree that Monte’s manual is well written. It’s just that there’s a lot of information packed into it and I really have to study what he’s written. That’s why my original questions were so detailed. I feel like I’m missing some basic information that would help fill the gaps between my knowledge and Monte’s writing. I am very excited about the 41CL and it’s literally a quantum leap from how I thought about how the 41C works to what Monte has put in the 41CL.

Monte, thank you for your posting. I won’t claim to understand what everyone has written yet, but I like the 41C system and have a lot of fun with it. Now that I have just about every application module ever developed for the 41 here in one machine, it’s almost like starting over again.

In reading and re-reading what you say about logical and physical addressing, I’m still confused. As an example, the YMCLR function that is used to initialize 4K blocks of memory to either a user-selected value or copies from another location in memory. Why 6 hex digits for physical addressing? If this function writes to 4096 memory locations and aligns the write to a 4K boundary, then all you would need to specify are hex digits P4 and P5 as P0 through P3 would be zero for the 4K boundary alignment. Unless the user has to put in zeros for hex digits P0 through P3 for this function to work properly (then why have 5 digits in the first place?). As for the logical addressing option in this function, L0 through L3 specifies a 4K block of memory within the 41C RAM/ROM memory space (assuming L0 is the least significant digit). How do you specify which page of the 41C 64K memory space are you referring to and how does the Bank hex digit fit into identifying the starting location (as an offset?)?

I apologize in advance if it seems like I’m nit-picking. I’m trying to understand how to properly set up the alpha register prior to using a function such as this. As another example of my confusion, under your section on Using FORTH41, you poke locations 0x804040 (MMU register for Page 4) with 809A and 0x80470 (MMU register for Page 7) with 809B after disabling the MMU. Yet the Flash addresses for forth4 and forth5 are 0x09A000 and 0x09B000 respectively. I don’t understand. I would think you are specifying where in memory you want the 41C to look for the Forth41 module.

Thank you all again for taking the time to answer my questions. It will make sense to me and I hope you all have enough patience to put up with my struggle to understand this.


Re: Some 41CL Questions
Message #11 Posted by Monte Dalrymple on 29 Dec 2011, 10:49 p.m.,
in response to message #10 by Gerry Schultz

YMCLR uses the same format as YPEEK and YPOKE for the Alpha register contents so that a common subroutine can be used to check the syntax. Characters 8, 7 and 6 are forced to 0s internally before the operation on the 4k page starts.

For the logical address format, L3-L0 are the 16-bit logical address. In this case characters 10, 9 and 8 are forced to 0s internally before the operation on the 4k page starts. In this format character 6 specifies the Bank information. Character 11 (L3) is the 41C "page".

Writing 809A to memory location 0x804040 tells the MMU to enable translation for page 4 (this is the "1" in bit 15), and to substitute the 12-bit value 09A for the "4" in a logical address in page 4. Writing 809B to memory location 0x804070 tells the MMU to enable translation for page 7, and to substitute the 12-bit value 09B for the "7" in a logical address in page 7. So, when fetching the first word of the Forth41 module at logical address 4000 the data at physical address 0x09A000 will actually be fetched instead.

Hope that helps,

Re: Some 41CL Questions
Message #12 Posted by Gerry Schultz on 30 Dec 2011, 12:29 a.m.,
in response to message #11 by Monte Dalrymple

Sure did, Monte. Obviously I miscounted the bits so thank you for the explaination and patience. When I have more questions, I'll let you know.

Thanks, Gerry

Re: Some 41CL Questions
Message #13 Posted by Diego Diaz on 30 Dec 2011, 7:03 a.m.,
in response to message #10 by Gerry Schultz

Hi Gerry,

I've enjoyed a lot while answering your questions... which BTW are perfectly reasonable when looking at RAM & ROM from a "standard" perspective.

And, as a very positive collateral effect, I've learned a lot about CL's memory management and organization by reading Monte's reply so, as usual, this is the point when asking/posting in this forum: keep the info sharing spirit alive! :-)

Enjoy your 41's (whichever "flavour") and best wishes for the New Year!


Re: Some 41CL Questions
Message #14 Posted by Gerry Schultz on 30 Dec 2011, 2:48 p.m.,
in response to message #13 by Diego Diaz

Thank you Diego for your kind words. That's exactly why I posted here. I thought that if I have questions, that others would too. Also, I also like it when my questions prompts others to ask their own and a spirted discussion ensues. So even if my questions look ignorant or stupid, I'll still ask them.

I also appreciate the time and patience everyone expends to answer questions here on this forum. I know that when I composed my questions, I spent an hour or two writing and re-writing them to make sure I was clear and concise on what I was asking about. Just think about the time Monte, Angel, Frido, you and others spend thinking about and responding to all these questions.

So, yes, thank you all for the contributors to this forum for your energy and willingness to add your knowledge and experience to our community. I for one deeply appricate everyone's contributions.


Re: Some 41CL Questions
Message #15 Posted by Massimo Gnerucci (Italy) on 30 Dec 2011, 3:07 p.m.,
in response to message #14 by Gerry Schultz

Just think about the time Monte, Angel, Frido, you and others spend thinking about and responding to all these questions.

So, yes, thank you all for the contributors to this forum for your energy and willingness to add your knowledge and experience to our community. I for one deeply appricate everyone's contributions.

You're not alone Gerry, thank you all for your time and patience.
Happy New Year!


[ Return to Index | Top of Index ]

Go back to the main exhibit hall