The TI-84 Plus CE will be available soon, and although we don't publicly know a lot about how things like peripherals, RAM, and Flash are configured, we do know that it follows the general design of the older calculators and has an ez80 core. Therefore, jsTIfied is going to need some upgrades to support the TI-84 Plus CE, and UnknownLoner has generously offered to help implement those additions. I'm hoping that some other community members will have some time to help out, but in the meantime, this thread is for planning our necessary changes to support the TI-84 Plus CE.

In addition, I have collected a number of suggestions from Runer112 and AHelper that were posted in the jsTIfied 1.0 topic. I really appreciate both of their work in cataloging features and bugs that need to be addressed in jsTIfied as it currently stands.

Debugger Improvements

• Memory and disassembly viewers need to use infinite scrolling in both directions. Requiring clicking a button to scroll is not required.
  
• Clicking to jump to PC needs to scroll to PC, not change have the start of the list be PC.
  
• The list should follow the PC while stepping.
  
• Hitting a breakpoint should show the breakpoint to the user.
  
• The current IM should be shown and be changable.
  
• There should be a way to set the PC to the currently selected instruction.
  
• A stack viewer should be added
  
• You cannot change the pages mapped to memory, this should be allowed.
  
• Flag checkboxes don't change F.
  
• Show if interrupts are enabled and allow that to be toggled.
  
• Disassembly view cannot display ld (ix+nn),mm properly. DD36FE08 shows ld (ix-$-7fe),$8ef
  
• Hitting enter/return in the address textbox for the memory and disassembly viewer should accept the value and jump there.
  
• Flags checkboxes should be disabled when running.
  
• Either I'm doing something wrong, or you can't actually continue out of a breakpoint.
  
• Step out. Feel free to chat with me on IRC about how to best implement this one, as it might be tricky. May also result in an improvement of the step over logic.
  
• The I and R registers should be visible in the debugger (and editable).
  
• The "p" flag should probably be labelled "p/v" if it can fit.
  
• The page bank boxes should not be editable.
  
• There needs to be a way to view the contents of arbitrary ROM/RAM pages in both the disassembler and the memory viewer.
  
• Index register bit instructions are disassembled as three bytes instead of four. The offset appears to be ignored and always zero.
  
• The debugger seems to choke on a number of undocumented instructions, mainly duplicate instructions or instructions that do nothing. The ones I've found: do-nothings (any "invalid" ED, DD, or FD opcode; should either be disassembled as a 2-byte nop or noni \ nop), duplicates of neg, duplicates of the im variants, the unknown im (ED4E/ED6E; it might actually be im 0 or im 1, but people who don't know have called it im 0/1), and the extended hl store and load instructions. I hope they're at least emulated correctly, but I haven't checked. Might be another topic worth chatting more about to make sure everything's covered.
  
• The "Continue" button should be disabled when emulation is running.
  
• An option to auto-update the disassembly/memory view tabs (while either stepping or running) would be nice.
  
• Options to emulate the missing RAM pages on newer 84+/84+SE calculators and to emulate the "real" Z80 in 83+ calculators could be nice.
  

Emulation Improvements

• Break on invalid flash commands (catches accidental flash writes or commands that are invalid)
  
• Clicking buttons quickly causes the page to get selected.
  
• Step over fails to function as it just continues. Happens with instructions as simple as ld a, $ff.
  
• The emulator should start in the bootcode of the calculator.

Bugs

• Loading a ROM from a clean state does not start the CPU, you must reload the page for it to start emulating and possibly try continuing in the debugger. You can also open the debugger and step through each instruction, but it will not continue.
  
• Creating the ROM uses the word 'Uploaded'. This implies that you uploaded the ROM to some location. Replace with 'Created'.
  
• Timestamp for creating the ROM image does not use the user-set date formatting string.
  
• Continuing to speak of key binds, it seems like every unbound key translates to down. They should probably translate to nothing.
  
• Related to keys, something about the keypad hardware emulation seems inaccurate. I first noticed this with my Pokemon demo program for GrayLib for which a VARS input, which should open the grayscale tuner, is interpreted as a CLEAR input, which quits the program.
  
