Ole Voss wrote: >On 10/16/03 10:46 AM, in article >20031016044624.19539.00000359@mb-m07.aol.com, "Michael J. Mahon" > wrote: >> I think that the 6502 architecture is not particularly well-suited to >> virtualization (pages 0 and 1 come to mind), which is one way >> that a larger variety of pre-existing programs could be made to >> co-exist with a network stack. >> >> -michael > >On the other hand how many programs exist on the Apple iie that would be >able to handle network input, or are you thinking of mounting network >devices via such a TCP/IP network as native DOS/ProDOS drives? I would be amazed to see this on a //e, just because ProDOS plus _any_ application program has such a large "footprint" that there is practically no corner left in which a TCP/IP stack could run. (TCP/IP is, itself, a pretty complex piece of software--at least for a 64K/128K machine.) Running the entire stack as if it were an interrupt routine will impose very severe constraints on how it can be coded and what it can assume about the state of the system. It may be possible, but it sort of "turns the problem inside out". I expect that most people aspire to file transfer and (text-based) web browsing, not to running PublishIt! with input from a network drive. ;-) This question--what a networked //e should aspire to--has a lot of interest to me, since I've been working intermittently on a baseband, contention-based network for Apple II's that uses no extra hardware, just bit-banging the wire. Of course, that rules out doing anything else when data is being transferred, but with appropriate re-trys, timeouts, and protocols it is easy to do other tasks between transfers. The data rate I'm looking at is about 10 kilobytes per second, which is pretty good. There is also a broadcast protocol, for initialization and address resolution. I began with a simple client/server architecture, exercised by direct calls for services from software. I've thought recently about peer-to-peer file sharing as an objective. My original motivation--and still a great interest--is using the network to create a multi-Apple parallel multicomputer (just for fun ;-), but I realize that others would probably find it more useful as a way of interconnecting two or three Apples. By adding a couple of transistors and a few resistors to the gameport plug, the net can easily scale to 16 computers (or more, if I broaden the addressing beyond 4 bits ;-), so it's got some "fun" potential! It definitely sounds like you're having fun, and that's the point! -michael Check out amazing quality sound for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/ Ole replied: >Your project sounds like a mission, but well worth the time in my eyes. >Afterall where's the fun in hooking up modern computers? I agree--though sometimes just getting it to work is perversely satisfying. ;-) >10KB/s is a hefty throughput using a one-wire protocol (did you peek at >Dallas Semiconductors?) and an Apple IIe. Am I right in presuming this was >done in Assembly? I haven't looked at the Onewire protocols in detail. Instead, I started from the inside out with assembly routines, trying to see just how fast I could go, while allowing for necessities, like maintaining sync within a cycle or two across machines with different clocks. I've got it to a point now where I don't think I could shrink the bit cell any more (it's currently 9 cycles, limited by sending). >Have you gotten some sort of file transfer programming running on this >network? I haven't integrated it into any file system (yet?), but can transport arbitrary-sized blocks of bytes in memory. A ProDOS device driver would not be difficult, but I've never done one. (Where's open source when you need it. ;-) >I'm very interested in hooking up IIe's because I worked on that computer for >a very long time. In the long run I would like to see the idea expand to all >members of the II family. Currently I'll be sticking with the IIGS purely for >comfort and speed. Ok, the 65816 has a lot going for it too ;-) My code is pure 1MHz 6502 code, so it is immediately portable across the entire Apple II line, as long as the machine has an annunciator output and a pushbutton input. (The //c's are a bit of a problem in this regard, but I expect that the IOU could be tapped internally.) >As far as space consumption goes, the TCP/IP suite does not really require >large amounts of memory and I'm sure one can cram the whole lot in a couple >of Ks... although that will be a lot already. For my purposes (and, indeed, for any very-low-latency network) TCP/IP is gross overkill. Just another case of a standard being used because it _is_ a standard--and that's fine. Since I have no desire to interconnect with anything but my own code, I'm free to create. Of course, someone could always layer TCP/IP over my transport. ;-) >I've been reading and re-reading the RFCs connected with this project but I >believe it's time to actually start doing something ;-) It's just been so >long since I last programmed a 65xx and the comfort of high-level programming >has taken its toll on me too. The joy of assembly will return quickly, I'm sure. If I were thinking about moving to the 65(C)02, I'd start there , though. Resource-constrained programming is best served by facing the constraints from the start. Merlin is a great assembly language environment, and with an accelerator (or an emulator) the speed is fine. (BTW, my code tolerates Zip Chips, or any other accelerator that drops to 1MHz mode for about 50ms. when a reference is made to slot 6 device space.) -michael Check out amazing quality sound for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/ Ned Ludd replied: >Michael J. Mahon wrote: > >> The fundamental question is: do most Apple users just want a >> connectivity solution, or do they want a native Apple solution? > >I'll cast my vote for native, though I don't claim to be representative >of _most_ Apple II users ;-) > >Sure would be cool to network all these IIe's I have stacked in the >closet... Cool. The next question would have to be what "networking" means... To most people it seems to mean TCP/IP and the internet. I have little interest in connecting an Apple II directly to the internet--it's a bit like hooking a 6" fishbowl to a firehose. I have plenty of internet connectivity, and prefer to use my Apple II's to escape the internet for awhile. ;-) To me, a network of Apple II's means multicomputing, parallel computing, and fun with protocols of my own devising. The network is baseband CSMA/CD (with CA arbitration) and the on-the-wire protocols include checksums, maximum packet data payloads of 256 bytes, fast ACK packets, and chained packets for arbitrary-size data transfer. My "starter pack" of peer-to-peer services currently include remote "peek" and "poke" (of arbitrary size) and remote "goto". That was enough to demonstrate that it worked and to play with. It all currently fits in about 1300 bytes. I've been planning to "crate up" eight //e boards and network them together, and, in the process, found that I'd like network boot, too--so I'm thinking about burning a modified "self test" that will reset into the service loop (in EPROM) to support remote booting from the network. ;-) (An alternative would be an EPROM in I/O space, but I don't want to put a card into the boards, since they can't be packed tight then.) The "Apple Crate" is currently a wooden cubical framework about a foot on a side. I figure an old PC power supply will do the job nicely. I had hoped to use the factory power edge connectors to supply power, but different //e board revisions actually have different voltages at the edge, and none of them have all four--I will probably have to pigtail a power connector (plugging into the existing connector also spaces the boards too far apart). A ninth Apple //e in it's normal desktop configuration will also be networked as the boot server and controller. It would be fun to attach eight more monitors to the crated //e's, and would be a neat display, but the space required is currently out of the question. (Maybe I can find some cheap 5" monitors... As it is, a "floating" monitor can be plugged into any of the boards to verify its behavior (or to diagnose misbehavior ;-). I work on this project in fits and starts, so progress is hard to predict--but as things develop, I'll drop a line here when there's something to report. -michael Check out amazing quality sound for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/