HP-41: Has anyone used the Laitram rom?



Post: #15

If so, what do you think about this takeover rom?


Post: #16

Hi, Geir;

right after building the MLDL2000 and adding a NoVRAM and a NoV32 to the 'troup', I had the change to get to know about the so many modules that existed for the HP41. I can tell I am one of the 'newest' users of these extensions amongst the 'older' worshipers of the HP41 system, though...

About the Laitran: I read about it, took a look at the manual but I was actually a lot interested on HEPAX, CCD-family, AECROM, FORTH ROM, Advantage, amongst some others. I must confess I never give it a try because it seemed to me that the proposed functionality was not something I was seeking for.

I'll get closer to it and let you know.

Cheers.

Luiz (Brazil)


Post: #17

I actually got one on eBay (at a very affordable price) and sold it later on - that should give you an indication of my appreciation for it... all that ado for nothing much, in my opinion.

Post: #18

Yes, I have one buried away in a box along with its special touchpad overlay. In my estimation it was a solution in search of a problem.

J.M. LaPeyre (I think that's the spelling) made his fortune in shrimp processing (Bubba Gump?) and a special staggered tread industrial stair/ladder (called the LaPeyre Stair), and he hired Dave Conklin and co. for the project. J.M. himself demonstrated the product at the 1985 users conference in Atlanta, and if memory serves Dave was there.


Post: #19

Can someone explain, in a few words, what this ROM is about?


Post: #20

AFAIR all possible functions are accessible with a few key strokes.

HTH

Raymond


Post: #21

Correct. It's a takeover rom where 16 keys are active and with combinations of keys, all HP-41 functions are available with very few keystrokes (2?).


Post: #22

... Sinclair´s keyboard conception. If the idea was to reduce keystrokes while entering (large) programs, maybe it is a solution. I´m addicted to [XEQ][ALPHA] spell [ALPHA] or the [USER] shortcut, though.

Luiz (Brazil)

Edited: 14 Jan 2010, 2:37 p.m.


Post: #23

Quote:
... Sinclair´s keyboard conception. If the idea was to reduce keystrokes while entering (large) programs, maybe it is a solution. I´m addicted to [XEQ][ALPHA] spell [ALPHA] or the [USER] shortcut, though.
Maybe one of you MCODE experts could write something that allows multiple KEYS files, so USER keyboards could be swapped out quickly like on the 71. Without it, I think you would have to run a program with lots of PASN's and it would be slow and take more memory. I haven't reviewed this recently so I may be forgetting something.

Post: #24

Hi, garth;

Ángel´s first 4K 41Z had a programmable, complex-addressed USER keyboard through a single MCODE function. Anyway, any pair of consecutive USER assignment (or after packing the existing ones) will ocupy a main RAM register, as we know.

For me, the best cost-benefit relation is the use of sofkeys (HP19, HP28, HP42S, HP48-series and so), and in some applications, like the ones in the HP41 Advantage Pack, such feature is simulated (not the softkeys themselves, something close to). The HP32S also takes advantage of the ALPHA keyboard with the addition of the small arrows pointing to the active keys.

The main issue of the USER keyboard is to remember what is assigned to which key, and I believe the [NULL] feature in the HP41 was one of the solutions to help the user to 'check before using' a particular key in user mode. If we have a set of USER keyboards, I guess the user would have to retain more information, though.

Please, these are just my own considerations about the subject. I neither have an answer, nor a solution to propose, but I really would like to have another possibility for the multiple user defined keyboards.

Cheers.

Luiz (Brazil)


Post: #25

Right. When I program FOCAL I do as the Advantage module (this I advice in the FOCAL coding standard).

The Laitram keyboard overlay is some crazy piece of thingymawiz

Post: #26

Quote:
Ángel´s first 4K 41Z had a programmable, complex-addressed USER keyboard through a single MCODE function. Anyway, any pair of consecutive USER assignment (or after packing the existing ones) will ocupy a main RAM register, as we know.
I am looking forward to using 41Z after I get one of the modules that can hold such images. But as for the RAM space taken by key assignments, I'm thinking of KEYS files in extended memory or one of the newer plug-in modules with more RAM file space. Then only the active assignments take any of main RAM.

Quote:
For me, the best cost-benefit relation is the use of sofkeys (HP19, HP28, HP42S, HP48-series and so), and in some applications, like the ones in the HP41 Advantage Pack, such feature is simulated (not the softkeys themselves, something close to). The HP32S also takes advantage of the ALPHA keyboard with the addition of the small arrows pointing to the active keys.
I do this on the 41 with local alpha labels as well as with GEYKEY and GEYKEYX. Useful functions, although not the same thing.

Quote:
The main issue of the USER keyboard is to remember what is assigned to which key, and I believe the [NULL] feature in the HP41 was one of the solutions to help the user to 'check before using' a particular key in user mode. If we have a set of USER keyboards, I guess the user would have to retain more information, though.
For this reason, I frequently change key overlays on the 71. I only have one for the 41 that I could write on (I should have bought a bunch when they were available), plus the special-use ones that came with the 41 and its modules. The guide for the text editor is on the back.

Edited: 15 Jan 2010, 2:21 a.m.

Post: #27

Both the 41Z and the SandMath modules have their own "USER function files" - very comparable to Garth's example with the 71B.

On the 41Z (either 4k or 8k version) it's called ZKEYS; on the SandMath it's called MHKEYS. Either one will remap the User keyboard to a pre-assigned function set, pertinent to the module in question.

As much as this is a good approach, I find this technique a little taxing on the user: because there are that many functions, there's a lot of toggling the USER mode on and off to also access the native 41C functions (or else lot of XEQ-Spelling). It also uses up a chunk of main memory with the key assignments "buffer" .

That's why I wrote the Complex Keyboard function (ZKBRD) on the 41Z (8k version). It provides access to many more functions than available on the basic layout, it does NOT conflict with the native or the user assignments, and it doesn't take any memory register. A charm, if you ask me. The cost of course is a lot of programming behind the scenes to make it happen.

Take it for a spin and you'll see what I mean.

Cheers,
"AM

Post: #28

Sounds rather like the eG0BEEP functions.


Forum Jump: