The list:

Removal of support for interrupt mode 2 on hardware revisions >= I
Removal of OFFSCRPT/ONSCRPT support in OS 5.3
No support in any form for assembly programming, even though it is advertised
Hiding away of application signing keys for whatever pointless reason
Use of 2nd type byte in programs listed in the VAT
Removal of Asm84PCE in OS 5.3.1
Blocking of FreeOS through OS validation at boot
Blocking of Cesium from application list through Application Validation (1 minute 30 seconds!)

---

Today there's some sad news; TI has broken either by accident or on purpose support for mode 2 interrupts. This basically means that user programs can no longer use custom interrupt handling; which is super unfortunate. However, interrupts are still usable within z80 mode via im 1 if you wish to take the assembly route solution.

Affected Revisions: Revision I manufactuerd on 3/2017 and later.

Technical findings: (courtesy of jacobly)

Interrupts in Mode 2 perform exactly the same as Mode 0 interrupts.

What this means:
I will be pulling interrupt support from the toolchain and getting it released as soon as possible. In addition; Oiram will need to be modified to not use interrupts; which will be more pain than I care to deal with.

Lessons to be learned:

TI is both incompetent and dumb. Not only did they fail to fix any of the hundreds of actual security issues, they removed a crucial part of assembly programming. Whoever is behind the development team deserves the boot.

Super lame news. Thanks for sharing.

Does this mean that Oram will not function on newly manufactured CE's ?

Feel free to read for yourself:

https://github.com/mateoconlechuga/oiram/issues/2

Some good news regarding Oiram, at least: it turns out Mateo was able to edit the code quickly so as not to use im 2 anymore, and it now works fine, performance still being good.
Watch the github repo for a release... (he said he was going to improve some things at the same time too)

TI has removed support for OFFSCRPT/ONSCRPT as of OS 5.3. They left all of the handling code for it; but removed the bit check. Again, yet another case of TI being completely oblivious to any sort of code compatibility.

Does TI-Innovator use type-2 interrupts? Because if so, they just broke their own product. Answer: No, nothing in TI ever used mode-2 interrupts.

Now, because they have removed it, Murphy's Law kicks into effect:

They shall make something that needs it.

And honestly, with what they've been doing lately, I wouldn't put it past them.

Sending an email with exactly that to TI-Cares

Is there any possibility of the community being able to design OS patches to bring back those lost features, as was done with the 68K calcs?

The second type byte of variables is used under PTT. This means directory support by a lot of shells can potentially be broken. Added to the list.

That would require modifications to the CPU core logic block, something which, I presume, they wouldn't be allowed to do without permission directly from Zilog. (Unless they added logic to check bus fetches, which is a terrible kludge that we might well be able to circumvent.) It's also disturbing that they would spend tens of thousands of dollars to make a new ASIC revision (shadow masks are that expensive) without making even a token effort to address the bus bottleneck. They're willing to spend a lot of money to break useful hardware functionality, but they have no interest in tripling performance. (For those who don't recall, the eZ80 CPU spends more than 80 % of its time stalled on bus cycles because the internal bus to RAM and flash is a high-latency, high-bandwidth ARM bus; ARMs compensate for high-latency with a cache, which the eZ80 doesn't have, and the eZ80's 8-bit interface can't make use of the extra bandwidth.)

Engineers staying relevant - continually 'improving' the calc design in an effort to remain employed?

*runs*

BTW, jacobly took a photo of the PCB of his rev I 83PCE, TI did completely change the ASIC (well... at least the packaging, going from BGA to QFP... but hey, stuff inside must have changed).
Also, the C10C capacitor + a dozen of test-points + a (CPU?) debug connector spot (without the actual connector) were added/filled. In addition, possibly for the first time in recent (if not all) calc history, they changed the MCB main model-number from SG92* to SG93* (for a reminder, we had that).

Source, with PCB image interactive comparison: https://tiplanet.org/forum/viewtopic.php?f=41&t=20856
Rev I PCB photo: https://tiplanet.org/forum/gallery/image.php?album_id=369&image_id=9088


Note: several people have reported that their rev I feels a bit snappier than previous revs, it'd be interesting to try to determine what exactly got better.
Jacobly confirmed that RAM and Flash access are the same, however.

That's really obnoxious. Luckily, Doors CE can already back up and restore folders, but I'll need some extra logic to do this even when the calculator hasn't reset.

The IM2 changes make me suspect they just switched to a different core design from ZiLog which was compatible for their uses. My guess is the change enabled either a Fab process change or reduced die area which means cheaper product over the lifetime.

Actually switching to QFN likely saves them money on the manufacturing side over BGA. With QFN they can likely use a cheaper process for assembly. Not sure on the pin count but I'd guess they needed to reduce it to switch to QFN and thus possibly needed a revised design of the asic.

!q 191