AHelper wrote:
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.
And yes, Javascript does have function pointers: this is a tutorial on how to do it. I am to assume that you would do these to differentiate between Flash and RAM reads?
Indeed. I am thinking that for each mode, you would just change the current read/write handler, one for normal, one for unlock bypass, get info, etc.. This should have a nice speed gain rather than if statements.
Also, site bug report: the mobile version doesn't have the jstified page show up correctly.
I like that a lot. In fact, I could even do it cleverly based on a flag indicating whether the fast mode could be used, or the slower mode that either handles ports 27/28 or handles the Flash ID read. I should note that the ti_83p_read() function is called 721 times from my z80 core, so I don't want to modify every single one of those. I'll probably add a function that will literally swap out the ti_83p_read() function pointer to one of two (several?) underlying functions when the mode to be used changes.
Edit: I missed the last page. AHelper just proposed exactly what I said. Also, regarding the bug, I will get comicIDIOT on that ASAP.
Might be interesting to benchmark the old and new implementations across a couple different browsers and see how it handles?
I implemented the function pointers. Here is the profiling report from going to the Apps menu, opening Doors CS, and moving the mouse around a bit. Function names have been changed to protect the innocent (actually, to make them more understandable).
Code: function name calls pct own time own/callee avg per min per max per
-------------------------- -------- ------ ----------- ------------ --------- --------- ---------
step_cpu 20484022 42.73% 52530.634ms 80556.011ms 0.004ms 0.001ms 3.82 ms
run_for_one_frame 356 20.82% 25596.708ms 121640.221ms 341.686ms 289.372ms 741.91 ms
ti_83p_mem_read_normal 26979769 19.23% 23644.505ms 23644.505ms 0.001ms 0.000ms 3.466ms
ti_83p_interrupt_fire 7853684 12.59% 15472.568ms 59949.395ms 0.008ms 0.003ms 4.063ms
ti_83p_mem_writebyte_internal 904797 1.41% 1733.906ms 2528.719ms 0.003ms 0.001ms 0.625ms
ti_83p_mem_write 904797 0.65% 794.165ms 794.813ms 0.001ms 0.000ms 0.623ms
ti_83p_port_in 458653 0.54% 658.415ms 736.515ms 0.002ms 0.000ms 0.702ms
ti_83p_port_out 615946 0.5% 611.137ms 764.814ms 0.001ms 0.000ms 2.376ms
anonymous 356 0.47% 582.047ms 582.047ms 1.635ms 0.995ms 5.292ms
jstified_lcd_recalculate 356 0.42% 518.558ms 645.907ms 1.814ms 1.343ms 4.534ms
sign_extend 446953 0.29% 358.229ms 358.229ms 0.001ms 0.000ms 0.29ms
anonymous 56848 0.1% 128.017ms 128.017ms 0.002ms 0.000ms 0.151ms
jstified_lcd_paint 356 0.1% 126.959ms 126.959ms 0.357ms 0.277ms 0.749ms
AHelper: I notice that even with a read from 0x00 returning $C4, GlassOS seems to not work. What am I missing?
When you can get me the ability to step through the OS, I will know what goes wrong
<edit>
Can you let it step through a breakpoint?
Also, once you hit a breakpoint, you can't start stepping again. It will only continue.
<edit>
It hits the function block at 0x30fa, then it dies in there. My money is on the function flashchipmanufcheck();
<edit>
Got it. When you read the flash chip info, it resets once you read it. No reset command needed. That is the problem at 0xF02C when I try to write to the chip, but the write fails.
I'm afraid that that didn't do it.
I'm working on a little disassembler now that should help, but anything you can tell me now would be very helpful.
AHelper wrote:
It works, and animated screenshotting worked for you too! That's excellent. Am I correct in thinking that this will require a GlassOS update/patch, since it didn't previously listen to the $C4 as a "no unlock bypass" flag?
Sorry, but from the GlassOS source, it should be C2, not C4. :-S
Heh, indeed. I updated the
relevant WikiTI page with that correction, fixed jsTIfied, and added a small debugger view. It can't fill in the arguments to every command yet, but it's getting there! I also need to fix up SourceCoder before I do too much more on jsTIfied, as I left it in disarray trying to add a mention to my book and other sources of TI-BASIC help and tutorials.
I believe I've found a bug. Interestingly enough, this only occurs in SourceCoder and not jsTIfied. However, when I use the exported .8xp from SourceCoder in jsTIfied, it works fine!
I think the best way to explain is by providing a screenshot:
http://imgur.com/YzGfO
As you can see, the compiled .8xp is completely garbled and the program is unable to run.
This continues to occur even when I remove the comments and extra ":"s.
techboy6601 wrote:
I believe I've found a bug. Interestingly enough, this only occurs in SourceCoder and not jsTIfied. However, when I use the exported .8xp from SourceCoder in jsTIfied, it works fine!
I think the best way to explain is by providing a screenshot:
http://imgur.com/YzGfO
As you can see, the compiled .8xp is completely garbled and the program is unable to run.
This continues to occur even when I remove the comments and extra ":"s.
It appears as if these are the HTML escape sequences for the individual characters in the program. Obviously a bug, but certainly has a root cause.
I actually remember bug-fixing this sort of issue long ago. Can you try a ctrl-F5 just to make sure everything is the newest script code? Can you also please check your Javascript console to see if there are any errors related to this?
I've got three:
1) 404 error for browsers.png
2) Refused to set unsafe header "Content-length"
3) Refused to set unsafe header "Connection"
Those don't seem to be Javascript though.
techboy6601 wrote:
I've got three:
1) 404 error for browsers.png
2) Refused to set unsafe header "Content-length"
3) Refused to set unsafe header "Connection"
Those don't seem to be Javascript though.
OK, good to know. Can you email me your current .8xp that creates this error? Use your username at this website's domain as the recipient email address.
Edit: Fixed this eventually. Note to self: PHP really sucks at encoding.
Yet another error:
Again, I'm not sure if this pertains just to jsTIfied or SourceCoder. What I'm doing is a program that uses the DCS GUI libs to display a GUI. I have uploaded DCS7 to jsTIfied as well.
The program runs fine, but when I use the arrow keys to move the cursor (both on the screen and on my keyboard) the GUI disappears after a short while.
I know this isn't my coding; I'm drawing the GUI and immediately after calling GUIMouse. The program works perfectly fine in WabbitEmu. I believe that this may be caused by the scrambling of keys; when I move my mouse around some of the buttons (in the DCS GUI, not the skin) it seems as if they were involuntarily pressed.
Again, this works fine in WabbitEmu, so I think the program's okay. It may either be jsTIfied or the way that SourceCoder sends programs to jsTIfied.
Good luck!
EDIT: I have managed to find some more details. Apparently pressing the left arrow key causes the GUI to immediately exit.
Thanks for the detailed bug report. Can you please either permission me to view the SourceCoder project in question, or send me the .8xp? Also, before you do that, can you verify if exporting a .8xp from SourceCoder and then sending that to jsTIfied also causes the issue?
Yes, I can verify that exporting from SourceCoder and uploading to jsTIfied also causes the issue. The "pressing left arrow key immediately quits GUI" issue is also apparent here.
techboy6601 wrote:
Yes, I can verify that exporting from SourceCoder and uploading to jsTIfied also causes the issue. The "pressing left arrow key immediately quits GUI" issue is also apparent here.
I am able to replicate this as well. I suspect it's more about debouncing and/or proper state-change delay in the keyboard code than anything else.