• The filename provided for some variable exports is just the extension (without the '.'). This seems to at least occur with appvars with lowercase letters in their name.
  
• The filename provided for application exports needs to be translated based on characters, not tokens.
  
• The size reported in the variable export list of applications is very wrong. Currently seems to be the page it starts on times 256 plus its number of pages.
  
• Refreshing the variable list with a corrupted VAT hangs the page.
  
• Loading a file from SourceCoder pauses the emulator and blanks the screen to white.
  
• However grayscale is emulated is very strange and can probably be improved. For instance, the GrayLib tuner: https://dl.dropboxusercontent.com/u/34812306/jstified_gray.gif. No, that's not your eyes. Even the fully white parts of the screen are pulsating.
  
• The screen cumulatively darkens with each breakpoint hit in quick succession.

UI/Useability Improvements

• Switch to jQuery for UI for simplicity
  
• Full-speed indicator is confusing, recommend using more universally recognized icons, such as a turtle and hare.
  
• Button lock. Wabbitemu allows this with a right-click menu, but perhaps a hold for something like 0.5s+ is better.
  
• If it's possible to distinguish right shift from left shift, it would be nice to bind right shift to CLEAR (does CLEAR even have any binding currently?).
  
• Logging in from the sidebar while on the jsTIfied page once redirected me to http://www.cemetech.net/forum/projects/jstified instead of the correct URL, http://www.cemetech.net/projects/jstified.
  
• Assembly programs should not provide an option to be exported to SourceCoder.
  
• The size reported in the variable export list of all variables that are not real numbers, complex numbers, or applications seems to include the 2 bytes contributed by the header size word. This doesn't seem desired.
  
• Attempting to load a file from SourceCoder that won't fit appears to currently do nothing. Instead, an error message (either via the browser or via the calc's OS) should probably occur.
  
• To go above an beyond other debuggers, I would recommend not just a port viewer, but configuration for the various peripherals in the ASIC. Rather than display the control port for the LCD, show the current row, column, and other settings. Same could be done for the timers, USB, etc.

To answer the question on CLEAR, I think clear is either right shift or '/' right now. I know it has a binding
Anyways, I havent read the thread entirely yet, but a few things I'll mention that I've been thinking about for awhile.

A few more 'radical' ideas:
I've been thinking that it might be useful to develop the z80/ez80 core separately from the rest of the code, and have all the calc-specific bits plug into it if you will. That can make it easier to test too since we could write a series of tests which run in node.js for the processor itself without the browser. We could also split the calculator models themselves into different projects. Obviously some functionality is the same between them, so one project could serve as the base of another, but separating them would make it less confusing to deal with differences in ports, memory, etc. A logical separation to me (with my limited knowledge of hardware differences) seems like one project for B&W, one for CSE, and one for CE, since it seems like not a lot is different between the B&W calcs aside from a crystal timer in some, some extra ram pages / archive in some, and maybe a few other things. Comments on whether anyone else thinks this is a good idea would be appreciated.

On features: as Kerm knows, I've wanted to provide a WebGL display with the Canvas 2D context serving only as a fallback where WebGL is not available for quite some time now. WebGL can let us do things like greyscale emulation, Z-Shifting, Color Inversion, Interlacing (for half-res mode), and any other effects we may need all in GLSL shaders. This shifts the work to the graphics card and leaves the CPU more power to actually work on emulating the processor. Even if the emulation is already running at full speed, this means the processor doesn't have to work as hard. That's especially useful on devices with batteries, it can reduce battery drain. Now is as good a time as any to add it since we're changing a lot of other things at the same time. As you can see here, even the latest iOS and internet explorer support WebGL, so we may as well take advantage of it.

I've also recently had the thought that we could implement sound playback from the linkport with the WebAudio API, since that lets you create and play arbitrary sound data at runtime. Not as useful as other features, but might be fun.

