Threaded Mode | Linear Mode

hth · 09-30-2019, 02:39 AM

I have made an OS update for the HP-41CL and wonder if there is anyone interested in beta testing it, before I release it to the general public? I have it running on my own HP-41CL and it seems to work fine so far.

The key feature is that it gives 3405 registers of extended memory. There are also a couple of bug fixes.

The detailed release notes can be found here https://drive.google.com/open?id=1GarWvk...iRsXyAwgLP

If you are interested and think you will try it out, drop me a PM and I will provide a download link.

mfleming · 09-30-2019, 02:29 PM

This looks like an excellent extension. What did you have in mind for testing? Module compatibility? HP-IL or printer testing?

Any chance of also adding Angel's ED patch?
https://www.hpmuseum.org/forum/thread-8775.html

~Mark (PM sent)

hth · 09-30-2019, 05:50 PM

(09-30-2019 02:29 PM)mfleming Wrote: This looks like an excellent extension. What did you have in mind for testing? Module compatibility? HP-IL or printer testing?

Just do what you normally do. Try it with your favourite modules. People walk different paths, which tend to expose issues. I also want to see that it works for others than me. It can probably be a good idea to test any relevant module that provides functionality for extended memory. I have really no idea who they are, CCD perhaps?

I have played a bit with the time module, some automated X-memory tests, HP-IL simulated drive, printer, some modules including Ladybug which fiddles quite a lot with basic OS behavior.

Quote:Any chance of also adding Angel's ED patch?
https://www.hpmuseum.org/forum/thread-8775.html

I can include an extension like that to ED.

To enable the extra extended memory you need to first wipe the current extended memory, either by clearing it (zapping the register at address 040 hex) or by a master clear. There is no longer any code to handle plugged in and out X-memory modules or different plug-in order. Instead it sets up all page links in one go when you first use extended memory. Whether this is needed is determined by inspecting the contents of register 040.

Ángel Martin · 09-30-2019, 09:05 PM

See if you can try it with the CL Expanded Memory ROM (mnemonic XPMM). Manual available here: http://systemyde.com/hp41/documents.html (It needs the Library#4 as well of course...

It uses the blocks at 801, 802 and 803 for direct register access or as a bulk backups, is that compatible with your extended X-Mem?

mfleming · 10-01-2019, 12:58 AM

I have the (un)enviable talent for breaking things without even trying, so I'll give it a go and email anything I find.

~Mark

hth · 10-01-2019, 01:03 AM

(09-30-2019 09:05 PM)Ángel Martin Wrote: See if you can try it with the CL Expanded Memory ROM (mnemonic XPMM). Manual available here: http://systemyde.com/hp41/documents.html (It needs the Library#4 as well of course...

It uses the blocks at 801, 802 and 803 for direct register access or as a bulk backups, is that compatible with your extended X-Mem?

The additional extended memory uses the 400-EFF range of internal RAM. I left the last page F00-FFF free for future use at the moment.

Looking at the 41CL memory map I get the impression that this the same range as you are talking about here? Do you access it the usual Nut way, or do you use the NEWT specific absolute addressing (wcmd)?

Sylvain Cote · 10-01-2019, 01:50 AM

PM sent!

hth · 10-01-2019, 02:10 AM

(10-01-2019 12:58 AM)mfleming Wrote: I have the (un)enviable talent for breaking things without even trying, so I'll give it a go and email anything I find.

~Mark

That's the spirit! Smile

Ángel Martin · (This post was last modified: 10-01-2019 06:32 AM by Ángel Martin.)

(10-01-2019 01:03 AM)hth Wrote: The additional extended memory uses the 400-EFF range of internal RAM. I left the last page F00-FFF free for future use at the moment.

Looking at the 41CL memory map I get the impression that this the same range as you are talking about here? Do you access it the usual Nut way, or do you use the NEWT specific absolute addressing (wcmd)?

Yes, it's the same range so there's an incompatibility in the designs.

The direct access functions (YSTO, YRCL, etc.) utilize the range 400-7FF (1,024 additional registers). For this I use the standard Nut way , i.e. RAMSLCT, READATA, etc. For block backup functions (YBK-ST, YBK-MM, YBK0XM, etc.) I use the WCMD though, also in the same memory range. Finally, the FOCAL routines in the same module can also reach to the upper pages (800-FFF), also for back-up purposes only.

