A85: Re: "Assemble This!"
[Prev][Next][Index][Thread]
A85: Re: "Assemble This!"
Man... you sound a lot like me -- I'm full of a ton of great ideas, but I
never have the time to actually sit down and code them...
>Why not make "Assemble This!" open source software? There's no way
>you're going to profit from it either way, and if you generate enough
>publicity on the list and on the web, the general public will know when
>someone pirates code. In fact, the GNU copyleft might be a good
>starting point for releasing shells.
>
>On a more technical note... any chance you'd make it EASY to switch
>shells? I'm looking at something like: AT! programs have one header,
>AT! shells have another. When a shell is running, the kernel responds
>to a certain key combination, which loads a list of all shells on the
>calculator. The user selects one, and the kernel sets that shell as the
>default. Control is then dropped back to the (new) shell. While a
>program with a non-shell header (or some other identifying
>characteristic) is running, the kernel is not hooking any keypresses.
>Except for perhaps an optional teacher-key. But the teacher-key might
>be best left to the shell to support.
>
>Idea for shell--this may not be feasible for most users, but some might
>appreciate it. An assembly shell is written for the client calculator.
>A host calculator has a different shell on it--one which only responds
>to EXIT and the link port. Basically it's a dumb variable server. The
>client shell uses the host shell as a simulated hard disk for storing
>variables. The host could display the name of a variable being sent for
>its output. Or perhaps it could display realtime information about the
>shell/program being executed on the client calculator. The
>possibilities are nearly infinite. The protocol could be written in
>such a way that unless a variable is asked for, anything coming across
>the link port will be ignored. So one host could server perhaps three
>or four (technically the only limit would be the power requirements for
>the link cable) clients, as long as the "network" didn't get too busy.
>This type of network would require zero coding, and provide very minimal
>services.
>
>Just some stuff to chew on. =)
>
>--Matt Cooper