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.

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

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

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

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

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