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