Hmm, yes, I see. Is the game in the Cemetech Archives somewhere so I can try it out myself and try to get to the bottom of that?

Edit: Now it is, thanks for that. I continue to work on various aspects of jsTIfied, especially improving the debugger. I also saw a significant speedup in Firefox from switching to an inter-frame delay of 0ms, as suggested here, but so far I haven't had anyone confirm that.

Edit #2: Multiple breakpoints now work, and the emulator will be faster than ever when no breakpoints are enabled.

*bump* Current status of the upgrades:


[X] Add an intermediate GRAM buffer
-- [X] First use that to directly populate the LCD canvas
-- [X] Save that instead of the LCD on quit
-- [X] Implement full GRAM-to-LCD copying when necessary
-- [X] Implement Vertical Scroll Control
-- [X] Look into GRAM offset
-- [X] Implement partial image mode and interlacing
[X] Fix alignment of drag-n-drop overlays on monochrome models
-- [X] Remove ROM drop for models without Flash
[X] Fix jr and some bit commands in disassembler view
[X] Make page mappings read-write in debugger
[X] Make registers read-write in debugger
[X] Display flags
[-] Look into Calc84's force-loading problem -> Solved by user
[X] Make memory read-write in debugger
[X] Refactor how memory is displayed
[X] Add debugger control:
-- [X] data watchpoints
-- [X] multiple breakpoints
[X] Add direct POST interface, switch Cemetech archives to it
-- [-] Remove callback interface?
-- [ ] Implement security for a reduced featureset for TI-Planet embedding
[/] Look into fixing GIF issues, especially frame data overcropping and color fudging
[ ] Fix sequential program loading for the TI-84+CSE

Data (read/write/read-write) watchpoints now work!

Good
I can envision the data breakpoint ability not costing any speed when not enabled (thanks to redefining the relevant JS functions), but I'm curious to know how much it costs when enabled ?

Before implementing a whole set of APIs aimed at external usage, having a semi-formalized discussion, between persons interested in JS-based TI-Z80 emulation, on
1) functional requirements + use cases;
2) whether + how to implement them
cannot narrow the applicability of jsTIfied (and thereby its applicability and popularity). I think it can only help

Every memory read or write requires one additional layer of function call and one check for an object property (ie, z80.watches.hasOwnProperty(address)). The slowdown with multiple watchpoints appears to be logarithmic, as I'd expect from a sane implementation of Objects.

Currently I'm not envisioning an extensive API; I want to mostly spiff up the ability to load external programs as used here and discussed elsewhere. What other APIs did you mean?

Bug report:

Since tonight, I am no longer able to run Doors CSE in the emulator. When the Defragmenting screen appears, it remains stucks there forever. Reseting the calc doesn't help, since the Defrag message comes back after trying to run DCS again.

In addition to that, When I try to access the memory manager, the calc freezes when attempting to display the free archive left.

I was seeing something like that, but I thought it was the fault of the program I was trying to load to the emulator. My watchpoint are probably interfering with flash emulation.

Yeah that's what I guessed, since it froze right when trying to display the free archive. At first I thought it was something to do with the latest DCS8 update lol.

Also is it me or we cannot send files that have the archive flag turned ON? If I try to send HPTUNNEL.8xp with it on, I get a transmission error, while if the file is meant to go in RAM, it works fine.

EDIT: Ok it works now, so I could test if screen shifting and swapping GRAM areas now worked: It seems that switching back and forth between both GRAM areas works, as the flashy title screen now flashes properly, but only in the emulator, not the screenshot. Also, the road still has problems during scrolling every once in a while in both the emulator and screenshot:



Note: This is an updated version of the game, which is why it looks slightly different.

I can't say that I've run into that before. Anyway, can you please test the current version of jsTIfied and make sure I've repaired this glitch?

If you mean the Flash glitch as well as the inability to send files with the archive flag on, then yes they seem fixed, but if you mean the scrolling one and lack of title screen flashing in the xLIBC tunnel, then no.

No, I meant the Flash glitch. I temporarily rolled back to an earlier version, then later rolled forward to a version I think is fixed. Please let me know if you run into any additional issues, and I'll look into the scrolling problem.

Ah ok thanks for the clarification. And sadly, yes I ran into more issues when I tried Pac-Man D: , two of which don't seem graphics-related:


http://www.ticalc.org/archives/files/fileinfo/456/45664.html

1: The ghosts AI seems broken. Notice, for example, how the red ghost constantly moves back and forth, unlike on calc, where it only changes directions after a long while.
2: Some dots don't get erased entirely when Pac Man changes direction. That doesn't only happen during screenshots, but in the emulator as well
3: Pac-Man stops moving when you try to move and there's a wall.

Those don't happen on the real calc.

I swear AssemblyBandit does some weird stuff; I also have problems with his Frogger. You die just sitting by the side of the road in jsTIfied, and I assume if that happened on real calculators, it wouldn't have gotten featured on ticalc.org.

