How to make a custom HP-41 rom for the rest of us

[Gene]

Ok, so I hope this thread can turn into a tutorial or at least a crushing of my dream rom ideas. We have lots of great roms available for the HP 41CL and emulators.

Sadly in some cases, I believe there are some OS extension functions that are scattered through various roms that I'd like to have put into one rom. Selfish, yes. :-)

My list of functions taken from various roms is presented in the PDF below.

Gene's Dream Extension Rom

Most of these already exist. They include functions like X>1? DDATE, X/E3, X<Z? and lots of others I would really like to have always available in one place. Makes it much easier to write programs containing these types of things if they are always available like the PowerCL and OSX3 roms are to me.

A couple of exceptions are the INC and DEC functions which used to be in an earlier version of the Sandmath roms, but were dropped for space reasons.

The rest come from the GJM, PK, TVM, Extended Statistics, or Card reader roms.

I know this is MY wish list. Question is:

1) How would I go about trying to make this rom? How would I copy the mcode routines from various roms and assemble them into one rom image?

2) What is needed to do this?

3) What are the steps? Anyone have a dummies guide?

4) Or, after helping answer these questions, if it is too complicated for people like me to do :-) does anyone feel like helping a guy out?

If anyone does, I will sing any song you like in my presentation at HHC 2016 for my youtube glory. Ha ha.


Basic Point: What is the procedure / steps for someone to make a custom rom on their own for the HP 41?

[Monte Dalrymple]

Gene,

I included functions in the 4CL Extra Functions to help with this if you want to do it on the machine itself. Look at the Memory Buffer functions. They allow you to assemble chunks of code in the Extra Functions buffer area in RAM without having to worry about the destination address (it's stored in an internal pointer.) This works if you're just assembling routines that don't share common subroutines, and probably isn't the best for what I think you want.

I would probably disassemble (on a PC) the modules you want to gather stuff from and then figure out where all the code is and gather it together in a new file. Build the FAT, run it through the assembler and hope everything fits.

Or you could just ask 'Angel...

[Didier Lachieze]

There is a tool for that: look for romnut in asmnut under utilities on TOS.

Form the documentation :

Quote: 3. The ROM maker

The aim of this tool is to provide the 'easiest way' to simply build and create its own ROM.

The context is that we have access to a lot of module image, embedding a lot of instructions. But several ROM give the same functions. Also, two ROM may be uncompatible due to the XROM number choosen, or the number of pages needed. Also you may have to load a ROM for only a couple of functions.

Starting from this, I decided to split several ROM into simple fonction or group of functions. And after, I wrote the ROM maker driver romnut to create a source file, and call the assembler and so create my own ROM from parts of others ROM.

[Ángel Martin]

If I've been able to do it then anybody else can too. The key is the development environment - several tools exist, some more professional than others and usually the more professional the more background knowledge is required.

For instance I don't use a "proper" compiler/assembler, rather some excel sheets and macros. This is involved; you need to do some manual steps that normally will be handled by the assembler - but the editing capabilities are unbeatable: copy, paste, move, swap, replace, hyperlinks...

Since I have all the source code already in excel templates, the "GeneDream" module could be put together in a couple of hours using this method - although I'd suggest some consolidation of functions into more-capable ones, with prompting options - but this is a personal thing.

I've never tried the ROM MAKER posted at TOS, but it sounds like a good idea for relatively simple modules, without lots of common subroutines or advanced features (say tables, secondary FAT's, bank-switched pages...). Also I think that tool doesn't run on Windoze, is that correct??

'Best,
ÁM

PS. Probably the "couple of hours" estimation is wrong: I didn't notice those Card-Reader functions, which will add substantial time to the project (not so trivial...)

[Gene]

What makes the card reader functions harder ? Total ignorance here. :-)

I'm sure most of us would have a list of dream rom functionality and they would all be different. I totally understand that.

I am curious how it could be done by an average Joe. Perhaps the next time someone makes a rom they video themselves doing it? :-)

[Gene]

And, forget the card reader functions for a minute...if a good number of the other programmer type functions could be shoe horned somehow into OSX3 or the PowerCL module as a secondary FAT entry, that would be great. I don't mind seeing these show up as a two line program function ala auxillary FAT item at all.

However, I would be good if there were documentation or examples somewhere on how to make a rom as step-by-step as possible. Maybe a rom with only a few functions, some mcode some FOCAL?

[emece67]

(08-04-2016 05:11 AM)Ángel Martin Wrote:  For instance I don't use a "proper" compiler/assembler, rather some excel sheets and macros. This is involved; you need to do some manual steps that normally will be handled by the assembler - but the editing capabilities are unbeatable: copy, paste, move, swap, replace, hyperlinks...

