Executing FOCAL programs from ROM vs. RAM

[David Hayden]

I've been reading about the 41C processor architecture and I'm hoping someone can explain how it executes FOCAL programs out of RAM vs. ROM

As I understand the processor, it has separate data and instruction address spaces. Separate CPU instructions are needed to access RAM vs. ROM.

Instructions use a 16 bit address where each address specifies a 10-bit word. ROMs placed in the plug-in ports get mapped to areas of this address space.

Data uses a 12-bit address where each address specifies a 56-bit register. Presumably RAM modules on the 41C get mapped into the data space by some control circuitry at power-on.

So here are my questions.

Since RAM and ROM are accessed using different CPU instructions, it seems like the processor would need two different methods to read FOCAL instructions - one when the program is in RAM and another when it's in ROM. Is this true? If not, then how does it work?

And what about the FOCAL program pointer and return stack in registers a & b? They are 16 bits. I assume those are ROM addresses when executing from ROM but what about when executing from RAM?

Thanks,
Dave

[hth]

(04-10-2019 10:09 PM)David Hayden Wrote:  Since RAM and ROM are accessed using different CPU instructions, it seems like the processor would need two different methods to read FOCAL instructions - one when the program is in RAM and another when it's in ROM. Is this true? If not, then how does it work?

Yes, it uses different ways to read user code instructions. One internal CPU flag (10) is used to tell if the program pointer is in ROM or RAM, which speeds up the decision.

RAM program bytes need slightly trickier decoding as it is a register address plus offset inside the register. A clever trick based on putting together an indirect jump based on that offset is used, but it is still slower than when running from ROM.

So the PC is really 17 bits.

Quote:And what about the FOCAL program pointer and return stack in registers a & b? They are 16 bits. I assume those are ROM addresses when executing from ROM but what about when executing from RAM?

Not all ROM addresses are possible for user code. The lower addresses are set aside for the internal ROMs, no user code exists in them. The 17 bit PC is compressed to 16 bits when stored on the stack, taking advantage of this. A compressed RAM address uses 12 bits in the return stack (plus a 0 upper nibble), a ROM address is 16 bits with a non-zero upper nibble.

[Ángel Martin]

(04-11-2019 04:41 AM)hth Wrote:  Not all ROM addresses are possible for user code. The lower addresses are set aside for the internal ROMs, no user code exists in them. The 17 bit PC is compressed to 16 bits when stored on the stack, taking advantage of this. A compressed RAM address uses 12 bits in the return stack (plus a 0 upper nibble), a ROM address is 16 bits with a non-zero upper nibble.

Is that so? I may not fully understand your comment about the lower addresses, how low do you mean? FOCAL programs run happily on the printer ROM (page 6) and also in the Library#4 (page 4).

I need to ruminate your comments on the 17-bit compressed to 16; as far as I knew the RAM addresses are in the format "BRRR", i.e. always 16 bits. But you know this much better than me, your RAMED function is to this day the best implementation known to man on the subject!

ÁM

PS. I admit that the addresses game is one of my least well understood, but I seem to remember that when we were experimenting on an extension of the PC (using an multi-byte XEQ/RTN) we were close to coming up with a working model...

[hth]

I just had a quick look. A return address is checked for ?xxx, if that '?' nibble is non-zero, it is assumed to be ROM. This means that execution of user programs (FOCAL/RPN) is not possible in ROM page 0 (first 4K). It can very well exist in page 1 and up, but as you know the first that has some is page 6.

It seems from a quick look that you can execute in higher RAM addresses, but it cannot store that on the return stack, as it is compressed, which is why I believe it is limited to 1FF which is 9 bits and 3 bits to tell the byte position (7 locations needed).

Yes, both RAM and ROM PC addresses are 16-bit, but it has to separate ROM from RAM execution, which is why flag 10 is used, so I just called it a 17-bit address...

I think it would be reasonable simple to grow extended memory to be bigger, though some code would need to change as it is cheating, taking advantage of that if it was not page 2, it can only be 3. Things like that.

However, I have not really found any big need for such large extended RAM memory. I have never filled much more than the first part of it. I even bought a couple of those extended memory modules and have them plugged in, but I do not think I ever really used them.

4K ROM pages are much more useful to me.

[David Hayden]

Thanks guys.

I'll call the pointer to the next FOCAL instruction the interpreter pointer (IP) to distinguish it from the CPU's program counter (PC). I'd argue that the IP is 16 bits where the top 4 bits indicate whether the program is in RAM or ROM. The fact that the CPU uses flag 10 to indicate whether those bits are 0 is an optimization.

I see that I wrote incorrectly about the RAM addresses. The max address is 0x3ff which is 10 bits, not 12. But it sounds like FOCAL programs must reside within the bottom half of the address space (0x000-0x1ff). That's because when executing from RAM there are only 12 bits available to specify a byte. 3 are used to indicate the byte within a register, leaving 9 to select a register within RAM.

So if I understand right, it gets the next byte in the FOCAL program like this C pseudo-code:

Code:

if (flag10) {   // flag10 true of top 4 bits of IP are non-zero
    // Program is in ROM
    word = readRomWord(IP);
    byte = word & 0xff;    // & is bit-wise AND. Truncates 10-bit word to 8 bits.
} else {
   // Program is in RAM
   byteOffset = IP & 7;  // shave off lower 3 bits for byte offset
   RAMaddr = IP >> 3;  // Get the address within RAM. >> is right shift
   register = readRamRegister(RAMaddr);
   byte = getNthByteInRegister(register, byteOffset);
}
// Now "byte" contains the next byte of the FOCAL program.

[hth]

Something like that pseudo code yes.

I have not bothered to keep in my mind exactly how it represent the byte offset in RAM, I look things like this up as needed and there are nice support routines provided making it. The source for HP-41 is a very well written piece of software, worth studying.