I'm thinking about doing a different version of the 41CL Extra Functions. But the FAT is full, so I have been thinking of ways to modify the set of functions available. One thing I thought of was to eliminate the UPLUG functions entirely - and instead using the PLUG functions with something like an "EMPT" identifier to signal to unplug the current image. I also thought that it might be handy to be able to use something like "?" in the Alpha register with the PLUG functions to return the current image plugged into the port. Any comments?
Monte
[41CL] Another question for users
|
05-28-2013, 02:16 PM
05-28-2013, 03:14 PM
Certainly Angel would love to assist you in creating a sub function fat in a second bank switched page! :-) Seriously: I think it's a good idea to omit redundant uplug - functions and to offer information about the page currently plugged in by exactly those modifications that you proposed:
- "FREE" or "0" (zero) in Alpha for unplugging; - "?" for retrieving information.
05-28-2013, 03:24 PM
Monte; Sounds as good ideas (EMPT/? for UPLUG/PLUG?) Functions like the BAUDs and TURBOs could take the argument (speed) from X to make the sets single functions.
05-28-2013, 03:34 PM
Quote: Yes in PROGRAM mode, but please, please make them prompting in RUN mode !!!!
05-28-2013, 03:40 PM
my first thought is "great idea"; my second is "OMG!! - there goes the PowerCL down to the gutter!" I hope you keep the same FAT entries for those functions that remain, and only the removed ones are replaced with new?
05-28-2013, 05:29 PM
Yes, I'll keep the same FAT numbering for the untouched functions. I'll also do my best to keep any other entry points (common subroutines) the same. That's why I was asking the question here, to let everyone point out any constraints that I should keep in mind.
05-29-2013, 01:27 AM
Here´s a few inputs for your consideration for the new version: 1. Protect YFNS/YFNP against accidental UNPLUG - checking for "OK" in ALPHA is a good method, also used in several other functions. 2. Restrict MMUCLR to operate only when the MMU is disabled. 3. Making UPLUGxx as an alternate of PLUGxx is a good idea to save 14 entries in the FAT. The EMPT mnemonic will work, although I´m sure I´ll miss the simplicity of today´s approach. 4. Making them prompting could save another 10+ entries. This is the approach used in the PowerCL, where SHIFT is also used to toggle between the PLUG and UNPLUG actions. I prefer this method for usability and maximum FAT entries saving, but the drawback is that in a program it will take an additional program line for the parameter. 5. Do a complete unplugging when using UPLUGxx on modules that straddle two ports - currently only the MMU settings for the first one are changed, and the "left-over" is behind. 6. Last and definitely *most*: pls. re-set the current page-4 mapping when doing the dynamic swapping you're planning - it's a fantastic idea but I'd not want the Library#4 to get lost during the action!
Cheers,
Edited: 29 May 2013, 3:42 a.m.
05-29-2013, 08:28 AM
Agreed :-)
05-29-2013, 03:56 PM
1. Not sure how this will work in conjunction with the new "EMPT" identifier and PLUG. Perhaps a dedicated identifier that means "no matter what"?
05-29-2013, 07:28 PM
It's not really important, but I can't see the point why "EMPT", a 4 character mnemonic, should be used to designate UPLUG. "0" would be sufficient, the PLUG routine could check for that special value first.
05-30-2013, 01:26 AM
1a. It´s possible that the EMTP string is in alpha from a previous UNPLUG action (perhaps one big module that straddles two ports), and thus it´s still important to protect the YFNS page from accidental unplugging. 1b. Conversely, it´ll be important to protect it from accidental plugging over it, i.e. using PLUG for another module on the page currently used by YFNS. 5. The MMU bit idea sounds like the way to go - much more efficient than working it all out each time.
ÁM. Edited: 30 May 2013, 3:00 a.m.
05-30-2013, 01:30 AM
Good point - I like the 4-chr mnemonic for consistency. If the YFNS is protected from plug accidents using EMTP then there´s a need for a master-unplug code that would work on YFNS:- this is where I´d suggest using "OK" in alpha would do.
05-30-2013, 06:38 AM
I went for a run this morning to fight the coach-potato syndrome (too much programming does that to you) and let my mind wander freely... It occurred to me that the better approach to protect YFNS is not using special mnemonics, but to implement a true protection scheme that can be applied to any page. What a better use for those MMU bits still available than to be used to flag ports as plug-protected, so they cannot be unplugged or plugged-over while the protection status is ON. YFNS would then inherit the protected status by default when plugged the first time (or after a MMUCLR event), remaining as such until the user decides to change it. Two functions needed (say YLOCK and YFREE as example) or just one if using the Toggle approach (say MMUTOG). Other protection type could be write-protect for RAM pages, as the HEPAX does with function RAMTOG. Your toughts?
Best,
05-30-2013, 02:24 PM
I think that a "protect" bit in the MMU register itself makes sense. That works fine for the PLUG commands but I'm not sure that I want to mess with the YPOKE command. But if you're YPOKEing in the system area you need to know what you're doing anyway...
06-01-2013, 10:44 AM
Tentative updates to 41CL Extra Functions: 1. Eliminate all UPLUG functions, fold functionality into PLUG functions as described below.
2. Merge YFNZ and YFNP back into single image, restoring YBPNT, YBPNT?, YBUILD,
3. Add new MAPCLR function, to go with MAPEN and MAPDIS. Only works while mapping 4. MMUCLR function only works while MMU is disabled. 5. Add new PLUGL (plug into library, page 4) function. 6. Add new PLUG12 and PLUG34 functions, specifically for images that span two ports.
7. PLUG functions implement the 4-deep stack for MMU entries. Since this is not backwards-
8. PLUG functions with "?" in Alpha return MMU contents for that page. Only works with
9.PLUG functions with ",," in Alpha pop the MMU stack, unplugging the current contents.
10. PLUG with "L:" in Alpha locks MMU contents - cannot be overwritten or unplugged. 11: PLUG with "U:" in Alpha unlocks MMU contents to allow overwriting or unplugging.
12: PLUG with "L:" or "U:" preceeding image identifier plugs in image with that attribute. Comments?
06-02-2013, 07:39 AM
here are some comments from me, fell free to ignore them as you see fit. 1. ok, still digesting the news... 2. sounds logical now that there are FAT entries available 3. not sure I see the need for it (desn´t MAPDIS suffice?) but ok 4. Great! 5. Excellent. Will it also work for the FORTH module, which takes ports 4 and 7? 6. Good idea, but what about PLUGging images straddling ports, i.e. using ports 9/A, or B/C...? 7. I think I get the concept of the MMU stack for each page, I guess this is how you´ll implement the dynamic page swapping. Yet it has some uncertainty regarding its work. Will the stack be pushed each time PLUG is used on that page? If so, I can foresee trouble when unplugging the image, which could (would) result not in an empty page but with another module replacing the previous one. Considering that the user may (most certainly will) have forgotten all about which ones were the previous tenants of that page, I envision trouble. 8. What about a PLUG? function instead? 9. See #7 above. Somehow I like "EMTP" better, not sure which characters have you chosen, two commas? Wouldn't it be needed to also have another function to really unplug the page, popping the four levels of the MMU stack at once? 10. What about a YLOCK function instead? 11. What about a YUNLOCK function instead? 13. Nice but the mnemonics are getting kinda long. It could also be accomplished using PLUG followed by YLOCK / YUNLOCK. Great to see all this thinking going into the CL software, hope this gives you some more food for thought.
-
06-02-2013, 11:31 AM
3. Currently the only way to initialize the MMU entries for Pages 0-3 is to use individual YPOKEs to the MMU registers. MMUCLR doesn't touch these entries at present, although I could just change that instead. Edited: 2 June 2013, 11:31 a.m.
06-02-2013, 12:13 PM
Quote: You're not, but some of us are mostly "lurkers". Where there's a choice between a bigger improvement or compatibility, I'd vote for the bigger improvement.
06-03-2013, 01:45 AM
Here´s some follow up: 8.,10. & 11. - I always forget that PLUG is not just ONE function, but really are 14 functions instead; so you´re right new functions like YLOCK, etc. would also mean a set of them... not a good approach, unless of course they're replaced by a single prompting function; YLOCK _, plus pg# The port metaphor is ok in that it mimics the real physical machine, but it´s also constrained by using the whole port as the "unit". That's why you implemented the PLUGL and PLUGU variants to begin with. With this we ended up with the 14 functions we have today:
PLUG1/2/3/4 for whole ports, Using the PAGE as a unit instead gets rid of this issue, but of course that'd need to be a prompting implementation or otherwise you´d need 11 of them: PLUGG4/6/7/8/9/A/B/C/D/E/F. This is how the PLUGG function launcher in the PowerCL works, dispatching behind the scenes to the half-port YFNS functions according to the input entered in its prompt. This digression is just contextual, it's probably not reasonable to modify the PORT paradigm at this point, therefore the PLUG12 and PLUG34 could have their place - although there are just a few 16-k modules, so it's a very corner case. I counted 10 images in this category, as follows: ADV1, ADV2, P3BC, SIMM, ASTT, FUNS, SANA, XXXF, K135, DEMO. They'll be good to avoid the accidental plugging-over, as it'd happen today using PLUG1/2/3/4 with those images - yet I guess nobody's complained about this. So if there are available FAT entries it'll be good to include them, forgetting about the port straddling as a practical design criteria. My two cents again, I too need to keep this aging brain active.
Best,
06-03-2013, 10:04 AM
As a lurker & user, I am very much enjoying this line of exploration of new CL functions. Just sayin'
06-03-2013, 10:09 AM
My first reason for wanting to add PLUG12 and PLUG34 is that it will allow me to quickly check for the LOCK status before actually looking up the image information in the IMDB.
06-03-2013, 12:03 PM
That enough is worth the admission price; PLUG12 and PLUG34 are definitely in! :-) Speaking of physical modules conflicting with MMU settings - this is awfully similar to the "ROM Shadowing" we hear from other systems (like Clonix/NoVo and the W&W-41CY?). Would that be feasible on the CL as well?
06-03-2013, 02:50 PM
From what I understand of "ROM shadowing" it would just require something to run at the power-on polling point. Basically fetch the MMU status for a page, temporarily disable translation, fetch a byte from the page to see if there is something in the physical Port, go to the next page if yes, restore the MMU settings if no. If you think that this is a useful feature it would not be hard to add. Of course it would require that the 41CL Extra Functions be plugged in, and I'd probably want to not check the page containing these functions...
06-03-2013, 09:20 PM
I may be out of my depth here, why not do something like the following ...
Edited: 3 June 2013, 9:52 p.m.
06-03-2013, 11:37 PM
Unfortunately, the interactive versions are probably beyond my programming capabilities. Edited: 3 June 2013, 11:38 p.m.
06-04-2013, 01:39 AM
From the ease of use this is great, and it follows the standards set by HP with their extension modules, like the X-Functions. It needs the X register and the Alpha registers to hold the data input parameters, perhaps the only drawback. It´s also more RPN-like that the prompting - I remember some arguments against prompting functions used when the 48SX first came out; like using SF 00 vs. 0, XEQ "SF". Prompting functions however are more intuitive and friendlier, you don´t need to remember the input sequence - which it´s suggested by the function itself. Alpha prompting for ROM-based functions is a bit of a tricky issue. In RUN mode it all works dandy, but in a program things get hairy. Consider that HP never implemented this in plug-in ROMS, like the X-Functions; but rather they used the ALPHA register to hold the arguments of the functions instead. Think of PASN for instance, very different from ASN. There are a few ways around this, as follows - in order of complexity and smoothness of the integration with the OS: 1. Get two functions to do the task, one in RUN mode (prompting, non-programmable) and another in program mode (takes inputs from X/Alpha). This is the ASN vs. PASN approach. The prompting function follows the standard conventions using the prompting bits in the function name, very well documented and trivial to implement. No extra coding is required at all for numeric prompts; little code snippets are needed to handle HEX inputs (like using A,B,C...F for the pages as opposed to 10, 12, ..15) 2. Use just one function, but behaving differently depending on which mode it´s being used in. This is checked using the CPU flags 4 and 13, so a couple of tests at the very beginning of the function code will fork to either mode. This can be done in a subroutine, common to many functions in the ROM. Drawback is the blank prompt in PRGM mode that must be input but is not taken in. The parameters are still taken from the stack (X) and/or ALPHA. 3. Implement the non-merged scheme whereby in a program the arguments are taken from the next program line. Examples of this abound in the 41Z and the SandMath (for instance RCL+ 12, or ZRCL 05). The simple version of this requires adding the argument line manually by the user. Same drawback as before with the blank input. 4. A refinement of the above - whereby the argument line is automatically placed in the program by the function itself. This is the HEPAX model, also used in the PowerCL and the SandMath. No drawbacks to speak of (except a corner case when doing SST execution in-between both lines) but it requires quite a lot of code, so it´s probably out of the question.
So in summary: A long rant but hopefully it helps.
Best,
Edited: 4 June 2013, 2:08 a.m.
06-04-2013, 01:54 AM
yes that Rom Shadowing surrogate is a very nice approach! - it'll avoid conflicts mapping MMU entries to already taken ports. A logical extension of this is to implement these checks when doing MMUEN - making sure all the destinations are safe.
That will take care of half of the problem. The other half occurs when the user plugs a physical module into an MMU-occupied page. Addressing this requires a hardware re-design, or maybe not? Edited: 4 June 2013, 1:56 a.m.
06-04-2013, 03:10 AM
Here´s a real-life example of option #2 above applied to the four PLUG functions for whole ports. I modified the code in YFNP, adding a few lines at the beginning of the function to handle the input value in the prompt if used in RUN mode, or to take it from X if in program mode. The new function PLUGX (following Sylvain's suggestion) replaces PLUG1, PLUG2, PLUG3, and PLUG4.
PAGERR A6AC 20D ?NC XQ Build Msg - UF25 clear the rest is all as-is, I'm sure you'll recognize the whereabouts - it starts at the same address as PLUG1 in the YFNP module, just moved the " TYPE ERR" message above the header. lines A6BD to A6D4 are the RUN/PRGM initial routine. This can be put in an independent subroutine and called upon initialization. In fact such a routine is in the Library#4 already. Lines A6DD to A6E2 make the changes compatible with the [MODN] routine output (I assumed register B was free to use and that A and C were needed).
Best,
Edited: 4 June 2013, 3:28 a.m.
06-04-2013, 11:55 PM
If the user only plugs in a module while the calculator is off the power-on polling point will always catch a newly-inserted module. The only problem with this approach is due to the polling sequence, which goes 5-6-7---F-3. So the result will depend on where the 41CL Extra functions reside in the sequence, relative to the module. A newly-inserted module that is polled prior to the Extra Functions poll will catch the MMU-enabled image rather than an inserted module for the polling point. The module will still be detected, but if there is power-on code in the module that is supposed to be run, that won't happen. |
« Next Oldest | Next Newest »
|