The problem isn't the progress bar on the Master end, which is drawn independently of the DCS GUI. The problem is the interface on the Slave end, because the event-handler for incoming network data on the Slave side is inside a DCS GUI MouseHook, which means the interface on the Slave side gets redrawn once per frame, or once every 250 bytes (the rest of the frame is 2 bytes of offset and 1 byte of frame type, and I leave a little leeway for safety, because I never trust taking all 255 bytes). I've measured the maximum theoretical bandwidth at nearly 4kbps, and this is getting a mere 2kbps, so I'll re-configure the handler and see what happens.

Edit: Down to 5695 bytes in 11.77 seconds = 483.9 Bps = 3871 baud. I'm quite happy with that rate, to be honest; according to the globalCALCnet benchmarks that's pretty optimal.

*bump* At last, successful transmission from slave to master, for RAM and Archive programs arriving in RAM and archive! This means that Sandpaper for zContest is just about done, pending documentation and final screenshots. My to-do list looks like this:


Code:


Most of that is fairly straightforward except for #2 and #3, which will require a good deal of code, unfortunately. I also want to implement the suggestion where I archive sandpaper itself (somehow) while leaving a stub in RAM during transfers, so I can maximize the size of programs that can be sent. This is particularly difficult because of the way Doors CS handles program execution.

This looks cool, I just had unfortunatly no time yet to test it...

I hope you get to it soon. Do you have two calculators that you can use to test? Also, that To-Do list looks like this now:


Code:

No, just have one calc.......

Just put the data into an appvar, detect the file type later and repack it?

Great work, especially on the busy indicator !

You lost me there.

Thanks! I was particularly happy with how that came out as well.

Ehm haha, I think I answered a post from page one, not having seen the other 4...

Haha, I can't tell you how often that happens to me. This project is done in the sense of being fully-functional for sending and receiving programs to and from archive and RAM; there's a video linked in this news article:

http://www.cemetech.net/news.php?id=487

But presumably you saw that now.

As you may have seen on IRC today, I've been modifying my calcpkg project so it can support multiple repositories (specifically, both Cemetech and ticalc.org), which will allow Kerm to use it as part of FTPHub. He requested I poke him in a topic, so here are the things I found that need to be done for it to work on Cemetech too:

Some sort of index file (similar to this one on ticalc.org) needs to be added. The format doesn't need to be identical, but it would help if it was, because then I could reuse more of my existing code.

It would also help if the pages for each file in the archive had fields indicating when the file was uploaded and the size of the file, so the file info outputted by calcpkg won't end up looking like this.

I have a little problem: If I want to connect ticalc or Cemetech (other things I couldn't test yet) It freezes when I press connect...
I don't have the updated version with that minor bug fixed yet. Is that bad?

It's not a bug in Sandpaper. When you connect to ticalc.org or Cemetech, it's asking my server for a listing of the root folder. Since I didn't finish putting the code together on my server for that last night, it just keeps waiting for a folder listing that the server is not going to send it. Just press [CLEAR] to disconnect and wait for me to finish the bridge.

I just downloaded this, and I think that this is great! I did some unit-to-unit tests with my friend, and saw that some things worked and other things had bugs. FYI, I am using a 84 Plus SE with OS 2.43, and he is using an 84 Plus BE with OS 2.53MP.
- Both of us were able to set up our calcs with our own usernames.
- File browsing worked fine - I could see all of my files on my system. However, the first program on the list was entitled "##ERROR##".
- Both of us were able to connect to each other's calculators.
- This is where the success ended. When we tried to send a small program to each other, Sandpaper froze, and I had to hold [CLEAR] to get out.
- In addition, I saw that the calculator had created X1T, Y1T, r1, and u crap variables that took up no RAM but appeared to be thousands of bytes. And when we deleted one of them, RAM cleared.

I'm very excited about this. I told my AP Stats teacher about CALCnet, and she was very excited about it because networking could be used to share statistical data and take tests. Once Sandpaper is complete, I want to network my whole class of 35 people - and possibly connect everyone to globalCALCnet. Keep it up!

Well, I wanted to connet, but it somehow doesn't seem to work anymore. I did it the same way as i did always but it doesn't really connect.....
Usually on SAX it says I'm connected but it doesn't. And on WebHub it won't even load any page. Terminal says it could connect:

Code:
(the patter started at the end is continued often)
What am I doing wrong?

Compynerd, I'm very happy to hear that, and thank you for the tests! Did you try to send a program, or a non-program variable of some sort?

Edit: Sorunome, I see what happened, it was a crash on the gCnHub last night. Fixing it now.

*bump* Compynerd, hopefully I manage to snag you again at some point; I'd like to ask a few followup questions on your bug report either here or on SAX.

Awesome work so far! Just a feature suggestion: Have you considered being able to sync programs/data from Sourcecoder to Calc with this? That could be really useful for basic/axe projects ongoing between Sourcecoder and calc.

I certainly have considered it, and think it would be a great bridge to add next to ticalc and Cemetech, but after I get those two working. My to-do list in order of importance on Sandpaper:

1) Implement transfer of non-programs
2) Get ticalc.org file contents listing
3) Get ticalc.ogr file contents transferring
4) Apply ticalc.org successes to Cemetech, create master.index
5) Page-scrolling in Sandpaper
6) Sandpaper 1.0 Beta 1
7) SourceCoder/File Backup bridge

@KermM: As you requested, here's more information about our attempted transfer:
- When I attempted to send a non-program variable (Matrix [A]), I got an "Invalid Data Type" message box, as expected.
- For our transfer, I was slaved to my friend's calculator, named "Rommel". (Mine was called "Compynrd").
- I can't remember exactly what program we transfered, but I recall it was ~10KB. "Rommel" tried to send the program to my archive, but the transfer hung. Both of us had to hold down CLEAR to exit Sandpaper.
- As I recall, ever since my friend put OS 2.53MP on his calculator (after a flash chip reinit), we have been having problems playing Obliterate as well. However, non-Cn2 link programs (such as Bomberkids by X-1 and Puyo Puyo by Quigibo) work fine.

Hmm, I hadn't previously run into any issues with CALCnet and 2.53MP, but it certainly bears further examination. Do you think you had sufficient RAM and ROM for the transfer? I don't think I have errors in my memory-checking routine, but it is certainly possible.