Last December, I started jsTIfied, a TI-83+ emulator written entirely in Javascript. February of this year brought an initial public beta, and in mid-September I announced that I had added TI-83+SE, TI-84+, and TI-84+SE support. I am now proud to report that with the addition of crystal timers for the TI-84+ series, the ability to record screenshots, and myriad improvements to the interface, jsTIfied is ready for a Release Candidate.

As you may know, Release Candidate 1 means that I believe all of the features of jsTIfied 1.0 are complete and functioning, but Cemetech's users and members are always the best at finding bugs for me to solve. A selection of the most important features jsTIfied offers:

:: Browser-side JS/HTML5 emulator for the TI-83+, TI-83+SE, TI-84+, and TI-84+SE graphing calculator. No installation or Flash necessary.
:: Extremely accurate hardware emulation
:: Accurate LCD physics for realistic grayscale rendering
:: Imports .8x* files, exports .8x* files
:: Loads and saves projects to and from SourceCoder
:: Takes static and animated GIF screenshots, highly-optimized for space.

TI-83+ support has gotten extensive testing in the eight months it has been live, but with all of the extra features I have added, I would appreciate your help. Please load up your favorite ROM (remember, sharing ROMs is illegal and jsTIfied keeps any ROM you load only in your browser) and test out jsTIfied! Kindly report problems like screenshot inaccuracies, glitches in programs that you run, or any other issues you encounter. jsTIfied has also been fully integrated into the SourceCoder TI-BASIC editor, so feel free to test it out there as well.

Use jsTIfied
Launch jsTIfied online TI-83+/TI-84+ graphing calculator emulator

The way you're going about this is amazing. Keep it up! I can't wait to see the Archive integration and the future of jsTIfied.
comicIDIOT wrote:
The way you're going about this is amazing. Keep it up! I can't wait to see the Archive integration and the future of jsTIfied.
Many thanks! Although things like directly loading programs from the Cemetech archives will likely be after a significant break; over the last few months I have been trying to aggressively clear unfinished projects off of my to-do list without taking on too many new ones. My PhD work is starting to get into full thesis swing, and I have another "official" project beginning in my spare time. Of course, I'm pretty bad at not starting new projects (LuaZM, wireless CALCnet, PrizmTI, ...).
Glad to see you working on this some more Wink.

I can't seem to get jsTified working at all now. I saw my homescreen from before, but I pressed 2nd quit once, and then the javascript didn't do anything. no errors. Are projects supposed to load properly now? They don't - maybe I need to clear my cache?
So what's on the LCD? Does it respond to anything? How about hitting the reload/refresh icon? Or loading your ROM again?
LCD is blank, tried everything but loading my ROM again. I hope you mean the old one, not that I need to make a new one?
LiquidMetal wrote:
LCD is blank, tried everything but loading my ROM again. I hope you mean the old one, not that I need to make a new one?
No, the old one. And absolutely nothing in the Javascript error console (did you check it)? What browser and version, ROM calculator and OS version, and ROM size in bytes?
Nothing in javascript errors, os version 2.55mp 84+SE ROM I mentioned size to you somewhere before... Firefox 14.0.? Let me try uploading it again hold on.

EDIT: I retrieved the rom from my recycle bin, and loaded it up. Works find now, thanks Wink.
LiquidMetal wrote:
Nothing in javascript errors, os version 2.55mp 84+SE ROM I mentioned size to you somewhere before... Firefox 14.0.? Let me try uploading it again hold on.

EDIT: I retrieved the rom from my recycle bin, and loaded it up. Works find now, thanks Wink.
Darn, I should have asked you more debugging questions before it was fixed. Very Happy I'm concerned that the same thing might happen to other, less vocal users who might be frustrated with it yet not ask for a solution.
Here it goes:

To get GlassOS to work, emulation of the flash chip's protocol must be added. Currently, GlassOS uses the unlock bypass and the get info functions, but in the future will use the extended flash erase command.

For the Get Info command, this is what happens:
GlassOS: trunk/src/kernel/all.c wrote:
How to check for a Macronix Intl. chip:
write aa at aaa
write 55 at 555
write 90 at aaa
read at 0000
if read data is C2, bad chip


