Correction the pressing of the on key actually Freezes the program. if you look a the Run indicator it freezes while on is held. As for possible fixes I tried one but it forgot to account for port 3 not getting the same write at the end of the intterupt (it defaults to %00001010 not the %00001011 we need)

Possible Fixes

    -Smc on the ram code
    -Change the interrupt to have the default of %00001011
    -Change kerms On handler to Be a hook like the precn2hook and have it be user defined. allowing us to force emulate a break. And give control back to the user for what ON does


Other thing. when a basic program crashes the link port is in a unuseable state is there anyway we can have dcs restore that globally upon return to the basic program? It is 5 lines of code

Code:

 res 3,(iy+33h)           ; ignoreBPlink         
 set 4,(iy+33h)           ; BPLinkOn      Enable Silent linking and link assist
 set 0,(iy+3Eh) 
 ld a,0
 out (08h),a               ; Reenable link assist


Just a few brainstormed ideas gogogo?
Five lines of code: I can easily insert those five lines of code into the DCS epilog for BASIC programs to clean stuff up.
[ON] held: Any insights into why that's the case?
because you call screen off and the intterupt keeps firing and looping back to where it is. I also see we do not go back to IM 2 after a power off. What are we doing in this code... @ pm on irc
geekboy1011 wrote:
because you call screen off and the intterupt keeps firing and looping back to where it is. I also see we do not go back to IM 2 after a power off. What are we doing in this code... @ pm on irc
That (1) debounces the ON key (2) turns off (3) turns back on. This line in particular should go:
Code:
res OnInterrupt,(iy+OnFlags)
In Cn2.2-enabled ASM programs, the OS interrupt is disabled, and there's no risk of it setting that flag. In BASIC programs, the OS interrupt SHOULD be allowed to set the flag. Please try commenting that line and see what happens.,
That didnt change anything sadly.

New bug of sorts? after about 9000 frames holding 1 list entry the calc gets a err:mem probably having to do with delvararc on the list entry.

According to iambian this is a problem with createvar and lists he says it has problems (according to his notes and stuff from c3 and athena)
geekboy1011 wrote:
That didnt change anything sadly.

New bug of sorts? after about 9000 frames holding 1 list entry the calc gets a err:mem probably having to do with delvararc on the list entry.
That would be 81KB all together; I'm suspicious.

Quote:
According to iambian this is a problem with createvar and lists he says it has problems (according to his notes and stuff from c3 and athena)
What sort of problems? I haven't encountered this before.

Edit: But as you demonstrated on HCWP, it certainly happens. Does the memory come back once the BASIC program ends?
OK we think that the problem is Bcall(_createvar)

I reworked the code to such and now it just crashes any thought as to what I'm doing wrong :/


Code:
DeleteAndCreate
;expects pointer to variable name in hl
;destroys all
;returns pointer to variable data in de
 rst 20h  ;load op1 with variable name
 rst 18h  ; save op 1 to the FPS
 ; Only need to save it if we are calling a delete as it survives chkfindsym
 bcall(_chkfindsym)
 push af
  jr c,create
  bcall(_DelVarArc)   ;delete if since it exists
Create:
  bcall(4390h) ;Popop1
 pop af               ; restore A which has the element type in it.
 and 1fh
 cp 1
 ld hl,(RVarLength)
 jp z,CreateRList
 bcall(_createvar)
 ret
CreateRlist:
 bcall(_CreateRList)
 ret
Hmm, I really see nothing wrong with that, as long as you're sure about those equates. Does it crash for both the Real and List execution paths?
I have yet to try it with a string.
I've been fighting with this list thing for a while now :/
geekboy1011 wrote:
I have yet to try it with a string.
I've been fighting with this list thing for a while now :/
Have you been able to use breakpoints and all that good stuff to narrow down where it goes off the rails?
I honestly haven't tried yet. been getting the same error which tells me that something is getting the wrong info imma do that in a few when i'm dont screaming at pti

Edit: last night i was stepping through code turns ouut chkfindsys is not returnig what i thought it should have been more looking into this tonight
OK, I look forward to seeing what you find. I guess the first thing you'll be checking is if you are giving ChkFindSym a valid Op1, and the second will be if the VAT/user mem is getting corrupted somehow?
Ok there were a few things causing bugs

    First: When chkfindsym is called and the variable is not found A is garbage. How I missed that I do not know.

    Second: _CreateVar Is garbage don't use it.

    Third: Now I have to prune redundant code Sad oh well could be worse