Besides the CL Expanded Mem ROM I also tap into the expanded memory zone in the SandMatrix, to extend the storage capacity of Matrices up to 50x50 linear systems for example. For the extensions to the Matrix functions (in the SandMatrix) I utilize the three upper blocks, so from 400 to FFF. The method I used was also the standard Nut way, since the starting point were the original matrix routines - modified to allow the expanded ranges.

So it's important to make this known to the adventurous users, warning them of overlapping use of the same memory resources. To quote a wise person: "with power comes responsibility"

PS.- How about a fail safe mechanism to restore the standard X-Mem layout? Will this only involve the control register at 040, or will the others also be impacted? My first impression is that it should be very easy to write a small MCODE routine to restore the "standard", simply re-writing those registers with the 600-Registers configuration used by the CL.

PPS.- BTW this is a great enhancement, and brings me renewed interest into the ultimate hack to the OS: extending the MAIN memory to use the 000-3FF range - a much more difficult feat since the FOCAL RTN addresses scheme (stored in registers a and b) will need to be substantially altered.

Sylvain Cote · 10-01-2019, 11:07 AM

Hello Håkan,

I have done the following procedure, but to my surprise it is not working.
I have to leave for work and I will check what I have missed or done wrong tonight.

Sylvain

Reset MMU

Code:

MMUDIS MMUCLR TURBO50 "YFNX" PLUG1L SERINI BAUD48 MMUEN
Upload ROM into the 41CL

Code:

PC: java -jar clupdate-1.1.0.jar --upload NUT0.rom /dev/tty.usbserial 4800 // File NUT0.rom loading ... done [YCRC=0x74B6DF77 Rev:2019-09-30] CL: "820000-0FFF" YIMP "820" YCRC // 74B6DF77 good PC: java -jar clupdate-1.1.0.jar --upload NUT1.rom /dev/tty.usbserial 4800 // File NUT1.rom loading ... done [YCRC=0x7C4D0C0C Rev:2019-09-30] CL: "821000-0FFF" YIMP "821" YCRC // 7C4D0C0C good PC: java -jar clupdate-1.1.0.jar --upload NUT2.rom /dev/tty.usbserial 4800 // File NUT2.rom loading ... done [YCRC=0xAFF5CC14 Rev:2019-09-30] CL: "822000-0FFF" YIMP "822" YCRC // AFF5CC14 good PC: java -jar clupdate-1.1.0.jar --upload XFUNS3.rom /dev/tty.usbserial 4800 // File XFUNS3.rom loading ... done [YCRC=0x07A3A082 Rev:2019-09-30] CL: "823000-0FFF" YIMP "823" YCRC // 07A3A082 good PC: java -jar clupdate-1.1.0.jar --upload TIME.rom /dev/tty.usbserial 4800 // File TIME.rom loading ... done [YCRC=0xDC5F9A0A Rev:2019-09-30] CL: "824000-0FFF" YIMP "824" YCRC // DC5F9A0A good PC: java -jar clupdate-1.1.0.jar --upload XFUNS5.rom /dev/tty.usbserial 4800 // File XFUNS5.rom loading ... done [YCRC=0x3D148A8E Rev:2019-09-30] CL: "825000-0FFF" YIMP "825" YCRC // 3D148A8E good
Setup MMU memory

Code:

"80400C-8820" YPOKE "80401C-8821" YPOKE "80402C-8822" YPOKE "80403C-8823" YPOKE "804050-8824" YPOKE "804058-8825" YPOKE
Validating MMU memory

Code:

"80400C-0000" YPEEK // "80400C-8820" good "80401C-0000" YPEEK // "80401C-8821" good "80402C-0000" YPEEK // "80402C-8822" good "80403C-0000" YPEEK // "80403C-8823" good "804050-0000" YPEEK // "804050-8824" good "804058-0000" YPEEK // "804058-8825" good
Activating Alternate 41OS

Code:

// unplugging serial cable MMUEN // unplugging often deactivate MMU "NEW OS" MAPEN // activating alternate 41OS
Checking Alternate 41OS version with Diagnostic ROM

Code:

Inserting ROM Press "-" // 0:NFL 1:D=,C ... mmm not working :-(

hth · 10-01-2019, 04:19 PM

(10-01-2019 11:07 AM)Sylvain Cote Wrote: I have done the following procedure, but to my surprise it is not working.
I have to leave for work and I will check what I have missed or done wrong tonight.

