WIP: 16C firmware hack for more memory

[brouhaha]

(02-01-2023 09:08 AM)EdS2 Wrote:  

(01-30-2023 06:40 AM)brouhaha Wrote:  2) The standard 16 labels, but additionally allow LBL CHS <two hex digits>, and similarly GTO CHS and GSB CHS, for two-digit labels (256 labels total, as CHS 00-0F would be the same as the standard labels)

3) LBL, GTO, and GSB always require two hex digit argument, requiring 16C users to adjust to the new entry requirement (256 labels total, but consistent key entry)

I'm really surprised to be seeing support for (3) despite the breaking of compatibility. Doesn't (2) offer the same functionality, but with the no-longer-advanced idea of suppressing leading zeroes? And the benefit of compatibility with earlier, smaller, programs?

I prefer 3, even though it's not entirely compatible with the 16C, because

* There's only one way to enter labels, so as a user, I have to retrain my fingers a bit, but then it's consistent
* It's easier to modify the 16C code to do this, rather than have a new flow involving the CHS key.
* I don't actually know where there's an extra bit of state in the 16C that I can use to track whether the CHS key has been involved in the sequence, without breaking something else. I don't think I can steal a bit from the ST register in the CPU, so I'd probably have to steal it from RAM.

I would observe than the 12C Platinum has done something similar with regard to requiring GTO and GTO . to be followed by three digits, vs. two digits on a normal 12C. I don't recall hearing any howls of frustration over that, but then again, maybe long-time 12C users don' t buy a 12C Platinum.

By the way, if you're asking why people support my option 3, I don't think there was any huge outpouring of support for it. Garry Lancaster's recent post supporting option 3 was for HIS option 3, not mine, although in an earlier post he said he said that of the three options I proposed, he was OK with 2 or 3.