Hey all, long time no see. I'm a TASer these days, and recently, someone submitted a TAS of a TI-83 game for the first time ever. One of the challenges of a TI-XX TAS is making the game load. Unlike an actual console, which loads any (acceptable) game from a cartridge, a calculator game already exists in the RAM or flash when you wake up your calculator up to play it. Starting the movie file from fresh RAM is preferred on all consoles; starting from a savestate is generally frowned upon if there is an alternative.

The runner, dwangoAC, worked around this by typing in the (BASIC) game live in his TAS before playing the game itself. I was able to improve his time significantly by making a Lua script/z80 assembly combo that basically does the following:


1) Uses the keypad to type in the opcodes for a routine that writes keypad inputs to memory (I chose SaveSScreen) and then jumps to it
2) Type in the data for a second ASM routine this way, along with the token data for the BASIC program.
3) Run the second ASM routine, which makes a new program variable with the BASIC data and runs it

The thing is, step 2 is pretty slow. Right now, data transfers at a rate of 4 bits per frame (at 61 FPS, 10000 cycles per frame). Would I be better off doing all of this over the link port, or can it still be faster to input the data over the keypad?

All code is hosted on GitGud. Half is shamelessly ripped from AsmGuru.

Routine for part 1:

Code:

Oh, definitely, it's way faster to send the file over the link port. Graphing calculators are, of course, quite different than consoles, due to persistent RAM and lack of removable memory (excepting HP calculators). Furthermore, for Z80 models, there are no frames, because there is no way to tell when the screen starts frame refresh (at least not without user interaction). The new eZ80 models have a V-blank-equivalent, but never mind about those models. You'd probably want to count time in simulated seconds or CPU clock cycles.

Also note that the OS scans the keypad at about 100 Hz, so you can improve the data rate just by having the Lua script pay attention to when the OS scans the keypad.

For flash models, there may exist differences in how emulators handle flash operation timings. The most consistent way to handle flash operations is to report that the operation immediately completes after the command is issued. This is never true for hardware, but there's too many different reasonable ways to simulate flash timings to do anything else.

Most emulators handle file sending by force-loading files; that is, they write the data directly into emulated memory, and then adjust OS pointers as-needed. Most do not simulate the data being sent over the link port. There are different protocols for PC- versus calculator-initiated transfers, and there may exist and advantage for one over the other.

Due to the persistent RAM and flash, I would suggest that the standard be that the calculator starts with all required files pre-loaded into RAM and flash, as appropriate for each game. If a shell is required, it is also loaded but not initialized, so it will have to do its first-run stuff. The calculator starts in the soft-off state (i.e. the normal powered-off state). Each TAS, therefore, starts with the calculator being turned on, with the calculator starting at the home screen, with an empty edit buffer. You then launch the shell and game as normal.

For any TAS, the result must be replicable by simply feeding a movie file to the emulator with the corresponding ROM. That means that my precision is limited to the frame rate (61 Hz).



I just checked. Unfortunately, there is currently no way to script sending a file to the calculator in TI83Hawk or interface with the link port from Lua or a movie file. Until someone adds that functionality to the emulator, I'm stuck with nothing but keyboard input.



The TI-83 is the the only model emulated by Bizhawk so far. Other emulators could possibly be accepted if they allow for movie replay but would be subject to scrutiny in case their emulation is not totally deterministic (consistent, frame-perfect result for a given movie file).



If the goal is to eventually replay TASes on actual calculators using only a movie file, this approach will not work. It would be great if you could offer your $.02 over at the BizHawk forums so that graphing calculator emulation for TASes evolves in a well-informed manner.



Since no TI-83 TASes have been published at TASVideos to date, this may still be a possibility. DwangoAC will submit his run soon (using the aforementioned keyboard loading method) and we'll have a chance to discuss it in the resulting thread.

What does that mean exactly? The TI83Hawk emulator copies the LCD's buffer to the visible LCD 61 times per second? As DrDnar said, a real calculator instantly displays any changes in the LCD GRAM on the screen, so there's effectively no such thing as a framerate.

Allow me to counter with the suggestion that the BizHawk guys come chat with us here, especially since a few of us have experience writing emulators, and many of us have experience working with the calculators' hardware.

That's not true. The LCD controller periodically refreshes the LCD at a rate that may or may not be about 60 Hz. Data sheets usually specify 50 to 60 Hz, but there's no way to tell from the calculator side, and the rate is not required to be very accurate. In fact, the type of LCD used requires that the LCD controller invert the polarity of the driving voltage periodically. This requirement leads to an interesting fading effect if you toggle a pixel at half the LCD's refresh rate; instead of getting 50 % gray, the pixel fades to white because it is no longer getting the required voltage flips. As long as the LCD controller refreshes the screen at a rate that is within the needs of the physical LCD, it could be any frequency, or even a variable frequency, perhaps about 30 to 100 Hz.

While a given emulator can synchronize playback using its own idea of what a "frame" is, software that actually needs frame-based timing has to invent the required timing for itself. This means that, without a standard on exactly what a "frame" is, movie files can't have any expectations on how different emulators play them back. Some games use the analogue response properties of the LCD to get grayscale by rapidly toggling pixels. In emulators, this either results in the display appearing to be garbage, or the user having to adjust the grayscale emulation depending on the game.

Frame rate is an often-artificial yet universal construct in the TASing world. Another example is Hourglass for Windows games. It lets you specify the frame rate that the input file is read at. If the frame rate for TI83Hawk is not 61 FPS, it would be a different number. I personally think it should line up with the interrupt frequency. If you have a different solution, I'd love to hear it.


Both would be nice