With some help from Monte, I came up with the following.

First load them to a sequence of RAM pages:

820 NUT0
821 NUT1
822 NUT2
823 XFUNS3
824 TIME
825 XFUNS5

(I use HP-IL, so the commands I use to load are different compared to the serial port.)

Then "%820 0" PPLUG and "*824 5" PPLUG sets up the mapping and finally MAPEN to enable it.

Note the '%' and '*' characters.

MAPEN is needed every time you turn the 41CL on (the actual configuration seems to stay).

I found it a bit tedious with MAPEN after a while, so I flashed it using the excellent Update module. I always feared flashing in the past, but the Update module makes it very simple. However, be very confident that you know what you are doing and test the new images a bit before you even consider flashing it.

hth · 10-01-2019, 04:38 PM

(10-01-2019 06:09 AM)Ángel Martin Wrote: So it's important to make this known to the adventurous users, warning them of overlapping use of the same memory resources. To quote a wise person: "with power comes responsibility"

Yes, be careful and know what you are doing.

Quote:PS.- How about a fail safe mechanism to restore the standard X-Mem layout? Will this only involve the control register at 040, or will the others also be impacted? My first impression is that it should be very easy to write a small MCODE routine to restore the "standard", simply re-writing those registers with the 600-Registers configuration used by the CL.

That is a possibility. Setting the [5:3] field to 000 in register 301 should suffice. Then perhaps it could use a check to see if page 4 and beyond are actually in use, and in that case perhaps prevent it until you purge some files. Restoring it would mean putting back the links in address 301, 400, 500 and so on.

Quote:PPS.- BTW this is a great enhancement, and brings me renewed interest into the ultimate hack to the OS: extending the MAIN memory to use the 000-3FF range - a much more difficult feat since the FOCAL RTN addresses scheme (stored in registers a and b) will need to be substantially altered.

Return addresses and the non-contiguous memory in page 3 and 4 are the main issues. Another issue is that it may have subtle incompatibilities with existing instructions that fiddle with the return registers (synthetic and MCODE).

Sylvain Cote · (This post was last modified: 10-01-2019 06:44 PM by Sylvain Cote.)

(10-01-2019 06:09 AM)Ángel Martin Wrote: extending the MAIN memory to use the 000-3FF range - a much more difficult feat since the FOCAL RTN addresses scheme (stored in registers a and b) will need to be substantially altered.

Good point, I will have to be careful not to execute compiled program in extended memory or at least the ones higher than 3FF.

mfleming · 10-01-2019, 05:21 PM

A minor addendum to the setup instructions. I found I had to do an UNLOCK for pages 0 to 3 before the PPLUG would work. I've also backed up the extended memory to RAM, just in case

Code:

"800>840"  YMCPY   ; May or may not be a good idea!

"801>841"  YMCPY

"802>842"  YMCPY

"803>843"  YMCPY

I'll do the same for the patched O/S XMEM registers to 844-847. Once done, perhaps a pair of O/S switcher programs for housekeeping?

Sylvain Cote · (This post was last modified: 10-01-2019 07:43 PM by Sylvain Cote.)

(10-01-2019 04:19 PM)hth Wrote: With some help from Monte, I came up with the following.
First load them to a sequence of RAM pages:
820 NUT0
821 NUT1
822 NUT2
823 XFUNS3
824 TIME
825 XFUNS5
Then "%820 0" PPLUG and "*824 5" PPLUG sets up the mapping and finally MAPEN to enable it.
MAPEN is needed every time you turn the 41CL on (the actual configuration seems to stay).

ok, it seems to work.

Test machine: 41CLv2 - FDBVER? show 09/04/2019 (M/D/Y)

Bug #1 : EMROOM only report 124 registers

Code:

memory lost         EMROOM  // 600 registers - OK  - original  41OS

MMUEN               EMROOM  // 600 registers - OK  - original  41OS

MAPEN               EMROOM  // 124 registers - BUG - alternate 41OS

"ABC"   10  CRFLD   EMROOM  // 112 registers - BUG - alternate 41OS

OFF     ON          EMROOM  // 588 registers - OK  - original  41OS

MAPEN               EMROOM  // 112 registers - BUG - alternate 41OS

MAPDIS              EMROOM  // 588 registers - OK  - original  41OS

Bug #2 : EMROOM registers report inconsistent (starting from previous setup)

Code:

