gsteemso
Newbie
48 bits or bust!
Posts: 19
|
Post by gsteemso on Sept 7, 2008 18:21:12 GMT -5
I've recently been challenged to suit action to words and develop a means of accessing Ethernet from any Commodore with an IEC port. Since IEC is just a serialized version of IEEE-488, a simple variant designed for that as well would provide high-speed network service to every model of Commodore 8-bitter except the C65. Given how few of those exist I can live with the omission.
The concept as it stands now is as follows: We have a small inexpensive box containing a microcontroller with an Ethernet port, and furnished with jacks to connect to 10baseT Ethernet and either IEC or IEEE-488, depending on which of the two models we're looking at. The firmware in the box would accept three categories of commands, maybe using a different bus address for at least one of them to keep things simple: (1) commands to load a disk image via HTTP into the device's RAM, (2) commands identical to those of standard disk drives to access said image, and (3) commands to allow transmission and reception of raw packets lower down in the protocol stack. These last would be necessary for any program that wanted to use a protocol other than HTTP.
This concept would permit at least basic usage on any Commodore straight out of the box, by the thing pretending it is a disk drive, while still allowing specially-written software access to the full power of networking. If the low-level interface allows access to low-level Ethernet packets, it would even be possible to implement support in software for networking via other protocol families, such as Windows, Novell Netware, or AppleTalk.
The number of enhancements I want to apply once the thing works at all is enormous. Just by way of example, here is a short list of some of them:
- Allow access to the disk image (command set #1) by protocols other than HTTP, such as any or all of HTTPS, FTP, SFTP, TFTP, BOOTP, etc.
- Allow saving the disk image in RAM to whatever location in the network -- basically, the "download image" operation in reverse.
- Allow multiple drives to be emulated, depending on the content of the image file. (1541, 1571, 1581, hard drive, etc.)
- Allow attaching a remote server as a Hard Drive image. Would probably make it look like a CMD device to local software, for compatibility. This would be enormously valuable with GEOS integration.
- Full and comprehensive GEOS integration, including network printers (assuming someone will supply the appropriate driver for your printer, though generic PostScript support ought to be straightforward enough).
- Include BOTH types of Commodore port -- IEC and IEEE-488 -- and implement a software bridge between the two physical busses. This would allow a computer on either bus to access drives on the other bus as though the interface were correct for it. Bus addresses would be shared between the two busses -- doing otherwise requires an address translation table, which is a management headache and a lot more trouble than just changing the device's number at the switch on the back.
- Include an option for power over Ethernet. Or, could possibly power it over the IEC/IEEE-488 bus(ses) -- modern microcontrollers that include Ethernet support use ridiculously little power.
Does anyone want to help with this? I can do all of it myself if I have to, but my last project has been stalled since last century because I have no way to burn my code to the microcontroller. It's taken me so long that other people are starting to beat me to it. I'd rather that not happen with this project.
Thoughts please?
G.
|
|
|
Post by David Murray on Sept 7, 2008 21:52:33 GMT -5
This sounds like a pretty ambitious project. But you seem very concerned with the ability to use it on all commodore 8-bits. But seriously, how many PET users out there do you think will be using this thing?
One thing that concerns me about the IEC interface is the fact of how slow it is. I realize it can be sped up some with new I/O routines, but is it really the best option? How about a user-port version? You have a lot more speed available there and most of your 8-bits have a user-port except for the C16. I realize you would loose the advantage of being able to load the client software directly from the ethernet device, but it may be a small price to pay.
Another interesting possibility I've wondered about is the cassette port. It has more or less direct lines to the CPU and could be bit-banged very quickly. It might even be possible to setup some kind of tape emulation routine that would allow you to load the client software from tape. Or rather, load some extremely small program that would load the rest of it in at high-speed. I experimented with this a few years back by trying to put a serial flashram chip on the cassette port. I just ran into difficulties with the fact that I needed 3 lines and one of those goes through a transistor because it is trying to deliver 9 VDC to the cassette motor. So there would need to be something there to convert that back to TTL signal.
|
|
gsteemso
Newbie
48 bits or bust!
Posts: 19
|
Post by gsteemso on Sept 7, 2008 22:33:08 GMT -5
This sounds like a pretty ambitious project. Well, yes and no. The basic functionality is pretty simple; the biggest hurdle I foresee is acquiring a hardware device programmer. Adding all the other stuff I listed could take years though. No worries, Ethernet-capable µCUs are usually self-flashable, too, so I can always make updates available online. Heck, if I had a stable URL I could make them automatic! Well, myself, for a start. :¬) If anyone else wants to as well that can only be a bonus. It's not like it would cost extra, except for the hideously expensive cable -- the µCUs I've been looking at all have ludicrously large numbers of I/O pins. (Bear in mind my concept of a "normal" number of pins is based on the old PIC16F84, which has 13, several of which have other functions.) It is the most widespread option. Many of the platforms that support IEC also support JiffyDOS, and even if that turns out to be impractical, the most important IEC target market is 128-mode C128s, which have fast serial anyway. There are a number of reasons I'm not pursuing a user-port solution. (1) It's already being done by other people. (2) There are at least five different ports that different models would need to be produced for. See this thread on the "Commodore 128 Alive!" forums about expansion options for different Commodores. Too much trouble, which means it wouldn't get done. (3) It would negate the benefit of not needing any extra software to make it go. There already exists a device (called the C2N232, q.v.) that puts a high-speed serial connection on the tape connector. It loads a bootstrap routine from the connected system by pretending to be a tape drive, then communicates at very high speed thereafter. The latest model also includes an IEC connector, though I do not believe he has written any firmware that uses it yet. You'd have to ask the maker (one Nicolas Welte) for any further information.
|
|
|
Post by David Murray on Sept 8, 2008 8:05:33 GMT -5
There already exists a device (called the C2N232, q.v.) that puts a high-speed serial connection on the tape connector. It loads a bootstrap routine from the connected system by pretending to be a tape drive, then communicates at very high speed thereafter. I googled that device, but wasn't able to find much information on it. The website I saw was dated back around 2002 and I couldn't see where you could actually buy the device, or any mention of one with an IEC connector. Do you have a link that is up to date for the project?
|
|
gsteemso
Newbie
48 bits or bust!
Posts: 19
|
Post by gsteemso on Sept 8, 2008 18:58:09 GMT -5
The trick is to include Nicolas Welte's name with the query. If you do that the first result is Marko Mäkelä's page on the subject, which gives Mr Welte's email address repeatedly.
|
|
|
Post by Jim Brain on Sept 8, 2008 18:59:44 GMT -5
|
|
|
Post by Jim Brain on Sept 8, 2008 19:27:59 GMT -5
The concept as it stands now is as follows: We have a small inexpensive box containing a microcontroller with an Ethernet port, and furnished with jacks to connect to 10baseT Ethernet and either IEC or IEEE-488, depending on which of the two models we're looking at. The firmware in the box would accept three categories of commands, maybe using a different bus address for at least one of them to keep things simple: (1) commands to load a disk image via HTTP into the device's RAM, (2) commands identical to those of standard disk drives to access said image, and (3) commands to allow transmission and reception of raw packets lower down in the protocol stack. These last would be necessary for any program that wanted to use a protocol other than HTTP. I think you should use the sd2iec firmware, as it already handles all of the low level IEC work, and provides a nice "disk" interface that can be modified to work against any target (like Ethernet). As well, the firmware already implements JiffyDOS, which would be needed to allow reasonable speeds for transfers. Further, I would suggest you use the uIEC hardware platform (or one similar to it), as it supports the AVR ATMega1281, which has plenty of room for firmware, uIP support, and is reasonable from a cost standpoint. An upcoming version of uIEC will support IEEE 488 as well as IEC. I would also recommend the use of the ENC28J60 Ethernet controller. 1 more I/O line on the uIEC hardware would allow the interface to operate with the existing SPI code in sd2iec. I'm happy to help you merge your ideas into the sd2iec/uIEC work. sd2iec already allows the use of DOS buffers, which would be an easy way to implement lower level access. I think you'd be best to limit the Ethernet options on the uC. I have code that implements a similar "files and disk images via FTP/HTTP/HTTPS/etc." and uses RS232 and a simple protocol for now. It would be easy to retarget that protocol for Ethernet, and let the server do all of the heavy work. Later, if you feel the need to implement all of those protocols on the uC itself, you can do so. I think it would be better to let the image live on the network directly. D64 images are already supported, and Unseen has started adding support for D71 and D81 images. I have code for DNP (CMD Native Partition) support as well. Jim
|
|
gsteemso
Newbie
48 bits or bust!
Posts: 19
|
Post by gsteemso on Sept 8, 2008 22:27:46 GMT -5
I think you should use the sd2iec firmware, as it already handles all of the low level IEC work, and provides a nice "disk" interface that can be modified to work against any target (like Ethernet). As well, the firmware already implements JiffyDOS, which would be needed to allow reasonable speeds for transfers. Sounds good. Does it also do fast serial, AKA "burst mode", on a 128? How (in)expensive is the ATMega1281? I've already invested in a PIC programmer, on the assumption I'd be using one of Microchip's nine variants on the 18F97J60. Those cost about $5 each when bought one at a time, which seemed reasonable to me. That's an interesting idea. At the very least, I already wanted to see what you could tell me about the IEC interface -- I have quite a bit of documentation on it, but actual implementor's experience is valuable too. I'm not sure I like the idea of having my project inextricably entwined with someone else's, but since you're more reliable than I am it's probably you who ought to worry more... :¬) It would be easy to implement, yes, but I dislike the notion of sticking the device's primary functionality into a shoebox that would be subsidiary to the disk image manipulation aspect. I'd have to really give that one some thought before I could agree it's a good idea. While I agree with that one to a point, I want something that will work "out of the box", without needing a server to be configured as a helper. I'd rather skip the miscellany of protocols entirely for the early releases than have a system whose entire architecture changes between major versions. I certainly would want that to be an option, but I somehow doubt that everyone who posts a disk image to the Internet is going to want every Tom, Dick and Harry (plus their dogs) trying to simultaneously write changes to it. Read-only access is all well and good, but I certainly couldn't call the implementation complete if I went that way exclusively. Now that I'm definitely interested in. My vision for the final version of this thing so far is a little plastic box with IEC, 10baseT, and IEEE-488 ports, a few status LEDS, and maybe a couple of buttons like SWAP 8 and stuff (people seem to like those). The device would be bus powered. The box would contain the microcontroller soldered to a super-cheap PCB, with a few support elements (diodes, resistors, clock crystal, jumper posts to wire the case to, etc.) and not a lot else. I guess I'll likely need to include buffer chips for all the I/O lines, which would eat more power and board space than the rest of the circuit combined. Software wise, you could hook the thing up to any Commie that isn't a C65, and have it pretend to be a 1571 at the very least. If you have JiffyDOS, so much the better, and if you have the instructions you'll know how to point it at remote disk images, or entire servers if you don't mind everything looking like a SEQ file unless it's a genuine Commodore file that's been cut adrift from its .D64 image. (I'm seeing a lot of those lately. I guess they must be aimed at emulator users.) You could set it, by means of a trivial command, to use one of a standard set of disk images -- hosted somewhere stable, I'd hope -- that will always contain the latest software available for your Commodore platform; then it's just a matter of running the appropriate utility to join an AppleTalk network or get on IRC or do email or whatever. The GEOS integration would be a massive project in itself, two projects if the 128 version is very different, but I bet it would be a lot of fun. G.
|
|
gsteemso
Newbie
48 bits or bust!
Posts: 19
|
Post by gsteemso on Sept 8, 2008 22:37:28 GMT -5
Good grief. This place censors personal names. "Tom, thingy and Harry" Words fail.
|
|
|
Post by robertb on Sept 9, 2008 1:47:46 GMT -5
This place censors personal names. "Tom, thingy and Harry" Yup, I cannot use the name of our esteemed FCUG treasurer; I have to rename him to D. Estel or Richard Estel. :-) Took me awhile to figure out why thingy was being put in, Robert Bernardo Fresno Commodore User Group videocam.net.au/fcugThe Other Group of Amigoids www.calweb.com/~rabel1/
|
|
|
Post by Unseen on Sept 9, 2008 5:28:42 GMT -5
At the very least, I already wanted to see what you could tell me about the IEC interface -- I have quite a bit of documentation on it, but actual implementor's experience is valuable too. I haven't seen any documentation about the IEC interface that is usable without reading a rom listing in parallel to find out about all the minor but important details the documentation authors left out like implicit delays that must be inserted if the protocol is implemented on something faster than a 1MHz 6502. You do know that there is no power line on the IEC bus? Abusing the data lines for power won't work here, the EN28J60 needs ~160mA.
|
|
|
Post by Jeff Ledger on Sept 9, 2008 8:24:01 GMT -5
In an attempt to keep the forums "family friendly" I had activated a "Censor list" which obviously changes offensive words in conversations as they are posted. Dick Estel and company will be pleased to know that this list can be accessed and adjusted by the admin of the forum. Jeff/OBC
|
|
|
Post by Jim Brain on Sept 9, 2008 14:30:47 GMT -5
Sounds good. Does it also do fast serial, AKA "burst mode", on a 128? Not yet, but the IO is there, it just needs someone like you to implement the protocol. It's not a huge priority right now, I would expect, because there are far more C64s and DTVs, and JiffyDOS provides the same speedup factor as burst. It's a nice unit, with an integrated Ethernet controller. It seems a bit light in the RAM department, as 16 open CBM DOS channels is 4K of RAM, and that does not leave anything for Stack and temp. Obviously, you can limit the number of open channels, but it looked like you already had plans that would require many of them be open at once. If you're OK with programming the PIC in ASM (I have a hard time with the register layout of RAM) and/or needing to buy a compiler to do C development, the I would suggest asking the 1541-III folks if they have some code you can share. Note that they do not currently have as rich a DOS emulation and speeder support and Unseen's sd2iec codebase. Rolling your own IEC routines is an exercise in futility. As Unseen has already mentioned, it is impossible without digging deep into the CBM DOS ROM code. I should know, I tried in 2005 with the first firmware version of uIEC. I thought I could simply implement the protocol according to the reference works (Programmer's Reference Guide and other books I had on hand), but I gave up in mid 2005 in the midst of hard to replicate corruption errors, lockups, etc. That is why I migrated to sd2iec this year, as I did not want to spend my free time reverse engineering the IEC protocol, and Unseen had alreayd done it. That said, even he continues to find small issues in the code that must be fixed to properly emulate 1541 behavior (The most recent one he found after I added REL file support into sd2iec and we tried loading Castle Wolfenstein, as I recall) I don't think it makes any difference. As the sd2iec codebase is GPL, you are free to fork the code at any time. THus, in my opinion, you gain the ability to use code already writtten, pushing your project ahead faster and further, and you retain the right the right to take it in your own direction at any point in the future. Of course, once you fork the code, you take on full responsibility for the codebase, but you were planning to do that anyway. There is also a large benefit in being able to actively collaborate with someone else on the source code. It's different than simply asking for comments in a forum like this one. Unseen may not care either way, but I did not anticipate this benefit in re-using sd2iec, and it also helps me write better code and stay focused on getting new features implemented I'm think you misunderstood the proposal. Either way you go, you'll need to implement the IEC routines, the CMD loop, the error channel, and the CBM DOS buffer routines. If you are going to make it CBM DOS compatible (as you noted as a feature), you also have to implement file_open, file_read, file_write, file_close. From there, you have the option of creating a new command(s) to implement your lower-level support, but at all times, you have to adhere to the rules of the IEC bus, which means you have to shoehorn your device functionality into the IEC structure (OPEN, OPENCHAN, LISTEN, TALK, TKSA, CLOSECHAN, CLOSE, etc.) I am going on the presumption that you will not be able to fit all of the protocols people will want into the PIC. With that in mind, you'll need to develop some intermediate protocol at some point to handle the rest. Thus, if you implement it first, you can write the protocol code and teweak it on the server, where it is easier to track and fix bugs. Then, you can move the code into the PIC after it has been well tested. Your proposal didn't say anything about limiting access to the image. You propose pushing a RAM image to the network, but what about pulling it back later for use? Either way (your idea or mine), you have to solve the access issue. If you solve the issue of access and leave the image on the network, then if power is lost or other issues (like network loss), the damage to the image is minimal. If you copy the entire image to RAM, you could lose all the changes to the image unless you implement some write-thorugh mechanism. But, if you implement a write-through mechanism, there is little reason to store the image locally, and RAM usage is greatly reduced (1581 images take 800kB of RAM) Jim
|
|
gsteemso
Newbie
48 bits or bust!
Posts: 19
|
Post by gsteemso on Sept 9, 2008 23:42:08 GMT -5
To simplify matters, please know that I have decided to call the device being hypothesized in this thread an “EtherSQUID”. (Properly it would be the SQUID-3, but that would have people bugging me to finish the first two.) Not yet, but the IO is there, it just needs someone like you to implement the protocol. It's not a huge priority right now, I would expect, because there are far more C64s and DTVs, and JiffyDOS provides the same speedup factor as burst. Fair enough. I still want to implement it at some point to help those without JiffyDOS, who still outnumber those with it as far as I can tell, but I agree — it’s not a high priority. The PIC family I’m looking at has provisions for external RAM. Looks like I can interface a CF card to it like in your project too — that would provide local hard storage for when the network is inaccessible. More on that below. I’m seeing more and more benefits to modifying your project to suit my own ends. More on that below too. I don’t know that I would need that many open CBM-style channels, but I’d need even bigger buffers for some of the stuff I have plans for, so it comes out the same. I am used to the weird PIC addressing scheme — at least it isn’t 8086 segments, and can we honestly claim the C128 is less convoluted? :¬) I loathe programming in C anyway; not having a compiler for it that targets PICs doesn’t really bother me. Looks like I have a lot of integrating ahead of me though, trying to make your code work on a different architecture. If the 1541-III people are willing to donate some code, that will help, though — thanks for the tip. Interesting. My old SQUID-1 project to interface IEC via protocol converter to old-style Mac serial was never finished when I lost the means to continue it, which is why I’ve still got it sitting here glaring balefully at me from its box 10 years later, but I nevertheless got it to reliably transmit data back and forth, or so things appeared, at least. (It was cool typing “CMD 8” on my C64 and seeing subsequent output appear on the Mac next to it.) How did the errors manifest? You’ve sold me on the idea. Now I need to think some more on what the hardware will need to look like so I can design code to drive it. Can you please email me some sort of description of the µIEC hardware, for reference purposes? This is very true. I was planning to pervert contort the IEC semantics in very different ways for the three different categories of commands, though. In many ways what I envision is like two separate devices that happen to share several key pieces of functionality (not to mention hardware). Actually, I'm giving serious thought to emulating a CMD hard drive instead of a 1541 or what have you. It would still work for most things and it would be a lot simpler. All I would need is a “dump/undump remote image” facility for packing and unpacking D64 images and such, which properly speaking would be a completely separate project. It is likely there is some need for such a thing whether I build a working EtherSQUID or not. I’ve been thinking hard about this. When I called Microchip to request a sample PIC, the only model number I could remember off the top of my head was for the huge honkin’ top-of-the-line model with 64 kibiwords of program space, so I’m not too worried about running out. Considering all the stuff people can cram into a C64, I should be able to get this thing to practically dance a tango and still have room left over. It only costs about a dollar more than the cheapest model, so why not? I figure I can include as many low-level protocols as I can envision anyone needing, and let application code on the Commie take care of anything high-level that I didn’t think of. There are entire HTTP stacks and things written for the C64, so if the low-level stuff is already taken care of, anything should be possible. Again, why not? I have to say, it seems to me that you are starting from the assumption that everything from the EtherSQUID towards the Commodore user is incapable of serious computation, and that any modern application will require a “real computer” on the far end to do the heavy lifting. If that truly is your position, and I honestly can’t tell one way or the other, I beg to differ. Sorry, yes, I did leave out the whole concept of access permissions, but I think it needs to be considered for an interface to a global network. The usual server-side permissions should be OK in most cases — most public stuff is read-only, but that itself would introduce dreadful complications if someone tried to use something like a GEOS disk “in situ”. Write protection can really ruin your day when you need a storage medium. We have to face facts — at some point in the next 20 years, there won’t be any working physical 5¼" drives LEFT, and many people already have some trouble finding a working specimen amongst a stack of old 1541s and 1571s. All of this is what got me thinking in terms of your CF solution. Having persistent local storage solves a lot of issues. Thank you for all the thought you’ve put into this. It’s really helped me reason things out.
|
|
|
Post by Jim Brain on Sept 10, 2008 13:10:40 GMT -5
Fair enough. I still want to implement it at some point to help those without JiffyDOS, who still outnumber those with it as far as I can tell, but I agree — it’s not a high priority. Dunno. 4.5million C128s sold, 14 million C64s (or 17 million, depending on who you ask), many million VICs, and a smattering of X64 (plus/4/C16) options, only the C128's support Burst. There are versions of JDOS for all of them. BBSs like to have lots of channels open. Also note that I would recommend you use SD/MMC cards, which sd2iec also supports. SD cards require fewer IO, and a newer version of uIEC will support both card types. I think 1541-III is in ASM, so that might be a better route. Simple stuff like you describe worked fine, but in a 202 block load, there would be 1 or 2 bit corruptions. They would only occur during the load and only in a large file transfer. As well, the spec is incomplete on what to do if the transfer is aborted at certain spots in the protocol (during the turn, during the bit transfer, during the close, etc.) www.jbrain.com/vicug/gallery has pics, but I only suggest uIEC for the 128k bytes of program space. I would search for SD2IEC PCB plans for the simpler SD interface. If you're talking about changing the protocol at the wire level, I don't know there would be much benefit. If you're talking about changing it at the command level, I'd question why. The CBM DOS is very flexible already. It would be trivial to do: open 15,10,15,"EM3:http://dir/to/image.d64", which would mount a virtual disk image on partition 3. open 1,10,2,"#2" would open a buffer to general use print#15,"TO:"chr$(2);"192.168.0.2" then, reading and writing from channel 1 on the CBM machine will read and write raw TCP packets to 192.168.0.2. Implementing SAMBA, FTP, HTTP, etc. can be accomplished in a similar mode. Instead of sending the command TO, Maybe overload it to: THO - http open, THC would would close TFO - ftp open, TFC would close THS - https... TSO - SMB TNO - NFS Add the ports on the end: THO;chr$(target_port%256);chr$(target_port/256);chr$(optional_source_port%256);chr$(optional_source_port/256) Then, if http port was open, then do: print#1,"GET / HTTP/1.0";chr$(13);chr$(13) and then grab the resulting data from channel 1 and parse. sd2iec already emulates a CMD HD in most respects (subdirectories, partitions, etc., and handles disk images already: @cd:image.d64 will drop you into the image directly, no unpacking needed. All I can say is that codespace disappears quick. The original MMC2IEC had 32K, and we passed that a while back. The SD2IEC has 64kB of flash, and we're up to 44K or so. THere are lots of things to add, and that does not include the uIP stack you need to do Ethernet. I'm thinking more of the need to support higher level protocols on the unit directly to handle mounting an image over HTTP or FTP or SMB. The Commie can't help you there, because it is expecting a complete disk to be sitting at device #10 or whatever. Thus, all of the heavy protocol lifting needs to be done in the uC. And, many D64 images on web sites are ZIPped, which means you need to unzip and temp store the image somewhere. I think they are capable of the same level of computation as the Commie they will service. No more, no less. The cycle time is faster, but there are limits. But, my comment is not a "Get a real computer, kid" one. Mine is a "where do you want to spend your time, and will anyone care that you packed it all in a uC" one. Your time is valuable, and many won't care if a small server app is needed for some protocols. If they complain, that's a great opportunity to ask them to help you move the protocols into the uC. As well, a small server that implements some helper code need not be installed by all. A single copy could handle thousands of connections, as it's not doing all that much work. So, your little uC could come preconfigured to talk to a server you have running, and then you can easily debug issue folks have with specific protocols. You can also use the server to check usage and gather stats on protocol usage, in order to prioitize your development efforts. Above all, while it is no doubt possible to put all of the protocols in the uC, you may decide some are not worth the effort. A helper server allows you to get those folks asking for some antiquated protocol off your back, while not actually implementing the worthless protocol in valuable uC space. As well, the development mantra used most often is "Make it work, then make it work right, then make it work fast and efficiently". In that mode, the first implementations of a protocol in a uC might not fit in the uC. Having to optimize the code before you even get it running in the uC is not a winning combination. It's best to get it running, see what optimizations can be made, whittle it down while debugging on a larger machine, and then placing the final code on the uC. I speak from experience. sd2iec uses FatFs for the FAT functionality. After a number of iterations of "change FatFs, complile, dload, test, gather rudimentary debugging via IO line changes and RS232 channel, repeat", I built a small PC test app and compiled the FatFs code via GCC on my larger machine. The testing cycles were much shorter, and Unseen used the testbench to find a small seek error that was hard to diagnose and fix, but was causing great issues. While I have no doubt he would have found it anyway, it took much less time to find it on the PC (it had to write to the FAT system to test, so doing it on the uC meant cleaning a card each time we ran the code. Doing it on the PC meant simply copying the old FAT image over the modified one before each run) In the worst case, you find you need the protocol and it is there. In the best case, you won't need it, but you can offer it as a "feature" for those who want to experiment with new protocols, like XMPP or IceCast, or others, that you are just not interested in. Yes, it does. As well, if you were to use the sd2iec base, you can offer your funcitonality on top of the base CF/SD/IDE functionality. Just a note, though. I know you loathe C, but it's going to be harder to find folks who want to code in ASM with you on a project. If you're OK being on your own, then it's no problem. But, I can tell you that working with a collaborator (or two, on sd2iec and the bootloader functionality) is priceless. There are times when one simply needs to bounce ideas off of someone who is close enough to your project that they can provide valuable input. As well, I know the PIC is in hand and you know how to program it, but in the larger scheme of things, a few dollars isn't that much of a deal to those who will buy your solution (PIC with integrated Ethernet versus AVR without). Yours will no doubt be compared to sd2iec, as it appears the most functional in this line of devices. If you go with the PIC and the 1541-III codebase, you may continually be behind, with people asking why you don't support JDOS or CMD partitions, or Dreamload, or whatever. You personally don't find those features all that interesting, but the folks who nag you about the project do. Never underestimate the uninformed public in their ability to be unintionally mean to a hobbyist hardware developer. Been there, done that, got the scars to prove it. It's hard to blame them, as they think all features are equally easy to implement. Still, the words hurt just the same. Jim
|
|