WIP: 16C firmware hack for more memory

[brouhaha]

I now have trig functions (sin, cos, tan, and their inverses) working in the hacked 16C firmware. I haven't yet found a good place to store the angle mode. I'll have to allocate another "status register" to store it.

tan(90 deg) is giving a 9.99999999e99 result, but not setting the overflow flag.

I haven't yet hooked up the rectangular to polar and polar to rectangular functions.

I also put in factorial, but not Gamma(x+1).

[Garry Lancaster]

The enhancements really are coming thick and fast now. Great to see!

[brouhaha]

I'm starting to think about how to make it available for testing. Maybe as Windows and Linux executables.

[brouhaha]

I'm working on adding the basic statistical functions (CLR Σ, Σ+, Σ-, mean, sample std. dev.) to the 16C. I recently posted a survey of what numbered reegisters are used for statistical accumulation in various HP calculators. In that post, I said that I was considering using registers 0 to 5, like the 10C, 11C, and 34C. However, after thinking this through a bit more, I'm now considiering registers .0 through .5 (indirect 16 through 21) like in the 19C/29C, 323E, 55, 91, and 95C. My thought is that they're still available without indirect addressing, but leave the low numbered registers available for other uses.

I could possibly add a ΣREG function like the 41C/42S, to allow them to be moved, in which case I think I'd still have them default to starting with .0, and also, like most models but unlike the 41C/42S, have n be the first statistical register rather than the last.

What do those of you that might care about a 16C with statistical functions think?

The Σ+ and Σ- functions would the f-shifts of + and -, though only in FLOAT mode. In integer modes those f-shifts would still be OR and NOT. I haven't decided on key assignment for CLR Σ, mean, sample std. dev., and ΣREG, but it would probably make sense to have those as the f- and g-shifted functions of × and ÷, to keep all the stats functions in the same area of the keyboard.

How important would it be to add L.R., ŷ,r, or weighted mean?

It appears that the stack behavior for Σ+ and Σ- are the same for all HP calculators with two-variable statistics, but there seem to be some differences in stack behvaior for L.R, ŷ,r, etc. between models, even within the Voyager series. I haven't checked the actual calculators, but the HP-11C manual says L.R. stores X into LASTx, and lifts Y and Z into Z and T. The 15C manual says that it lifts X and Y into Z and T. I would have expected these models to behave identically.

[rprosperi]

For the stat. register locations, I think default .0-.5 make the most sense. These are out of the way of the 'normal' registers for everyday use but still easily remembered as 'same but with dots' as the normal 10/11/34. And I also think adding a ΣREG function, so the user can move them if needed is a good idea, flexibility is always a good thing.

[Garry Lancaster]

(04-22-2023 06:00 AM)brouhaha Wrote:  I'm working on adding the basic statistical functions (CLR Σ, Σ+, Σ-, mean, sample std. dev.) to the 16C.

Nice! I'd agree .0 to .5 seem sensible with the increased memory, as it's fairly unlikely to have insufficient available registers to use them. Even better if they could be moved, of course, but that's not really an essential. n first to match the other Voyagers also seems sensible.

Quote:How important would it be to add L.R., ŷ,r, or weighted mean?

I personally probably wouldn't miss them, but definitely nice to have available. It depends what other functions you might possibly be considering including instead

[brouhaha]

The functions I'm planning to add can be seen in the right pane of this screen capture of a program I'm working on. It's pretty ugly now, but the intent is to be able to drag the new functions to the assignable key locations, to experiment with the FLOAT-mode keyboard layout.

   

[Garry Lancaster]

(04-23-2023 04:03 AM)brouhaha Wrote:  The functions I'm planning to add can be seen in the right pane of this screen capture of a program I'm working on. It's pretty ugly now, but the intent is to be able to drag the new functions to the assignable key locations, to experiment with the FLOAT-mode keyboard layout.

Great, thanks for sharing.

I notice you have 34 new functions, which I assume is to match the number of "operations not active in floating-point decimal mode" (excluding A-F) section in the manual, plus WINDOW and #B (which aren't listed, but also are not active).

Looks a really well-chosen set of functions. However, I wonder if it would be possible to also add the very useful ->H.MS and ->H conversions? This could perhaps be achieved by replacing the three separate DEG/RAD/GRAD functions with a single DRG key that can cycle through the modes. It always seems a waste to have 3 separate keys for that.

Alternatively, maybe ->H.MS and ->H could replace D->R and R->D, which are more trivial to calculate manually and are, IMHO, less useful.

[brouhaha]