For gifs: I'm convinced that we can do a lot better than we are in terms of palette picking and speed. When I run the gif recorder my emulation starts to slow down, and if possible it'd be nice if we could avoid that without sacrificing framerate. I'll need to look into it a bit further though because I'm no expert on that sort of thing.

Suggestion: In Google Chrome, double clicking (clicking twice within the same second, which, given an attention span crafted by the Internet, feels like an eternity) highlights the emulator. This does not happen in IE. Any way to fix it?

Actually yes, we can just add an event.preventDefault() to the onClick and it should work (I think)

Animated GIFs continue to be a very hard problem, because we're getting the worst of both worlds, slowing down emulation because we need to spend some time picking palettes and saving frames, and getting inaccurate palette choices because we're trying to use a more circumspect method. Would using WebGL allow us to take animated GIF screenshots any more efficiently? Has an animated GIF library that is better than mine and has a jsTIfied-compatible license been created in the past 18 months or so?

I definitely support this feature. MESS has it, and it could theoretically approximate Wabbit and Pindur's similar features.

Since mobile devices are more and more important to jsTIfied's audience (I believe jsTIfied may be the only way to run a TI calculator on iPads and iPhones, for instance?), I support anything that gets us better mobile performance wholeheartedly.

I think the only part of our z80 core that bleeds into the rest of the emulator is the interrupt handling, so I feel like it's already pretty modular. I suspect that adding an ez80 core could be done pretty easily, but I'm almost tempted to suggest that we try to just modify our z80 core into an ez80 core, and run it in z80 mode for the z80 calculators. On the other hand, that might throw off things like timing because of pipelining, so it's probably not the best decision in terms of emulation accuracy.

I'm sure you're aware how atrociously slow jsTIfied v1 runs on mobile. I really don't see this improving much, granted I don't know anything about WebGL and how it'll improve the speed with the limited resources iOS hardware provides.

On my Nexus 5, it runs at just about realtime speed; on Eeems' FirefoxOS device, it also runs close to realtime speed. What device and OS combination do you mean by "mobile"?

Offloading the rendering to the GPU should allow for pretty drastic speedup if any substantial time is currently spent in the rendering loop, with added special effects to better emulate the LCD physics with essentially nil-overhead on the emulator core.

Also, for screenshots, https://github.com/hughsk/gl-gif

Maybe Kerm should start following along in the graphics tutorial thread

Over the last few days I've been working on jsTIfied, trying to get everything in order for the ez80 and TI-84 Plus CE upgrades. Much of this has ended up being optimization, and most of the remainder has been code cleanup and reorganization:
:: Changed icons above calculator to CSS sprites
:: Moved file-related functions into a separate JS file
:: Used a trick that Tari showed me (the <a> download attribute) to eliminate the need to bounce downloaded files and screenshots through the Cemetech server. jsTIfied state is now completely stored on the client and never touches the Cemetech server.
::z80 core optimizations: Explored extensive tricks to optimize the speed of the z80 core, leading to in some cases a 200-300% speedup in CPU-intensive, LCD-light operations when the speed governor is disabled.
:: Added jQuery as a dependency, simplified certain event and UI-related functionality, improved handling of unmapped keys.

For once, these changes haven't been made live, as the production version of jsTIfied and the private development version are now separate. I have a few more repairs I need to make before I merge these changes into the production version. In addition, unknownloner is working on improvements to LCD rendering and screenshotting, the completion of which should get us to the point where we are ready to add TI-84+CE support.

Some final notes, testing an intermediate form of the optimized z80 core with a TI-84+SE ROM on Chrome:
- Counting to 200 with disps: 37 seconds
- Counting to 200 with disps, non-fancy LCD: 31 seconds
- Counting to 20,000 without disps: 22 seconds
- Counting to 20,000 without disps, non-fancy LCD: 14 seconds

Edit: I fixed a problem with loading the z80 core from localStorage, and now my optimizations and fixes are live. The work continues!

Edit #2: I changed how key click handlers work, so now rapidly clicking keys in Firefox, Chrome, or IE will not highlight the whole calculator. This change is live. I'm also experimenting with a visual indication of which key was clicked.

