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:


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

That (1) debounces the ON key (2) turns off (3) turns back on. This line in particular should go:
Code:
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)

That would be 81KB all together; I'm suspicious.

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:

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 :/

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 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

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

Ahhh, that makes sense. Let's see if that's the case: go to line 248 of calcnet22.asm, and change
Code:
to
Code:

Ok decided to take a different route then the above. Now our handling code looks like such.

Code:


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

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:


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.