|
Post by robertb on Sept 10, 2008 21:17:44 GMT -5
...Estel and company will be pleased to know that this list can be accessed and adjusted by the admin of the forum. Too much trouble, Jeff. :-) Don't worry about it. D. Estel and I have a good laugh whenever I bring up the subject. Truly, Robert Bernardo Fresno Commodore User Group videocam.net.au/fcugThe Other Group of Amigoids www.calweb.com/~rabel1/
|
|
gsteemso
Newbie
48 bits or bust!
Posts: 19
|
Post by gsteemso on Sept 13, 2008 0:28:57 GMT -5
Hi again all! I haven’t been posting about this for the last couple of days because I was trying to collaborate with Jim over IM, but since we’re never online at the same time that didn’t work out. So, back to thrashing it out here: BBSs like to have lots of channels open. Ah, so I will need lots of channels. OK. IEC allows up to 32 secondary channels if you avoid the Commodore Secondary Open/Close commands -- do any drives out there make use of that, or am I dreaming the unfeasible dream again? Why is that, exactly? I’m not bothered about losing I/O lines, as the microcontroller I have a sample of on order is replete with 70 of the things; and from the Wikipedia comparison I saw, CF came off best overall. It didn’t mention how expensive they are though, probably because it changes so fast. Are SD/MMC cards cheaper? I intend to take the more mature codebase (sd2iec) and reimplement it in PIC assembly by “hand-compiling”. If I see any improvements that can be made while I’m in there, I will of course send them back to you. I expect I won’t need _all_ of your code as my project won’t do the same sorts of things. Urgh. Messy. I’m glad you guys have already gone through all that for the rest of us to benefit from. Not so much those as, well, let me give everyone an example. Note I am not trying to talk down to the people who already know this stuff, but rather to inform those who do not as I go along. Let’s say we have configured the EtherSQUID to pretend it is drive 8. All commands to unit #8 will be interpreted pretty much as they would be by the existing projects whose code I will be reusing. As far as anyone’s program will be able to tell, device 8 is a normal drive. The network interface, on the other hand, would live at some other address — I’ll pick #24 at random for this example; I don’t think anyone is using that already. Any command CM$ we send would look like this: OPEN {file},24,0,CM$ which, for those who have not mucked with this stuff before, would on the IEC level be MLA24 CSO0 {text of the command} UNL Not everyone knows what those abbreviations mean, so I'll go over them. MLAi is “My Listen Address i” and commands unit i to listen to the bus. i has a range of 0-30. UNL is “Unlisten” and tells all units to stop listening. CSOx is a Commodore-specific extension to the IEEE-488 protocol all this was derived from, and stands for “Commodore Secondary Open x”. x can be from 0-15. It means the same as MSAj where j is x, MSAj being “My Secondary Address j”, except the unit being commanded is to open a file according to the data string which follows. Note that j can be 0-31 but x is still only 0-15. We would be able to attach a Commodore file number to a given channel (1 to 31, as 0 is the command channel) with OPEN {file},24,{channel} which would result in no activity on IEC until something was read from or written to {file}. At that time, the bus would be commanded as follows: MTA24 MSA{channel} (listen to the data for a while) UNT
for a GET# operation (MTAi is “My Talk Address i”, and works like MLAi in reverse; UNT is, you guessed it, “Untalk”), and MLA24 MSA{channel} {data} UNL for a PRINT# operation. For channels up to 15, we can (as in the first example above) combine the file assignment with a PRINT# operation, which is done via an OPEN with a string argument and produces another CSO command on the bus. There would be a simple syntax for the command channel, one which I hope would be easier to remember than what Jim proposed above. You'd set the drive part (unit #8) to access a disk image or PRG with “FILE-GET:{path to new image or program file};{usual URL syntax}” on the unit #8 command channel. Naturally, you could abbreviate it “F-G”. The reverse operation would be “F-P” for “FILE-PUT”. Any other network operation would be addressed to unit #24 in this example. Basically you'd tell the thing what channel and protocol to use and what addresses/ports to send via, and then just PRINT# or GET#/INPUT# from the appropriate channel. That much is like what Jim proposed, but I'd simplify the command structure: open{file},24,{channel},"{protocol} ,{address to send from if we support multinode access, else leave blank} :{port to send from} ,{address or domain name} :{port to send to if other than default}" I think that’s a lot easier than trying to remember cryptic abbreviations so it can all be shoehorned into the DOS syntax. This way you’d only have to remember the customary abbreviations for the protocols. (They shouldn’t be further abbreviated if we are to allow for future expansion.) This is a very good point. If I'm supporting HTTP I will need to support automatic unzip in any case, as the protocol allows ZIP compression. I'm thinking I will limit the on-board support to HTTP and its lower-level kin; that will save a lot of trouble. As you suggested, I will figure some way to offload computation for other high-level protocols to a “helper” machine somewhere on the network. I like this idea. I don’t… actually I do have a server, don’t I? I’m on broadband and my computer is only off when it crashes or I'm working on its innards. This is a hot one. I will have to provide something people can install locally, though; a lot of machines on people's private networks are not visible from here. Or… would I? What we’re discussing is basically a proxy server. That doesn’t sound hard at all. I'll have to swallow my dismay and work partly in C, it’s true. As you say, collaborators are valuable, and if I go off your codebase I’ll want to be able to pick your brain occasionally. (Heh… The brain of Brain… Gee, I’m sure you’ve never heard THAT one before…) So, people? I know this thread has readers. Anyone up to helping out? All I really need is an involved mind I can bounce ideas off of; it’s not an onerous duty. You’d just have to stay on top of my progress, which would likely be easy on account of me being a rather slow worker. G.
|
|
|
Post by Jim Brain on Sept 13, 2008 1:35:38 GMT -5
Hi again all! I haven’t been posting about this for the last couple of days because I was trying to collaborate with Jim over IM, but since we’re never online at the same time that didn’t work out. So, back to thrashing it out here: Give it a few more days and you'll see me online. I'm on the road at this exact moment, so we drive to new locations during the evening, and I do the driving, meaning I can't be online. As well, while we do have Internet while on the road (cellular air card), I'm not monitoring the chat, and the connections goes off at times (We travel through some remote spots, this trip was in South Dakota, and there are stretches of nothing for long periods in SD). BBS systems would respect KERNAL rules, which limit IEC channels to 16 (0-15) SD cards are becoming a bit cheaper, and it's easier to lay out the board. When i first designed uIEC, CF was easier to learn (as it is has True IDE mode), but Unseen has conquered the SD init stuff, in my opinion. Actually, it would be 0x38 0x60 "text..." 0x3f. But, yes, you're proposal works fine if you move off the disk device number to your own number. It is still easy to support that in sd2iec, though, as the command received is sent to parse_command(), and then you can take over. You would need to make parse_command device specific (have a switch/case in parse_command that checks the device number currently active, or some more elegant way with void* functions) I think we're saying the same thing. You're proposing F-G, while I was proposing EM (because CMD drives plan to use the EM for mounting an image, not because I liked it). In your case, you'd do: open 15,8,15,"F-G4:http://something/to/the/image.d64" which would mount that image on partion 4 of the drive #8. Not that it matters at this point, but I think GET and PUT are confusing in this context. You're not "getting a file", you're just opening it. There is no need for F-P, as opening a file is just assigning a reference. You would GET and PUT by the open commands against the filesystem (whether they are Write or Read or Append calls). I didn't consider using a different device number for the TCP/IP stuff. It looks good so far. Note though, that many ML developers will hate this syntax, since it requires they convert their binary data to ASCII/PETSCII for transmission. So, you might want an alternate syntax that allows them to send binary IP address data and ports and such. When you get around to allowing the C64 to command a remote drive over the Internet, a local copy is needed, but until then, it's just a outbound proxy, as you note. Still, just bundle the copy you are running on your server. It's the same codebase. My only reason for preferring the command channel syntax over the file-based one you propose is in the target audience: "How do you mount an Ethernet image" "Well, you tell the device #10 command channel to mount the image on a specific partition number" "OK, and how do I open a HTTP port" "Well, you open a file called "blah" on device #24. "Hold it, I thought the Ethernet device is device #10?" "Well, it's both #10 and #24" "Huh?" It's not horrible, but I think a small tweak to your syntax would make it work both ways: open <handle>,<device>,<secondary>,"#T<TCP/IP protocol information follows as per your original idea>" This simply extends the built in "buffer" handling to handle TCP/IP connections. Jim
|
|
|
Post by David Murray on Sept 13, 2008 10:19:57 GMT -5
Actually, I have found SD cards to be much cheaper than SD cards. In fact, I think they run about half the cost. So that is a significant amount. However, for use with a Commodore, you probably don't need more than about 1 GB anyway, in which case the cost is irrelevant.
|
|
gsteemso
Newbie
48 bits or bust!
Posts: 19
|
Post by gsteemso on Sept 13, 2008 16:46:54 GMT -5
Actually, I have found SD cards to be much cheaper than SD cards. How's that again? I think you meant "CF" for one of those.
|
|
gsteemso
Newbie
48 bits or bust!
Posts: 19
|
Post by gsteemso on Sept 13, 2008 17:35:32 GMT -5
Give it a few more days and you'll see me online. I'm on the road at this exact moment, so we drive to new locations during the evening, and I do the driving, meaning I can't be online. As well, while we do have Internet while on the road (cellular air card), I'm not monitoring the chat, and the connections goes off at times (We travel through some remote spots, this trip was in South Dakota, and there are stretches of nothing for long periods in SD). Sounds like a fun trip to make. I look forward to hearing more directly from you when you get stable connect time again. Well, if you want to be all obscure and speak in hex instead of symbols, yes. It’s the same thing. (Though $38 corresponds to MLA8… MLA24 is $48. The whole “five bit address field” thing makes using hex to discuss this stuff questionable at best, IMO.) Huh? those aren't the same thing at all. The primary functionality of FILE-GET is to retrieve and install a file from the network. The fact that it then descends into the file, provided it was a recognizeable disk image, is just a nice convenience designed to prevent the user having to enter multiple commands. You want a normal filesystem call to result in stuff being spammed to random addresses all over the Internet? I’m sorry, but I just can’t see that working out. Oh, that’s a sharp one. I hadn’t even thought of that. I like it. I will have to think on a good syntax to use though. Probably something with a flag character at the beginning to indicate the data is in binary instead of PETSCII. The protocol abbreviation would still need to be in PETSCII though; otherwise there would be no way to coordinate the assignment of protocol identifier tokens to third-party extensions in the proxy server. Well, more or less. If people want to access an image on, for example, their private AppleTalk network, they will need to install the proxy locally. It is all the same codebase though, I agree. All I need to do is make it clear that the Ethernet unit lives on whatever address one sets at the switch on the back, and also installs a virtual disk drive on unit 8-11 (also switchable on the back panel). I was of two minds whether it should be the network unit or the drive unit that can be commanded to go retrieve or save a remote file, but the command naturally fits into the DOS command set better than it does the networking one. Still, either way, some sort of URL or file path needs to be blindly handed from one unit to the other. This is the whole reason I initially identified THREE categories of commands — that’s what there ARE. Maybe it would be best if you could send FILE-PUT and FILE-GET to either unit? That’d work, I guess, but there are an unlimited number of protocols to support, even if most of them would actually be implemented in the proxy server. Still, I guess you could patch the same syntax in with a different abbreviation: OPEN {file},{unit},15,"#{buffer number}↑http,:80,www.example.com:80" I chose the upwards arrow because nothing I know of already uses it, and it kinda points “up” to the network. G.
|
|
|
Post by David Murray on Sept 13, 2008 17:55:00 GMT -5
How's that again? I think you meant "CF" for one of those. hahah.. Yes, I meant to say that SD is cheaper than CF. Sorry.
|
|
|
Post by Jim Brain on Sept 13, 2008 17:56:44 GMT -5
Sounds like a fun trip to make. I look forward to hearing more directly from you when you get stable connect time again. We're back in IA now (Des Moines, about 2 hourls from home), so the trip is nearly over. Would have been home last night, but needed to stop in Northern IA to pick up a bunch of CBM equipment. Snagged some CND HW, though, so it was worth it. I meant to point out the SA00 was really SA96 (if my hex to dec is working today). Yes, 0x48 is correct. My only intent was to point out that MLA24 SA00 would be 0x48 0x60 on the wire. What is it installing it to? The device? the CBM machine? What is the "file"? Just a program? I am confused. Not sure I understand the issue. Currently, my VIP codebase (which does the same thing you are proposing, but it uses a serial link from the uIEC to the PC, and the PC handles the TCP/IP traffic, and it works fine there. Ah, true. Local network files would require local install. That was what I intended. With the code, you could support both options.... See which people use the most, and plan accordingly. Jim
|
|
gsteemso
Newbie
48 bits or bust!
Posts: 19
|
Post by gsteemso on Sept 13, 2008 19:12:06 GMT -5
What is it installing it to? The device? the CBM machine? What is the “file”? Just a program? I am confused. I’m sorry. I meant to do a better job of explaining myself than that. It works like this: You issue FILE-GET to one of the command channels on the EtherSQUID. A properly specified FILE-GET command includes a path to somewhere on the Flash media along with a URL to the target file. The EtherSQUID retrieves the file from the network and saves it at the given location on the Flash media. If the file is a PRG or what have you, nothing further happens. If the file is recognized as a disk image, it is descended into like a directory, if I understand you correctly somewhat as though the EM command had been issued. This is merely a convenience and can be overridden. I doubt it does EXACTLY the same thing or we would not be talking at such cross-purposes here. *grin* My confusion stems from an apparent blurring on your part between disk image access and network access. The two are not the same and cannot be treated the same if you want it to make any kind of sense. Later on, I hope to be able to mount remote servers and have them show up as a local drive (or maybe a partition), but I will have to hold off on that until I get the basic functionality working. Is that what you were talking about? G.
|
|
|
Post by Jim Brain on Sept 13, 2008 23:11:53 GMT -5
I’m sorry. I meant to do a better job of explaining myself than that. It works like this: You issue FILE-GET to one of the command channels on the EtherSQUID. A properly specified FILE-GET command includes a path to somewhere on the Flash media along with a URL to the target file. The EtherSQUID retrieves the file from the network and saves it at the given location on the Flash media. If the file is a PRG or what have you, nothing further happens. If the file is recognized as a disk image, it is descended into like a directory, if I understand you correctly somewhat as though the EM command had been issued. This is merely a convenience and can be overridden. I understand now, but I think what you want is already designed. If you "mount" an http page or ftp directory using something like: <DOS CMD><PARTITION NUMBER>:<URL> Then, all existing apps can use the partition to copy files from the remote server to a local drive. They can even copy the file from the remote server to another drive (your option only allows copying files from the remote server to the drive represented by your device). From the perspective of remote disks/images/directories, it does, but it requires the PC server. So, it differs from your project in that I never added any commands for raw Internet access (easy to add) and it does not use Ethernet, but Serial/USB (harder to add). Jim
|
|
|
Post by vk4akp on Oct 18, 2008 11:37:54 GMT -5
Hi Guys! I think adding Ethernet / LAN support to the uIEC project is a fantastic idea!.
You will certainly have a customer here for such a device.
uIEC with SD card, IDE & now Lan (ethernet) support would indeed be a be all end all device for the CBM 8biters!.
I also have a IEEE-488 drive here still (CBM-2031). So The IEEE-488 connector would also be cool. Although CBM Pet gear is getting rare it is still around and it would be very cool to see a device still support it!
I would also like to see an E-Sata connector become available on uIEC projects in the future. But I do understand that this is a very big ask. .-.-.
|
|
gsteemso
Newbie
48 bits or bust!
Posts: 19
|
Post by gsteemso on Feb 4, 2009 22:32:54 GMT -5
I've had this project, the EtherSQUID, in a state of suspended animation for the last few months, but I /have/ been working at it in fits and starts. My apologies to all those who hoped for a speedier implementation.
The thing I'm having the most trouble with at the moment is nailing down the logical model for interacting with the network side of the beast. Stuff arrives off the network in serial fashion, but the logical model of socket-based communication is inherently parallel, so that's the model I'd have to present to the user. I think I'd need three categories of command for the network transmissions and one category for mounting remote disks and files:
- simple high level stuff like HTTP GET. Parameters are the protocol name, the operation desired, the destination buffer file in local storage and the source URL; reverse the adjectives on those last two for a PUT operation but the command syntax would be the same. All the details would be handled internally. These would be once-off commands and normal disk operations on the buffer file would be used for setting and reading data.
- mid-level stuff like TCP, UDP and IP. Parameters are the protocol name, whether you're reading or writing, the desired socket (or socket pair for outbound transmissions) and the buffer file(s) in local storage. These would necessarily be applied sequentially, as using one would imply you are implementing something on the Commodore side instead of in the proxy server. You'd write to the buffer file and call "send", which would empty the buffer. Receiving would be handled by normal filesystem commands on the buffer file, once you'd established the socket for listening. I think I might need a command or two for socket management too... for example, allowing two "inbound" buffer files per socket would allow the Commie to read from one while the network dumps data into the other.
- Really low-level Ethernet commands, which would basically dump the output buffer into a raw Ethernet packet, and vice versa. This would allow things like AppleTalk and Windows networking to be implemented on the Commodore side. If I were a cheapskate this is all I would have to implement, but I don't think I'd have too many customers that way!
- Then there's the modified "mount partition" command. Saying "mount this network resource as a disk on partition X" is simple enough. I think access permissions can be handled by returning a DOS error if someone tries to read or write something they're not allowed to. In fact, since Internet protocols all return an error code (even if it's just "200 OK") it might make sense to allocate a DOS error number to reporting the status of the last operation on a network partition.
Does anyone have any suggestions on this? I'm not entirely compos mentis and haven't been for a number of years now, so fitting even a big slice of this project into my head at once is not easy. I welcome all feedback.
|
|
gsteemso
Newbie
48 bits or bust!
Posts: 19
|
Post by gsteemso on Jan 18, 2011 17:40:35 GMT -5
As I suspected might happen, this project has now been superseded. Members of the Vancouver, Washington-based “Commodore Computer Club” (apparently no relation to the UK group of the same name) have produced a device called a Pilot that interfaces by IEC (with optional fastloaders like JiffyDOS), has several floppies’ worth of local storage, and is in current production. Sorry to have not finished this project myself, but at least someone else did. Go ask them for further information.
|
|