ralphw@ius3.ius.cs.cmu.edu (Ralph Hyre) (10/11/88)
In article <594@hudson.acc.virginia.edu> gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) writes: >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. ... >anyone want to write a TCP/IP sort of network? Yes. The thing to agree on would be the encapsulation of the packets. Eventually you would submit this to the DARPA Network Information Center (SRI-NIC) in the form of an RFC, but first: 1) talk about it work networking people (comp.protocols.tcp-ip) 2) other users of the MIDI medium (rec.music.synth?) You might even consider the option cranking the speed up (if the ST can support it.) You will want to support more than 16 nodes/physical network, so you wouldn't want to tie yourself to using a MIDI/channel designation for the address. That would confuse any musical instruments that are sharing the network, and you would probably turn the musical community off to networking. Perhaps reserving a well-known channel (say, 15? [any objections]) for 'MIDI nets' will make it easier for implementation to interoperate. Support for other MIDI capable machines (IBM PC, Amiga, Mac (even though it already has Appletalk), and even the venerable Apple ][ will help this become a reasonable thing to do.) You will want to build some kind of gateway, so that your net can be interconnected with other networks. Machines with MIDI Thru capability will be prizedfor the ability to provide easy wiretapping capability. The KA9Q package is probably the best starting place for the guts of all this, then just add a MIDI driver to it. Truly Free networking (except for the (passive) cables) would be another point in Atari's favor. You might even be able to use something like Apple's MIDI interface to hook up Appletalk-only laserwriters, if you stuffed the bits into in the right fashion. Good luck. (perhaps my proposal for MIDI TCP/IP encapsulation will appear on this forum shortly.) -- - Ralph W. Hyre, Jr. Internet: ralphw@ius3.cs.cmu.edu Phone:(412) CMU-BUGS Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA "You can do what you want with my computer, but leave me alone!8-)"
koreth@ssyx.ucsc.edu (Steven Grimm) (10/12/88)
I had the opportunity to take a look at John DeMar's "ST-NET" in a very
primitive form. It was *SLOW*. File service is slower than floppy access
by a significant amount. And that's with only two computers talking to
each other; things will slow down even more when you add more computers
to the net. The problem isn't anything you can really solve in software;
it's the 31Kbaud transmission rate of the MIDI port. That's simply too
slow for anything but the most primitive networking applications (MidiMaze,
for example). Even Appletalk, which isn't a speed demon by any stretch
of the imagination, runs seven times faster than the MIDI port. Combine
that with the cockeyed way the ST handles MIDI interrupts (they have lower
priority than things like the RS232 port, which is silly since the MIDI
port is half again as fast) and you have a really monstrous programming
project that's not going to give you a whole lot of benefit anyway.
The DMA port is the only good place to plug a network interface into the
ST; it is fast enough to do reasonable networking, such as Ethernet. If
someone develops an Appletalk box for the ST, they will stand to make quite
a tidy profit, especially if they can make it work with the Spectre 128
and Magic Sac. That or an Ethernet interface are much more worthwhile
networking projects for the ST.
(Of course, if you're just doing MIDI networking for the fun of programming
the stuff, ignore everything I've just said...)
---
These are my opinions, and in no way reflect those of UCSC, which are wrong.
Steven Grimm Moderator, comp.{sources,binaries}.atari.st
koreth@ssyx.ucsc.edu uunet!ucbvax!ucscc!ssyx!korethdbell@cup.portal.com (10/13/88)
Ralph - As for choosing a MIDI channel to avoid interferance w/ instruments, I'd say the simplest way would be to allow the net to operate on ANY channel (or even break the net into zones using channels), but encode all network communications as SYSEX blocks. The are a lot of SYSEX id's not yet assigned (confer Intl MIDI Assoc. data). This would serve to encapsulate the communications in an isolated pseude channel, where the contents of the SYSEX block is *entirely* up to the network community to decide upon; the only restriction being that only 7-bit data is allowed within the block... Dave
gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) (10/13/88)
midi networking would be fast enough for print sharing and network applications
such as midi-maze. if we could beat the centronix port into being 2way we
could do reasonable disk sharing. however, i think that the first 2 applications
alone might be worth the effort.
----------
Greg Lindahl internet: gl8f@virginia.edu
University of Virginia Department of Astronomy bitnet: gl8f@virginia.bitnet
"Doesn't Quayle know that the FBI handles doesmetic assassinations?"c91a-ra@franny.Berkeley.EDU (reader.john.kawakami) (10/13/88)
In article <625@hudson.acc.virginia.edu> gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) writes: >midi networking would be fast enough for print sharing and network applications >such as midi-maze. if we could beat the centronix port into being 2way we >could do reasonable disk sharing. however, i think that the first 2 applications >alone might be worth the effort. >---------- >Greg Lindahl internet: gl8f@virginia.edu >University of Virginia Department of Astronomy bitnet: gl8f@virginia.bitnet > "Doesn't Quayle know that the FBI handles doesmetic assassinations?" I add: only if it's an ascii printer; a Postscript laser would choke a MIDI net. And I thought the centronics port was two way (with a proper xbios call). A MIDInet would never pass muster as a real net, but it is a cheap step up to one. You could implement mail, and net based games :) and other useful functions. You could also do file transfers relatively quickly without having to rig up a null modem. 3.5KB/sec is not exactly inconvenient if it is done only occasionally. Now all we need is a standard ;-) 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.
ggf@js.UUCP (Gary Frederick) (10/14/88)
We are looking at using the midi port between two STs. The speed of the midi
port does make the midi less than fantastic for a network. However, what
we really want is a way to get at files on a ST from another ST. How we
are planning is to use UUCP software to get files. It will not be as
fast as an ethernet connection, but for the price of midi cables and
some software, we have easy access to files on two systems.
Something else we are looking at is using minix to distribute the operating
system over the two STs. Minix was designed to be easily implemented
as a distributed os, and Amoeba, software to do rpc, is available for
the PC version of minix. Perhaps a little work would let us use the midi
port to tie STs into one system. (* perhaps not :-) *)
Gary
UUCP: ggf@js.uucp
uunet!unisoft!nud!js!ggf
BIX: ggf
jsbbs: ggf (* (602) 276 6102 *)wes@obie.UUCP (Barnacle Wes) (10/19/88)
In article <5080@saturn.ucsc.edu>, koreth@ssyx.ucsc.edu (Steven Grimm) writes: > I had the opportunity to take a look at John DeMar's "ST-NET" in a very > primitive form. It was *SLOW*. File service is slower than floppy access > by a significant amount. And that's with only two computers talking to > each other; things will slow down even more when you add more computers > to the net. The problem isn't anything you can really solve in software; > it's the 31Kbaud transmission rate of the MIDI port. Consider this little GEM :-) gleaned from the Abacus "Atari ST Internals" book: Bits 0 and 1 of the Control Register on the MIDI 6850 chip control a "divider" for the input clock, determining the baud rate. The MIDI sets these bits to 01, meaning divide the clock signal by 16. The clock to the 6850 is 500 Khz, which gives us the MIDI speed of 31250 bps. If you reprogram these bits with 00, it tells the chip not to divide the clock, giving you a clock of 500 Khz, which is adequate for a simple, small network (like AppleTalk). I have wanted to play with this for quite a while, but I have not been able to find out what setting is used for the rest of the bits in the CR on the 6850. Can anyone tell me where the MIDI port is initialized by the ROMs? If you can give me an address, I can go disassemble the code and find out what the CR is set to on initialization. I'd like to see of the rest of the circuits surrounding the 6850 can stand up to this kind of speed. It isn't all THAT high, but I'm not going to stick my neck out until I've tried it personally. This could make programs like MIDI-NET much more usable if it works! -- {hpda, uwmcsd1}!sp7040!obie!wes "How do you make the boat go when there's no wind?" -- Me --
gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) (10/25/88)
In article <229@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: > >Consider this little GEM :-) gleaned from the Abacus "Atari ST Internals" >book: > >Bits 0 and 1 of the Control Register on the MIDI 6850 chip control a >"divider" for the input clock, determining the baud rate. The MIDI sets >these bits to 01, meaning divide the clock signal by 16. The clock to >the 6850 is 500 Khz, which gives us the MIDI speed of 31250 bps. > >If you reprogram these bits with 00, it tells the chip not to divide the >clock, giving you a clock of 500 Khz, which is adequate for a simple, >small network (like AppleTalk). > i thought appletalk ran more like 110 Khz? anyway, the midi init routine is on page 29 of usa.s in your developer's documentation -- you can buy used copies for cheap if you can find disgruntled developers :-) it says : /16 clock, 8 bit, 1 stop no parity rts low, no transmit interrupt, receive interrupt. i guess you'd eventually want to turn on the transmit interrupt and replace the bios routine which handles those interrupts, so that you could buffer in and out. it's too bad that that acia doesn't support /4 clock. but maybe /16 will work? if i had 2 st's i'd try it. -- greg ---------- Greg Lindahl internet: gl8f@virginia.edu University of Virginia Department of Astronomy bitnet: gl8f@virginia.bitnet "Doesn't Quayle know that the FBI handles domestic assassinations?"
david@bdt.UUCP (David Beckemeyer) (10/26/88)
In article <229@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >Consider this little GEM :-) gleaned from the Abacus "Atari ST Internals" >book [ editied ] >If you reprogram these bits with 00, it tells the chip not to divide the >clock, giving you a clock of 500 Khz, which is adequate for a simple, >small network (like AppleTalk). The UART used for the MIDI port is an old part, with only a one character FIFO (does that count as a FIFO?). 500 Kbs is about 50,000 characters per second and with the MIDI hardware such as it is, the 68000 is going to have to do something for every character received. At 500 Kbs, the system has approximately 20 microseconds to handle one character. The 8 Mhz 68000 in the ST can probably sustain this rate in a tight loop, but I don't think it can handle the 100,000 or so interrupts per second necessary to handle a bi-directional 500kps interrupt driven link (i.e. "background" network). This is before you consider that other ST interrupts have a higher priority than the MIDI UART interrupt and any one of these other interrupts (e.g. RS-232) might take well over the 20 microsecond time limit. This scheme may be usefull for a "dedicated" server under extremely controlled conitions, such as printing while the system isn't doing anything else, but it is *very* unlikely that it could be used for a LAN type architecture. -- David Beckemeyer (david@bdt.UUCP) | "Lester Moore - Four slugs from a .44 Beckemeyer Development Tools | no Les, no more." 478 Santa Clara Ave. Oakland, CA 94610 | - Headstone at Boot Hill UUCP: {uunet,ucbvax}!unisoft!bdt!david | Tombstone, AZ
walkerb@tramp.Colorado.EDU (Brian Walker) (10/26/88)
In article <229@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >If you reprogram these bits with 00, it tells the chip not to divide the >clock, giving you a clock of 500 Khz, which is adequate for a simple, >small network (like AppleTalk). Best to check that one out. Most USART chips require the clock division to be set to at least 4 when using the asynchronous mode of the chip. You can set the clock division to 0 only if you set the chip to synchronous mode. Brian Walker, University of Colorado at Boulder|| printf("Say please:] \n"); walkerb@tramp.colorado.edu=======|| if (say_please(user)) {ncar,nbires,sunybcs}!boulder!tramp!walkerb====|| be_nice(random());
awm@gould.stars.flab.Fujitsu.JUNET (Aled Morris) (10/26/88)
>Bits 0 and 1 of the Control Register on the MIDI 6850 chip control a >"divider" for the input clock, determining the baud rate. The MIDI sets >these bits to 01, meaning divide the clock signal by 16. The clock to >the 6850 is 500 Khz, which gives us the MIDI speed of 31250 bps. > >If you reprogram these bits with 00, it tells the chip not to divide the >clock, giving you a clock of 500 Khz, which is adequate for a simple, >small network (like AppleTalk). Unfortunately, there is an opto-isolator in the circuit, and unless Atari have been extremely generous, I doubt very much that this part will be capable of running any faster than the original specification called for (i.e. 30k-ish). I don't think that you can simply bump up the clock frequency in order to improve the networking performance of the MIDI port. Aled Morris systems programmer mail: awm@doc.ic.ac.uk | Department of Computing uucp: ..!ukc!icdoc!awm | Imperial College talk: 01-589-5111x5085 | 180 Queens Gate, London SW7 2BZ
brenes@skywest.UUCP (Erasmo Brenes) (10/27/88)
In article <4284@boulder.Colorado.EDU> walkerb@tramp.Colorado.EDU (Brian Walker) writes: >In article <229@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: >>If you reprogram these bits with 00, it tells the chip not to divide the >>clock, giving you a clock of 500 Khz, which is adequate for a simple, >>small network (like AppleTalk). > >Best to check that one out. Most USART chips require the clock division to >be set to at least 4 when using the asynchronous mode of the chip. You can >set the clock division to 0 only if you set the chip to synchronous mode. > The ACIA used by the Atari, the 6850B, can only be set to three divider modes, namely, by 1, 16, and 64. For MIDI, it is set to divide by 16 given its input clock of 500KHz. However, to set it to work in the divide by 1, ie. 500KHz, the received clock and data MUST be synchronized externally, for which the Atari ST has no provisions. So, it is not possible to run the MIDI port at 500KHz unless some additional hardware is added. Erasmo. P.S.: The hardware needed is trivial, but you would have to tinker with your soldering iron. :-)
wes@obie.UUCP (Barnacle Wes) (11/02/88)
In article <1584@netmbx.UUCP>, hase@netmbx.UUCP (Hartmut Semken) writes: > Are you sure, the 6850 used will operate at tht speed? > And the MIDI output driver (transistor) and the MIDI input circurit > (optokoppler)? > and think about the interrupt priority: less than everything else... It's a conspiracy: Atari does not *want* us to use the MIDI port at any speed other than MIDI speed. Imagine that. > The MIDI ports may be used for a little "network" just for email and > little messages, but file server functions over a token ring MIDI > network are nonsens. Yah. File transfer isn't too gawd-awful, but I'd sure hate to load a BIG program, like Timework's DTP, off of such a network. Once again, the holy grail slips away into the mist. Maybe the parallel port - anyone got an electronic engineer laying around they can loan me for a year or two? :-) :-) -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." - Bertrand Russell "How come he didn't put `I think' at the end of it?" - James P. Hogan