Post Reply 
HP-41CL self-update via HP-IL
11-18-2017, 03:36 PM (This post was last modified: 11-21-2017 09:48 PM by Geir Isene.)
Post: #1
HP-41CL self-update via HP-IL
Since my quest to update the HP-41 via HP-IL was split across three threads (due to different questions along the way), I thought it would be better to update those who are interested on this one thread. Here goes:

The solution is working for all ROMs except those "modern" CL-specific roms that uses bits 12 & 13. As far as I understand, those new ROMs loses speed functionality when updated this way. In order to solve this, I am hoping for some MCODE master to create a routine that will read raw, uncompressed (8K) ROMs from mass storage into an HP-41 page where a CL RAM page is plugged (or directly to a CL RAM page if possible).

From the GitHub repository (https://github.com/isene/hp-41cl_update):

"There are two alternative programs on the PC side, both doing exactly the same: "HP-41CL_update.rb" is the Ruby version, while "HP-41CL_update.py" is the Python equivalent. There is one FOCAL program on the HP-41CL side, "FUPDATE".

HP-41CL_update.rb (or HP-41CL_update.py) takes HP-41 ROM files from a folder named "roms" and adds those to a LIF file that can be mounted by pyILPer. The pyILPer is a Java program that can mount LIF files so that an HP-41 can access that file via a PILbox. The "roms" folder must reside in the same folder as the HP-41CL_update.rb (or HP-41CL_update.py) program. The file names of the ROMs to be updated must be prefixed with the HP-41CL address so that the FOCAL program knows where in flash to update the ROMs (only the first three hex numbers are inserted at the beginning of the file name).

Example: You want to update the ISENE.ROM on your HP-41CL. The ISENE.ROM should go to the location "0C9", therefore you rename the rom to 0C9ISENE.ROM and drop it into the folder called "roms". You run HP-41CL_update.rb (or HP-41CL_update.py) and you get a LIF imge called cl_update.lif in the same directory as the HP-41CL_update.rb (or HP-41CL_update.py) program. Mount this LIF file in pyILPer and run the FUPDATE program on the HP-41CL."

Just for fun I decided to create a Python version of the original Ruby program (since pyILPer is already in Python and if you don't want to install Ruby, you can use "HP-41CL_update.py"). This is my first ever Python program and I would welcome any criticism or suggestions for improvements :-)

And from http://www.hpmuseum.org/forum/thread-9456-page-2.html:

"As it is now, you can simply drop the roms in the "roms" folder - but with all the roms you want updated prefixed with the three first location numbers. Example: The ISENE.ROM should go to the location "0C9", therefore you rename the rom to 0C9ISENE.ROM and drop it into the folder called "roms". You run the program and you get a LIF imge called cl_update.lif.

The idea is that the user then mounts this LIF image via pyILPer and then run a FOCAL program (yet to be made) on the HP-41CL and go for dinner."

I also plan to create ready-made LIF files for even easier auto-updates.

After member "jsi" (http://www.hpmuseum.org/forum/user-2921.html) at the speed of sound created "romlif" to add uncompressed ROM images to LIF files (to cater for bits 12 & 13 in "modern roms"), the only missing element is that MCODE routine already mentioned that can read such uncompressed ROMs from mass storage into an HP-41 page (or directy into an HP-41CL RAM page). The romlif is found here: http://www.hpmuseum.org/forum/thread-945...l#pid83407

As you can see from the code on the GitHub repo, the solution concists of a compact Ruby/Python program on the PC side and only 66 FOCAL lines on the HP-41 side.

Please tell me if there is anything you need or want from this solution.
Find all posts by this user
Quote this message in a reply
11-18-2017, 10:05 PM
Post: #2
RE: HP-41CL self-update via HP-IL
It isn't just bits 13/12 that need to be preserved. Both the IMDB and the FLDB use
all sixteen bits in a word.

I don't know anything about HP-IL or HEPAX RAM, so I have some stupid questions:

1. Aren't HP-IL transfers byte-oriented?

2. If the transfers are byte-oriented, where are the bits getting lost? That is, is
it on the PC side where data is put on the IL, is it when data is taken from the IL
and written to RAM, or is it when the data is extracted from the RAM?

Sorry if the questions are stupid.

The UPDAT-3B functions use the CL serial port, but it is just a communications
port, so theoretically it should be possible to substitute some other comm
channel and achieve the same result. I know serial, and this is what the CL
serial port was designed for, so that's what I used. But it should be possible
(and I'm not saying I'm capable of doing it) to substitute something like HP-IL.
Or am I delusional?
Visit this user's website Find all posts by this user
Quote this message in a reply
11-18-2017, 10:11 PM
Post: #3
RE: HP-41CL self-update via HP-IL
Great questions, Monte. I have no answers to your questions since I am less clueful than you in this area. Hoping someone with answers to chime in.
Find all posts by this user
Quote this message in a reply
11-19-2017, 01:57 AM
Post: #4
RE: HP-41CL self-update via HP-IL
Monte, I guess if you use the routines of the UPDAT-3B module and get a hand from Ángel, then it should be a rather simple matter to read from the HP-IL instead of the serial port...
Find all posts by this user
Quote this message in a reply
11-19-2017, 08:20 AM (This post was last modified: 11-19-2017 08:21 AM by Ángel Martin.)
Post: #5
RE: HP-41CL self-update via HP-IL
(11-19-2017 01:57 AM)Geir Isene Wrote:  Monte, I guess if you use the routines of the UPDAT-3B module and get a hand from Ángel, then it should be a rather simple matter to read from the HP-IL instead of the serial port...

Everything *but* simple, IMHO. In fact I wouldn't know where to start... other than studying the READROM/WRTROM code to see how's done for the HEPAX case.

The starting point is very weak: what's the file format? Not knowing that makes the task a horrible trial-and-error swamp.

Like Monte, I'm also not saying I'm capable of doing it!
Find all posts by this user
Quote this message in a reply
11-19-2017, 11:51 AM
Post: #6
RE: HP-41CL self-update via HP-IL
It's a raw ROM format, 8192 bytes, uncompressed just like you find it on the PC put into a LIF image so that it can be mounted via the PILbox.
Find all posts by this user
Quote this message in a reply
11-19-2017, 07:41 PM
Post: #7
RE: HP-41CL self-update via HP-IL
Of course it isn't a fundamental problem to use HP-IL instead of a serial connection.
The data transfer is byte-oriented, and you can transfer whatever you want.
But you can't reuse easily what already exists; The old ROM writing and reading functions often only use 10 bits for storage and define a compact packed format.
And in the final step, when these functions transfer the word to the ROM page (HEPAX-style RAM), they use the "writ s&x" machine command that moves 10 bits only, of course.

The idea of Geir was to store all ROM images in a large lif file.
Then you would have to write your own File-Read function, which is not that easy, as Angel says; f.e. you have to find out where the ROM image is located on the mass medium, and you have to manage a file pointer and know how to tell the IL device that it should set and advance his read pointer and so on. The relatively easier way could be to investigate existing file i/o functions and extract what is needed; maybe not too much has to be adjusted, not much more than the file length, the word length and the write function to the final destination ( CL RAM page instead of page in the HP-41 address space).

Another approach ( Monte is thinking of) would be to use the PC as an HP-IL controller (similar to its role as a controller of the serial data transfer). For that you need software like the tools coming with the HP-IL ISA card, or ILCtrl from the PIL-Box software suite. Then you would have low level access to HP-IL protocol ( for sending and receiving IL frames), and you could set up your own communication protocol between 41 and pc. Not that easy, especially the HP 41 part ( that has to be realized in mcode for speed reasons); certainly more work to do than implementing just a 16-bit HP-IL read file function, but maybe faster and more direct ( you save the additional step of creating the lif image for the rom modules.)

I'd recommend the easier LIF file based approach; since an auto update program will run unattended, execution time is not such a big concern.
Find all posts by this user
Quote this message in a reply
11-19-2017, 08:01 PM
Post: #8
RE: HP-41CL self-update via HP-IL
The benefit of the LIF file approach is that we could host date stamped LIF images for easy upgrades. A person could take the next released LIF image and run that for upgrading all new modules since the last LIF image release (much like Ubuntu releases).
Find all posts by this user
Quote this message in a reply
11-21-2017, 07:21 PM
Post: #9
RE: HP-41CL self-update via HP-IL
FYI: Håkan Thörngren has created an MCODE routine that reads an 8K ROM from a LIF image on a mass storage device via HP-IL to a RAM page on the HP-41CL. It needs testing... and I'm pondering wheter I should take that plunge, considering my serial connector for my CL is broken (and thus I have no backup if something goes wrong). Given that tests work out, we will have a full working solution for updating the HP-41CL via HP-IL/PILbox :-D
Find all posts by this user
Quote this message in a reply
11-21-2017, 07:37 PM
Post: #10
RE: HP-41CL self-update via HP-IL
(11-21-2017 07:21 PM)Geir Isene Wrote:  FYI: Håkan Thörngren has created an MCODE routine that reads an 8K ROM from a LIF image on a mass storage device via HP-IL to a RAM page on the HP-41CL. It needs testing... and I'm pondering wheter I should take that plunge, considering my serial connector for my CL is broken (and thus I have no backup if something goes wrong). Given that tests work out, we will have a full working solution for updating the HP-41CL via HP-IL/PILbox :-D

If it transfers it to a RAM page, it should only affect RAM. Unless there is something
really messed up with the memory addressing, it will only mess up the destination
RAM page.
Visit this user's website Find all posts by this user
Quote this message in a reply
11-21-2017, 08:21 PM
Post: #11
RE: HP-41CL self-update via HP-IL
To verify the transfer, try uploading a ROM from a LIF file to a sector buffer and comparing the uploaded image to the one in flash. Take for example the flash image for CHEMUSER on page 0x01A. If your target RAM page is 812, then you can use the following commands from the YFNF 41CL Memory Functions

"01A000"
STOXP
"812000"
STOYP
YDIFF?

The display should increment through the whole 01A000 - 01AFFF range before stopping on a difference between flash and RAM at 01B000 on the next page.

Can't wait to see Håkan's work! Can it transfer a page to a LIF file as well?
~Mark
Find all posts by this user
Quote this message in a reply
11-21-2017, 08:37 PM
Post: #12
RE: HP-41CL self-update via HP-IL
(11-21-2017 07:21 PM)Geir Isene Wrote:  FYI: Håkan Thörngren has created an MCODE routine that reads an 8K ROM from a LIF image on a mass storage device via HP-IL to a RAM page on the HP-41CL. It needs testing...
Does this MCODE routine also support larger LIF image files than the 130K tape drive? That's short when handling 8K rom image files.

The layout of the LIF images allows for a maximum medium size of 16 GB. You can create empty large LIF image files as follows (undocumented feature):
Code:

lifinit -m hdrive16 <name of lif image file> <number of directory entries> (16MB)
lifinit -m hdrive8  <name of lif image file> <number of directory entries> (8MB)
lifinit -m hdrive4  ... (4MB)
lifinit -m hdrive2  ... (2MB)

Please indicate that the Q&D utility "romlif" works as expected to include it in the LIFUTILS release.
Find all posts by this user
Quote this message in a reply
11-21-2017, 08:59 PM
Post: #13
RE: HP-41CL self-update via HP-IL
(11-21-2017 08:37 PM)jsi Wrote:  
(11-21-2017 07:21 PM)Geir Isene Wrote:  FYI: Håkan Thörngren has created an MCODE routine that reads an 8K ROM from a LIF image on a mass storage device via HP-IL to a RAM page on the HP-41CL. It needs testing...
Does this MCODE routine also support larger LIF image files than the 130K tape drive? That's short when handling 8K rom image files.

The layout of the LIF images allows for a maximum medium size of 16 GB. You can create empty large LIF image files as follows (undocumented feature):
Code:

lifinit -m hdrive16 <name of lif image file> <number of directory entries> (16MB)
lifinit -m hdrive8  <name of lif image file> <number of directory entries> (8MB)
lifinit -m hdrive4  ... (4MB)
lifinit -m hdrive2  ... (2MB)

Please indicate that the Q&D utility "romlif" works as expected to include it in the LIFUTILS release.

It works as intended :-)

Also, the MCODE routine should be wholly agnostic to the LIF Image size.

As far as reversing the process - Håkan's routine does not write to the LIF Image. There should be different routine for that in any case.
Find all posts by this user
Quote this message in a reply
11-21-2017, 09:00 PM
Post: #14
RE: HP-41CL self-update via HP-IL
(11-21-2017 08:21 PM)mfleming Wrote:  To verify the transfer, try uploading a ROM from a LIF file to a sector buffer and comparing the uploaded image to the one in flash. Take for example the flash image for CHEMUSER on page 0x01A. If your target RAM page is 812, then you can use the following commands from the YFNF 41CL Memory Functions

"01A000"
STOXP
"812000"
STOYP
YDIFF?

The display should increment through the whole 01A000 - 01AFFF range before stopping on a difference between flash and RAM at 01B000 on the next page.

Can't wait to see Håkan's work! Can it transfer a page to a LIF file as well?
~Mark

Mark, I bet you're the only user who read the 41CL Memory Functions manual
and knows how to do this!

Another (quicker) way is to just do YCRC on both pages and compare the result.
This will indicate same/different, and then you can do the compare if there is
a difference that you want to find.
Visit this user's website Find all posts by this user
Quote this message in a reply
11-21-2017, 09:21 PM
Post: #15
RE: HP-41CL self-update via HP-IL
I was about to start trying it out, but my 41CL does not want to cooperate.

The calculator appear to work, but if I insert the HP-IL module and then press CAT 2 it freezes with a kind of flickering DATA ERROR in the display.

Inserting the same HP-IL module in a Halfnut HP-41CX och doing the same results in the expected CAT 2 behavior.

Is there a procedure to reset it, or what to do?

Håkan
Find all posts by this user
Quote this message in a reply
11-21-2017, 10:05 PM
Post: #16
RE: HP-41CL self-update via HP-IL
(11-21-2017 09:21 PM)hth Wrote:  Is there a procedure to reset it, or what to do?

RTFM was the obvious solution, HP-IL cannot be used before MMU is set up.

Håkan
Find all posts by this user
Quote this message in a reply
11-21-2017, 10:50 PM
Post: #17
RE: HP-41CL self-update via HP-IL
(11-21-2017 09:00 PM)Monte Dalrymple Wrote:  Mark, I bet you're the only user who read the 41CL Memory Functions manual
and knows how to do this!

I played around with these functions extensively while trying to work out a way to capture and process data from a GPS module via the serial port. I do have a minor question/bug report regarding some of the functions in the YFNF module. I was trying to copy data from one buffer to another using the sequence

Code:

YPEEK+
XP<>YP
YPOKE+
XP<>YP

The poke command should process the data in Alpha returned by the peek command, but the copy was failing because the XP<>YP command overwrites the content of Alpha with the new value of XP. My code ended up writing the low order four digits of the destination address to the destination word instead of the desired data. Not quite what I intended!

Should the pointer register commands alter Alpha in this way? Most might be harmless since they wouldn't necessarily occur between the peek and poke commands, but perhaps they should be silent and let the programmer use RCLXP to return the pointer value to Alpha if needed. Or perhaps they could just replace the first six characters of Alpha (imagine YPEEK+, XP+X, YPOKE+ for instance).

At any rate, to resolve the buffer copy I had to Alpha shift and Alpha store the data value to a register, then Alpha recall it before the poke command. Three extra instructions!

Just my observations,
~Mark
(The one without the beard)
Find all posts by this user
Quote this message in a reply
11-21-2017, 11:19 PM
Post: #18
RE: HP-41CL self-update via HP-IL
(11-21-2017 10:50 PM)mfleming Wrote:  
(11-21-2017 09:00 PM)Monte Dalrymple Wrote:  Mark, I bet you're the only user who read the 41CL Memory Functions manual
and knows how to do this!

I played around with these functions extensively while trying to work out a way to capture and process data from a GPS module via the serial port. I do have a minor question/bug report regarding some of the functions in the YFNF module. I was trying to copy data from one buffer to another using the sequence

Code:

YPEEK+
XP<>YP
YPOKE+
XP<>YP

The poke command should process the data in Alpha returned by the peek command, but the copy was failing because the XP<>YP command overwrites the content of Alpha with the new value of XP. My code ended up writing the low order four digits of the destination address to the destination word instead of the desired data. Not quite what I intended!

Should the pointer register commands alter Alpha in this way? Most might be harmless since they wouldn't necessarily occur between the peek and poke commands, but perhaps they should be silent and let the programmer use RCLXP to return the pointer value to Alpha if needed. Or perhaps they could just replace the first six characters of Alpha (imagine YPEEK+, XP+X, YPOKE+ for instance).

At any rate, to resolve the buffer copy I had to Alpha shift and Alpha store the data value to a register, then Alpha recall it before the poke command. Three extra instructions!

Just my observations,
~Mark
(The one without the beard)

I was thinking of keyboard execution rather than program execution when I set it
up that way, like the display shows the X register. I could change it to be silent
(as far as the ALPHA) register in program mode, or I could add a mode control to
make it silent, or I could add a mode control to make YPEEK+ or YPOKE+ use a
different pointer than X. Then you could use X for YPEEK+ and Y for YPOKE+. I
didn't really think of the byte-by-byte copy case when I was designing the
functions, more for serial/buffer case.
Visit this user's website Find all posts by this user
Quote this message in a reply
11-21-2017, 11:47 PM
Post: #19
RE: HP-41CL self-update via HP-IL
(11-21-2017 11:19 PM)Monte Dalrymple Wrote:  I could change it to be silent (as far as the ALPHA) register in program mode, or I could add a mode control to make it silent, or I could add a mode control to make YPEEK+ or YPOKE+ use a different pointer than X.

Perhaps condition Alpha register usage by the keyboard mode versus run mode context? If commands are executed from a program, then commands could use the X register instead of the Alpha register for addresses or data. A program could manipulate pointer values, swap bytes in words, or perform other operations without going back and forth to Alpha. All fairly useful to FOCAL programmers like me!

~Mark
Find all posts by this user
Quote this message in a reply
11-22-2017, 05:01 AM
Post: #20
RE: HP-41CL self-update via HP-IL
(11-21-2017 08:21 PM)mfleming Wrote:  Can't wait to see Håkan's work! Can it transfer a page to a LIF file as well?
~Mark

Is there a need to save a page to LIF too? Are not all these ROM images available on the host side already?

Håkan
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)