OFF                         // insert CCD module

ON                  EMROOM  // 588 registers - OK  - original  41OS

MAPEN               EMROOM  // 112 registers - BUG - alternate 41OS

ASN "FACT" -15              // create a key asignment

"MYK"   SAVEK       EMROOM  // 585 registers - OK  - alternate 41OS - inconsistent with previous behaviour

MAPDIS              EMROOM  // 585 registers - OK  - original  41OS

MAPEN               EMROOM  // 585 registers - OK  - alternate 41OS - inconsistent with previous behaviour

Code:

"MYK"   PURFL       EMROOM  // 588 registers - OK  - alternate 41OS

MAPDIS              EMROOM  // 588 registers - OK  - original  41OS

MAPEN               EMROOM  // 588 registers - OK  - alternate 41OS

OFF     ON          EMROOM  // 588 registers - OK  - original  41OS

MAPEN               EMROOM  // 588 registers - OK  - alternate 41OS

memory lost         EMROOM  // 600 registers - OK  - original  41OS

MMUEN               EMROOM  // 600 registers - OK  - original  41OS

MAPEN               EMROOM  // 124 registers - BUG - alternate 41OS

Sylvain

hth · (This post was last modified: 10-01-2019 08:14 PM by hth.)

(10-01-2019 07:39 PM)Sylvain Cote Wrote: ok, it seems to work.

[.. bugs ..]

Try without mixing NFL and new routines. After memory lost, perform MAPEN, then EMROOM. The first function that detects that extended memory has not been initialized will set it up. (If that fails, try the PPLUG commands again, I had one case where it managed to have a partial mapping between RAM and flash which caused weird problems.)

You will not be able to jump back and forth between the NFL code and the new one. The reason is that the NFL code makes lots of assumptions based on that there are up to two possible extended memory modules. It will just "know" certain invariants like if the module is not 2xx, then it can only be 3xx. While it is flexible in that that extended memory modules can be (physically) plugged in and out (which the new code does not support), it is not at all flexible with additional memory pages. Another issue is that the link registers between modules are 040, 201 and 301 in the NFL code. That is still true, but now it also adds in 400, 500 and so on. That a link register can be anything other than x01 outside the base module is nothing the NFL routines can handle. There are also assumptions about the top register of a module that is also invalid from page 4 and up. I did it this way to utilize every possible register, there are no gaps from page 4 and up.

I suspect the CCD ROM has copied the NFL routines and does not call the entry points in 41CX, which is probably to be expected as it wants to work with all 41 models, 41C/CV/CX.

Sylvain Cote · 10-01-2019, 09:11 PM

You were right, one of the PPLUG did not worked it seems, EMROOM correctly report 3405 registers now.

I have plugged the Auto/Start module (AUTO) in port 9 and the following program activate the alternate OS at each power on

Code:

LBL "RECOVER"

MAPEN

END

Sylvain

Ángel Martin · (This post was last modified: 10-02-2019 04:44 AM by Ángel Martin.)

(10-01-2019 08:14 PM)hth Wrote: I suspect the CCD ROM has copied the NFL routines and does not call the entry points in 41CX, which is probably to be expected as it wants to work with all 41 models, 41C/CV/CX.

That's actually correct, the CCD and derivatives like the OSX3 have their own way to enumerate CAT-2, CAT-4, and CAT-6.
I assume this makes them somehow incompatible with the alternative OS as well...

hth · 10-02-2019, 04:56 AM

(10-02-2019 04:43 AM)Ángel Martin Wrote: That's actually correct, the CCD and derivatives like the OSX3 have their own way to enumerate CAT-2, CAT-4, and CAT-6.
I assume this makes them somehow incompatible with the alternative OS as well...

Among those I would suppose only CAT-4 is really affected as it uses NFL style routines to step in the extended memory.

Basically it means CCD and derivatives are incompatible with this OS.

hth · 10-06-2019, 08:55 PM

Regarding this lower and special characters in ED.

I have added support for it, but I also rearranged the code a bit to make it shorter. However, I am not sure everything works as expected. Lower case and many obvious special characters works, I can enter them and ARCLREC then PRA it to the printer. Then there are some that I do not understand what they are supposed to be. Pi is a star burst and basically a checkered square when printed?

How to test it properly?

(I assume the second fix to get it display properly should not be applied as it requires a Halfnut display which we do not have on the HP-41CL.)