I don't believe it has been. I could easily use SourceCoder to generate a set of programs to exhaustively test all commands, but I'm not sure that would be as useful (or as quick, perhaps) as manually figuring it out.

I was thinking it wouldn't be too hard to write a program with all tokens by hand, but that you could set up some custom debugging code in jsTIfied to monitor changes to the interrupt settings, and if you knew the address in memory for the code where a token is parsed, record the current token whenever the PC is at that address. Save the timestamps of all of these events, and merge them after the test program is done running.

I guess the other fear is that the buffers might get clobbered by TI-OS shenanigans?

I might be wrong, but I don't believe that the TI-OS will clobber saveSScreen and appBackupScreen, since the TI-83 Plus SDK says that those memory areas are not used by the TI-OS, except when the calc does an APD and saves the screen into saveSScreen. That means that BASIC programs that use CALCnet can't use Input, Pause, or Menu while it's active (although I would assume that those routines would also mess with the interrupts).

Ah, I'd forgotten about Pause and Menu as probably candidates for interrupt badness.

I'm planning on putting as much code as I can on appcode ($8000) and then using a spare ram page for everything that doesn't fit. So long as tios doesn't clobber that in a basic program we should be golden

Are you still trying to do your own Calcnet implementation instead of the DCS one? I am still strongly in favor of being able to use USB.

It really all depends on where we patch into the interrupts. If we use a IM2 interrupt it will support USB. If we hook into the Getcsc hook we can support USB. If we use the link activity hook (which im not leaning towards any more) It would be I/O only.

I'm just not sure if a full blown token hook is saner or less sane than just using a hook like getcsc and then a few small changes to the dcs libs to support this. I honestly have no idea which will take more space if this ever gets incorporated into the dcs app.

Well, luckily for including this in the DCS app itself, the page with the hybrid BASIC libraries (page 2, the third page of 0/1/2), has the most space free, in the area of 200 bytes. Hopefully we can design something that will fit in that space, because that would be a perfect feather in the cap of Doors CS 7.2.

I have to look into parser hook stuff to see about how much space that will take up. Each Hook will be able to call the same routine thankfully


Code:


So the in app storage for that space is rather small its just hooking into each of the hooks and doing such setup.

Where we will run into a problem with that is reimplementing the
Get(
Send( functions.

200 bytes is definitely not enough space for all of that on top of the hook table.

So I guess we need to optimize more stuff lol.

Well, assuming that the regular Doors CS BASIC parser hook is already running, we don't need any new hooks, just extra conditional paths in the existing hook. 200 bytes should be enough for all of the catching and protecting, but as you point out, it probably won't be enough for actually implementing filling and reading the buffers. Some more optimization will have to happen, even though I swear I've implemented every spare byte out.

Hmm do you have space anywhere else in DoorsCS?

There are currently 333 bytes free in Doors CS 7:


Code:


And I will definitely need all of the bytes on Page 0 for DirectUSB gCn fixes.

I guess the order of business here is write the routines optimize them to hell then see if we can squeeze then into dcs huh :/


So what routines do we exactly need.

replacements for

-Get(
-Send(

And what else.

We need the initialization code.

And we need to document all the tokens that change to IM1

Correct?

Replacements for Get(, Send(, and ways to setup (Cn2_Setup) and tear down (Cn2_Setdown) the CALCnet system. Perhaps also a hook from getKey into cn2_GetK, although it would be better to just chain the OS interrupt and avoid that.

We can just have the first call of get( or send( initialize the calcnet routines.

A hook for getkey to cn2key should be simple i'll look into that first. ... rather can you look into that as that would be directly incorporated into dcs7's parser hook which I don't have access to the code to *poke poke*

Do you have a way to see when the basic parser is exited Kerm?

Yes, I do indeed, so it would be easy to also close the CALCnet system, although I would prefer if there was also a manual way for BASIC programs to request it shut down earlier. It seems reasonable to start it up on the first Get( or Send(.

Well seeing as Get( and Send are taking arguments I could set it up that Get(1 , Send(1 Sets up Calcnet explicitly and then Get(0 and Send(0 (technically anything >=1 for optimizations sake probable but meh) would explicitly disable it. Think that would work.


Do you have a way to see when the basic parser is exited Kerm?

Yes, I do; that's what I meant by "Yes, I do indeed, so it would be easy to also close the CALCnet system,...". I should have been more explicit about that.

Actually I just reread your post and now that makes perfect sense so... my bad lol

Ok reading through the calcnet Code again we need to make our own Cn2.2 setup routine. as your uses SaveSscreen which unless we disable APD (IDK if people will want to keep that) is a really bad place for Calcnet in a basic program.

Disable APD in your calcnet startup and teardown, and make it clear in the documentation that your routines do that.