Now, the above is how to read and reply to the get info function (limited use). There is more and can be found at any of the datasheets used for the ti83+SE/84+/84+SE.

Now, why check for a Macronix chip? It is, from my research, the only chip to not support the unlock bypass. If more chips are found, then I can reverse my logic. Now, this check directly modifies the OS at 0x0050.

Now, the unlock bypass works like this: Instead of issuing a flash write command, then giving it the byte, this will send the write command once, then stream in all writes. To initiate the unlock bypass, it writes 0xaa, 0x55, 0x20 to 0xaaa, 0x555, 0xaaa. That is similar to how a normal write works, you should see that.

Now, when it writes data in unlocked more, it just writes 0xa0 then the byte to the location on the chip. 0xa0 can be written anywhere and the chip accepts it. To get out of the mode, write 0xf0, 0x90, 0xf0 to anywhere on the chip.

Now, you can force this unlock mode off by having reads to 0x0050 to always be zero.
Really nice updates. I'll keep them in mind, when creating a z80 project.
stefan bauwens wrote:
Really nice updates. I'll keep them in mind, when creating a z80 project.
Thanks, I appreciate it. Let me know if you encounter any bugs.

AHelper: Pardon my ignorance or lack of reading comprehension; I'm afraid I'm a bit unclear as to what exactly I didn't implement properly for GlassOS. Is it that I need the flash chip emulator to understand the unlock bypass code, and it's currently not? Or would a valid alternative be to force the unlock off?
It isn't just the unlock, it needs more commands. The get info command highlighted above is required. Without it, the OS will not like you. Unlock bypass's use it determined by this command.
AHelper wrote:
It isn't just the unlock, it needs more commands. The get info command highlighted above is required. Without it, the OS will not like you. Unlock bypass's use it determined by this command.
If I claim that I don't support unlock bypass, though, will both GlassOS and the TI-OS happily fall back to streaming the data in the slow way? Or does only GlassOS use this feature?
You are missing the point. Unlock bypass is one of many functions supported by the flash chip. If you don't support any commands other than what TIOS uses, then GlaßOS might freeze in either the get info or flash writing routines, get a bad return from the get info and force unlock mode on, or just dance around the flash. The unlock bypass isn't the first function called, the get info function is. If you tell GlaßOS that you don't support the unlock bypass, then it falls back to normal flash routines.
Got it, that all makes sense. However, as I mentioned on IRC, I started implementing this, then realized I had already implemented it and removed it. Finishing the implementation would require modifying the read path for every single byte read. I'd have to make every read check: is this addr 0x0 and I am in Silicon ID mode? Then return $C2 or whatever; otherwise keep going with a normal read. Reading a byte is the most critical path in the whole emulator, since it's used both for reading instructions and instructions that read memory. Can you pretty please make a failover in GlassOS that if the read at 0x0000 equals whatever was at 0x0000 anyway, it assumes no data streaming? That's probably a good failure mode anyway.

Edit: Ahelper says: You can just block writing to the address on page 0, then the flash code will not fail.

Edit #2: Wait, what? You said that at minimum the get ID command is required. I say that it would slow things down to much to add that. Hell, I don't want to add port 28/29 handling for the same reason.
AHelper wrote:
Now, you can force this unlock mode off by having reads to 0x0050 to always be zero.
AHelper wrote:
AHelper wrote:
Now, you can force this unlock mode off by having reads to 0x0050 to always be zero.
But that's still a special case in the read path, which I'm trying to avoid. Very Happy However, I _can_ make this a modification in the flash write path instead, perhaps? That seems awfully hacky to me, though. Sad
The same can be said about ignoring the flash chip emulation. Does js have function pointers? That can solve it. Also, i could try to get GlaßOS to see if the flash chip works, but am not sure on a nice way to do it.
AHelper wrote:
Does js have function pointers? That can solve it.

I think it does, and this seems reasonable. Instead of an if, have a 2 entry array of function references, and call it with


Code:

read_behavior[!(boolean && test || condition || here)](reference,to,necessary,state,here);


A switch statement could be used to do the same thing inline, which sheds some overhead if the Javascript interpreter is smart enough to turn that into a jump table instead of a conditional.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page 1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Page 1 of 6
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement