Threaded Mode | Linear Mode

Diego Diaz · 05-10-2016, 04:37 AM

Hi all,

Again a superb job from our M-code guru.

While Ángel is keeping on pushing the limits of the 41 addressable space, it's clear that newer devices (apart form CL) will be needed to handle these ROM sizes.

Yep, they're in the oven already.

Thanks to David Brunnel for his support providing the required microcontrollers. ;-)

More details as the project progress.

Cheers from Caribbean.

Diego.

Ángel Martin · (This post was last modified: 05-10-2016 07:06 AM by Ángel Martin.)

(05-10-2016 01:33 AM)derekamos Wrote: As everyone is so concerned about stopping Angel getting 'old age' in his fingers, here is my chip-in - it may help.

Artificial-variable Free Solution Algorithms for LP Models by Hossein Arsham, deals with tremendous changes to basic simplex matrix ops, as originated by Saul Gass. Even in some of Gass' latest books there is no real update to the old 2nd world war work. Here is an update worth a module or a 4k? page somewhere. The Jean-Marc Baillard site (link shown above) has some RPN work in samples on these updates, which show 1/3rd faster routines than the older matrix ops. Arsham' work is a revolution in this field, through his 'push/pull' method.

Programmed in mCode & run on a 41CL the routine speed should be blinding? How does this sound for an interesting/insightful/advanced piece of work (no hardware involved).
DA

Garth that sounds beautiful but you're obviously over-estimating my abilities on both accounts, MCODE and Math... as well as my capability at this late (brain) age to learn the numerous new tricks required to pull this off... But it's intriguing, and it's in the right direction for ideas.

Besides it seems there's a fly in the ointment, judging by articles like this showing counterexamples to the Artificial-free method.

I\m not sure about enhancing the CX EDitor, but I'm ruminating on a couple of potential new projects. The first one is getting the FORTH module to a more stable state, which right now it appears it's not. Every time I look into that one I see a tremendous amount of work done with a good structure and approach, but not quite complete. I need to revise my notes as well as the few threads on that subject from the forum that were posted in the past.

The second is the extension of the OS to allow for more registers and RAM access - and here we're talking 41CL only. The Expanded memory module uses all the extra RAM space above 1FFF but the OS is not. On initial (light) inspection I encountered a couple of road blocks why it wouldn't work but I'm still not throwing the towel. Mind you, modifying the OS is a *very* touchy subject that one should not attempt unless absolutely all consequences have been clearly studied...

Of course these two are tall orders, probably only approachable joining forces with other folks (too much for a solo project). Partners in crime are welcome (Greg, you reading this? :-)

Cheers,
'AM

Ángel Martin · (This post was last modified: 05-10-2016 05:06 AM by Ángel Martin.)

(05-10-2016 04:37 AM)Diego Diaz Wrote: ... it's clear that newer devices (apart form CL) will be needed to handle these ROM sizes.
Yep, they're in the oven already.

Thanks to David Brunnel for his support providing the required microcontrollers. ;-)
More details as the project progress.

Diego this sounds promising beyond belief... I'm trying not to read between the lines but I'm hoping you're looking into an SD-Module or similar, a.k.a. "the last frontier" :-)

Keep us posted!

Massimo Gnerucci · 05-10-2016, 07:55 AM

(05-10-2016 04:37 AM)Diego Diaz Wrote: Hi all,

Again a superb job from our M-code guru.

While Ángel is keeping on pushing the limits of the 41 addressable space, it's clear that newer devices (apart form CL) will be needed to handle these ROM sizes.

Yep, they're in the oven already.

Thanks to David Brunnel for his support providing the required microcontrollers. ;-)

More details as the project progress.

Cheers from Caribbean.

Diego.

Sounds really intriguing, Diego!

Thank you.

Diego Diaz · 05-11-2016, 02:23 AM

Some of you may remember this from Oct. 2008.

$[Image: www.clonix41.org\Projects\MOARP\MOARP01.JPG]$

But the idea didn't work as expected, and for now i'll just include an 18 ROM pages module, and a more flexible RAM handling. May be 64K RAM is too much for most users out there and 32k or even original (Adv. HEPAX) 16k in two blocks of 8 is more handy.

