Menu
Table of Contents 1. How Does It Work? Links and Information 1.
Sep 18, 2015 - There is nowhere you can get a TI-84, but there is an online application at. You could download an emulator to your computer, but you would need a TI-OS. TI-SmartViewâ„¢ Emulator Software for the TI-84 Plus Family. For concurrent license server installations, download TI-Admin Software.
Overview is an online graphing calculator emulator, emulating the TI-83 Plus, TI-83 Plus Silver Edition, TI-84 Plus, and TI-84 Plus Silver Edition. It runs entirely in your browser using HTML5 and Javascript, so it requires neither Java nor Flash. For legal reasons, you must load your own ROM image, which is stored in your browser and never sent to the Cemetech server. Figure 1: A flowchart of major jsTIfied components.
![Ti 84 Emulator Online Ti 84 Emulator Online](http://mergy.org/wp-content/uploads/2011/01/Screen-shot-2011-01-13-at-11.41.43-AM.jpg)
Blue are modules with calculator hardware equivalents, purple are emulator-related features, and turquoise are network-dependent features. Larger text and larger boxes correspond to modules that require more code. Figure 1 shows that while the majority of the code in jsTIfied corresponds to physical hardware features of a TI graphing calculator, a substantial amount is also necessary for emulator-specific features and tools. Let me tell you about each of the modules in Figure 1, how they work, and how they communicate with other pieces of jsTIfied.
z80 CPU: The CPU (processor) is the heart of jsTIfied, and occupies a huge amount of code. Although automated tools adapted from the helped simplify the process, a great deal of tweaking, optimization, and adjustment was necessary. The CPU includes the code to process instructions, all of the z80's registers, and most of the code to manage interrupts.
Memory: The memory module handles raw memory reads and writes. While many go to RAM, some also go to ROM, and writes to special addresses trigger special 'meta' flash commands. The ASIC in the TI-83+ and TI-84+ includes several numerical ports that remap pages around the device's address space, and intercepts all memory commands, so this module shares some of the work of the ASIC modules. Flash: Handles only the 'meta' flash commands, such as those used to erase sectors, pages, or the entire chip, or fetch its capacity or ID. Reads and writes from/to EEPROM are handled by the memory module. TI ASIC: The second-largest module other than the z80 CPU.
Serializes and deserializes calculator-wide state including the RAM, ROM, and ports into and out of DOM storage. Mediates between the SourceCoder and file import/export module and the calculator's virtual link port to allow files to be send to and from the emulated calculator.
Handles the main event loop that feeds opcodes to the CPU, times and hands interrupts off to the CPU, and handles z80 port input and output. Not shown: timer module that handles TI-84+-specific crystal timers, technically part of the ASIC but broken out into a separate module for jsTIfied. 96x64 LCD: Thanks in part to research from the emulator, emulates very accurate LCD physics, which makes grayscale look good and calculations and graphs look authentic. Emulated physics include LCD power levels, pixel turn-on and turn-off intensity profiles, and sub-pixel emulated LCD pixel divisions. Keypad: Practically a single function, sets internal ASIC registers in response to Javascript key up and key down events.
Debugger: Reads CPU state and memory state from the z80 CPU and memory modules. Also includes a rudimentary disassembler to render memory as z80 ASM code. Linking Assist: Part of the ASIC; a variety of functions to perform silent linking to send files to the calculator and get them out again. Also used to list the variables present on the emulated calculator. Screenshot Tools: Includes code to once or periodically grab an LCD image, and generate a GIF image.
Although a public GIF library was used as the base for this functionality, such extensive changes were made to fix bugs, introduce new GIF features, and optimize the size of the resulting files that it is practically a new GIF library. SourceCoder, File Import/Export: A simple set of functions to interact with SourceCoder's API. AJAX Interface: Standard AJAX functions to push and pull data to and from the Cemetech server.
Because Javascript cannot directly output files to the client's browser, jsTIfied uses the Cemetech server as a mediator for screenshots and files. It pushes the data to be exported, then opens an invisible iFrame that causes a file download dialog to appear. To the layperson, the logic behind some of the design decisions that I made may not be obvious. Why, for example, was it so important to keep the ROM images on the users' computers? Or why did I choose to implement/overhaul GIF rendering in Javascript rather than use simple server-side GIF libraries? Critical Design Decisions jsTIfied's design was influenced by several key considerations. First and foremost, it had to be fast, whether one or 1000 users were using it simultaneously.
Secondly, it had to be reasonably secure, preventing the possibility that users might lose proprietary state stored on their devices. Thirdly, it had to be legal: many emulators have been become unavailable over the years by including or releasing ROM images. Fourthly, it had to be as compatible as possible and require minimal prerequisites.
Finally, it had to offer most if not all (or more!) features compared to offline, installable emulators. Among the decisions that each factor influenced:. Fast: Although Javascript is not an inherently fast language, modern JIT Javascript engines help. To eke out every bit of speed possible, I use Google's Closure compiler, compress global names to reduce symbol table lookup times, and performed many rounds of profiling and optimization using Firebug and Chrome's JS profiler. To make sure that users get a consistent experience, I made sure that almost none of jsTIfied's required computing power comes from Cemetech's own servers. The most server-intensive features are exporting screenshots and exporting files, and even those simply require the server to echo a data stream back to the client.
It would also be impossible to include the Cemetech server in the loop for any critical part of the emulation due to variations in latency. Secure: All RAM and ROM state is kept on the clients.
Screenshots and file exports are bounced through the Cemetech server due to Javascript limitations, but are not cached or stored server-side. Legal: According to most interpretations of the law, ROM images are specific to the device from which they're dumped, on the grounds that in buying the device (ie, the calculator) you purchased a license for its software (ie, its operating system), and by duplicating or distributing a ROM you are illegally distributing software without authorization or a license. By using DOM Storage to keep the jsTIfied ROM from touching the Cemetech server, there is no question that users are using only their own ROM, and that Cemetech isn't inadvertently turning either itself or its users into legally-vulnerable criminals. Compatible: By requiring only a browser and Javascript, jsTIfied can run on any operating system with a decent browser, from Windows, Linux, and Mac OS to mobile devices. Flash and Java would both be too cumbersome of requirements for the job, not to mention that I dislike Java and have little Flash experience. Features: By using a webapp approach, new features will be instantly pushed to every user. Javascript is now powerful and expressive enough that all the essential emulation features, plus extras like a debugger and screenshots, are possible without sacrificing the real-time speed of the emulation.
Emulation Example: The DJNZ Instruction To help you understand the very basics of how jsTIfied works, let me show you an example of one opcode being executed. In z80 assembly, the djnz opcode is a 'decrement and jump if not zero' instruction. It operates on the b register, one of the several 8-bit registers in the z80 CPU. It first decrements b, then checks if it is zero. If so, it continues to next instruction past the djnz, but if b is not zero, it jumps to the label mentioned after the djnz.
An example of some real code that uses djnz. Ld a,(randData);save randomness of data ld b,255;255 bytes to clear ld hl,MainSafeRAM;clear our saferam areas InitClearLoop: ld (hl),0;put zero in it inc hl;go to next byte djnz InitClearLoop;done yet? Ld (randData),a;recall contents of random data First, I want to tell you a little more about djnz. Every z80 instruction takes a certain number of clock cycles, and as on most processors, jump instructions take longer when the jump is taken.
Luckily, there are plenty of tables for z80 opcodes that tell you everything you need to know. Addr Data Code 6C80 10 FB djnz InitClearLoop As you can see, this instruction happens to be at address 0x6C80. The key bytes from the program here are 0x10, the djnz instruction itself, and 0xFB, which means to step backwards 256-251-2 = 3 bytes to address 0x6C80-3=0x6C7D. Let's imagine that we're executing this on jsTIfied. When we start executing this instruction, the CPU will already have plenty of state.
The z80 variable in jsTIfied holds the current CPU state, including registers z80.pc (the program counter, the address of the currently-executing instruction), and z80.b (the value of the b register). We'll start with z80.pc = 0x6C80 and z80.b = 2. The very core of the emulated z80 processor is the z80.step function, which looks like this.