I have just released alpha version 8 of a Javascript TI-92 Plus emulator: http://www.ocf.berkeley.edu/~pad/emu/v8.html

Features so far:

- Pedrom (from Pphd) included with the emulator so you don't need to download a ROM to use it. No obvious flaws with basic use.
- Several games also included (which just happen to be written by me) and work.
- Should run at full speed in Firefox or Chrome on a recent PC.
- Shows calculator image with clickable buttons (which might even work on a tablet) and also accepts keyboard input.
- Able to load ROM images from your computer (unfortunately, AMS 2.09 does not work yet)
- Most important, in this version I am now confident in saying that bugs are worth reporting even if they only erase 55% of the data on your hard disk (if you are one of the special few who has seen the older versions, you know the threshold used to be higher)

Priorities for future development:

- Improving accuracy to allow more programs to run
- Link port emulation to allow sending any file straight to the emulator

That's quite impressive. Just played a quick round of phoenix. Do you have the keyboard map listed anywhere?

Patrick, this is great work! I am very impressed with how far this has come since the first time I tried it out. I'm curious if you wrote all of the hardware emulation by hand, or if you designed some tools to automate the opcode emulation (as I did for jsTIfied). I'm quite happy that we now have online 68k and z80 emulators for the community to use.

Now all we need is an SH3/4 emulator...

Out of curiosity, do you have plans to extend this to support the other 68K calculators?

Hi PatrickD

AMS 1.05 boots up, but AMS 2.xx doesn't, due to FlashApp-related code which exercises some instructions in a peculiar way.

Emulating other calculator models would be an interesting feature
Besides the addresses and sizes of the Flash memory, and keyboard layout, hardware differences between the 89, 92+, V200 and 89T are low, for the purpose of emulating the vast majority of programs.

Emulating the more obscure aspects of the hardware (the embryo for an instruction pipeline), or the noxious bits (RAM execution protection - users usually just kill this pure nuisance using HW3Patch or tiosmod+amspatch), is not important: >99% of the programs don't need them for proper operation.

I heartily support the journey of making a usable, maintainable, thin-client (OS-independent) TI-68k emulator, with support for user-supplied OS images / ROM dumps and programs.
Modern JITs in browsers make it possible to emulate TI-Z80 calculators, and even x86 computers ( http://bellard.org/jslinux/ ), with JS - so TI-68k calculators are definitely possible

Too much is still unknown about the functional details of the Prizm hardware at this point for that to be feasible, not to mention that it's much harder to emulate a 60MHz 32-bit processor in realtime in Javascript than a 6-15ish MHz 8/16-bit processor.

I was sort of joking about making it in javascript, but it would be nice to have an alternative to fx-Manager... something like wabbitemu

I have now released alpha version 9 - http://www.ocf.berkeley.edu/~pad/emu/v9.html

This version adds the ability to transfer variables to the emulated calculator, so you are no longer limited to running the pre-loaded programs. Note that most of my testing has been with the pre-loaded programs so compatibility with others is rather limited. On the plus side, at least Another Mario 1.04 work!

KermMartian: There isn't any automatic generator beyond what you can see in the script itself. That would perhaps be called "semi-automatic" since I certainly didn't type in all the tens of thousands of opcodes individually, but rather for each instruction (or group of very similar instructions) loop through all the possible registers, addressing modes, and sizes to generate the code for each one in the opcode table.

Yes, I see what you mean, and I am quite impressed with your work on that. I found it to be faster to have the code to handle all my opcodes pre-generated, so I have some scripts that create a big linear file of switch statements, then use the Closure compiler to optimize it.

I have just now updated it to alpha version 10: http://www.ocf.berkeley.edu/~pad/emu/v10.html

This version improves compatibility significantly. In my brief tests all of these games now work:

Jezzball 1.8 (Thomas Fernique)
Insane Game 1.1 (Greg Dietsche)
Asteroids 2.0 (Don Barnes)
Tetris 1.60 (Jimmy Mardell / Greg Dietsche)
Solar Striker 1.00 (Brian Tribondeau / Benoit Scherrer)
Propanoid 68K 1.2 (Mony Samuel)

FWIW, the emulator works better (that is, the AMS 2.xx boot procedure fails at a later stage) if

Code:

is added right after executing an opcode:

Code:

That seems weird to me. You're anding by 0xFFFFFFFF, which should do nothing, right? I guess maybe it sets a flag somewhere?

Javascript doesn't use sane integer types.

Very helpful, I completely understand now

0xFFFFFFFF is a 32 bit mask. All numbers in Javascript are 64bit floats, meaning the largest integer is 53bits. That means 0xFFFFFFFF + 1 is 0x0100000000 and not 0x00000000

Oooh, that makes sense. Silly me for assuming 32-bit numbers

Any idea if calcrogue would work with pedrom? If so this'll become a massive time waister for me. I guess I should give it a try tomorrow, or not if I actually want to get work done. x.x