Connectivity Kit Editor enhancements

[Bob Frazee]

Quote:Tim Wessman wrote:
There are still a ton of people trying to use "programs" in the same way as they work on the 48 series. We really envisioned each program file to contain a collection of routines, data, and so on rather then a single function or two. I agree that some improvement around organization might be helpful, but I am not certain what form this should take at all...

My concern about the above statement, is that the connectivity kit editor opens the whole file for editing. If the file is large and contains numerous routines, data and so on..., then there is a chance to inadvertently change something some where in that file. Now I have the whole file to look through to find the error, rather than a small routine.

Well, back in the mid 80's, Microsoft had a DOS programming language called QuickBasic 4.5(qb45). QuickBasic is the one I mention here, because it is the one I have some experience with. With that editor, you could have one large file with a collection of routines in it (the way you envisioned programming on the Prime), and that editor allowed you to open the routines individually for editing. If something got inadvertently messed up, you knew where the problem was.

This editor would also allow you to have individual program, subroutine, and function files, similar to the way you typically program on the 48 series. Now this "ton of people trying to use "programs" in the same way as they work on the 48 series", would be able to do so. Typically you would have this collection of files in a folder or library (hint, hint, Prime memory organization).

So..., my suggestion would be to change the way the connectivity kit editor operates, change the way the memory manager operates(to handle folders or library's properly), and leave the programming language alone.

Thanks for reading.
rcf

[eried]

The calculator does not support big files, so I think the first step is to enhance that side of the device

[Kevin Ouellet]

Best connectivity kit enhancement possible: Add a mass storage device mode on the calculator so that no more connectivity kit software is needed. We just plug the calc in the computer, then it asks us if we want to go in mass storage device mode, then we can easily send files from Windows explorer. Once we are done, we press Esc on the calc then it checks the files to ensure they have the valid format.


If Casio started doing it in 2010 (with the fx-CG10/20) and is still doing it in 2013 (fx-CP400), then why HP and TI can't?

[debrouxl]

Quote:Best connectivity kit enhancement possible: Add a mass storage device mode on the calculator so that no more connectivity kit software is needed. We just plug the calc in the computer, then it asks us if we want to go in mass storage device mode, then we can easily send files from Windows explorer. Once we are done, we press Esc on the calc then it checks the files to ensure they have the valid format.

Agree as far as pure file transfer is concerned. MSD protocol (which is specifically designed for that purpose, after all) would be faster, and easier to use, than HID protocol through an extra program.

HP could have made the Prime to support regular file transfers through MSD protocol. However, they would probably have had to complement it by something else for the functionality they wanted to implement:

Quote:If Casio started doing it in 2010 (with the fx-CG10/20) and is still doing it in 2013 (fx-CP400), then why HP and TI can't?

Both the Nspire and the Prime/39gII support remote operations (e.g. for classrooms) which do not have (clear) file type. For instance, receiving screenshots, sending keypresses, setting calculator date and time, or (on the Prime) a two-way chat. Mapping those operations (or possibly more convincingly, other yet undiscovered / future operations, as far as the Prime is concerned) exclusively onto a file/sector-oriented protocol such as MSD may be - not impossible, but unwanted - for some reason.
I don't have insider information to support this guess.

I'm not aware the Prizm supports remote screenshots, remote keypress triggers or two-way chat. I can't find any source indicating that the new, overly expensive, crappy fx-CP400 can do any of those either.
Classpad Manager is some sort of teacher software, whose description paints it as a computer version of the Classpad (like the Nspire student software or Prime emulator), but does not mention non-file remote monitoring and control features. Relatedly, there's no cradle or wireless hat for the Prizm or fx-CP400, AFAICT.

[Cristian Arezzini]

(12-28-2013 08:41 AM)debrouxl Wrote:  HP could have made the Prime to support regular file transfers through MSD protocol. However, they would probably have had to complement it by something else for the functionality they wanted to implement:

I had two smartphones (a Nokia and a Samsung) that did exactly that. When connected to a computer, the phone would ask if you wanted to connect in "mass storage mode" or in "native mode" (or something like that). Worked like a charm to transfer photos and videos, and suited me fine since I don't use Windows and usually only needed to transfer files..

[eried]

But what is the content the user can "browse" as mass storage from the Prime? In a phone it makes sense, because multimedia files.

[debrouxl]

Quote:But what is the content the user can "browse" as mass storage from the Prime?

IMO, the same thing as on the Prizm (programs, to begin with), and possibly more, e.g. PNG screenshots triggered by a key combo

On its own, the Prime's USB controller can achieve the best transfer speed for a calculator on the marketplace (though much lower than contemporary cheap ARM-based dev boards), as shown by Prime reflashing being faster than Nspire OS upgrade, even though the amount of data for reflashing a Prime is up to about three times larger than the amount of data for upgrading a Nspire's OS.
More than hardware capabilities (the Nspire CX has a USB 2.0 controller as well, AFACWT), it's due to the Prime's firmware upgrade protocol being smarter than the Nspire's protocol, which is still locked onto 64-byte unit transfers.

[eried]

Yes, but which programs do you expose? create a folder per app? When the programs are parsed into the "compiled" version? Where the errors appear? What about the other features like time sync, messages, etc? What png images?

How about if the xbox controller expose a txt file with the button states instead of using the game controller hid. It is like forcing a concept just because it looks convenient, but it isn't.

[debrouxl]

Quote:Yes, but which programs do you expose?

Why not all of them ?

Quote:create a folder per app?

Possibly, but that should remain optional IMO. On the TI-68k series, I know that some people like having a hundred files in the main folder, and no other folders, while others try to put programs in separate folders and have as few programs as possible in the main folder.

Quote:When the programs are parsed into the "compiled" version?

Possibly.

Quote:Where the errors appear? What about the other features like time sync, messages, etc?

How about if the xbox controller expose a txt file with the button states instead of using the game controller hid. It is like forcing a concept just because it looks convenient, but it isn't.

We largely agree on that, I duly mentioned earlier that MSD probably had to be complemented by something
With special-purpose filesystems, at a higher level:
* receiving screenshots could be mapped to a read from one in a set of files with special names (or a write for defining the format, followed by a read);
* sending keypresses and setting date + time could be mapped to a write to files with special names;
* two-way chat could be implemented by reads and writes to one or two files with special names.
However, at a lower level (on the wire), for these operations, you and me agree that it's probably best to use something other than MSD.

Unless someone goes through the process and pain of making a kernel driver, or wants to depend on unmaintained third-party projects, Windows users would be left out of the kind of aforementioned special-purpose filesystems where data does not necessarily read back (ala Linux procfs/sysfs, or one of the many projects based upon Filesystem in USEr-space capabilities and enjoyed by many *nix users on a daily basis).

Quote:What png images?

I was thinking out aloud about an idea given to me by Levak's nCapture for making a disconnected Nspire produce screenshots from near-arbitrary locations in the OS, and the fact that the Prime already produces screenshots in PNG format.
Such "offline" screenshots could be transferred back onto the computer, even with HID.

[ajgryc]

Even if you don't expose all the functionality (like screen caps, etc), exposing the programs and vars through umass seems very natural and would be extremely helpful for us that don't have Windows. Maybe using the main category names in the Connectivity kit as directory names? I'd love to be able to simply access the programs on the Prime from my Mac. (Yes, yes, I know I can run VMWare+Windows, etc; I'd rather not spend even more money on buying a copy of Windows just to install into VMWare for my Prime)

