In November 2011, I announced the release of Sandpaper v0.8, a CALCnet-powered FTP client and server for TI-83 Plus and TI-84 Plus graphing calculators. That version, first hacked together when I visited Maine for a Cemetech retreat with fellow administrators Elfprince13 and Merthsoft, could send and receive unarchived programs and could list directories in the archives. Other than a few hours spent fixing bugs in July 2012, the code lay dormant until three weeks ago, when an internet-deprived plane ride inspired me to finish Sandpaper off once and for all.

During my commutes to and from my summer internship these three weeks, I have fixed sending and receiving programs, pictures, groups, AppVars, strings, GDBs, matrices, and lists to and from RAM and Archive. Although the program weighs in at a hefty 7KB, it is extremely full-featured, using the Doors GUI API and CALCnet to offer a friendly and fast user interface. You can connect to a friend's calculator across the room or around the world, browse their Doors CS folders, and send programs directly between their calculator and yours. You can also use the globalCALCnet FTP bridge to directly download files from the archives onto your calculator. No longer do you need to install TILP or TI-Connect: simply connect your calculator to the 'FTPHub' gCn hub, open Sandpaper, and start browsing. You can even view readmes (and other .txt files) directly through Sandpaper.

So why is this v0.95, and not v1.0? In the past, Cemetechians have been invaluable in helping me track down all of even the most subtle corner-case bugs in programs like Doors CS. I call on your once again to lend your eyes and calculators to testing out Sandpaper. To make your life easier, the Sandpaper v0.95 download even includes a preview of the newest gCnClient and Doors CS 7.2 beta 2c, which bring a great deal of stability to Direct USB-based globalCALCnet. Please give Sandpaper a try and report any and all bugs in the attached thread.

Sandpaper v0.95

A video of Sandpaper in action from the v0.8 release (left) and Sandpaper connected to the archives (right)
Disconnects when reading a long description. It says:

