According to this forum thread (see web page link), the bug affects ROM V2.0V too. Without a shell, though, programs will have to be modified to run on different ROM versions.

Hi,
my name is Alexander (Xander for friends), in the last months I have made some work for fix TI8x emulation in MESS, today I have see this new dump and I have tested on MESS, the problem is that this dump is more similar to the TI-82 that to TI-81 v1.8k, is possible that v2.0v has some difference in hardware?

I'm not sure I understand exactly what you mean, but the United TI thread I linked to in my above comment now has some discussion on hardware changes in versions V2.0V and up, particularly with the LCD. Apparently, versions prior to V2.0V used a memory-mapped LCD, but V2.0V and up went back to using a driver and port, like the TI-82. However, the ROM still used the same memory area in RAM for the LCD contents but added an interrupt routine that periodically copies the entire screen to the hardware port to update it.

I had noticed this simile with TI-82, but not having access to the hardware I was not sure, Thanks for the information.

Darn this is awesome. I am curious if ROM 1.1K (the TI-81s with no lithium battery cases) could also run ASM programs.

You might try this experiment: Go to the Y= editor and set Y1 to (-1)^\pi\ and enter Prgm2 as mentioned in the document, then keep typing junk into Y4 until it won't let you enter any more. Then follow the part in the document where it says "Repeat 6 times:" where it says how to run Prgm2.

On my V2.0V TI-81, the end of Y4 will eventually start getting corrupted, and if I keep doing it the calc will crash. If something like this happens on your 1.1K model, then my guess is that this method will work on it too (though ASM programs would have to be written for that ROM).

This is absolute madness. My mind is blown at how amazingly genius this is. How does one ever go about figuring this out in the first place?

A few days before I made the interrupt code, I decided to figure out the maximum size of the stack for my TI-81 documentation, & I noticed that the maximum SP got stuck somewhere else at one point. I was sure it was a fluke or a bug in the dump or emulation, but it worked on the real hardware. The interrupt itself was not too bad, except for the load-reset-debug cycle.

This kind of begs the question: can it be linked?

No, as there is no link port. Data can be transfered to the PC using a digital camera :), but the other way still requires lots of typing. :/

Now a TI-81 Assembly (machine code) directory will have to be added. Today is the day that I wished I owned one...

I would comment, but I seem to keep going over some 40 character limit.

The posting system doesn't allow a single word (or series of characters without spaces) to be more than 40 characters. Are you trying to post a URL or line of code without spaces that exceeds that?

I don't recall exactly what I tried to post, although I know it did not contain any string (without spaces) over 40 characters long. I ultimately emailed my comments/questions to Randy himself and was subsequently pleased to receive a response shortly thereafter.

Now I wish something like that was done with the Casio CFX-9850G series, even if they are discontinued. Most Casio calcs are weaker and more limited than TIs, but the CFX series had 3-color LCDs and each color could be changed in the contrast menu. Possible games could be tilemap-based RPGs where the 3 colors could be changed according to your needs for each tilemap or dungeons. However, I wonder if using the same method as with the TI-73, 82, 85 and 92 would work on them, plus, it would most likely be a different processor and since there are several variations of the CFX-9850, 9950 and 9970, maybe the hardware or ROM is different in each of them.

Ok, I think this is definitively possible on ROM 1.1K too. I have tested on my TI-81 which have this ROM version (and no backup battery slot) and after doing the "execute Prgm3" step, I went to Y3 and there were full of junk there including stuff like I/O, MATRIX, DATA, etc, after the 3.141592654+-2.14592654X stuff. However, I couldn't do the steps right after the one where I ran Prgm3, as there was no All-OffBcol in Y3.

There were a lot of Y2T-OffBcol stuff, though, so I tried the rest of the instructions anyway and eventually ended with 467 bytes instead of 442. Unfortunately, from there, I accidentally chose the Reset option x.x. I might try to redo it later when I get more free time, though. But just reporting in to say weird stuff happened on 1.1K as well. Could this means ASM is possible on this older ROM too?

Also, one thing I noticed during the making of Illusiat 81 in 2008: when you have 6 bytes of free RAM, if you go in the STAT editor, the calc freaks out and random garbage appears in program names. Got a few RAM clears from there, too. I'm not sure if this happens in later ROM versions, though.

Nope, I both tested it on 1.8K & checked the ROM dump. They fixed that bug.

