Very Happy just a start got some bugs left Very Happy
Beautiful job, geekboy! I took a pass through your code and see that I'll need to do a tiny bit of optimization, but otherwise it's great. I also need to find the time to finally fix up gCn once and for all.
Yeah once I get it working I will be doing a large handful of optimizations as well. I see a couple but just want to get it working first Razz

Whats wrong with gCn?

And the last things I need to do are figure out why the program is crashing on exit unless it is cause theta is garbage I'm currently stumped. But that is what debugging is for is it not? First order of business is finding exactly where it is crashing I think that would be the problem.

Also you think users would get a benefit from being able to send arbitrary data as well like a bitmap? I could add that in as well we are currently at ~640bytes free which is a lot better then my original estimate.
What do you mean by a bitmap? I thought we were sending a string (or is it a list now? I forget. Very Happy). The things wrong with gCn are two-fold (and related):
1) A directUSB connection can only be made on the homescreen
2) Reconnecting directUSB inside a program does not work.
Ah. And we can send a list or a string. The program parses the imput on cn2send and sets the frame up for which ever data is being sent. Cn2get then recreates it on the other side
geekboy1011 wrote:
Ah. And we can send a list or a string. The program parses the imput on cn2send and sets the frame up for which ever data is being sent. Cn2get then recreates it on the other side
Yes, so it does; now I remember. Smile I think that's a good enough start for now. A string can be a string or binary data, a list can be used as a real number (one element), a complex number (two elements), or a real list (1+ elements). The only thing we're really missing there is pictures, and I'm sure there's a DCSB Libs + C3 way around that problem.
I should mention i do not support complex lists. Diffferent data headers and structures
geekboy1011 wrote:
I should mention i do not support complex lists. Diffferent data headers and structures
Aye, that's why I specified real list. And to transmit a complex number, you would of course have to send {real(X),imag(X)}.
A complex list also has a different name. I don't send the variable names across the network. So for a complex list I would need more branches in my code but the guts would stay the same Razz If needed it can be added ^^

ListObj,tVarLst,Name,Goes,here is a Real list
CListObj,tVarLst,Name,Goes,here is a complex list

I don't store any of that in the CALCnet frame they are reconstructed dynamically on the other side of the network
Why would it be a different name? I would think we could just edit the byte that indicates the data type to be one of three instead of two possible states, then use 18 bytes per element instead of 9 bytes per element if it indicated complex lists. At any rate, I don't think adding complex list support should be any sort of priority for us.
Actually it would just be changing the flag byte at the start of the calcnet frame.

Where data type is currently
0 for a string
1 for a list

So i could make 2 be a picture complex list appvar w/e doesn't matter even a program and so on and so forth
Well, the problem with sending things like picture variables is that we would have to handle the logic of breaking it up into four different frames and sending those. I think we should avoid that. Let's just fine-tune what we have now and save future expansions for Doors CS 8. Smile
Your gonna have to buy me a 84+cse if you want my help with that Kerm Wink

Runer suggested using the typebyte instead of 1/0 while that works it actually costs 6 more bytes then not using them but allows for more readable code. Thoughts?
OK Bad news. If you run a CN2basic command and the Interrupt is disabled it will crash your calculator. ( Why couldn't the zilog give us a nice way to check what interrupt mode we are in Sad )

Good news. It seems to work and be stable Very Happy soon as my batteries charge I am going to put together a really crappy demo where you can move an X around the screen from either calculator on the network.

As long as no bugs pop up with this the only remaining things that need doing is some optimizations that Kerm apparently sees and adding more basic variables that can be sent if we want to.

Fun Facts:

  • The new code is 348 bytes
  • It gave me a headache to understand
  • Is the second CALCnet library of sorts i have worked on Very Happy
Wow, sounds awesome, is actually pretty useful, nice work! Very Happy
Great job, geekboy! Please upstream the code to me somehow and we'll see what I can do with it. Smile

Edit: Pulling out my TI-84+SE for the first time in a long time to try to debug the DirectUSB gCn issues.
Blow that dust off Very Happy this will be fun Very Happy if you need a hand nag me on irc I got a 84+se that can help if needed
My thoughts on the beta test run:


    * Speed: Speed of transmission was very fast, every with huge numbers.
    * Handling: The interface is great at handling errors. If a string is over 252 characters, it'll automatically truncate, if the link cable is disconnected during transmission the calculator will continue attempting to receive/send without any problem at all.
    * Usability: This was incredibly easy to get up and running with. Given that I haven't messed with a lick of BASIC code in about 2 months, I was able to create a testing program in under 5 minutes.


    * On key: While transmitting/receiving, the on key doesn't work, which means it's impossible to stop a program while it's looping. Geekboy has acknowledged this and says he has an idea to fix it, however.

A little more background information:

    * The test was conducted with the latest version of Pindur TI (an emulator)
    * The ROMs used were of an 83+
    * The testing program was a simple infinite loop that sent/received data
    * Functions used were Cn2Ctrl, Cn2Get, and Cn2Send

I'll add more later. Next time, I'll look in to the transmission of lists.

Thanks for giving me this opportunity!
Great job, Techboy! The [ON] behavior is probably caused by my code; does pressing [ON] make it turn off? I'm curious what geekboy's suggested solution is.
Pressing [ON] does nothing; it doesn't quit the program or turn off the calculator. Nor does [2nd] + [ON].
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  Next
» View previous topic :: View next topic  
Page 6 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