qazz42 wrote:
very nice Kerm! Looks excellent, I really like the look of it so far. I can't wait until you get far enough for a demo
![Very Happy](images/smiles/icon_biggrin.gif)
Thanks, I feel the same way.
My only time crunch is zContest, although I'm concerned that projects and schoolwork may still interfere enough to make meeting that deadline an impossibility.
*bump* I give you... remote file listing for real files!
Yay! Great job, Kerm.
souvik1997 wrote:
Yay! Great job, Kerm.
![Very Happy](images/smiles/icon_biggrin.gif)
Thanks very much, Souvik.
Hopefully the speed with which I can throw this stuff together once I put my mind to it for a few hours will inspire more people to work with CALCnet and the Doors CS GUI API.
According to my post on the previous page, next is:
:: I can move on to listing program folders
:: Displaying the folder name in that blank space for the same
:: File send/receive popup followed by the send/receive code
Edit: I should mention that I've moved my ASM programs under development to version control, so things are now that much safer!
Sweet! Now I never have to deal with TI-Connect Ever Again! TilP doesn't exactly work wonders either.
![Wink](images/smiles/icon_wink.gif)
I won't even be disappointed if you say it's 1/4 of the speed of them, since it usually takes me 10 tries to get anything to send
willrandship wrote:
Sweet! Now I never have to deal with TI-Connect Ever Again! TilP doesn't exactly work wonders either.
![Wink](images/smiles/icon_wink.gif)
I won't even be disappointed if you say it's 1/4 of the speed of them, since it usually takes me 10 tries to get anything to send
![Razz](images/smiles/icon_razz.gif)
It will of course be limited by the maximum transfer rate of CALCnet, which is dictated by whether you're using I/O or USB linking, but almost everything should take no more than a handful of seconds to complete.
*bump* I bring you scrolling! I bring you listing of groups and appvars! I bring you almost functional listing of lists, both numeric and named, with only minor name-rendering issues (no complex lists yet). Next up is folder name displaying; the get/send popup works, so after that is actual transferring!
Very nice work indeed, Kerm
benryves wrote:
Very nice work indeed, Kerm
![Smile](images/smiles/icon_smile.gif)
Thank you very much, benryves. Because I apparently am making more progress on this than anything constructive, I've gotten program listing and also the more painfully-threaded-in folder listing implemented; only thing that's broken is hiding two mischievous programs and making going into subfolders work.
Top stuff again.
As a minor aesthetic issue, is there a reason for the folder icons having a flat bottom in the navigation bar at the top and a rounded bottom in the file list? Could you display the current folder name next to the folder icon at the top?
Will you make the protocol for file transfers and directory listings public? Network attached storage would seem like a fun project (a cheap microcontroller plus an SD card should be sufficient).
Thanks, benryves.
![Very Happy](images/smiles/icon_biggrin.gif)
Other than the fact that one is 6px wide and the other is 5px wide, I'm not sure why I have two icons that are so different. What do you recommend I do to fix it, all flat or all rounded? Yes, that empty space is for the current folder name, and I'll shortly add the code to populate it. I absolutely will make the protocol for file and directory transfers (as well as the logic to broadcast your existence and accept connections and all that) public; I would love to see a NAS device! I plan to write gCn bridges that will connect to the ticalc.org and Cemetech archives, as well.
I think flat bottoms on both would probably look the best at this small size (they start looking too round otherwise) but it is of course your call.
The gCn bridges certainly sound fun, too. I can see lots of possibilities for this project!
Indeed, that's what I was thinking as well with the icons; I'll switch to that. And I'm looking forward to coding up those bridges, assuming I can find time to do it soonish.
*bump* Managed to track down the problems with program and folder display last night while starting up a cycle of watching Caprica through for the second time. Next up is displaying the folder name in that box, then on to transferring!
*triple-post-bump combo!* Interspersed with hard work on my book, schoolwork, and just about everything else on my plate, I have been getting the system for sending files to and from calculators in place. I'm building the components to send a file from the master to the slave first, from which I will then be able to plug in logic to switch the direction. Currently I've gotten it almost working; both ends sync, the slave tells the master if it can deal with the requested transmission, creates the program if it can as an empty program, and begins piping data in. It then crashes; I'm fairly confident it's a size mismatch that's making it wander above $C000 that's the problem. Also, for my and benryves' future edification:
KermMartian wrote:
*triple-post-bump combo!* Interspersed with hard work on my book, schoolwork, and just about everything else on my plate, I have been getting the system for sending files to and from calculators in place. I'm building the components to send a file from the master to the slave first, from which I will then be able to plug in logic to switch the direction. Currently I've gotten it almost working; both ends sync, the slave tells the master if it can deal with the requested transmission, creates the program if it can as an empty program, and begins piping data in. It then crashes; I'm fairly confident it's a size mismatch that's making it wander above $C000 that's the problem. Also, for my and benryves' future edification:
![](http://www.cemetech.net/img/projects/sandpaper/sendrec.jpg)
Nice data sequence diagram... but what do you mean by "d ick" (on the left side)? Or is that supposed to be "click"?
Since each packet has an offset field, does that mean the protocol could support partial and/or resumed file transfers? If files must be transferred completely from start to finish, I wouldn't think each packet would need an offset (since the offset could be calculated by adding up each packet's size).
That says "click"; it's just a cleaned-up cell phone picture of a whiteboard sketch.
![Smile](images/smiles/icon_smile.gif)
The protocol could indeed support such things, but the main point of that offset field is in case packets get re-ordered inside globalCALCnet. Local CALCnet guarantees in-order delivery, but gCn does not specify an in-order guarantee necessarily, since it doesn't dictate what protocol gCn operates over. I figure better safe than sorry.
KermMartian wrote:
Local CALCnet guarantees in-order delivery, but gCn does not specify an in-order guarantee necessarily, since it doesn't dictate what protocol gCn operates over. I figure better safe than sorry.
Oh, I see. So gCn doesn't always run over reliable, ordered protocols like TCP/IP? I admit I'm not familiar with how gCn handles data transfer over unreliable links (retransmission et al).
christop wrote:
KermMartian wrote:
Local CALCnet guarantees in-order delivery, but gCn does not specify an in-order guarantee necessarily, since it doesn't dictate what protocol gCn operates over. I figure better safe than sorry.
Oh, I see. So gCn doesn't always run over reliable, ordered protocols like TCP/IP? I admit I'm not familiar with how gCn handles data transfer over unreliable links (retransmission et al). It currently does run over TCP, but I try to be as defensive as possible with these sorts of things just in case.
Edit: Successful transmission from master to slave for programs to and from RAM and Flash! It's a little slow, but only because of GUI overhead. I need to do something about that... Anyway, next is the other way around, then those folder names, then submission to zContest! And then get things other than programs working, and consider Ben and Daniel's idea about accepting big programs.
That is swell!
INVALID is about 6 kbytes, right? That transfer took about 24 seconds, so that's about 250 bytes per second, or 2 kbps. Is that about right? Would updating the progress bar cause that slow of a transfer rate?
Does the progress bar update once per second or once for every packet sent? (Of course, with the maximum CALCnet packet size of 255 bytes being transferred at 250 bytes per second, it's about the same either way, assuming you're sending maximum-sized packets for data).
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
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