HP-41 in a reasonably powerful configuration, will have a free port (say #4) to plug peripherals (HP-IL, Card reader, WAND, printer, etc.) and RAM memory (8-16k at least).

Also, except from HEPAX and Ángel's ROMs, the remaining ROMs are 4/8k. With this scenario, user can have HEPAX, 41Z & LIBRARY#4, taking 13 (4k) pages and using addresses h'4000, h'6000, h'C000 & h'D000. Still 5 ROM pages available that can be used for other ROM images.

In the case you don't want/need HEPAX all 18 pages are available to be arranged either in two blocks or as single block.

I'd appreciate comments in case some foresee this ROM size isn't enough to handle any specific configuration; since I'm sure there are points that I haven't got yet.

Look forward to reading your input.

Best wishes.

Diego.

hth · 05-11-2016, 06:09 PM

(05-11-2016 02:23 AM)Diego Diaz Wrote: But the idea didn't work as expected, and for now i'll just include an 18 ROM pages module, and a more flexible RAM handling. May be 64K RAM is too much for most users out there and 32k or even original (Adv. HEPAX) 16k in two blocks of 8 is more handy.

HP-41 in a reasonably powerful configuration, will have a free port (say #4) to plug peripherals (HP-IL, Card reader, WAND, printer, etc.) and RAM memory (8-16k at least).

Also, except from HEPAX and Ángel's ROMs, the remaining ROMs are 4/8k. With this scenario, user can have HEPAX, 41Z & LIBRARY#4, taking 13 (4k) pages and using addresses h'4000, h'6000, h'C000 & h'D000. Still 5 ROM pages available that can be used for other ROM images.

In the case you don't want/need HEPAX all 18 pages are available to be arranged either in two blocks or as single block.

I'd appreciate comments in case some foresee this ROM size isn't enough to handle any specific configuration; since I'm sure there are points that I haven't got yet.

Look forward to reading your input.

Best wishes.

Diego.

I think we will see more modules making use of bank switching. Going to 24 or 32 ROM pages would be very handy. 32 pages would give 4 banks in all pages 8-F, but I can see that a future library 4 could even that use bank switching. So, while I think 18 is a lot, I can definitely imagine that I may wish for more in the long run.

Håkan

derekamos · 05-12-2016, 03:09 AM

Hi Angel,
It seems the short upset argument you posted previously on Simplex problems is answered by Prof Arsham, some 6 years after that article appeared.

"(An algorithm for simplex tableau reduction: the push-to-pull solution strategy. H. Arsham, T. Damija, J. Grad. 2003) Concluding remarks: LP problems, which lack feasibility at the origin point, have raised difficulties since the beginning of LP. For such problems, the ordinary simplex algorithm requires additional variables (i.e., artificial variables) along with large penalty terms in the objective function. Unfortunately, adding these extraneous variables creates computational instability [6,7] and increases the computational complexity [8]. Moreover, classroom experience shows that some students, particularly non-mathematical majors, have difficulty in understanding the intuitive notion of such requirement [2].
We proposed a new general solution algorithm, which is easy to understand, and it is free from any extraneous variables."

Mind you I fully understand the complexity of a venture into the tricky programming of an mCode Simplex algorithm, its not something to be done without considerable effort. Maybe this 'project' is a bit to much to hope for? I think a team effort of mathematical programmers, like that used for the PPC Rom would obviously be more able. Contacting Jean-Luc might provide insights/help?
DA

quantalume · 05-12-2016, 02:59 PM

(05-11-2016 06:09 PM)hth Wrote: I think we will see more modules making use of bank switching. Going to 24 or 32 ROM pages would be very handy. 32 pages would give 4 banks in all pages 8-F, but I can see that a future library 4 could even that use bank switching. So, while I think 18 is a lot, I can definitely imagine that I may wish for more in the long run.

Håkan

I have almost everything I need in a NoV64, except for the ability to run more than one of Ángel's large packages at the same time. However, you are right, something like 32 or 64 pages would be even better. I predict that Ángel's next undertaking will be to rewrite the entire 41CX OS to take advantage of all 4 banks in the lower pages. ;-) Hats off to Ángel's and Diego's continued work on these classic machines.

Ángel Martin · (This post was last modified: 05-12-2016 03:21 PM by Ángel Martin.)

(05-12-2016 02:59 PM)quantalume Wrote: I predict that Ángel's next undertaking will be to rewrite the entire 41CX OS to take advantage of all 4 banks in the lower pages. ;-) Hats off to Ángel's and Diego's continued work on these classic machines.

Oh well, don't hold your breath on that one!

gjmcclure · 05-19-2016, 07:35 PM

(05-10-2016 05:01 AM)Ángel Martin Wrote: [quote='derekamos' pid='55746' dateline='1462844011']
I\m not sure about enhancing the CX EDitor, but I'm ruminating on a couple of potential new projects. The first one is getting the FORTH module to a more stable state, which right now it appears it's not. Every time I look into that one I see a tremendous amount of work done with a good structure and approach, but not quite complete. I need to revise my notes as well as the few threads on that subject from the forum that were posted in the past.

The second is the extension of the OS to allow for more registers and RAM access - and here we're talking 41CL only. The Expanded memory module uses all the extra RAM space above 1FFF but the OS is not. On initial (light) inspection I encountered a couple of road blocks why it wouldn't work but I'm still not throwing the towel. Mind you, modifying the OS is a *very* touchy subject that one should not attempt unless absolutely all consequences have been clearly studied...

Of course these two are tall orders, probably only approachable joining forces with other folks (too much for a solo project). Partners in crime are welcome (Greg, you reading this? :-)

Hmmm, not having played with FORTH that much I think I need to review the standards and what I would expect from the HP41 modules already created, and review the problems with that solution...

I once thought about patching the OS to allow more RAM / XRAM area, but ran into a few roadblocks that caused that action to cease (for example, many synthetic programs would no longer work). I then realized I need more experience with MCODE before thinking about that effort again, and I still don't think I have enough of that!

Greg.

Ángel Martin · (This post was last modified: 03-13-2017 06:47 PM by Ángel Martin.)

(03-13-2017 05:25 PM)Mike (Stgt) Wrote: Hello Angel,

some days ago I found your 41Z Delux Edition and now I see in this forum, it exists alredy for quite some time. So I am a little late with my comments.

Your Complex Number Module "HP-41Z Deluxe+" together with its 116p manual is a grand work. I took a closer look and would like to suggest few minor emendations. (Do not take it as criticism pls.)

Hi Mike, thanks for your detailed feedback, I'm glad there is at least one user of this module out there ;-) Let's address the items individually.-

(03-13-2017 05:25 PM)Mike (Stgt) Wrote: i) First line of the manual is "(c) Ángel M. Martin – March 2017", in contrast the module file shows "(c) 2013 Angel Martin". It took you indeed several years to finish the manual?

