For the past week or so I have been working on improving the Mess/Mame support for the TI73/83p series calculators.
For those who don't know what Mess is see here

One of the best things about Mess is it is an extremely portable and versatile emulator running on everything from desktops to phones to even web browsers. Yes I said web browsers, to see some examples of this in action see JSMESS[url], [url=https://archive.org/details/consolelivingroom]The Internet Archives Console Living Room section or Benryves GameGear FireTrack Port

There was very basic VTI level support for the ti83p and the ti83pse was totally broken.

There was no support for the flash chip at all, the ti83pse was just treated as a TI85 with more rom, aka not at all.

Hardware status

• CPU
  Mess already has a very robust z80 core, with an awesome debugger to boot.
  
  
  
• Flash chip (erase and autoselect)
  Mess also already has great support for intel and AMD style flash devices such as the flash chip used in the calculators so it was just a matter of adding the 3 specific model chips used in the calcs, and support for the top boot sector which I implemented as a generic chip option in case other devices have other sized chips with the same features.
  
  
• LCD
  There was already a very basic T6A04 driver written for the ti calcs but I plan to reimplement it based on the PTI LCD code in the future once I have the ports mapped more robustly.
  
  
• Memory Mapping
  The mode 1 and mode 0 memory mapping works and is implemented but I still need to fix things so I can boot with 0x7f in the $0000 bank rather than booting as Tilem does which puts the calc in memory mapping mode 1 and puts the 0x7E in $4000 and 0x7F in $8000
  
  Port 26 and 27 are completely unimplemented at this time.
  
  I plan to reimplement the memory mapping by overriding the mess automatic memory mapping control with me manually handling reads. This way I can check PC on memory read and implement the no execute memory and boot with 0x7f in the $0000 bank like the real thing.
  
  Update: The memory mapping has been redone to use MESS's generic bankdev driver for handling memory banks though this has made flash locking harder to implement short term it has simplified the code greatly. Still need to change things such that I can emulate flash locking as well as Port 26 and 27 but as they are rarely used this shouldn't be a huge issue for now.
  
  
• Linking and sound output
  Sending of data/files is not implemented and I'm not sure yet how to go about doing so, Perhaps treat the files as games or parameters which can be passed to the mess command line?
  
  Sound will be easily doable and may already work as mess already has a two wire to stereo sound driver to do the heavy lifting and I think I have the ports hooked up to it.
  
  
• Flash Locking
  Flash can be locked and unlocked but the protected port output sequence is not required as of yet, this will require the memory read overrides mentioned above.
  
  Update: No longer working due to Memory banking handling changes above, doing this properly will require me to create some sort of wrapper for the default memory handling which I haven't dug into how to properly do yet.
  
  
• Interrupts
  Interrupts are emulated at a fixed speed which I haven't checked for correctness yet. Adjusting the timing via ports does nothing currently.
  
  
• Crystal Timers
  Lol nope, nothing there yet
  
  Update:Seem to mostly be working, at least enough to get the TI84+SE to boot and be happy about it!
  
  
  
• Ports supported or at least partially supported
  0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x09, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x20
  
  
• Saving
  If you turn off the calculator before closing mess ram is restored just like on a real calc.
  Flash is saved but not back to the original rom file and I'm not sure if it is restored before loading the original rom file or afterwards so it isn't clear which takes precedence.
  
  
• Input
  I've also gotten a clickable layout setup based on the same ti83pse PNG used by jsTIfied and wabbitemu thanks to Kerm and Buckeye but I don't have that uploaded to share as of yet.
  
  
• RTC hardware
  Not implemented yet.
  
  

Where to get it/try it out

My current patches are at http://jonimoose.net/calcstuff/ti83pse.diff
Note the ti83p is slightly broken with the current patch due to me mostly testing on the ti83pse as any ti83pse changes will be backported to the ti83p driver

JSMESS Based
This will be third party OS's + freeboot only since I don't have a way to upload roms yet, I'll have to talk to Kerm on how he did it.

• PongOS ti83p (Updated with Newer Build)
  
• Knight OS on a 83+
  
• Knight OS on a 83+SE
  
• If you want to try another Third Party OS let me know or if you want a build you can try with your own rom let me know and I'll help you get it setup.
  

Future Goals

• TI84pCSE support
  Mostly LCD and adding the Flash chip equates. Flash is easy LCD is hard, the extra ports and GPIO stuff is all battery related so hardly worth the effort unless we want to emulate low battery condition properly.
  
• USB support, how crazy can we go with libusb? Or at least let them talk to other Mess instances.
  
  
• Custom debugger UI though the mess frontend frame work. The Mess debugger is pretty powerful but the layout could be a bit better and doesn't interface with include files or similar to handle linking with your code like the Flash Debugger can.
  
  
• Port some changes over to the TI m68k calc driver, though that seems fairly complete last I checked but I haven't looked closely.
  

Good luck! That sounds like it is a major undertaking; great job so far!

I now have TI 83+SE and TI-84+SE support working. I have yet to try a TI-84+ rom but that should also work assuming my Flash emulation code is working.

I've updated the first post with my progress.

Due to some restructuring to update the driver to the newer MESS memory mapping setups Flash locking is not implemented so assembly programs can erase your entire flash chip. Though that isn't a huge issue as I don't have program loading working yet.

On my todo list is to implement some sort of linking such that I can load programs to be able to test things better. I've also been looking at implementing some sort of netplay using either gCn or a generic Socket based link that could connect to a program handling gCn or TI's link protocol. If libticables/calcs were updated to support linking with it in theory you could send files via TiLP or maybe even a real calculator or TilEm.

If I go with the Socket based setup I could likely set things up such that I have one generic linking driver and then have libticables or a custom gCn driver that could connect to it and do as it sees fit.

Good
Agreed about the usefulness of virtual linking for development and testing (besides end user usefulness), that's why I added it to libhpcalcs (on a separate branch).
For libti* integration of a virtual linking cable, Benjamin is more knowledgeable than I am.

A wild wish would a means of two-way socket communication compatible with one side running in a Web browser. Would it be as simple as (secure) WebSockets ?

I've updated the patch and rebased it on the latest mess source and submitted it. I sadly kinda got stuck on hard things and haven't had motivation or skill to really attack it properly.

The latest patch is at http://jonimoose.net/calcstuff/ti83pse-v4.diff and it still needs some work but its something.

Well my v4 patch got accepted upstream here.

Sadly the committer accidentally put it as Joe instead of Jon but at least now if I get distracted by too much UT and FTL someone else can pick up where I left off.

I'll of course keep here updated as I work on it more.


Edit: apparently I linked to the wrong commit, whoops x.x

https://github.com/mamedev/mame/commit/947d3960103a0ca4c1b507b3ea499d9042e28c61

Wel the ti84p driver now officially works and I added the hash of a dump thanks to another cemetech staffer getting me a ti84p boot code dump. In the future the mess guys would like me to split up the rom into multiple files so you can easily use just the boot code dump and leave the rest as is.

Good


Yeah, splitting the ROM into multiple files is the only way to prevent combinatorial explosion on the TI-Z80, TI-68k and Nspire series.

BTW, can MAME/MESS run images for which there are no ROM_SYSTEM_BIOS / ROMX_LOAD entries yet ? Failure to fulfill such basic functionality (from the point of view of the TI community, which has been used to emulators able to perform direct imports of ROM files and OS upgrades since the 20th century) would make MAME/MESS even more unsuitable for usage as a generic emulator...

You can possibly mark the BIOS as not required or mark it such that there are no verified dumps but really an easy fix would be a minimal FreeBoot style boot rom that does enough to init it to the point where the OS would be happy.

I'll also likely have to add support for Ti OS update files and App files to the to the mess quick load system such that it can easily add it to rom as without a certificate sending via the Link port. Kerm thankfully sent me some code that he uses for linking that I might be able to butcher enough to get things going with the mess rs232 -> Socket setup once I get more familiar with the mess code.

It's not just about the boot code, for which the solution is even easier on the TI-68k series than on the TI-Z80 series.
It's about developers of third-party OS not having to recompile (or otherwise modify, through e.g. binary patching) MAME+MESS to update an image hash each time they want to test a new build

VTI, TIEmu, TilEm, jsTIfied, the JS TI-68k emulator, and other TI-Z80/TI-68k emulators created by the TI community make no fuss importing arbitrary OS upgrade images and ROM dumps. MAME+MESS shouldn't get in the way of users, otherwise users won't be using your hard work.

How flexible is the display code for MESS? I've been thinking for a while it would be fun to have a TI emulator that ran purely in text-mode in a terminal.

It uses SDL so you could do framebuffer output but it won't do true text mode output, it will need a framebuffer of some sort.

On a related note I have a good start on linking going and here is some proof:

Code:


Those bytes should look familiar to people who have been watching KermM's CBL2 protocol topic as that is the exact same bytes he got sending Send({0 to a CBL2 from a TI-83 Plus which means I am on the right track.

The next step is going to be implementing sending to the calculator and seeing if I can adjust the code to work for link assist on the actual calculator.

You don't need to recompile to use a different rom or dump, it will just warn you and say it doesn't recognize it so it may not work. As long as it is named properly it will run just fine.

During testing I get this but it doesn't actually matter for running things and it works just fine. They do that to prevent bug reports from people who couldn't be bothered to verify their dump is correct and for most systems that is just fine.
[/quote]

Would you mind clarifying where those CRCs are coming from? Is there a set of CRCs computed over "standard" ROMs of some sort, which of course will be wrong for every ROM except the one with the exact certificate used for the original CRC? Or am I misunderstanding the purpose of that checksum?

That is currently what is happening yes. The ideal situation would be to split the bootcode dump file from user flash and thus the CRC would only be compared to known boot code versions but for now keeping compatibility with existing emulators meant keeping it all in one file was easier.

I see; that's rather unfortunate. Surely TI calculators aren't the online system where the unchanging OS and some type of device-specific information are combined together into the ROM, though? I feel like MESS would be a more flexible emulator if it could support this type of division.

It does, you are just supposed to put the changing parts and unchanging parts in separate files.

I guess it would be a bit user-unfriendly to provide a tool to split a standard TI emulator .rom file into those two halves for now, although I think that may be better than warning everyone that they have an invalid ROM.

What I might do is make make it so that rom8x style dumps work with it such that it is easier to manage but I'm not 100% sure. Either way technically the boot code is all that should be included with the dump.

My other thought was to submit a patch to rom8x for creating boot code only images as well as splitting roms into the boot code + cert + everything else.

On a related note, due to mess being designed such that it assumes the dumps are ROM, the provided rom is not modified and instead the flash is saved in nvram/$system/flash and the ram is in nvram/$system/nvram this means going from a split rom file to a combined one won't be hard due to that flash file being the full rom.