Edit #3: The keymaps are now SVGs instead of image maps. I'm working on making sure no functionality has been lost before I roll this out to the live version. I'm also hoping to add the ability to visually indicate which keys have been pressed, even if you use a hotkey.

This is the first time I've used jsTIfied, and it's quite good, especially given that it's all browser-based. When I was asked to test it out just a short while ago, I found the following problems listed below. Other problems found but not able to be reproduced are not listed.

Browser: Firefox 36.0
TI-83 Plus SE ROM loaded with OS ver 1.16

Issues noticed:

* CPU (Debugging console) Changes made to the CPU state does not stick.
* ON button on keyboard skin does not respond.

Things I did during the test:

* Loaded Calcsys and scan through VAT
* Loaded CaDan and tried to play it. (it ran quite smoothly)
* Loaded a 4-channel interrupt audio routine. Initial test failed to respond to key input indicative of an interrupt failure of some kind. A calc reset later and the routine worked, though the emulator doesn't even pretend to have a linkport (the graphic doesn't show a changing line state)

Fixed. The debugger now can properly modify the registers in the new z80 core.
I made a silly typo in the HTML for the TI-81/TI-82/TI-83/TI-83+/TI-84+ skin, specifically a missing quotation mark. Should be fixed.

I'm glad to hear that!
Hmm, that's strange; I'd be interested in debugging that with you. Actually, jsTIfied does emulate the link port, and my dear colleague UnknownLoner is planning to hook the WebAudio API to it.

I dug a little deeper into the 4-channel audio routine and found that the high speed audio interrupt (based on crystal timer $30-$32) stops triggering once the crystal timer at $33-$35 is set.

I may have prematurely blamed the linkport since the routine responsible for writing to it stopped running. But now I want to blame the crystal timers. Need to put together tests eventually.

At first I had trouble getting jsTIfied to work. It seemed that it saved a ROM from a previous visit. I would not be able to do anything with this ROM. Once I reloaded a different ROM, I could load different ROMS and toggle the icons above the calculator. However, I could not press the keys on the skin via a cursor. I could still press the buttons via my keyboard. To fix this, I trashed the state and reloaded a new ROM. After that, jsTIfied started to work properly.

Also, I don't know if it is my computer or jsTIfied, but sometimes the animated sceenshots turn out wrong.


Edit: I was using Google Chrome 40.0.2214.115 m

I may have fixed the issues with the un-clickable keys. If anyone else runs ino this, please try to dump your localStorage before refereshing the page. The screenshotting issue is due to a difficult tradeoff between computation and speed when picking GIF palettes, causing some colors to get rounded incorrectly to the transparency color index.

For TI-81 emulation (which only supports ROM 2.0V afaict) a TI-81 skin from either the second or third design should be used. But that could just be me being picky and calling 2.0V and 1.x TI-81s different calculators.

Also for TI-81 ROM 1.8K (if that can be checked (if ever supported (if ever dumped))) and TI-82, pixels should be blue.

If I tried to make skins for all the different possible calculator case varations, I would go mad. Does something break with non-2.0V emulation? If so, what?

Ask and you shall receive. Left is the TI-82, right is the TI-83 non-Plus.

Started work on the WebGL LCD display. There's no LCD effects yet, but you can view and modify the pixels. I'll work on it more soon, first priority is interlacing.

http://z80.ukl.me/lcd/

if you want to draw, open your browser console and use the 'lcd' variable.


Code:

How's the WebGL LCD going? More importantly, how is ez80 support going? I know that you were reading over the ez80 manual and collecting some clues. We also have some excellent information posted by calc84maniac that may be helpful.

A less maddening solution may be allowing important of custom skins. I'm not sure exactly how you'd have them specify keyboard buttons.

Perhaps it would be worth supporting the VirtualTI skin format? There certainly are enough VirtualTI skins in the ticalc.org archives, and it already provides a way to specify the image, key locations, and if I recall correctly, even the calculator model(s) that the skin represents.