You know what's like, the documentation is the most difficult part...

(03-13-2017 05:25 PM)Mike (Stgt) Wrote: ii) All checksums are bad. A pity for such a gem.

iii) The warning on p. 8 about 'slightly different function arrangement in the FATs' in respect to previous versions of your 41Z modules should be placed at a more striking location, on the cover page or on page 2 after 'This compilation, revision A.6.7.' In addition the wording could be unmistakably clear. "*** RED NEON ***: Do not program using functions of this module as with future updates of it the chance is quite high your routines will not work any more or - even worse - present wrong results without any error message." As a. m., no criticism, only a suggestion.

"C'mon, don't be so harsh - it's not that dangerous... I think the warning on pg#8 is appropriate - after all this is for "engaged" users, right? If you don't think so, do you remember what happened last time you changed your Windows version?

(03-13-2017 05:25 PM)Mike (Stgt) Wrote: iv) Manual p. 8 bottom, 'Note for Advanced Users', IMHO the terms 'Upper Page' and 'Lower Page' are confused. The even page of a port is the lower one (8, A, C, E), the odd page the upper one (9, B, D, F). So if XROM #01 of 41Z-Deluxe+ is on page A then its XROM #4 must be on page B.

The information is incorrect as written in the manual. The lower page has XROM 01, and the upper is XROM 04 - thanks for pointing out this typo.

(03-13-2017 05:25 PM)Mike (Stgt) Wrote: v) Same spot as iv) The only reason the ROMs should not be set to "straddled" ports is just the bank switching? A look at the FAT pointers shows that two functions of XROM #01 point to the upper page and many from XROM #04 to the lower page. So wrong placement of the ROMs will most probably cause some deterministic trouble. (Do you really jump from one bank-switched page to the other?)

Actually the 41 OS will happily cope with straddle dual-modules with port-crossing FATs, not a problem from that side.