A coworker of mine also used Excel to build an assembler for the 8051. I'm rather curious about this use of Excel. Sadly my coworker passed away some years ago.

Does your environment generate the final .bin/.mod file? Manages both FOCAL and assembly programs? I'm not developing anything for the 41 but, as I said, I'm just curious.

Regards.

[Ángel Martin]

(08-04-2016 12:38 PM)emece67 Wrote:  A coworker of mine also used Excel to build an assembler for the 8051. I'm rather curious about this use of Excel. Sadly my coworker passed away some years ago.

Does your environment generate the final .bin/.mod file? Manages both FOCAL and assembly programs? I'm not developing anything for the 41 but, as I said, I'm just curious.

Regards.

I know it's not cutting-edge technology but I hope to outlive the process...

It gets the ROM file compiled, then I use the MLDL2k_Manager to encapsulate those into MOD containers.

Best,
'AM

[hth]

(08-04-2016 11:36 AM)Gene Wrote:  What makes the card reader functions harder ? Total ignorance here. :-)

I'm sure most of us would have a list of dream rom functionality and they would all be different. I totally understand that.

I am curious how it could be done by an average Joe. Perhaps the next time someone makes a rom they video themselves doing it? :-)

The card reader has calls inside that rely on being in page E. Ordinary modules are written to execute from any page. The long call/goto mechanism is different. It means you need to rearrange more and understand what is happening in the code at a deeper level than otherwise. You need to translate the code to be page independent. I do not know if this problem applies to the functions you list, perhaps not as they should be rather free-standing.

Piecing together your own module is easiest to do on a computer using some kind of tools. Here is just an idea of a process (using tools that contain an assembler among other things):

1. Get your RPN programs as .raw files, either by transfer from the HP41 (somehow), or use a tool to extract then from suitable modules.
2. For the MCODE parts you need to either disassemble the ROM to transform it to source code, or work on the binary image. I prefer the source code route as it is more flexible and can handle arbitrary complex scenarios. (For small hacks, working at the binary level might do.)
3. With the source code (of the whole module), take a function at a time. They can be located from the FAT. Look at how it is implemented, what calls does it makes. Then use a text editor to lift the relevant code out and put these is in your own module source file (or files).
4. Repeat 3 until done.
5. Clean up your own module source, fix dependencies (RPN function calling other functions in the ROM), add suitable headers, FAT and the (probably empty) poll vectors and identification at the end.
6. The tool I use need a couple of small support files to tie it all together. Then let the tools chew on it and out comes a module image. Test it and go back to fix any issues.
   

You need some understanding of MCODE to do step 3 and be able to use a text editor. You need to understand the module layout, XROM entries and the tools you are using to do step 5 and 6.

This is for a rather plain module. If you want to play with MCODE tricks, you need to work more as well as understand MCODE at a deeper level.

[d b]

When I was still surveying; I would have liked a Surveying Pac that:

1) -had the math pac's triangle solutions included. I solved this by buying one. HP may have saved enough space for this by deleting "transit rule" because nobody used it, and "volume of a borrow pit" because one could pretty much use "volume by average end area" to do the same thing.

2) -had point storage built in. Our own Ted Kirber wrote a marvelously small routine to do this but since the ROM called to it's subroutines with local labels, he had to copy all of them into main memory appended to global labels. It worked but took up a lot of space in the duplications.
2a) or one that used global labels on the subroutines

3) -used arc length instead of chord length on curves in "TRAV" like the whole world did and does. This would have speeded up the process and saved a few keystrokes. It might have even saved ROM memory. In a 4k chip, that's important.

With the advent of the (take your pick) 41 co op module, 42, 71, 48sx, the CMT MC series, or the Husky - this all became a non issue, except that many of us would still rather use our 41 than any other calculating device.

[damaltor]

I am actually experimenting with simple microcontrollers to do the job at the moment. as modern micros are fast and cheap, there might be a way to get around fpga/cpld/... stuff, though i cant tell if everything works out like i think it will. i plan on using a small 8bit controller with a high enough clock rate to output the rom data quick enough. this is somewhat tricky, but might work it would also mean that the new rom module has far more processing power than the 41 itself.
in deep sleep modes, recent microcontrollers go down to less-than-microamp currents, so i guess that should not be a huge problem.

[emece67]

(08-05-2016 09:46 AM)damaltor Wrote:  I am actually experimenting with simple microcontrollers to do the job at the moment. as modern micros are fast and cheap, there might be a way to get around fpga/cpld/... stuff, though i cant tell if everything works out like i think it will. i plan on using a small 8bit controller with a high enough clock rate to output the rom data quick enough. this is somewhat tricky, but might work it would also mean that the new rom module has far more processing power than the 41 itself.
in deep sleep modes, recent microcontrollers go down to less-than-microamp currents, so i guess that should not be a huge problem.

