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). Wink


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. Sad What am I missing?
When you can get me the ability to step through the OS, I will know what goes wrong Razz

<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. Sad 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! Very Happy


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.
  
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 Previous  1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Page 2 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