(04-23-2023 08:48 PM)Garry Lancaster Wrote:  I notice you have 34 new functions, which I assume is to match the number of "operations not active in floating-point decimal mode

If my count is correct, there are 42 positions available, if unshifted A-F and the SET COMPL functions are included.

Quote:However, I wonder if it would be possible to also add the very useful ->H.MS and ->H conversions?

The list of new functions available was (and is) preliminary.. I've already added those and a few more to the latest work in progress.

Quote:This could perhaps be achieved by replacing the three separate DEG/RAD/GRAD functions with a single DRG key that can cycle through the modes. It always seems a waste to have 3 separate keys for that.

I prefer to keep them separate, both to match other HP models, and to make them unambiguous when used in a program. (Of course, looking at the program line will still have ambiguity with regard to whether the line is executed in an integer mode or FLOAT mode.)

Here's a new image. Due to some internal rework, I've lost the legend colors, but they'll be back soon.

   

[Garry Lancaster]

(04-23-2023 09:10 PM)brouhaha Wrote:  If my count is correct, there are 42 positions available, if unshifted A-F and the SET COMPL functions are included.

I would make it 43, although as that matches your new image, perhaps 42 was just a typo.

I'm sure you're aware of this, but the set complement functions actually do work in float mode and affect the conversion when switching to integer mode. No great loss IMO if they were repurposed in float mode, though.

Quote:I prefer to keep them separate ... to make them unambiguous when used in a program.

Ah yes, good point. I hadn't considered that.

Quote:Here's a new image. Due to some internal rework, I've lost the legend colors, but they'll be back soon.

Excellent, this is definitely shaping up to be my perfect calculator!

[brouhaha]

(04-23-2023 09:37 PM)Garry Lancaster Wrote:  

(04-23-2023 09:10 PM)brouhaha Wrote:  If my count is correct, there are 42 positions available, if unshifted A-F and the SET COMPL functions are included.

I would make it 43, although as that matches your new image, perhaps 42 was just a typo.

I've gone over it again, and I still count only 42 assignable positions:

Code:


    6 f A-F (shifts and rotates)
    6 g A-F (LJ, shifts, and rotates)
    2 MASKL, #B
    1 MASKR
    2 RMD, DBLR
    2 XOR, DBLdiv
    3 SB, CB, B?
    2 AND, DBLx
    1 NOT
    1 OR
    1 WSIZE
    2  <, >
    4 SHOW HEX, DEC, OCT, BIN
    6 A-F
    3 SET COMPL 1s, 2s, unsigned

If you think there's a 43rd, let me know where.

I conider the complement mode to be the least desirable, and the unshifted A-F to be the next least desirable, but in principle I can reassign them in FLOAT mode.

[Garry Lancaster]

(04-24-2023 07:06 AM)brouhaha Wrote:  If you think there's a 43rd, let me know where.

The other one I had was WINDOW.

Quote:I conider the complement mode to be the least desirable, and the unshifted A-F to be the next least desirable, but in principle I can reassign them in FLOAT mode.

I'd definitely agree with both of those. Labelling will be a challenge, especially if unshifted A-F are included.

[brouhaha]

(04-24-2023 04:19 PM)Garry Lancaster Wrote:  The other one I had was WINDOW.

I forgot that I had omitted WINDOW.. I omitted it because it doesn't work well as an alternate FLOAT function. It requires an argument of 0 to 7. I suppose in principle this would be a way to cram in another eigth functions, in the same way as the 15C "MATRIX [0-9]" and "TEST [0-9]". But that sort of thing always reminds me of the TI 58/59 "2nd OP" stuff, which I very much dislike.

[Garry Lancaster]

(04-24-2023 05:23 PM)brouhaha Wrote:  I forgot that I had omitted WINDOW.. I omitted it because it doesn't work well as an alternate FLOAT function. It requires an argument of 0 to 7. I suppose in principle this would be a way to cram in another eigth functions, in the same way as the 15C "MATRIX [0-9]" and "TEST [0-9]". But that sort of thing always reminds me of the TI 58/59 "2nd OP" stuff, which I very much dislike.

Fair enough, I didn't realise the arguments had to match.

I suppose it could potentially be used for something like viewing the statistics registers, but maybe not particularly worthwhile.

[brouhaha]

(04-24-2023 08:06 PM)Garry Lancaster Wrote:  Fair enough, I didn't realise the arguments had to match.

That's a result of reusing the same program instruction codes for the new FLOAT mode operation.

I haven't yet added the ability to have new instruction codes, e.g. for having more LBL, GTO, GSB. Once I have that going, it would be possible to have WINDOW behave differently in FLOAT mode, though I would still be reluctant to do it, because it would make looking at a WINDOW line in a program even more confusing than the other new FLOAT mode operations.

