Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Public jsTIfied Beta: a TI-83+ in Your Browser
» >
» Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
» View previous topic :: View next topic  
Do you see any errors in the error console? Which browser are you using? I'll do my best to replicate your results.
No errors, Chrome 22.0.1229.94 (Official Build 161065) m

I can send you my rom if you want.
[nikky] the free market will decide who gets to be on the channel and who isn't
Array(16).join("wat" - 1) + " Batman!"
CC20: Air
AHelper wrote:
No errors, Chrome 22.0.1229.94 (Official Build 161065) m

I can send you my rom if you want.
I have my own GlassOS ROM, and I'm fully able to load the ROM, reload the ROM, reboot the virtual calculator, etc. It just doesn't get past setting up the file system, because it ends up in the interrupt handler.
KermM, do you support all of the undocumented syscalls?
[nikky] the free market will decide who gets to be on the channel and who isn't
Array(16).join("wat" - 1) + " Batman!"
CC20: Air
AHelper wrote:
KermM, do you support all of the undocumented syscalls?
I assume by undocumented syscalls you mean undocumented opcodes. I think that I do, unless you can think of one you think I'm not. Smile
Yup, sorry, op codes. I use the ixh/ixl/iy_ ones.

So, here is what happens (and why I asked the above question):
  • I make a library call to fs_format. Requires undocumented ops.
  • Erase the flash normally
  • Write on each page
[nikky] the free market will decide who gets to be on the channel and who isn't
Array(16).join("wat" - 1) + " Batman!"
CC20: Air
I assume you have set a breakpoint and verified that it's not getting to the page-erasing? Or is that not the case?
KermMartian wrote:
I assume you have set a breakpoint and verified that it's not getting to the page-erasing? Or is that not the case?
Nope, didn't do that yet. I couldn't because of the bad speed of the emu before. I will try later on today. And I assume that the page erase is failing since writing already works or the execlibf fails.

<edit>

The reason why I haven't debugged is that I need a working trunk build. Since it currently fails to boot, I need to roll out a fix in order to get the function maps and asm output.
[nikky] the free market will decide who gets to be on the channel and who isn't
Array(16).join("wat" - 1) + " Batman!"
CC20: Air
I just tried it in Chrome, and I seem to have no problems with GlassOS and jsTIfied. Smile I see that page 0 is full of rst 38h ($FF?), so when the interrupt fires, it just keeps jumping to $38h and pushing repeatedly onto the stack.
page 0 shouldn't have ff at 0x38 as you can't write ff to reset bits Razz

So far bugs:
Arrow To step once a breakpoint is hit, you have to clear the breakpoint, hit continue, then hit step. Not doing that doesn't step.
Arrow After you continue from your first breakpoint, no other breakpoints will be caught

Feature requests:
Arrow Step over?
Arrow Have it so that when the skin is on, you simulate the LCD contrast and such, but with the skin is off, just use greyscale - no contrast shading and such.
[nikky] the free market will decide who gets to be on the channel and who isn't
Array(16).join("wat" - 1) + " Batman!"
CC20: Air
AHelper wrote:
page 0 shouldn't have ff at 0x38 as you can't write ff to reset bits Razz

So far bugs:
Arrow To step once a breakpoint is hit, you have to clear the breakpoint, hit continue, then hit step. Not doing that doesn't step.
Fixed. One of the two execution paths for stepping had an extra check to see if you hit a breakpoint that was preventing progress. You shouldn't have to Continue to Step.
Quote:
Arrow After you continue from your first breakpoint, no other breakpoints will be caught
Fixed.

Quote:
Feature requests:
Arrow Step over?
Excellent idea. I'll think on how to implement that, although I have a pretty good idea.
Quote:
Arrow Have it so that when the skin is on, you simulate the LCD contrast and such, but with the skin is off, just use greyscale - no contrast shading and such.
That would certainly save a lot of CPU time.
LDIR Bug

Upon running all.c: void flashErase(unsigned char page) __naked, the ldir command succeeds the first time. When ran again, ldir doesn't copy any data.

Dump 1:
Code:
/** Erases a sector
 *
 * Given a page, the sector will be erased
 * @warning Do not use this directly
 *
 * @param page Page in the sector to be erased
 */