All right, so now just about everything I wanted to implement is implemented, save the issue of how we're going to embed this as another site requested. I'll shortly be newsing about the new features and fixes, although I should probably check AssemblyBandit's games again to see why those bugs are happening, and understand what's with Tunnel Demake.

If you mean Omnimaga, I am a bit concerned about how well this will run with OmnomIRC enabled, not to mention the entire site will be remade. >.<

By the way, the Tunnel demake uses the xLIB's real(8 functions. One real(8 command used allows me to decide in which GRAM I want to draw stuff (the visible one or the hidden one) and the other command used is to change the LCD offset.

The primary feature requester for external usage of jsTIfied is TI-Planet, but Omnimaga and others could take advantage of it as well.

And me. I've been bugging him for it since he made jsTIfied.

ACK

I guess it's already, or will soon be, time to bootstrap the discussion...
So, here's an undoubtedly incomplete list of functional requirements gathered from:
* the unnamed JS TI-68k emulator started by PatrickD, my large improvements to its reliability and flexibility, and critor's integration into the TI-Planet archives system (which uses the same JS code as the standalone version);
* the terse use case description posted on #ti a couple weeks ago, by someone wanting to do JS TI-Z80 emulation in use cases not currently targeted by jsTIfied.

I'm not using MUST / SHOULD / MAY language on each item, I think it would hamper readability.

===== BEGIN LIST =====
* a well-defined set of HTML elements (div, canvas, img, map, etc. with agreed-upon names) used for interfacing between the HTML world and the JS world;
* initializing and resetting and the emulator;
* changing the skin (especially between multiple skin sizes for a given model);
* changing the ROM image;
* saving the state to an arbitrary place outside of the emulator;
* restoring the state from user input (from another script, dumped into the HTML page, etc.);
* sending individual files to the emulator;
* sending other linking commands to the emulator (e.g. dirlist, or remote keypresses, if the target model supports that operation);
* pausing and resuming execution;
* retrieving screenshots under some form;
* retrieving files from the emulator;
* triggering the debugger;
* individual access to features embedded into the debugger: manipulating breakpoints, dumping memory (including MMIO), disassembling memory, etc.
* SHOULD provide higher-level scripting support 1: support for unit testing, e.g. the ability to execute scripts containing a sequence of commands. Recently mentioned on #ti;
* MAY provide higher-level scripting support 2: the ability for executed programs to trigger actions in the emulator (e.g. outputting a dump of the MMIO to the console), using special instruction sequences which do not appear in real-world code targeted at this platform (like the header of AMS native comment data on the TI-68k, which uses some instructions legal only on the 68020+, or like VALGRIND_MAKE_MEM_NOACCESS). That's an old feature request for TIEmu, which never got implemented.
===== END LIST =====

Of course:
* many of those are already implemented, under some form, in jsTIfied;
* we fully understand the value of integration into the Cemetech tools, but for jsTIfied to maximize chances of being The One United Community JS TI-Z80 emulator (even more than it already is), it should be optional;
* anyone presenting jsTIfied to users MUST indicate its origin somehow (e.g. "powered by jsTIfied);


It would be great if the JS TI-68k emulator were at the level of usability of jsTIfied, but sadly, it isn't... The mainr reason why the link to the standalone version remains private (PatrickD and Kerm are among those in the know) is that despite an improvement of mine, the emulator still misses a significant proportion of keypresses and clicks, which makes it far less than pleasant to use. I haven't worked on the code base for nearly four months by now, since the end of my summer holidays...

Indeed, and examining my code again, I'm not entirely sure why the symptoms you're seeing are happening. I'll retry myself and see if examining the JS state when that display glitch appears helps me narrow it down.

Well, I think that's more for me to decide.

At this point, as you say, jsTIfied has most of those features except for arbitrary state saving/loading by the user and using user-defined skins. The features are certainly there for external use of all of the features, by nature of how Javascript works, but they're not formalized, and I for one certainly acknowledge that I'm occasionally lax with consistent method naming. To quickly get jsTIfied embedded on the sites that want it, I propose we start out with TI-Planet using an iframe containing the standard jsTIfied page, somehow opened with either POST data or the callback query when a website user chooses to try a program (so that it's not loaded on every single archives view). We'll have to come up with some way to securely identify the referrer as TI-Planet so that I can make the templating engine omit the standard header around the emulator, while retaining the necessary sidebars (ROM-loading, help, debugger, and so on).

iframes ? Sounds like a complicated architecture to me... the API of the JS TI-68k emulator (a bunch of HTML elements and JS functions exported from one of the objects) is simpler for embedding.

Also, I'm no fan of referrer-based solutions, not least because as a security measure, I disable referrers (and many people should do). The Internet doesn't break when I do, jsTIfied shouldn't, IMO

Indeed, that's why I said "secure" referrer; it's too easy to fake anyway. I just mean a challenge-response system or time-based hashing that jsTIfied can use to verify who's trying to embed the application. I said iframe because there is a great deal of HTML that goes into making jsTIfied work, and I tweak it nearly as frequently as I tweak the JS.