Maybe once the instruction code expansion is in place, I should actually assign new codes for all of the new FLOAT functions, and display them in a program line as e.g. "FL 42 A" for the FLOAT f-shift of the A key, rather than just "42 A". If I did that, then "42 A" would always be SL, and be a NOP in FLOAT mode, while "FL 42 A" would always be the FLOAT mode function, and be a NOP in integer mode. I think this would probably be better, but it's a fair bit more work, so I'm not entirely sure that I'll do it. Opinions on that are welcomed.

[Garry Lancaster]

(04-25-2023 04:42 PM)brouhaha Wrote:  Maybe once the instruction code expansion is in place, I should actually assign new codes for all of the new FLOAT functions, and display them in a program line as e.g. "FL 42 A" for the FLOAT f-shift of the A key, rather than just "42 A". If I did that, then "42 A" would always be SL, and be a NOP in FLOAT mode, while "FL 42 A" would always be the FLOAT mode function, and be a NOP in integer mode. I think this would probably be better, but it's a fair bit more work, so I'm not entirely sure that I'll do it. Opinions on that are welcomed.

I can't really see how that would work in practice. If you were entering a program which switches between integer and float modes you'd have to keep exiting program mode, changing the current integer/float mode and then re-entering program mode in order to enter the correct code. That would be really irritating.

I suppose the program mode could try and keep track of the last int/float mode switch instruction, but it would be messy and pretty much impossible to get right in all circumstances (eg after a label).

So I think it would be better to keep the same codes regardless of which mode you are in. It's not as if stepping through a program on the 16C gives you particularly readable code anyway - the keycodes are more just to check against actual source, written on paper or whatever, or for debugging with singlestep. IMO there's little benefit in having "FL" to remind you whether 42 A refers to SL or (say) SIN, when your source is going to tell you anyway.

[brouhaha]

At HHC 2023, I demonstrated modified 16C firmware with the memory expansion discussed in this thread, and natrual and common log and exponential functions, y^x, factorial, and trig and inverse trig (currently degrees only). I've been working on the basic statistical functions.

I demonstrated these running in my Nonpareil simulator, and also in a physical SwissMicros DM16L, which I passed around.

[Paul Dale]

WINDOW with argument lines up very neatly with the statistical operations....

[blackjetrock]

(01-22-2023 02:53 AM)brouhaha Wrote:  I don't have it completely sorted out, but I did figure out how the 0xe0 RAM base works in both the register addressing, and in limiting the size of a program. I'm able to make that 0xc0, which allows for 427 program steps, or 854 registers (if word size is <= 4 bits). In principle I should be able to expand it even further. but I haven't tried yet.

I've just watched the video which included this change and it was mentioned that there was only room for two instructions to calculate the RAM address.
As this is emulated code, surely it is possible to have more than one instruction at an address? The strict one to one relationship between addresses and instructions that the hardware imposes on a real machine doesn't necessarily need to apply when emulating instructions?

[brouhaha]

(11-10-2023 08:38 PM)blackjetrock Wrote:  As this is emulated code, surely it is possible to have more than one instruction at an address? The strict one to one relationship between addresses and instructions that the hardware imposes on a real machine doesn't necessarily need to apply when emulating instructions?

I have a simulated program counter that points to an simulated ROM word, so without going too crazy in inventing new embellishments to the Nut architecture, I still only get two instructions in two ROM addresses. Or one two-word instruction, such as a subroutine call to elsewhere else.

The two-word thing was interesting, in that it limited the choices available unless I replaced it with a subroutine call. A much bigger acoomplishment was fitting a higher-precision divide-by-14 routine (multiplication by a higher-precision approximation of the reciprocal of 14) in the less space than the original, and having it work just slightly faster.

When I got the HP-41C and HP-41CX microcode running on the DIY5 hardware the late Richard Ottosen and I built, in order to add four-level stack display, I had the simulator trap certain PC addresses and do special things. The four-level stack display actually runs the microcode that formats the X register display four times instead of just one, for T, Z, Y, and X in that order, so that at the end of the iterations, the calculator state should be identical to what it would be if only X were displayed. There were several other such hacks to increase the number of flags, etc. (I have no idea whether the SwissMicros firmware for their DM41X uses similar techniques.)

In the case of the HP-41, I was worried that actually changing the mainframe ROM image could break things. In the case of the HP-16C, it is a much more contained problem, due to having no plug-in ROMs, so I'm more confident in my ROM patches.