usb_bulk_write (libusb0-dll:err [_usb_reap_async] timeout error
Error: Failed to send Direct USB frame

Doesn't show the following programs:
83plus/asm/games/[Axe]Picraft 2 v2.1 Alpha
83plus/asm/games/Mr Oops!!
83plus/asm/games/Rainbow Dash Attack z80

Hope you can fix it. Very Happy

New bug:
I clicked the button to go back to the root folder, and it say Root at the top, but it contains readme.txt and CENTIPDE.8xp.
Sandpaper++ [edit] Sandpaper++ Sandpaper++
Caleb: Please don't write single-word posts. We value quality posts over quantity of posts here at Cemetech.

Spence: I was messing with the ability to go upwards one folder instead of all the way to the root. It works now, but unfortunately client limitations prevent it from displaying the correct name. The missing files are missing from's master.index file, which has this entry, for example:
Index of /pub/83plus/asm/graphics/doorscs (TI-83/84 Plus Assembly Graphics Programs (Doors CS))            WiredWorks v1.0 for DoorsCS 7.1.1 + Vertex3D lib
I have a bug report in to Travis about it.

Current To-Do Items:
- The ability to ascend (back out) of the folder and zip folder hierarchy DONE
- Large directories need to be broken up into chunks
- Some descriptions are coming up empty (?) (cannot replicate)
- Files excluded from rankings break CalcRepo FIXED
- Client expirations are not updated properly DONE
- Nag tev about master.index errors (partially done)
Awesome! I'll have to give this a try with my TI-84+ now.

Are you planning to work on the integration with Cemetech as well sometime in the future?
Nice job, is the server bridge open source? I would be interested in writing one on my own, i'd just have to look into the protocol sandpaper uses (I know the gCn protocol, but on how sandpaper sends packages) Very Happy
Chances are the server bridge isn't open source, and won't be.
Kerm has been burned by too many people taking his work to merely slap their name onto it; he backups the source code on his own, and sends it to select persons, but does often not publish the source code for general consumption (at least, in a human-readable manner - jsTIfied is minified) Wink
Maybe you're one of the persons who would qualify for getting a copy of the source code, though.

I'm not speaking for Kerm, just posting about my feelings.
That would be great, all I would use it for is to know what to send in the frames so that sandpaper stuff works, it is far more fun to write a own bridge anyways! Smile
TC01, probably. Thanks to your calcrepo, it would be relatively simple. I'd just need to update calcrepo's module to understand the Cemetech archives. I would imagine it shouldn't be too much work.

Sorunome and Lionel, yes, that's exactly right. I'm always happy to share my source with specific people who ask nicely if I know they're responsible individuals and won't share my code with others, but I have been burned by theft too many times to release much of my code to the general public. Which part are you curious about, Sorunome? If it's gCn messages, there's great documentation on that. If it's Sandpaper messages, you're almost better off taking a look at my internal documentation of the several messages Sandpaper uses than at the Python code for the bridge, which is shamefully poorly documented.
I'm interested about sandpapers messages, like what strings it sends and how it sends the progs as strings etc, so the poorley documented part >.<
Sorunome wrote:
I'm interested about sandpapers messages, like what strings it sends and how it sends the progs as strings etc, so the poorley documented part >.<
Well, here's a first pass at that. Here's what's in the header of my source code:
;===Frame types:===
;1   [9-byte name payload]      Broadcast for "I am here"
;2   [no payload]            Request pair (master->slave)
;3   [no payload]            Accept requested pairing (slave->master)
;4   [no payload]            Reject requested pairing (slave->master)
;5  [no payload]            Disconnect (either direction)
;6   2-byte payload            Request folder list
;7   variable payload         Folder list, multipart.  First frame is two bytes and holds list size.
;14 sz[2], titlesz[2], title... Begin "chat" message
;15 offset[2], size[2], text    Chat message body
;16 title[8]               Remote folder name

;8    sz[2],compsz[2],arcd[1],fld[1],t[1],name[8]   Request-to-send (RTS, master sends to slave) (master->slave)
;9  accept/deny[1]            Accept/reject incoming file (slave->master)
;13 accept/deny[1],sz[2],compsz[2]      Accept/reject outgoing file (slave->master)

;10 T[1],name[8],loc[1],memfree[2] Request-to-get (RTG, master fetches from slave) (master->slave)
;11 y/n[1], sz[2]            Success/fail, header (slave->master)

;12 offset[2],data      Data packet (either direction)
Thanks, That'll help a lot!
but what are things like
well, i guess the [] just mean how many bytes, but please complete this for me:
sz = size
titlesz = titlesize
compsz = ? (compressedsize?)
arcd = ?
fld = ?
t = ?
T = t?
loc = location?

and for 12, offset, is that the offset in bytes and how many bytes are usually sent per frame?
sz[2] = Size bytes. For lists, these are something like (col, row); for programs, they are (lowbyte, highbyte), etc
compsz[2] = Computed size, in bytes. For a 2-element list, this would be 2+9*2=20 (it includes the 2-byte variable header). For a 100-byte program, it would be 102 (100 bytes + size word)
arcd = archived, 0 or 1
fld = folder, 1 to 255. Or 0 to put in no folder. Folders are a Doors CS thing.
t = type, like 5 for programs, 6 for locked programs, and so on.
loc = location = source folder, as I recall
Got my bug pinned down: I run Doors, run Sandpaper, hit "Programs", then press Clear. Run Sandpaper again, hit "Programs" again, and it crashes. This it does without fail. It also, after my pressing Clear, when I go to the memory menu, the "Y-Vars" menu, it displays a bunch on trash like "> Y1....21009". All the "Yx" vars, the "Y/XxT" vars, and the "rx" vars, are used, and the sum of them, as is often the case with Ram corruption, is far above the available RAM.

Also, I have about 70 programs on calc at all times, in various DCS folders, with the hierarchy extending to about 5 nested folders. Model, 48K TI-84+SE, OS 2.55 mp. Also I have about 37 other nonprogram files oncalc.
Caleb, I'll try to replicate your issue. To make it easier for me, can you please email me a backup of your calculator (namely your programs and your DCS7, DCS7b, and FLDSV7 appvars)? It sounds to me like something with your folder structure that Sandpaper is not properly handling.
I'm using a 48K 84plus BE with OS 2.43, not a lot of programs/apps and no folders, and DCS 7.2β3α, and I can't replicate the problem.
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
Page 1 of 1
» 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