void flashErase(unsigned char page) __naked
{
  page;
#ifdef SDCC
  __asm
  di
 
  ld hl,#__flashErase_start
  ld bc,#(__flashErase_end-__flashErase_start)
  ld de,#0xf000
 
  ldir
 
  pop bc
  pop hl
  push hl
  push bc
  push hl
  call #0xF000
  pop hl
  ei
  ret
  __endasm;
#endif


Dump 2
Code:
void _flashErase(byte page)
{
  char *f1 = (void*)0x6AAA; // Page 2
  char *f2 = (void*)0x5555; // Page 1
  byte *spot = (byte*)0x4444;
  char oldpage = Port_Mem_B1;
 
  // Dont' do something stupid
  if(page > 0x67)
    return;
  //ASSERT(page < 0x08 || page > 0x67, "flashErase: Page out of range!");
  // Electro-Disco  --  Thanks PongOS!
  Port_Mem_B1 = 0x02;
  *f1 = 0xAA;
  Port_Mem_B1 = 0x01;
  *f2 = 0x55;
  Port_Mem_B1 = 0x02;
  *f1 = 0x80;
  *f1 = 0xAA;
  Port_Mem_B1 = 0x01;
  *f2 = 0x55;
  Port_Mem_B1 = page;
  *spot = 0x30;
 
  while(*spot != 0xFF)
  {}
  Port_Mem_B1 = oldpage;
}


IRC log
#cemetech on 10/25 CST wrote:
[16:46] <THX1138> KermM, narrowed down why GlassOS crashes
[16:46] <THX1138> you implimented ldir incorrectly
[16:46] <THX1138> it copies the wrong data afaik right now
[16:46] <THX1138> yup, it copied garbage
[16:47] <BrandonW> That sounds like a critical issue.
[16:47] <BrandonW> Something that would've come up before now.
[16:47] <THX1138> the source couldn't have changed
[16:47] <THX1138> it is in the rom
[16:48] <THX1138> I have verified that the src is correct
[16:50] <THX1138> for ldir, hl is src, bc is length, and de is target, right?
[16:50] <BrandonW> Yes.
[16:50] <THX1138> then KermM broke it
[16:51] <THX1138> yup
[16:51] <THX1138> KermM, MAJOR problem
[16:51] <THX1138> ldir to page 81 at 0xf000 doesn't work


Memory dump on unsuccessful copy
Code:
f000: call $390f
f003: pop af
f004: pop bc
f005: ld e,l
f006: push de
f007: push bc
f008: call $379c
f00b: pop af
f00c: pop de
f00d: ld a,$3f
f00f: sub e
f010: jr nc,$3
f012: ld l,$3
f014: ret
f015: ld l,e
f016: ret
f017: ld l,$30
f019: ret
f01a: cpl
f01b: ld h,l
f01c: ld (hl),h
f01d: ld h,e
f01e: cpl
f01f: ld h,e
f020: ld l,a
f021: ld l,(hl)
f022: ld (hl),h
f023: ld (hl),d
f024: ld h,c
f025: ld (hl),e
f026: ld (hl),h
f027: nop
f028: ld a,($50)
f02b: cp $ff
f02d: ret nz
f02e: ld de,$f000
f031: ld hl,$307e
f034: ld bc,$45
f037: ldir
f039: call $f000
f03c: ret
f03d: ld a,$aa
f03f: ld ($aaa),a
f042: ld a,$55
f044: ld ($555),a
f047: ld a,$90
f049: ld ($aaa),a
f04c: ld a,($0)
f04f: cp $c2
[nikky] the free market will decide who gets to be on the channel and who isn't
Array(16).join("wat" - 1) + " Batman!"
CC20: Air
I need to get to that. For now, I must mention that I fixed TI-83+ (normal) support for early OSes, which expect the PC to start at 0x0000 when the calculator is reset. Later OSes deal with 0x8000, which is what the TI-83+SE, TI-84+, and TI-84+SE expect.

Code:
Uncaught RangeError: Maximum call stack size exceeded
i6_read_normal
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step
z8_interrupt_fire
timer_expired
z8_step


I think this is a problem. This isn't an issue in GlassOS now. The DI instruction (at 0x38) should be interrupted...
[nikky] the free market will decide who gets to be on the channel and who isn't
Array(16).join("wat" - 1) + " Batman!"
CC20: Air
jsTIfied keeps asking for a ROM image after I've supplied one. Cookies are enabled, and the emulator functions, but the dialog box appears every time I load the program to the emulator.
What browser? OS? It could be your browser supports DOM storage but it deletes the DOM storage periodically.


There are two types of people in the world: those who can extrapolate data from incomplete data
comicIDIOT wrote:
What browser? OS? It could be your browser supports DOM storage but it deletes the DOM storage periodically.
That's my thought as well. DBrak: Does it ask for a ROM every time you reload jsTIfied? Or whenever you try to transfer a .8xp program to your jsTIfied-emulated calculator?
I tried loading a Pic variable from my CSE up to jstified, and sadly, it fails to do so. :< Is the support for it not there, or could there be other issues? Had to use TILP to get the pic file from my CSE to my pc.
tifreak8x wrote:
I tried loading a Pic variable from my CSE up to jstified, and sadly, it fails to do so. :< Is the support for it not there, or could there be other issues? Had to use TILP to get the pic file from my CSE to my pc.
Support is definitely there, and I have loaded Pic variables on my own jsTIfied version before. What happens, it just displays the failed message on the right side?

Edit: Or were there Javascript errors? I recently changed how variables are sent, as you may recall, so I could have an undiscovered bug.
Quote:
Error: Unable to load the specified file. Are you sure it's a TI-83+ program, file, or application? Are you sure there's enough free memory to fit it? Is the calculator at the homescreen?


That's the message it pops up with.
  
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
Public jsTIfied Beta: a TI-83+ in Your Browser
» Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
» View previous topic :: View next topic  
Page 7 of 8
» All times are GMT - 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



© Copyright 2000-2019 Cemetech & Christopher Mitchell :: Page Execution Time: 0.231575 seconds.