|
Contiki
Mar 23, 2016 19:11:09 GMT
via mobile
Post by gsteemso on Mar 23, 2016 19:11:09 GMT
The main focus of their recent efforts has been the disk-image hosting on commodoreserver.com, and I'm pretty sure I saw a link on there to buy a Comet last time I looked.
|
|
|
Post by gsteemso on Mar 23, 2016 4:24:23 GMT
I mentioned the SL/IP or PPP over Comet idea to Greg and to Steve "AgentFriday" Davison at the PSCUG meeting this past Sunday, and they were both quite interested by the possibility. Naturally, given that both protocols have fallen mostly out of use in recent years, neither friend could guess meaningfully at whether it might work, but they did mention looking into it in future. I will have to see if I can persuade one or both of them to comment in this thread.
|
|
|
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.
|
|
|
Contiki
Mar 14, 2016 14:59:00 GMT
via mobile
Post by gsteemso on Mar 14, 2016 14:59:00 GMT
…Uh, what? What would any of that achieve? The Flyer already communicates quickly and efficiently with the Commodore over the Commodore Serial Bus. That is not the problem. The problem is that the Flyer is designed to simplify network communications by presenting a useful subset of them (HTTP and TCP over IPv4) in the form of a drive-type device. Unfortunately, Contiki requires far lower-level access, with the possibility of constructing ANY type of network packet from scratch. This uses a lot more resources on the main Commodore, but allows Contiki to natively support things like IPv6 that became the norm since the Flyer was designed.
|
|
|
Post by gsteemso on Mar 14, 2016 13:10:37 GMT
As far as I know, the Shift Lock key does not have a distinct scan code within the Commodore (though VICE as an emulator may treat it differently, I honestly don't know). As far as the original hardware is concerned, the Shift Lock key duplicates one of the ordinary Shift keys (I think it was the left one on a C64) and only differs in that it physically locks down in the "on" position.
|
|
|
Contiki
Mar 11, 2016 4:41:29 GMT
via mobile
Post by gsteemso on Mar 11, 2016 4:41:29 GMT
Oops. Knew I forgot to tell you folks about something! I was in touch, several months ago, with the fellow who has done most of the recent work on the C128 port of Contiki… Essentially, Contiki is carefully arranged at every level based on the assumption that it can direct the network interface at a low level in real time. Thus, it has evolved over the years to adopt very modern internet features such as IPv6 without much fuss, because it constructs all network packets from scratch and can do so without externally imposed preconceptions.
This state of affairs is, as I understand matters, fundamentally incompatible with indirect network access via a device such as a Flyer (or, I believe, a Comet), which does all network operations internally in a “black box” kind of way, accessed at one remove by commands over some other kind of interface (IEEE-488 or Commodore Serial Bus for the Flyer, user-port RS-232 for most Comets). Such devices can only update their handling of network protocols via a firmware upgrade, which is not especially practical for several very good reasons. Unless a future Flyer or Comet firmware upgrade adds a feature to allow the blind transmission of arbitrarily constructed network packets, Contiki will never be able to make use of either one. Since such a feature would to some extent run counter to those devices’ design goals, I do not foresee it becoming a priority for any of their various developers any time soon.
|
|
|
Post by gsteemso on Feb 20, 2016 1:12:17 GMT
I have just run across this newly developed OS (C64 only, it appears—drat!), which attempts to adapt some UI concepts of iOS to our beloved Commodores. Not sure how useful it is absent the hardware mod to add a touch screen, but this illustrates how much room there still is to experiment in this realm!
|
|
|
Post by gsteemso on Feb 20, 2016 0:52:27 GMT
Apologies, but I’m finding your phrasing to be a bit harder to decode than usual. Are you asking what specific chip the 64DTV uses as a CPU?
|
|
|
Post by gsteemso on Feb 20, 2016 0:42:59 GMT
While I don’t know enough about 1570 hardware to take a guess at why you are not getting any DC voltage out of it, the presence of AC ripple is worrying; if it is too pronounced, the logic chips can be harmed. At a minimum, it will not hurt and may help a great deal to replace any elderly aluminum electrolytic capacitors in the unit, unless your checking of them extended as far as capacitance measurements. As is well known, the things tend to lose capacity pretty seriously after about 15 years, which happened 15 years ago!
|
|
|
Post by gsteemso on Jan 19, 2016 5:55:58 GMT
I have no idea of hardware prices for manufacturers back in the day, but I can believe the 488-cable would be at least 3x more expensive than CBM-serial cable (or more expensive). I vaguely recall a figure of $40 per cable being quoted for a certain period in the late 1970s (maybe 1979ish?), though I do not recall what source I got that from. That seems deal-breakingly expensive to us even almost 40 years later, at a time when most currencies have lost around 3/4 of their value from those days. Think about that for a minute in terms of what that $40 would have been worth in 1979. Would YOU, today, even laughingly entertain the idea of going to Amazon or NewEgg and paying over $150 for a simple, 5' long USB or eSATA cable?
|
|