HP-41 extended memory file types
|
09-18-2019, 09:17 PM
Post: #1
|
|||
|
|||
HP-41 extended memory file types
HP defined three file types in the extended memory, Data, ASCII and Program.
This was added on by the CCD module. According to "Extend your HP-41", the following mappings are used by the CCD module: 4 - matrix 5 - I/O Buffers 6 - Key assignments Interestingly, I have a (never released) CAT replacement code that uses the following (opposite mapping): 5 - Key assignments 6 - I/O Buffers I kind of wonder why it is swapped in my code, as I got the matrix at the same position (4). Is there a comprehensive list somewhere that shows all file types that have been defined somewhere by the community? Do we have a need for additional file types? (ROM compressed, ROM uncompressed, WALL, others?) |
|||
09-18-2019, 09:39 PM
Post: #2
|
|||
|
|||
RE: HP-41 extended memory file types
Not exactly what you asked for, but here's a list of LIF file types.
LIF File Types v8 .xlsx (Size: 34.02 KB / Downloads: 56) |
|||
09-18-2019, 11:20 PM
Post: #3
|
|||
|
|||
RE: HP-41 extended memory file types | |||
09-19-2019, 05:13 AM
(This post was last modified: 09-19-2019 05:14 AM by Ángel Martin.)
Post: #4
|
|||
|
|||
RE: HP-41 extended memory file types
(09-18-2019 09:17 PM)hth Wrote: HP defined three file types in the extended memory, Data, ASCII and Program. In the AMC_OS/X I followed the CCD scheme above, plus defined a few other types for the following: 7.- "T": Status Registers backup 8.- "Z": Complex Stack from 41Z 9.- "L": LIFO File for Doug Wilder's LIFO functions 10.- "F": FORTH Code backup 11.- "H": Binary Stack backup from HP-16C The enhanced CAT" 4 shows the file types letter for all the 11 types in the display during the enumeration. (09-18-2019 09:17 PM)hth Wrote: Interestingly, I have a (never released) CAT replacement code that uses the following (opposite mapping): I wouldn't use a swapped-numbers convention for KA and Buffer files, that would be a big problem in the code checking on the file types, and very confusing to the users as well of course. Cheers 'AM "To live or die by your own sword one must first learn to wield it aptly." |
|||
09-19-2019, 05:30 AM
Post: #5
|
|||
|
|||
RE: HP-41 extended memory file types
(09-19-2019 05:13 AM)Ángel Martin Wrote: In the AMC_OS/X I followed the CCD scheme above, plus defined a few other types for the following: Thanks a lot for that information! I wonder why I swapped them, maybe I just made a mistake or did not really know the correct numbers. Good to have it confirmed so I do it right this time. What is the reason behind using 'T' for status, is not 'S' a good alternative as that letter is not used? What about WALL, should that exist? Can I add that as 12 (or perhaps even 0)? |
|||
09-19-2019, 07:40 AM
(This post was last modified: 09-19-2019 07:46 AM by Ángel Martin.)
Post: #6
|
|||
|
|||
RE: HP-41 extended memory file types
(09-19-2019 05:30 AM)hth Wrote: I wonder why I swapped them, maybe I just made a mistake or did not really know the correct numbers. Good to have it confirmed so I do it right this time. I honestly don't know why I used "T", as you say "S" would also work...maybe I was considering another type that started with 'S" and never got around it, but I don't remember. Edited: I remember now: I reserved "S" for a STACK backup, either the "real" one or the Shadow Stack in the WARP_Core module (which really is buffer#7 but that's another story) I also toyed with a Polynomial File but after some reflection I decided to use Data Files for them, not different enough to warrant a separate kind. WALL files in X-Mem? I'm not aware of any function creating that kind but if you're working on one by all means using 12 or 13 for its type will be compatible. I'd stay away from "0" as a valid file type... not sure that'll break code somewhere? ÁM "To live or die by your own sword one must first learn to wield it aptly." |
|||
09-19-2019, 04:31 PM
Post: #7
|
|||
|
|||
RE: HP-41 extended memory file types
I will reserve 12 for WALL files then.
This is for an update of EMDIR, so it is just for display at this point. I will probably go for using 'S' to indicate status for now, as status has been used in the past as a type on secondary storage. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)