(03-13-2017 05:25 PM)Mike (Stgt) Wrote: vi) Manual p. 7, last sentence of 2nd paragraph: "All interaction occurs behind the scenes and transparently to the user." Sounds obscure to me, pls explain how I may observe what's going on backstage.

Sure, which part specifically you'd like to know more? Sub-functions? LastFunction? Bank-switching? Non-merged STO/RCL? RCL Math?

(03-13-2017 05:25 PM)Mike (Stgt) Wrote: vii) Manual p. 113 and p. 115 f.: tables missing column header.

It's the same table that starts on page 112.

(03-13-2017 05:25 PM)Mike (Stgt) Wrote: viii) Both secondary banks have a one item FAT, programmable, but just a RTN. I can not see a purpose for it, so could you please be so kind and explain your reasons for this two functions. (Yes, I am nosy, I know.)

They have the same function as the section headers in the main FATs, i.e. they are... well, section headers. ;-) Seriously, you can skip a complete section if you stop the catalog, then hit ENTER^, then SST, then ENTER^ again... very much the same as the CCD Module.

What they are programmable?... because everything on the auxiliary FAT is.

(03-13-2017 05:25 PM)Mike (Stgt) Wrote: ix) The interrupt vectors of both secondary banks are void. For Cold Start and Deep Sleep Wakeup I would do a bank switch (and then branch to normal CS or WKUP routine), just to ensure unambiguous bank state even when running on poor emulators concerning this matter. But - you know it - as a. m., just a suggestion.

Good idea, will see if there's a convenient location to add that code...

(03-13-2017 05:25 PM)Mike (Stgt) Wrote: Leafing through the 116 pages of the manual shows a very impressive piece of work. I have no practical use of complex math so please take my few pettiness-remarks as high estimation of your '41Z Deluxe+' as application pack altogether.

Thanks again... make sure you don't miss the new additions like the DFT, Derivatives and Continuous Fractions.

Cheers,
ÁM

Monte Dalrymple · 03-13-2017, 10:26 PM

(03-13-2017 06:45 PM)Ángel Martin Wrote:
(03-13-2017 05:25 PM)Mike (Stgt) Wrote: ix) The interrupt vectors of both secondary banks are void. For Cold Start and Deep Sleep Wakeup I would do a bank switch (and then branch to normal CS or WKUP routine), just to ensure unambiguous bank state even when running on poor emulators concerning this matter. But - you know it - as a. m., just a suggestion.

Good idea, will see if there's a convenient location to add that code...

Should not be necessary, and is almost certainly not testable. Both Cold Start and Deep Sleep Wakeup conditions are supposed to reset the bank selects to Bank 0. The 41CL hardware does.

hth · 03-14-2017, 05:24 AM

(03-13-2017 10:26 PM)Monte Dalrymple Wrote:
(03-13-2017 06:45 PM)Ángel Martin Wrote: Good idea, will see if there's a convenient location to add that code...

Should not be necessary, and is almost certainly not testable. Both Cold Start and Deep Sleep Wakeup conditions are supposed to reset the bank selects to Bank 0. The 41CL hardware does.

HP does this, and it is not for sure that the calculator goes to sleep before running a poll vector.

Ángel Martin · 03-14-2017, 06:13 AM

(03-14-2017 05:24 AM)hth Wrote:
(03-13-2017 10:26 PM)Monte Dalrymple Wrote: Should not be necessary, and is almost certainly not testable. Both Cold Start and Deep Sleep Wakeup conditions are supposed to reset the bank selects to Bank 0. The 41CL hardware does.

HP does this, and it is not for sure that the calculator goes to sleep before running a poll vector.

I have never run into an issue with the current status (i.e. without the additional "assurance" on the secondary banks) - not on V41, i41CX, all the standard machines, and of course the CL. I too was under the impression that the Cold Start or deep sleep will do that as well, but yes I've seen that done on the 41 Advantage - maybe due to the type of chip they used for that module?

Moreover, all throughout the code there are numerous locations where I haven't been all that rigorous switching back to the main bank - like after an error condition (Data Error, NonExistent, OutOfRange). This doesn't seem to have an adverse effect, the machine is back to the main bank regardless - which should confirm the Deep Sleep assumption.

hth · 03-14-2017, 06:22 PM

