41-MCODE: Dr. Jekyll & Mr. Hyde



#11

While waiting on Monte´s new Image Database functions (and really wishing they were available already...) I spent a little time experimenting with ideas to overcome the 64-function FAT limitation.

I just added a new entry to the articles section, hope you find it interesting.

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=1173

Cheers,
AM


Edited: 7 July 2012, 4:03 a.m.


#12

Hi, Ángel;

Although I have not yet had the chance of delving deeply into the 41-Mcode - just a few experiments some six, seven years ago - I could understand the idea and the concept, and I found it an ingenious solution. But I would also add that the naming is as ingenious as the solutions itself. It's both entertaining and enlightening at the same time.

Priceless joy! THANKS!

One question about the 'check upon the calculator-ON event' feature. I remember that there are four reserved addresses at the end of each 4K-ROM area: one of them is used for the ROM review ID and at least two of the others hold 'subroutine' calls for specific ON events. Would it be possible to associate this subroutine call to a buffer content, I mean, like DJEKYLL and MRHYDE, could the calculator 'reaction' to a key pressed while turning ON be different according to a previously set circumstance, i.e., after a command like the ones above? I know this would lead to the need of turning the calculator OFF and back ON prior to the needed features to become active, but that would also allow some features available in some modules - like the AECROM - not to conflict with other modules' features when you want other modules' features to have such functionality as well. Just a brain flicker...

The other question looks more like a Devil's advocate question: what happens if, by any kind of bad luck - power surge, low battery condition -, the actual swapping part of the subroutine, from steps A07B to A082, is interrupted before the complete tables are reconstruct? Am I wrong concluding that the calculator will have mixed up, partially rebuilt tables? If so, will the calculator freeze in case it happens?

Please, forgive me if my conclusions are wrong and if I also unnecessarily mixed up some users' thoughts... 8^(

Best regards.

Luiz (Brazil)


#13

Hi Luiz, glad to hear you liked it.

Quote:
from steps A07B to A082, is interrupted before the complete tables are reconstruct?

Well, that's I suppose technically possible but remember that it takes a few miliseconds to do the complete tables, so it really isn't any likely at all.


Quote:
will the calculator freeze in case it happens?

no it wouldn't, just the FAT would be mixed up but it could be rebuilt just by running the function again. It really is a very harmless approach, despite its initial looks.


W.R.T. the "seven scanning enty points" - otherwise known as polling points. There are seven in total, each of them kicking in as a poll from the OS upon the specific event. The ON event is different from the OFF one, so no conflict from that part.

There's some information in the HEPAX manual, and Ken Emery's book as well. Maybe also in the ZENROM manual but I haven't looked. I mostly learned about them just by looking at the way it was used in those power modules, like the CCD, etc.

Cheers,
'Angel

#14

After a few more CPU cycles I´ve reverted to the HEPAX approach - one more time the HEPAX is the standard-setting with their masterful implementation, can´t be emphasized enough!

Its multi-function functions (HEPAXA, XFA) manage to be both Dr. Jeckyl and Mr. Hyde sort of simultaneously, effectively offering a sub-FAT within each of them.

So here´s the deal: the next incarnation of the POWER_CL module will have three banks, with bank3 containing more stuff in the same fashion.

Now that I come to think about it, this would be the ideal solution for the IMDB functions, as a second bank of YFNS... hope Monte is reading this :)


#15

The problem with this approach, from my perspective, is all of the units in the field... with YFNZ in a protected sector of Flash. This makes it difficult for a user to upgrade. The YFNZ and YFNS mnemonics do not use the IMDB, but are hard-coded. I did this to make sure that they would still be available even if the IMDB got corrupted. So these mnemonics cannot be used to point somewhere else. I suppose that I could use a different mnemonic for a new bank-switched version... But with the MMU it is simple to just PLUG an alternate version in place of the current one...


#16

Hi there,

Well, seems like I'll have to get back to job and include banks 3 & 4 to the Clonix/NoV's configuration features.

Oh! how I miss those days when SW developers wait until the hardware was built and ready to support their programs... ;-)

BTW I also think the HEPAX approach to multifunctions is the most convenient.

Will keep in touch.

Diego.


#17

Sorry to rock your boat Diego but yes, adding a third bank to the POWER_CL is in the works and will soon be available. The temptation is too strong to resist, and the benefits of the sub-functions approach are just too many to ignore.

I guess we can start on the CL and then migrate to the Clonix/NoV's as you implement the fixes. No rush though, if this has waited 35 years so far I'm sure it's not an urgent thing :-)

Cheers,
ÁM

Edited: 9 July 2012, 6:37 a.m.


#18

Hi Ángel,

It's ok, since the HW is already full 4 banks compatible.

Just re-tooling the firmware and (most difficult part) the required configuration upgrades, but that's a hobby, it wouldn't be funny if it wasn't chanllenging... ;-)

Fortunatelly, I've got my ten fingers back to full funtional status.

Cheers!

Diego

#19

Yes I see the point, the MMU is more capable and less restricted than the bank-switching method - and having sRAM pages a-plenty certainly removes any doubt.

and speaking of this, will the new IMDB functions be ready soon?


#20

Sorry it's taken so long. I can only do about a hundred lines of code per day. The search routine was fairly involved (and still isn't working completely). To make matters worse, I have Jury Duty starting today...


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP-41 MCODE: The Last Function - at last! Ángel Martin 0 147 11-08-2013, 05:11 AM
Last Post: Ángel Martin
  41-MCODE: Auto XEQ+ALPHA possible? Ángel Martin 5 269 05-29-2013, 06:15 AM
Last Post: Ángel Martin
  HP 41 Mcode related Questions Michael Fehlhammer 4 246 05-10-2013, 07:09 PM
Last Post: Michael Fehlhammer
  One for Mr NAMIR PGILLET 4 204 03-23-2013, 09:59 AM
Last Post: Dieter
  41-MCODE: Breaking the FAT barrier. Ángel Martin 0 116 09-03-2012, 06:31 AM
Last Post: Ángel Martin
  HP41C: Factorial (kind of) in MCODE Frido Bohn 7 331 05-26-2012, 09:18 AM
Last Post: Frido Bohn
  41-MCODE: SOLVE & INTEG - 4k ROM Ángel Martin 9 362 04-19-2012, 05:29 AM
Last Post: fhub
  41-MCODE: a weekend challenge Ángel Martin 3 178 03-19-2012, 06:49 AM
Last Post: Mike (Stgt)
  41-MCODE trivia: backwards or forwards? Ángel Martin 3 172 03-05-2012, 04:38 PM
Last Post: Håkan Thörngren
  32-bit MCODE tool chain for the HP41 incl. D41 now MichaelG 4 212 02-12-2012, 08:57 PM
Last Post: Kerem Kapkin (Silicon Valley, CA)

Forum Jump: