▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
Well, extended-expanded in a modest way if you consider adding ONE more function worthwhile.
As it turns out there was room in the FAT for one more entry, and plenty of room in page 3 for some additional code (no need to resort to the bank-switched page). So... you can imagine how tempting such a situation is.
Here's the question: If you had a choice, which one would be the single one and only function to incorporate to the CX function set?
In fact there could be up to three, assuming we'd use the section headers to call the remaining two. Sort of "easter eggs", as it's done on some power-user modules (like the CCD).
Possibly having to do with extended memory management (CLEM, RENMFL, RETYPFL...) or would you go other way?
Let's have a poll!
Edited: 9 Dec 2010, 9:15 a.m.
▼
Posts: 381
Threads: 32
Joined: Mar 2006
CXISA = Read ROM word (address in X) and push it on the stack
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
interesting choice, I can tell you're a heavy-duty programmer! :)
▼
Posts: 381
Threads: 32
Joined: Mar 2006
Otherwise, I agree that some kind of random number generator function would be useful.
Posts: 896
Threads: 183
Joined: Jul 2005
One would of course have to have a function to call the header easteregg functions as well.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
Yes of course. We could think about adding XROM as the "official" entry, or rely on having the OS/X or CCD around.
▼
Posts: 896
Threads: 183
Joined: Jul 2005
I say self contained - all the way. SO, XROM is in.
Posts: 115
Threads: 10
Joined: Aug 2008
What are you up to now? Replacing the 41cx ROM?
If I were in charge when the 41CX ROM was made, I would have added a random number generator.
Since done is done, today I would probably use the space for extended prompting, but that would not take any FAT entry.. :)
Or rather, I think I would leave it alone, done is done, just put the extensions in a separate plug-in module instead.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
Not after replacing the CX ROM but to extend it (a little bit at least). I like the RNG idea, and would like to suggest using the one you published in PPCCJ way back then.
It uses the time module to produce a credible seed, and is buffer-based and everything, so it's a nice all-round exercise.
But let's see which other inputs we get..
▼
Posts: 896
Threads: 183
Joined: Jul 2005
Posts: 1,322
Threads: 115
Joined: Jul 2005
I think the most glaring omission from the extended function set was the ability to easily store and recall DATA files between mass storage and extended memory. The TDS survey ROM has this function using TDC and THP and it simply makes the whole module useful. Otherwise, one is limited to having one 300 point file, period - or changing file type from data to ascii and back in order to move them.
I never understood why HP would not have given the ability to archive data files from a platform that was being used as a data collector. It stores and retrieves program and ascii files between ex mem and mass storage media. It's as if HP expected users to be using their 41 for word processing but not math.
Anyway; that's my vote.
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
I sort of agree with you but remember that we're emulator-based, so the HP-IL is not a very useful device... afraid to say.
This is fun, sort of the most-wanted drill all over again.
▼
Posts: 896
Threads: 183
Joined: Jul 2005
No, no, we're not necessarily emulator-based... I'm not. I'm all for The Real Thing, HP-IL and all.
Posts: 1,253
Threads: 117
Joined: Nov 2005
In retrospect it's true that they gave a lot of emphasis to the ASCII files, way over the data files if one is to judge by the number of functions (with the EDitor being the clearest example). Perhaps too much considering the obvious limitations in the platform for text editing...
at any rate, looks like the poll is over, and the winner is...
Posts: 2,247
Threads: 200
Joined: Jun 2005
You asked for three functions, so here is my pick:
1. Random number generator.
2. Write all/range of memory registers to a data file on the PC.
3. Read a data file on the PC into memory to replace all or some of the memory registers.
Namir
Edited: 9 Dec 2010, 12:54 p.m.
▼
Posts: 564
Threads: 72
Joined: Sep 2005
I think the answer changes tremendously with the reference frame:
For a physical HP-41 back in the day when modules where expensive (or a physical HP-41 today with no clonix) I would have to vote for peekb/pokeb and code/decode. These are very powerful functions that are time-consuming to replicate in pure Focal and they have massive re-use. RAND is useful once in a while for games and the like but it is easily replicated by FOCAL and doesnt really expand what one can do with the HP41. Assuming there is enough space in page 3 for more stuff, one would have to consider allowing sto/rcl/x<> to the system registers a,b,c,d,etc which does not require a FAT entry.
In an emulator world I would vote for saving/retrieving XM to/from a QROM page and/or save/load a user program to a QROM page to free up memory. If there is only 1 FAT entry, a SAVEALL command to save/exchange the complete RAM and XM to 1 (or 2 with full XM) QRAM pages would allow to have a couple of configurations always at hand in ones simulator (say a data collection configuration, a games configuration and a programming configuration)
Basically an additional function should be hard to replicate with already existing functions and combine well with existing functions to create new possible uses.
Cheers
Peter
Edited: 9 Dec 2010, 3:21 p.m.
Posts: 297
Threads: 25
Joined: Nov 2006
HEX and DEC (and maybe OCT), to toggle between these modes. Like the corresponding keys on the 16c. Then I'd never need anything except my 41. Hmm....
Monte
|