Pushing the 15C to its limits (software labels?)

[Michael Zinn]

Hey everyone.

When I exceeded the 5 User programs limit I wrote a tool for quick remapping, but now I'm running into the 20 programs limit because there are only 20 labels.

Now, it's possible to jump to line numbers using the I register, but since programs can move around those line numbers should probably not be hardcoded on the call site. I think what's needed is a software GTO command that uses some lookup table, either in registers or in program memory. I have some ideas but... has all of this happened before?

I mean, those calculators are from the 80s. Surely ,every limit I bump into must have been overcome before I was born... What's the well-engineered way to deal with label shortage or to get the most out of that calculator in general?

[Joe Horn]

ONE way is by cleverly using the same label multiple times for forward jumps within each program. There is no requirement to use each label only once... unless there is a backwards jump to it.

But it sounds like you're asking about having more than 25 different programs in memory at the same time in a 15C (0-9, .0-.9, A-E). Got me stumped. I never had that many programs that tiny all at the same time. Anybody?

[Michael Zinn]

(04-09-2018 12:22 AM)Joe Horn Wrote:  ONE way is by cleverly using the same label multiple times for forward jumps within each program. There is no requirement to use each label only once... unless there is a backwards jump to it.

But it sounds like you're asking about having more than 25 different programs in memory at the same time in a 15C (0-9, .0-.9, A-E). Got me stumped. I never had that many programs that tiny all at the same time. Anybody?

Yeah, jumping forward to a duplicate label only gets you so far...

My thoughts on this currently look like this:
- If you put the lookup table at the start of program memory all programs will move when you add to the lookup table, breaking all line numbers, so that's out of the question
- If you put the lookup table at the end of program memory the lookup table itself will move. This means you'll have to adjust the lookup offset (only one value, but still annoying)
- I think it's best to put the lookup table in virtual registers of size 2 and the lookup logic at the start of program memory: That way the line numbers don't float around and you can comfortably add new virtual labels at the end. The virtual register size means you can only jump to virtual labels that are on line numbers 1-99, but if you put all virtual labels in the first 99 lines of program memory and the real labels in line 100 and up you might get enough labels (at least for now).

So the plan for the memory layout looks like this:
- virtual label line numbers are stored in virtual registers, starting at real register 18 and growing backwards.
- program memory begins with the virtual label logic, followed by programs under virtual labels, followed by programs under real labels. New virtual label programs have to be added at the end of the last virtual program, right before the first regular real label.

Does this make sense?

[Dave Britten]

(04-08-2018 11:37 PM)michaelzinn Wrote:  What's the well-engineered way to deal with label shortage

Upgrade to a 41 or 42.

[Michael Zinn]

(04-09-2018 12:36 PM)Dave Britten Wrote:  

(04-08-2018 11:37 PM)michaelzinn Wrote:  What's the well-engineered way to deal with label shortage

Upgrade to a 41 or 42.

Where's the fun in that?

[rprosperi]

(04-09-2018 01:00 PM)michaelzinn Wrote:  

(04-09-2018 12:36 PM)Dave Britten Wrote:  Upgrade to a 41 or 42.

Where's the fun in that?

For the kinds of apps you've been contributing, and what you're trying to expand the 15C to (btw, in a very nice article) the 41 or 42 adds much more memory, many new programming flexibilities, alpha characters, and will be MUCH more fun. Try an emulator first if you're not sure, but you owe it to yourself to use a real one, they feel about as good as a calculator can feel.

[Dave Britten]

Note that a 15C would still have a few advantages over a stock 41:

- Matrices
- Complex numbers
- Solver
- Integration
- Hyperbolic trig
- Combinatorics
- Random number generator
- Recall arithmetic (RCL+, etc.)
- X>=0? and X>=Y?

Of course, most of those can either be implemented with the much greater programming capabilities, or via something like the Advantage module. The 42 includes all those features (plus a lot more).

[rprosperi]

(04-09-2018 03:36 PM)Dave Britten Wrote:  Note that a 15C would still have a few advantages over a stock 41:

- Matrices
- Complex numbers
- Solver
- Integration
- Hyperbolic trig
- Combinatorics
- Random number generator
- Recall arithmetic (RCL+, etc.)
- X>=0? and X>=Y?

All true, but for the types of programs OP has been submitting, these don't seem to be the types of applications and tools of primary interest. More importantly, while the 15C is what it is, the 41 does not have to remain stock.

And although not free, upgrading to a 41 (or even better, a 42S, or better still a DM42) will provide near endless room and flexibility for the kinds of small, focused programs he likes.

[Dave Britten]

(04-09-2018 09:44 PM)rprosperi Wrote:  All true, but for the types of programs OP has been submitting, these don't seem to be the types of applications and tools of primary interest. More importantly, while the 15C is what it is, the 41 does not have to remain stock.

Yeah, that was more intended as a disclaimer than actual dissuasion. But matrices and complex numbers are definitely handled more seamlessly on the 15C compared to the 41's Advantage module, so if I were relying heavily on those two specific things, I'd probably opt for the 15C. But the 42 beats them both.

[rprosperi]

(04-09-2018 10:36 PM)Dave Britten Wrote:  

(04-09-2018 09:44 PM)rprosperi Wrote:  All true, but for the types of programs OP has been submitting, these don't seem to be the types of applications and tools of primary interest. More importantly, while the 15C is what it is, the 41 does not have to remain stock.

Yeah, that was more intended as a disclaimer than actual dissuasion. But matrices and complex numbers are definitely handled more seamlessly on the 15C compared to the 41's Advantage module, so if I were relying heavily on those two specific things, I'd probably opt for the 15C. But the 42 beats them both.

We agree completely. Only the DM42 beats a 42S... Got one yet?

[Dave Britten]

(04-10-2018 01:12 AM)rprosperi Wrote:  We agree completely. Only the DM42 beats a 42S... Got one yet?

Yup! Apart from the keys being too stiff, it delivers on its promises.

[grsbanks]

(04-10-2018 12:25 PM)Dave Britten Wrote:  Yup! Apart from the keys being too stiff, it delivers on its promises.

That was also my main problem with the DM42. However, I've had a beta unit for nearly a year now and the keys on it are much softer than the ones on my production unit, which I've had only for a few months now. I know the manufacturing process hasn't changed since the first run of beta units, so I can only conclude that the keys soften over time.

[Michael Zinn]

Alright, I figured it out: You put the label definitions in registers, virtually labeled code at the start of program memory, regularly labeled code at the end and then you append more virtually labeled code right before the first regularly labeled code.

I made vLBL and vGTO programs for this, vGTO can also be used like vGSB.