I'm on the same quest right now, although I'm using an ARM based controller. In fact I think that a CPLD/FPGA based approach can be better, but I was unable to find a device with enough memory and with in a small enough package to fit inside a 41 module. Add (in case of FPGA) the configuration memory and space gets even tighter.

[derekamos]

I feel that the "A custom HP-41 rom for the rest of us" concept, is a mighty tall order. How on earth could you get a concensus about the content of a ROM for the rest of us, surely everyone would want their own features! You would end up having to make 2, 6 or even a dozen or more CUSTOM ROMs - just to satisfy the 'selfish' wants of individual minds.

Honestly you might as well leave it all as it is, with people loading roms as they like into a stack they personally agree with. I must say this is what I have done, and being a programmer, I have altered or deleted many programs in roms that I did not need. This proved a long process as I have been at it since the 1980s.

The latest update & change has occurred because of the HP41 emulation on a SMARTPHONE, which wont run HPIL. I chose to use it as the method for 41cv in/output. However now I have updated all my old HPIL output to standard ACA/PRBUF printer output, which on the smartphone emulators is emailable as text. So I am able to get rom blocks of ASCII-HEX text onto my PC to convert & then disassemble using MLDL2k. This process uses all kinds of bit parts, similarly to most others methods, as shown in the above posts. Personally I still use my update of the DAVID assembler rom to do mCode programming, as I find its instant code inputs really efficient.

One thing that stands out in the concept of a custom rom is the use of page 4 as a library of callable routines which comprise the core, always in use subroutines. This however doesn't load as just one custom block rom with the rest, similarly with card reader problem it is hard addressed.

Hence you see the overall multi-split nature of a CUSTOM ROM, as a bit of a paradisical dream.
DA

[Gene]

My intent was not ONE custom rom for the rest of us but how could each person with an interest make their own custom rom. :-)

[derekamos]

Gene, sorry I seem to have misunderstood you.

Programmers hold all the aces here, if your programming is up to par you certainly can achieve this. The simplest job here would be to complete a clump of the roms you wanted in a block of whatever size it all comes to. Without complex functions like bank switching, library 4 or card reader roms.

For a programmer, one completed job leads to the next in relentless fashion, as perceptions open as to 'how it could have been done better', only after completing it. Finding willingness to continue, as it can become like 'to hard to labour with', may rely on a good set of tools that you are comfortable using.

Hope this helps,
DA
P.S Didn't I see an Isene rom around? you seem to me to be well established already.

[Ángel Martin]

(08-07-2016 05:28 AM)derekamos Wrote:  P.S Didn't I see an Isene rom around? you seem to me to be well established already.

Gene Wright and Geir Isene are two different people, both great chaps and super contributors to this forum ;-)

Gene's inputs for other modules content's have always been very useful and have materialized in some collections, like the GENE_RAW's ROM.

[smp]

(08-07-2016 10:53 AM)Geir Isene Wrote:  Gene raises a very good point. I would take it even further. Here's a use case:
<...snip...>

Wow. That would be a dream come true!

smp

[Gene]

Angel: You brought up a good point about some of the functions I hoped to have some of those functions again in a rom image nearly all of us will always have plugged in, such as OSX3 or PWRX. I'm sure the FATs and secondary FATs are probably about as full as they can get.

However, if you look at many of the functions that were in my list, there were three primary types:

1) More comparison tests of X, Y and Z against Z and T. Any chance of a generalized test prompting function?
2) More comparison tests of X and 1, X>1 and X<1. X=1? is already in there.
3) Then a few other manipulations of X. X*E3, X/E3, X/2 and A=X.

That's the majority.

Ignore the card reader functions and the XTAT functions. I was pulling them in to fill in a new rom image if made.


My goal was to have available in one rom a few more programming tools without having to have a ram program dependent on the Total Rekall rom being plugged in, or the PK roms being plugged in. If these were in OSX3 or PWRX or YFNZ (Monte ?) then they would essentially always be available (since I cannot imagine any 41CL users are using them) -- ha :-)

I tend to have my 41CL set up like this:

Page 4: Lib 4
Page 6: PWRX
Page 7: OSX3
Page 8: YFNX
Page 9: XTAT
Pages A and B: SM44

leaving CDEF for other stuff.

Just curious if there might be room to bring in *some* of these types of functions into PWRX or OSX3 (or even SM44!).


Although Geir's idea is incredible.

[derekamos]

This is the creation of an "Artificial Intelligence Site". AI probably won't fit on the 41 (ha ha), but a site with mCode routines of any compilers choice would be great. With mCode and/or RPN contributions as an ongoing basis, this means it would adapt into the future, almost endlessly.

What a development for the HP41 to achieve? Now just how is this possible, there a need for more brainstorming here...
DA