I finally just updated my Prime even though it's been on my list since November. The inertia of digging an old Windows machine out of the boxes in the basement was lessened since I was already putting away Christmas decor :-)

[debrouxl]

(01-03-2014 03:57 AM)ajgryc Wrote:  I'd love to be able to simply access the programs on the Prime from my Mac.

For the purposes of normal communication, libhpcalcs ( https://github.com/debrouxl/hplp / http://www.hpmuseum.org/forum/thread-52.html / http://tiplanet.org/forum/viewtopic.php?t=13337 ) compiles and runs on Windows, Linux, MacOS X
It's written in C for maximum portability and interoperability. However, nobody made a GUI for it. Nowadays, Qt is the abstraction layer / GUI toolkit of choice.
It does not implement the firmware reflashing protocol, which is only partially understood ( http://tiplanet.org/hpwiki/index.php?tit...ing_mode_2 ).

Some MacOS X users are experiencing different behaviour depending on how the calculator is connected to the computer (e.g. directly or through a hub), but that's outside libhpcalcs' control. There has also been a recent report of overly large and corrupted screenshots... but on the computer side, the size of the packet is extracted from what the calculator sends, so it would seem like the calculator sends garbage ?
At least, the same packet parsing code works when I'm testing against the Windows Prime emulator, through to the CK <-> Emulator communication channel, under Wine. This is all I can do by myself because I don't have a real Prime.

Further discussion about libhpcalcs itself, if any, belongs to the other topic, however