(03-14-2017 06:13 AM)Ángel Martin Wrote:
(03-14-2017 05:24 AM)hth Wrote: HP does this, and it is not for sure that the calculator goes to sleep before running a poll vector.

I have never run into an issue with the current status (i.e. without the additional "assurance" on the secondary banks) - not on V41, i41CX, all the standard machines, and of course the CL. I too was under the impression that the Cold Start or deep sleep will do that as well, but yes I've seen that done on the 41 Advantage - maybe due to the type of chip they used for that module?

Moreover, all throughout the code there are numerous locations where I haven't been all that rigorous switching back to the main bank - like after an error condition (Data Error, NonExistent, OutOfRange). This doesn't seem to have an adverse effect, the machine is back to the main bank regardless - which should confirm the Deep Sleep assumption.

Calling an error exit routine from a bank other than 1 will leave the current bank active. In most cases the error is displayed and the calculator goes to light sleep, resetting to bank 1.

However, if flag 25 is set (keep going on error), and you are in a running program, you will carry on with the secondary bank active. Calling a routine in such ROM will cause a NONEXISTENT error as the FAT is no longer visible (as soon as flag 25 is clear).

Regarding the poll vector table. HP resets to bank 1 here, but on second thought that seems a bit overkill to me. If you manage to leave the wrong bank up, you will most likely run into an error not being able to find a routine in the FAT, stop any execution and everything goes back to normal, with a mysterious NONEXISTENT message. Trying to switch the bank back in the poll vector routine will very seldom help to prevent this.

The 41CX ROM resets to bank 1 as part of its poll vector routine, but that only affect page 5. 41CV and 41C does not do this, but they do not have any secondary banks in page 5 either.

My conclusion is that you should never exit back to mainframe without switching back to bank 1 first. Furthermore, you also should reset to bank 1 before going to an error exit routine from a secondary bank, as otherwise this will leave a trap if flag 25 is set in a program. Any poll vector area in a secondary bank can just be filled with NOPs.

Håkan

hth · 03-14-2017, 09:39 PM

I just want to add to previous comment. If it is important that your poll vector is handled every time, then use an entry in the banked poll vector table that points to an ENROM1 bank switch instruction at the location before the real handler in bank 1. That will make it reset to bank 1 and fall into the usual poll vector handler.

Ladybug had an error here. It tried to do the HP trick, but got it wrong and instead caused an unpredictable jump. I have now fixed it to do what is described above, switch bank and fall into the proper handler, should someone manage to leave the second bank enabled.

Ladybug already switches the bank back before doing error exists from the second bank. This should make Ladybug safe in all these aspects, as far as I can see.

So, if Ladybug version 0A is placed next to another bank switched module (so that they are bank switched together) and that other module does not do it right, it may cause problems with Ladybug doing an unpredictable jump.

Håkan

Ángel Martin · (This post was last modified: 03-15-2017 10:50 AM by Ángel Martin.)

I've forced a few errors to test this scenario on the CL and haven't got into any trouble; bank-1 is always switched on even if it's not part of my code...

I should repeat the tests using Clonix/NoVRAM to see if things are also ok there, will report when done.

hth · 03-16-2017, 04:21 AM

(03-15-2017 10:48 AM)Ángel Martin Wrote: I've forced a few errors to test this scenario on the CL and haven't got into any trouble; bank-1 is always switched on even if it's not part of my code...

I should repeat the tests using Clonix/NoVRAM to see if things are also ok there, will report when done.

Try the following program:

Code:

01 SF 25

02 any instruction that cause an error exit from a secondary bank, without switching back to bank 1

03 any instruction in the FAT of the same ROM

Run the program (do not step), you should see NONEXISTENT, switch to program mode and you are at line 03, which looks normal.

The problem is that when a secondary bank is left active and flag 25 is set, the error handler will reset flag 25 and keep running the program (with the secondary bank still enabled). Line 03 will try to look up an instruction from the FAT that is now invisible, and this will result in NONEXISTENT.

The calculator goes to light sleep due to the FAT lookup error and when you press PRGM, it wakes up, resets to default banks and now it will find the instruction in the FAT and can display it.

I deliberately changed Ladybug to go directly the ERRNE from bank 2, then tested it on hardware (41CL/MLDL2000 combo) and with a simulator, both setups behave as described above. The normal code in Ladybug switches back to bank 1 on error exit, and in that case the example runs without any problems.

Håkan