Hello! I am a student who uses the JsTiFied emulator with a TI-84CSE rom, and I enjoy how the calculator lets me use TI software on my iPhone/in a web browser rather than having to carry a calculator. However, the calculator has an issue with the scrolling history- If you scroll up in the history of the calculator, the calculator will error out and the display will start to look odd, forcing you to reset the calculator to keep working, which makes working more difficult. Wabbitemu does not have this issue, so it isn't due to a poor ROM dump, and means that JsTified has a bug itself. It would mean a lot to me for this issue to be fixed, even though it appears that jsTiFied isn't being worked on very much at this point.

Thanks,

Shawn.

There is a thread dedicated to jsTIfied Bug Reports, where posts like this should go. This bug has been reported (by myself) back in 2015, and it turns out this is due to a bug in the OS, rather than jsTIfied.

I believe this is the same bug that cursed the "Program a Game in 60-Seconds" display at Maker Faire this year, which would freeze and have to be reset every now and then.

Regardless; even if it is a bug; it does not properly emulate the calculator. Undocumented hardware features should still be implemented, as undocumented instructions are also implemented.

Then how does Wabbitemu work correctly with this? Using the rom with Wabbitemu works perfectly, and the calculator history works fine then. If the behavior is undocumented, how does Wabbitemu do it?

This issue has now been repaired. To the best of my knowledge, the LCD requires that you read and write bytes in pairs when reading or writing a pixel. In the function that colors history items blue (for the curious, BCALL $54A3, at $6153 on page $03), reads 3 times to determine the current pixel color (white or black), then immediately writes 2 bytes out to color a pixel blue if necessary. jsTIfied's LCD of course keeps track of whether the last byte read/written was the high or low byte, and in this case, it'll be off by half a pixel, leading to random data being read back, apparently leading to the OS majorly crashing (I'm intrigued why, but that's an investigation for another day...). Therefore, since this seems to work on hardware, I added a new variable inside the LCD called lastrw that keeps track of whether the last operation was a read (0) or write (1). If in lcd_write() or lcd_read(), the last operation was the opposite kind, it resets the variable tracking whether the last byte read/written was a high or low byte.

Thank you for lighting a fire under me to get this repaired. Enjoy!