In the task of making bank switching on the NoV-32 automatic, I have the following code in Page #B (last HEPAX RAM page) on both of the 16K memory banks:

04E  C=0 ALL

15C  R=6

110  LD@R 4

050  LD@R 1

130  LDI S&X

000  HEX:000 (on second bank: 0FF  HEX:0FF)

040  WROM

3E0  RTN

The code works, but it has one (and only one) odd side effect: It messes up my key assignments. Why?

I don't know why that would affect key assignments, but it's possible that I (or someone else) might have a better idea of what's going on if you explained what the code is supposed to do. I don't really understand how writing to the code memory helps to make bank switching automatic.

The usual approach to bank switching is to have switching routines near the end of the page, just below the poll vectors, and code that needs to know which vector is active would normally look at the ROM ID words, which should be different in each bank.

The code simply writes to the address h4100 to swap the two memory banks/blocks of the NoV-32. I do this manyally (through HEXEDIT) all the time. I wanted to have the possibility to switch to the other block from within a user code program.

Hi,

are you sure it is the ML code above which messes up your KA,

or is there any other special code in your FOCAL program?

What happens if you insert a STOP into your FOCAL program,

just before the call to the ML routine,

then do an SST when the program halts there?

Other idea: Is #0FF the suitable constant? I thought it was #111...

One more: Does your FOCAL program reside in one of the simulated HEPAX RAM pages?

And another one (to Diego): Could it be a side effect of the switching itself?

Is there any kind of initialisation when/after switching banks?

Raymond

Hi all,

First, (not because of its importance but just in order to make things clear): the *only* meaningful bit into NoV-32's RAM block selection word (@ H'4100) is the *Less Significant Bit*. So ANY odd word will turn Block #1 (one) ON, and ANY even word will turn Block #0 (zero) ON.

The H'0FF stored after power on is just a reminiscent of the debugging process and could be replaced by H'001. I'm serously thinking in replacing it in the next version of NoV's code to avoid further confusion.

The fact is that NoV-32's Block swapping method was conceived with the idea of being achieved by keyboard input thru HEXEDIT (or any other software able of a WRITE s&x (H'040) instruction) residing *into* NoV-32's internal Flash ROM. (Note you cannot write into NoV-32's RAM from an external module!)

In the user's guide (not accurate regarding the overall process though), it was recommended to power cycle the HP-41 after block swapping.

Apart from that, the only effect of swaping RAM Blocks is that one chip is powered OFF while the other is powered ON. I can't see no side effect form this into user memory registers (where key assignments are stored). However, some actions may be taken by MF code depending on the contents of the polling points in the actived block. Are these polling points all "zeroed"?

Please keep me/us informed of any other relevant info that may concern this issue. I'm now working in the NoV-64 code which deals with four chips *swapping*, and also handles the config word @ H'4100 both to manage RAM (4x16k) and ROM (3x16k) blocks; so I'm the most interested in acquiring as much info as possible on this subject.

Best regards from the Canary Islands.

Diego.

Quote:

---

(Raymond:)
are you sure it is the ML code above which messes up your KA,
or is there any other special code in your FOCAL program?

---

Quote:

---

(Diego:)
Apart from that, the only effect of swaping RAM Blocks is that one chip is powered OFF while the other is powered ON. I can't see no side effect form this into user memory registers (where key assignments are stored). However, some actions may be taken by MF code depending on the contents of the polling points in the actived block. Are these polling points all "zeroed"?

---

This I didn't get. MF? And which polling points?

MF: Main Frame

Polling Points or interrupt vectors: there are some designated locations

near the end of each page where interrupt vectors are located,

which are checked by the associated MF code at certain events,

like key press, ON interrupt, Memory Lost, etc...

Effectively these locations contain either zero (000/NOP)
or a relative jump (JNC -somewhere).

For more details please take a look into the SDK41 manual;-)

Geir:
As I remember [I'm at work and don't have access to my documentation] key assignments are stored in two places:
1) for "internal" commands in one of the upper registers of the first RAM chip [where X,Y,Z,T,alpha, etc. are.
2) for "named" functions: ie. FOCAL programs, ROM based commands and the like a buffer is created in low memory -- the area below where program .END.[the fixed lowest available memory] is stored.
It is unlikely the code snippet you show is corrupting--directly--these areas but when you are returning from the call you are leaving the CPU registers in a specific state. Rather than simply clearing and setting the bits you want a better way would be Call the routine, save the register content you need to change, load address and value, poke the value, restore the register and then return.
Also be aware: a call from the keyboard [I'm assuming you have assigned the MCode routine to a key] takes a different path from calling the routine in a program.

Good luck David

Thanks Raymond, I couldn't have said it better... ;-)

David, you've just remembered me a good teacher I had, he used to repeat about 10 times an hour: "PUSH registers, always PUSH registers into the stack before you CALL *anywhere*... even phoning your girlfriend!". He was not very good making jokes... but certainly a very good teacher.

Cheers

Diego.