Post by gsteemso on Mar 19, 2016 4:38:47 GMT
That could in theory be a fine idea as far as a Comet goes. You might even be able to do it with just a firmware update, depending how much spare room is available in its controller's Flash ROM ("very little," unfortunately). It is however more or less completely inconsistent with the entire purpose of a Flyer, which is to enable "cloud" based disk storage for Commodores. It didn't require anything extra except a bit of programming time to allow arbitrary HTTP requests and such to be sent as well, again within the notional context of a disk drive with files on it, but what you are talking about would require a total hardware redesign to basically duplicate the guts of a Comet, AND a completely different interface paradigm.
If you want a Comet just buy one, but even there, the fundamental concept is a simplified network interface made to look and act like a serial modem.
A Comet's original purpose was to allow Telnet-enabled BBSes and the like to be accessed using the same terminal emulation software as a Commodore would have run for a dialup BBS or whatever in the 1980s. All they had to do to extend that into a cloud-storage facility à la Flyer was to do up a Telnet interface for a disk-image server. (You can actually access your CommodoreServer account directly from any simple Telnet program, provided you haven't forgotten your password. In keeping with the finest traditions of the Internet, you can in principle do everything it allows a user to do directly from a mechanical teletype, especially if a paper-tape punch is fitted to accept any downloaded Commodore files.)
Note that neither of these devices was in any way designed to provide totally arbitrary, i.e. "raw" or bare-wire, access to a network interface. Providing that function would be, while not diametrically opposed to their intended purposes, more or less unrelated to them. The Flyer pretends very effectively to be a generic disk device, and the Comet pretends very effectively to be a serial modem (and, if you run the supplied "V1541" support software to partially reimplement part of the host machine's ROM so that it will accept an RS-232 device that is pretending to be a disk drive, it also works quite well as one of those, albeit with certain subtle, inescapable limitations imposed by the nature of the changes).
To provide arbitrary access to either device's network chip is certainly possible at a hardware level, but would require an extensive, perhaps even total rewrite of their controllers' firmware. The Flyer would, if I recall my long-ago conversations with its developer correctly, probably need to sacrifice some existing functionality to clear out some firmware space for this feature. The Comet is still being actively developed with new hardware revisions, and so could probably accommodate the feature in future releases without really large amounts of trouble, but anyone who already owns one would likely be out of luck; I haven't examined the design closely, but as far as I know it incorporates an off-the-shelf serial-to-Telnet bridge chip. Even if the actual bare network interface inside that chip can somehow be accessed by the Comet's microcontroller, the same severe limitations on available firmware space would apply.
Now, all of that being true, I must admit that the idea of connecting to a Comet via SL/IP (or PPP, if applicable) is an interesting bit of out of the box thinking and might even work. I'll still have to check with Greg "Goog" Alekel at the PSCUG meeting Sunday to see whether the Comet is even physically capable, in theory, of transferring those IP packets across to the attached network (to say nothing of the firmware space requirements, which would likely remain prohibitive), but overall it's a very intriguing possibility. I don't know whether it is even possible to do SLIP with IPv6, though, which if you'll recall is important to Contiki.
Thinking further on the topic, I believe the SLIP or PPP idea may in theory also be applicable to a Flyer (yes, a Flyer connects to its host Commodore over a multiple-device disk drive bus, but those protocols SHOULD work equally well regardless of the underlying connection type). Alas, I'm 99% certain the firmware requirements would remain prohibitive in that case, possibly even more so than for enabling extremely low-level control of the network interface unit. I'll have to get in touch with Brandon Bogle and ask him his opinion.
If you want a Comet just buy one, but even there, the fundamental concept is a simplified network interface made to look and act like a serial modem.
A Comet's original purpose was to allow Telnet-enabled BBSes and the like to be accessed using the same terminal emulation software as a Commodore would have run for a dialup BBS or whatever in the 1980s. All they had to do to extend that into a cloud-storage facility à la Flyer was to do up a Telnet interface for a disk-image server. (You can actually access your CommodoreServer account directly from any simple Telnet program, provided you haven't forgotten your password. In keeping with the finest traditions of the Internet, you can in principle do everything it allows a user to do directly from a mechanical teletype, especially if a paper-tape punch is fitted to accept any downloaded Commodore files.)
Note that neither of these devices was in any way designed to provide totally arbitrary, i.e. "raw" or bare-wire, access to a network interface. Providing that function would be, while not diametrically opposed to their intended purposes, more or less unrelated to them. The Flyer pretends very effectively to be a generic disk device, and the Comet pretends very effectively to be a serial modem (and, if you run the supplied "V1541" support software to partially reimplement part of the host machine's ROM so that it will accept an RS-232 device that is pretending to be a disk drive, it also works quite well as one of those, albeit with certain subtle, inescapable limitations imposed by the nature of the changes).
To provide arbitrary access to either device's network chip is certainly possible at a hardware level, but would require an extensive, perhaps even total rewrite of their controllers' firmware. The Flyer would, if I recall my long-ago conversations with its developer correctly, probably need to sacrifice some existing functionality to clear out some firmware space for this feature. The Comet is still being actively developed with new hardware revisions, and so could probably accommodate the feature in future releases without really large amounts of trouble, but anyone who already owns one would likely be out of luck; I haven't examined the design closely, but as far as I know it incorporates an off-the-shelf serial-to-Telnet bridge chip. Even if the actual bare network interface inside that chip can somehow be accessed by the Comet's microcontroller, the same severe limitations on available firmware space would apply.
Now, all of that being true, I must admit that the idea of connecting to a Comet via SL/IP (or PPP, if applicable) is an interesting bit of out of the box thinking and might even work. I'll still have to check with Greg "Goog" Alekel at the PSCUG meeting Sunday to see whether the Comet is even physically capable, in theory, of transferring those IP packets across to the attached network (to say nothing of the firmware space requirements, which would likely remain prohibitive), but overall it's a very intriguing possibility. I don't know whether it is even possible to do SLIP with IPv6, though, which if you'll recall is important to Contiki.
Thinking further on the topic, I believe the SLIP or PPP idea may in theory also be applicable to a Flyer (yes, a Flyer connects to its host Commodore over a multiple-device disk drive bus, but those protocols SHOULD work equally well regardless of the underlying connection type). Alas, I'm 99% certain the firmware requirements would remain prohibitive in that case, possibly even more so than for enabling extremely low-level control of the network interface unit. I'll have to get in touch with Brandon Bogle and ask him his opinion.