Cool! Yeah, that definitely sounds like the bug exists in 1.1K as well. The whole trick has to do with the BASIC program that calls itself a bunch of times and then inputs a number. When you enter something that causes an error, the ROM then forgets to restore the stack. The LinReg and RegEq stuff is only there to make it faster to fill up Y3, if I understand correctly—you could fill it up by typing anything, but it would take longer.

I also got stuck at the same point when I tried the instructions—I couldn't find the part in Y3 that the instructions mentioned. But I think this is because these instructions were written only for 1.8K. The random garbage you see in Y3 is actually the part of the ASM stack that overflowed into this part of RAM. It represents ROM addresses that the OS is supposed to return to, but these will vary on each ROM version, so the part you need to change would likely be different.

Even if you knew what to change, though, I don't think the program would work since the docs say it uses 1.8K's ROM calls only, unless those calls happened to be exactly the same on 1.1K. ROM versions will probably be a bit of a problem for 81 ASM—you'd either have to type in an ASM shell to translate things (like the 82 and 85 shells did) (I don't know how much space this would take up), or there would have to be a separate version of each program to type in for each ROM version.

Sadly, since you have to type everything in and since there isn't much interest in the 81 anymore (and barely anybody probably has one nowadays), I have a feeling that TI-81 ASM won't advance very far, though. :-( And to be honest, it really isn't all that practical, either—but I definitely think it's still fun and fascinating because it's something most of us never dreamed was possible. :-)

It sounds like it's definitely possible!

I've written a program to "dump" the ROM (see link.) And it would probably be possible, in a similar way, to write a fully ROM-independent kernel. But if you want to run anything more than the most trivial assembly programs, you'll probably want to know some of the ROM routine addresses.

In theory, if we can get enough of the ROM versions dumped/analyzed, a kernel could allow ROM calls to be translated at run time (using either a ZShell-like or an SNG-like approach.) This would, of course, increase the size of the programs, and of the kernel; perhaps it would be easier just to assemble the same program several times for different ROM versions.

Ouch, well I guess I can forget about it for now. I don't have a SD card large enough to fit one hour of video of that resolution atm, nor a tripod or a good place to record x.x

Plus the next stuff seems a bit complicated and I'm computer illiterate. If I get the tools required to record the ROM dump, I could maybe do it later, though, then send the mp4 file produced to someone who could do the rest x.x

Yeah, it's quite a bit of work, and everything (including the videos) has to be practically perfect. I went through several videos before I found some that worked reasonably well. And even then I ended up shortcutting the process and just happened to get lucky enough to get a good dump one time. ;-) And with each video taking an hour to record, we're talking a lot of time as well, just for the videos (not even including the final stages).

I think it would be best to improve the ROM dumping tools first before expanding the project to other ROM versions. For instance, I wonder if it would be practical to make the ROM dumper use a bar code or something instead of characters? It seems that OCRing bar codes might be a lot easier and more reliable than alphabetic characters.

For V2.0V (I will check the MD5 against theirs when I finish) I just wrote the ROM data to the screen as a bitmap. It is a little more tricky to do the conversion, but that multimedia programming class I took finally came in handy.

Bar codes are an excellent idea. I'll look into implementing that in the future.

One thing to consider is that sometimes the camera captures an image of the LCD in the middle of an update - in the case of detecting characters, this usually means the entire frame is unreadable and thus gets thrown away. In the case of bar codes, this would just give you garbage data, so you'd need some good error detection to compensate.

For the same reason, I don't think I would want to speed up the LCD updates very much, so it would still take a long time to dump the whole ROM. But of course, there's no reason you couldn't break it up into several smaller dumps.

Try displaying the ROM data directly to the screen (checksummed if you want). That is what I did (although I am still extracting the data, because it requires a few different tools (I am using Hugin & GIMP) to clean up the images). Then there are only 43 (possibly more if checksummed), so it does not take so long.

That comes back to Travis's point about needing to keep the picture perfectly steady - except that now you need to be much more precise, since you have zero redundancy in terms of reading the pixel values. Yes, you could manually adjust the coordinates on a frame-by-frame basis, but doing that 43 times is way too much work for me. :)

I expect you also need more uniform lighting than what I was able to provide, and/or some more sophisticated algorithms.

To each his own, though. If you get it to work, would you be so kind as to share the code? Perhaps others would prefer to try your method.