bw0i+@andrew.cmu.edu (Bryan Wu) (09/22/88)
Note: I hoped to send this to David Small, but couldn't e-mail to him.. I don't know if it is even possible, but since you are making a new cartridge for the 128k ROMs, will you also be putting in AppleTalk network port in? Perhaps by putting in the Zilog chip onto the cart itself (since the chip can be bought by anyone) you would be able to get networking into the Atari series via AppleTalk. Perhaps making the Zilog chip available to the ST via. cart slot and bypassing the Mac ROMs you could also introduce high speed nets to the ST w/o using the Mac part of the cartridge? .. This way you could put a high speed port on the Spectre 128 cart itself and wouldnt have to use the Atari's hardware ports (as they are supposed to be slow compared to the AppleTalk ports) for networking. One of the big reasons I'm asking this is because I'm at Carnegie Mellon and we have a computer net. called Andrew (as in Andrew Carnegie, MIT had a similar system called Athena I think) which is a campus wide (even in the dorm rooms) file server system. Just last year, they released a handler for the Macintosh that allows you to access the network via the AppleTalk port. (This project is a joint effort between CMU and IBM and recently Apple (using Mac II's as workstations soon)) Now the project is going to start at the University of Michigan (I think) as well and will be trying to get all kinds of computers (not just IBMs and Macs) onto the fileserver. The Andrew project is aimed towards Universities it seems. If you could get the Spectre 128 to work with AppleTalk, then you would offer a "cheap" alternative to buying a $2000+ Mac SE and would get the business of students buying STs at colleges with the Andrew System..if the Andrew system goes over well. In addition, you could get the ST to share printers w/ Macs if necessary, send info between the two and so on.. a great aid to the ST line which has no really good networking to speak of. Having AppleTalk networking capabilities certainly won't hurt the product. eh? Besides, it would be nice to use the laser printers in the clusters from my room.. sigh..
c91a-ra@franny.Berkeley.EDU (reader.john.kawakami) (09/23/88)
Interfacing to Appletalk thru the cart port and Spectre 128 is a good idea,
but doing it through the DMA port would be the ideal method. There could
be an Appletalk connection whether Spectre were running or not.
[spectre->[appletalk->[ST] vs. [spectre->[ST]<-appletalk]
|| ||
some net some net
TTL EXE MUX PRG A3I MTX TTP FOE TUS APP JTK MMU CRT VDI TOS DRI GEM CPM ACC OMV
JOH NKA WAK AMI c91 a-r a@f ran ny. Ber kel ey. Edu kaw aka mi@ zen .Be kel ey.
dlm@druhi.ATT.COM (Dan Moore) (09/24/88)
in article <YXC6Ity00XoBI940VJ@andrew.cmu.edu>, bw0i+@andrew.cmu.edu (Bryan Wu) says: > Note: I hoped to send this to David Small, but couldn't e-mail to him.. You can reach Dave on the Well. Try hplabs!well!dsmall. > I don't know if it is even possible, but since you are making a new cartridge > for the 128k ROMs, will you also be putting in AppleTalk network port in? > Perhaps by putting in the Zilog chip onto the cart itself (since the chip can > be bought by anyone) you would be able to get networking into the Atari series > via AppleTalk. It isn't very hard to place a Zilog SCC on a cartridge for the ST. It can even be made to function as an AppleTalk interface. But there are some large problems with using it, expecially at higher speeds. The STs cartridge port was designed only to support ROMs. There is no write line or interrupt lines on the connector. With a little fiddling it is possible to write data to the port, basicly you use the address lines as data lines. As far as I know there is no simple way to get interrupts from the port without hardware modifications. AppleTalk runs at about 230Kbps which is about 28K bytes per second. On the Mac the SCC is setup to interrupt the CPU every time a data byte has arrived and it also interrupts the CPU when it needs another byte for transmission. So in the worst case the CPU could be interrupted 56K times per second, assuming you are transmitting and receiving data at the same time (something that is never true as far as I know). The majority of the time the link is idle so the CPU is not being interrupted. So on the Mac when you use AppleTalk you use up a lot of the CPU servicing the port. Users don't notice this since most of the time they aren't using AppleTalk, and when they are they aren't doing anything else (I'm ignoring Multi-Finder for now). If you have an SCC connected to the STs cartridge port it can not be interrupt driven, it must be polled by the CPU on a regular basis so that it can detect incoming data. So you need to setup one of the hardware timers to interrupt the CPU 28K times per second (actually it needs to be at least 50% faster than that in order to be sure no data is lost) so it can check if a data byte has arrived and if it needs to feed the transmitter another byte. This would occur *ALL* of the time, whether or not the AppleTalk link is active. This would slow down the Spectre 128 a lot, maybe even make it unusable. Unfortunately this means the cartridge port isn't a reasonable method of connecting a high speed (230Kbps) device to the ST. The only reasonable alternatives are the DMA port and the parallel port and the Mega ST expansion port. The DMA and parallel ports have some problems which may or may not be fixable. The best alternative is the Mega expansion port, but that won't help most ST owners. I'm not saying that you can't hook an ST to AppleTalk. I'm just saying that no one has come up with a reasonable and affordable method. Yet. ------------------------------------------------------------------------------ Dan Moore AT&T Bell Labs Denver dlm@druhi.ATT.COM ------------------------------------------------------------------------------
Thomas_E_Zerucha@cup.portal.com (09/25/88)
I think the 128K roms take the 128K address space of the cartridge port, so you can't add any networking there. The DMA port has possibilities. But I think it would be interesting if someone came up with a Mega ST expansion board which had sockets for the Macintosh chips (one place that had the ROMs had the IWM, and the Zilog chip should be available). So you could get a much more maclike machine. It might be able to fix the zerostore bug in hardware too. And of course, if it had the Zilog chip at the same address, Appletalk should then work. Just dreaming... but I think it is possible, i.e. enough space in the Mega's memmap.
braner@batcomputer.tn.cornell.edu (Moshe Braner) (09/29/88)
[claims the ST cannot connect to Appletalk through the cartridge port since it has no capablity to interrupt the CPU...] I am not trying to defend the *stupid* design of the cartridge port in the ST (when it could easily have been a full expansion slot), BUT: A device there that would connect the ST to Appletalk (or any other network of similar speed) could have some reasonable amount of RAM so that it could buffer incoming (and outgoing) data. The CPU could poll it every once in a while, often enough to prevent overflow of the buffer, and do a quick transfer of the data into the CPU's RAM if there is anything in the buffer. Outgoing data could be deposited in the buffer and then sent at the network speed by the controller on the cartridge. Sort of like pseudo DMA :-) Of course this method means more hardware on the cartridge, meaning higher cost. But not THAT much. The pure-software solution used in the Mac (typical of Apple) has its own disadvantages too, as the previous poster indicated. A solution using the DMA port is of course more elegant. What's new in the field of ST networking through the MIDI ports? - Moshe Braner (In 39 years we'll see the promise-LAN, so hang in there :-)
gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) (09/29/88)
In article <6424@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (Moshe Braner) writes: > [stuff deleted] > >What's new in the field of ST networking through the MIDI ports? > i haven't been writing any networking code, but i have been looking into MIDI networking. you could use a true ring topology, with packets being received and retransmitted around the ring. this would require interrupt driven receiving and sending through the MIDI port. at the moment, the MIDI ACIA chip is configured to do interrupt-driven receiving, and busy-waits for sends. this is sub-optimal. the 6850, however, can be set to another mode which interrupts on both receipt and sending. the midi and keyboard acias share an interrupt; therefore, you would have to replace the current handler with a new one which checked for more conditions. this would eat a little more CPU than the present routine. anyone want to write a TCP/IP sort of network? you could do print sharing using a memory buffer, and disk sharing by using a GEMDOS-level driver. if you wanted to get really fancy, you could also allow the rs232 as a device, to link rings, or over Bitnet or a conferencing system such as Genie. and maybe you can rig the parallel port to send and receive... or... or... greg disclaimer: this message does not resemble reality in any way, shape, or form. Greg Lindahl internet: gl8f@virginia.edu U Va Dept. of Astronomy bitnet: gl8f@virginia.bitnet
bammi@dsrgsun.ces.CWRU.edu (Jwahar R. Bammi) (10/01/88)
In article <3602@druhi.ATT.COM>, dlm@druhi (Dan Moore) writes: > > If you have an SCC connected to the STs cartridge port it can >not be interrupt driven, it must be polled by the CPU on a regular >basis so that it can detect incoming data. So you need to setup one of >the hardware timers to interrupt the CPU 28K times per second (actually >it needs to be at least 50% faster than that in order to be sure no >data is lost) so it can check if a data byte has arrived and if it needs >to feed the transmitter another byte. This would occur *ALL* of the >time, whether or not the AppleTalk link is active. This would slow down >the Spectre 128 a lot, maybe even make it unusable. > Well thats true if you take the Apple `lets do everything in software' approach. The other alternative is to use buffers from/to which the CPU can transfer data as needed. In fact, it is conceivable that all the packetiztion etc be done by a simple processor, and then shipped thru the cart. port., a packet worth at a time, or at some appr. granularity. -- usenet: {decvax,sun}!cwjcc!bammi jwahar r. bammi csnet: bammi@dsrgsun.ces.CWRU.edu arpa: bammi@dsrgsun.ces.CWRU.edu compuServe: 71515,155