Perhaps it's bad luck, and perhaps the 84+ keypads are just poor quality. I was devastated to hear about them not shipping the non-CAS Nspires with the 84+ keypad anymore. Sad
Progress?
souvik1997 wrote:
Progress?
Haven't had an ounce of free time, I'm afraid. Sad Other than that, though, I'm hoping Sunday and Monday I'll have time to work on this and Obliterate. Feel free to nag me (all of you) so I do so!
KermMartian wrote:
souvik1997 wrote:
Progress?
Haven't had an ounce of free time, I'm afraid. Sad Other than that, though, I'm hoping Sunday and Monday I'll have time to work on this and Obliterate. Feel free to nag me (all of you) so I do so!

I can easily nag you about a project, just ask sircmpwn and Quigibo.

Anyway, it might take you a bit more than an evening, but I would love to play oblit enough to help you test it.
KermMartian wrote:
souvik1997 wrote:
Progress?
Haven't had an ounce of free time, I'm afraid. Sad Other than that, though, I'm hoping Sunday and Monday I'll have time to work on this and Obliterate. Feel free to nag me (all of you) so I do so!

Nag. Very Happy
Consider me properly nagged; perhaps we can continued in the Slashdotted thread? I recently trimmed all the Obliterate parabolic discussion into a separate thread.
*bump*

On Brandon Wilson's nagging, here is a preliminary spec on the direct USB gCn bridge.

1) Some kind of synchronization mechanism must be present. There's no such thing as out-of-band communication, correct? Is there anything in the direct USB transfer to mark the "beginning" of a virtual packet?
2) Inside the packets (frames) needs to be receiver, sender, data word, payload
3) Non-broadcast frames need the two-byte checksum on the end. Is there any point ack'ing the checksum, or even having them? Does USB offer some guarantees on data integrity?
4) As far as calc->bridge frames, I can't think of anything special that needs to happen.

Thoughts?

Edit: Lots of helpful thoughts from BrandonW on Have Calc, Will Program! Not the least of which is this:

http://cemetech.pastebin.com/SL7rYMMM
We covered this last night, but for the sake of letting everyone know, here's what we learned:
This is actually a lot simpler than we had originally thought as far as the calc and computer side of calc->computer, and the computer side of computer->calc. Basically, when a calcnet packet is ready to be sent to the computer, all that needs to happen is a bcall gets made, and the data in the buffer gets sent out (getting broken up by the OS). It then gets sent to the computer, and the computer puts it all together and then basically raises and event that has the whole buffer. From there, it can just be sent straight to gCn. As for sending to the calculator, just one function call is needed to send it the calc. The calc will then have to do some stuff to make it work (which is where the complicated part is).
If we go ahead and use the framework I have in place, the PC side is really simple. The hard part in this, as I see it, is when the calc gets data from the USB. Kerm doesn't have much space to work with in DCS. The code he posted from Brandon is basically what the calc needs to do when it gets data, except it's in C.
Even more specifically:


Code:
Page 0 is 16250 bytes long (134 bytes to spare)
Page 1 is 16370 bytes long (14 bytes to spare)
Page 2 is 16122 bytes long (262 bytes to spare)


This means that because the interrupt is on Page 0, I have 134 bytes to fit all the Direct USB stuff. I'll have to do some shuffling or some optimization before I actually write the Direct USB stuff, which I am not at all anticipating with any happiness.
merthsoft wrote:
If we go ahead and use the framework I have in place, the PC side is really simple.

If/when you and Kerm come to visit, we should look at rewriting your C# code to more generic C for better cross-platformness. I don't *really* want to try and build Mono from MacPorts.
I'm not writing any C, it's a foul language and can't be trusted. Running it under Mono is not any harder than it would be to port this to C. Actually, though, I might have to make a Mono specific port.
elfprince13 wrote:
merthsoft wrote:
If we go ahead and use the framework I have in place, the PC side is really simple.

If/when you and Kerm come to visit, we should look at rewriting your C# code to more generic C for better cross-platformness. I don't *really* want to try and build Mono from MacPorts.
I too am very interested in doing that, although I think that Merth may be less enthusiastic. I will also be bringing my brand-new Prizm to show you guys!
elfprince13 wrote:
merthsoft wrote:
If we go ahead and use the framework I have in place, the PC side is really simple.

If/when you and Kerm come to visit, we should look at rewriting your C# code to more generic C for better cross-platformness. I don't *really* want to try and build Mono from MacPorts.
Mono does binary releases that should work on most Macs, assuming there is Libusbdotnet support you should be gold or am I missing something?
Well, my personal objection was that I was hoping to merge all the gCn Bridge drivers together into one gCnClient package that would support the Direct USB link, the USBHID ($10) Bridge, and the Arduino Bridge, but it wouldn't be the total end of the world if that turned out too be too much work to be worthwhile.
KermMartian wrote:
Even more specifically:


Code:
Page 0 is 16250 bytes long (134 bytes to spare)
Page 1 is 16370 bytes long (14 bytes to spare)
Page 2 is 16122 bytes long (262 bytes to spare)


This means that because the interrupt is on Page 0, I have 134 bytes to fit all the Direct USB stuff. I'll have to do some shuffling or some optimization before I actually write the Direct USB stuff, which I am not at all anticipating with any happiness.
I have a question, why can't the "Direct USB stuff" be on a separate page than the interrupt?
Probably because page swapping in an interrupt would not be a good thing to do.
souvik1997 wrote:
Probably because page swapping in an interrupt would not be a good thing to do.
Exactly this. Page swapping is not the fastest of operations, plus it would require another few bytes in the RAM part of the interrupt stub to perform the actual page switch. It's a possibility, but not one that I want to be my first approach.
Merth: C is a delightful language Razz Much more so than most of its dialects.

TheStorm wrote:
Mono does binary releases that should work on most Macs, assuming there is Libusbdotnet support you should be gold or am I missing something?

I am meh-ing at Mono in general.

KermMartian wrote:
Well, my personal objection was that I was hoping to merge all the gCn Bridge drivers together into one gCnClient package that would support the Direct USB link, the USBHID ($10) Bridge, and the Arduino Bridge, but it wouldn't be the total end of the world if that turned out too be too much work to be worthwhile.

We can see how it goes =) I like this plan as well.
For sure. Anyway, for this weekend, I am going to try to brainstorm ways to optimize and consolidate things in Doors CS. I will be posting my progress in this thread.
I hope that goes well. Smile
  
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, 8  Next
» View previous topic :: View next topic  
Page 2 of 8
» 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