Whats this mean? ITS FIXXEEDEEDEDEDED. And now on to the next one. Which is the on keybug. Kerm how do you want to go about this one?
Congratulations, glad you managed to fix those! That's a good step forwards towards making this beta-able. For the [ON] bug, I am confused that removed the res onInterrupt,... line didn't do the trick, so we'll have to do some experimenting.
The problem has to do with how the onkey is handled by the TiOs intterrupt i believe. My hobest opinion we should remake the on key handler to be setup like a hook and have the asm profram handle it. And we should set a default hook to handle screen off in normal operation
geekboy1011 wrote:
The problem has to do with how the onkey is handled by the TiOs intterrupt i believe. My hobest opinion we should remake the on key handler to be setup like a hook and have the asm profram handle it. And we should set a default hook to handle screen off in normal operation
Can you be more specific about what you mean? You have the OS interrupt running first, right? That means it should catch and handle the [ON] key before the CALCnet interrupt; we need to figure out why it's not.
Yes it is running Before the Calcnet ISR. The problem I believe is the OS expects the interrupt to be generated via ON and there for is not checking the on bit like we do in Calcnet. Which is why we do not get an ON-Break
geekboy1011 wrote:
Yes it is running Before the Calcnet ISR. The problem I believe is the OS expects the interrupt to be generated via ON and there for is not checking the on bit like we do in Calcnet. Which is why we do not get an ON-Break
Ahhh, that makes sense. Let's see if that's the case: go to line 248 of calcnet22.asm, and change
Code:
   ld a,%00001010                  ;Set 1st timer active                  ;2
to
Code:
   ld a,%00001011                  ;Set 1st timer and ON key active                  ;2
Ok decided to take a different route then the above. Now our handling code looks like such.

Code:

Cn2BasicOnHook:
;ok we have to check if its a onkey intterupts...wherere is tix code
 in a,(4)
 rrca    ;puts bit 0 into carry to see if ON key gens interrupt. 4cc savings.
 ret nc   ; quit if not an onintterupt not our place to handle it
 call Cn2_Int_Done_TIOSInterrupt
 ;if we get here the intterupt didnt trigger an on break this happens for some reason.
 ; so now we setup for an bjump jerror
 ld a,E_BREAK
 bjump($44d7) ;jerror


This works because miraculously the basic parser does not need the TIOS interrupt to function Very Happy

now to internally check for bugs but this should be solid as far as I remember!

Kerm: i have a patch file for you when you want it if you do.
I wrote an improved version of BASIChat, but the latest DCS began causing problems. It runs fine in the first DCS Calcnet beta that geekboy sent me.

Code:

:"<>"→Str9
:0→θ
:11→dim(∟BCHAT
:ClrHome
:Output(8,1,"LOADING..."
:If not(sum(∟BCHAT
:Then
:ClrHome
:Input "USERNAME:",Str1
:sub(Str1+"{^-1}{^-1}{^-1}{^-1}{^-1}{^-1}{^-1}{^-1}{^-1}{^-1}{^-1}",1,11)→Str1
:For(X,1,11
:inString("ABCDEFGHIJKLMNOPQRSTUVWXYZ .-+/º'()?",sub(Str1,X,1))→∟BCHAT(X)
:If not(∟BCHAT(X
:37→∟BCHAT(X
:End
:End
:"+"→Str2
:For(X,1,11)
:Str2+sub("ABCDEFGHIJKLMNOPQRSTUVWXYZ .-+/º'()??",∟BCHAT(X),1)→Str2
:End
:11→X
:Repeat X=1 or sub(Str2,X,1)≠"?"
:X-1→X
:End
:sub(Str2,2,X-1)→Str2
:sum(19,1
:Goto H
:Lbl X
:sum(19,0
:Output(8,1,"BY CVSOFT v1.0-a"
:Stop
:Lbl H
:ClrHome
:If Str9≠"<>"
:Output(1,1,Str9
:Output(8,1,"SEND        EXIT"
:Lbl K
:0→X
:0→K
:Repeat K or X=95
:X+1→X
:getKey→K
:End
:If K=11 or K=21 or K=105
:Goto S
:If K=15 or K=22 or K=45
:Goto X
:Str9→Str8
:sum(18)
:If Str9≠Str8
:Goto H
:Goto K
:Lbl S
:ClrHome
:Input "<"+Str2+">",Str1
:"<"+Str2+">"+Str1→Str1
:sum(18)
:sum(17,Str1
:Goto H


It will make it to the main menu (where it shows "SEND EXIT"), but will not accept user input and will not show the run indicator. It will respond to [ON] with the HomeRun Break error screen, and quit to TI-OS or goto the first line of code in the program.
  
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, 7
» View previous topic :: View next topic  
Page 7 of 7
» 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