Don't have an account? Register now to chat, post, use our tools, and much more.
» Tweet Your Calculators with the #TISelfieContest
» Back-to-School 2014: What Graphing Calculator Should I Buy?
» A Brief Reverse-Engineering Tutorial with the g3p Format
» Cemetech To Return to World Maker Faire 2014
There are 82 users online: 0 members, 68 guests and 14 bots.
Bots: MSN/Bing (1), Spinn3r (1), Magpie Crawler (5), Googlebot (7).
RSS & Social Media
You must log in to view the SAX chat widget
jsTIfied Online TI-83+/TI-84+ Emulator
Click here to launch the jsTIfied online graphing calculator emulator, check out the video below for an overview of the major highlights, or read on for more details about how jsTIfied works.
2. How Does It Work?
jsTIfied is built as a series of modules, roughly corresponding to either a major component of a graphing calculator or a major feature of the emulator. Figure 1 shows the major modules of jsTIfied, categorizing them as emulator features or calculator components.
Figure 1: A flowchart of major jsTIfied components. 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.
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:
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:
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:
As you can see, the djnz intruction takes either 13 or 8 cycles to execute and starts with byte 0x10. It is followed by one byte that indicates how far to jump forwards or backwards. Here's how the djnz line in that code above gets assembled:
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:
Focus on the part of the code near the end that processes the case where op_code=0x10, the code for djnz. The tss variable tracks the number of clock states that have elapsed, and for every instruction, the z80.step() function adds at least 4 clock states, since the fastest instruction takes 4 clock states. In the case 0x10: code, we add another 4, since the no-jump djnz case takes 8 clocks. Next, the function decrements b, and since b is an 8-bit variable, fixes an underflow from -1 to 255. If z80.b is not equal to zero, then the code adds another 8 clocks to tss (making 13 total), and modifies z80.pc to take the jump into account. Finally, whether the jump is taken or not, the code increments z80.pc one more time, and fixes z80.pc if it overflows.
And that's all there is to it! Of course, there are about 500 other cases for all of the other instructions the z80 CPU supports. There's plenty of other code around this, including the code that refreshes the screen every time a certain number of clock cycles passes, but this is all you need to know to get an idea of what jsTIfied spends most of its time doing: emulating many z80 instructions very fast.
I hope you enjoyed this short introduction to jsTIfied's inner working and found it edifying. Don't hesitate to snag me (Christopher "Kerm Martian" Mitchell) on the Cemetech forum, the SAX chat widget, or #cemetech on the Efnet IRC network if you have any questions, comments, or suggestions. 3. Information and Links
© Copyright 2000-2014 Cemetech & Kerm Martian :: Page Execution Time: 0.013751 seconds.