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.
glenne@hpnmdla.HP.COM (Glenn Elmore) (10/14/88)
I have recently uploaded a version of the KA9Q TCP/IP package to netlib@lakesys.UUCP. The package is one I run at home for networking my ST on amateur radio TCP/IP through a modem to my radio. It does have a MIDI driver on it also though which can be used to support another link. The package supports Telnet, SMTP and FTP as well as some amateur radio specific operation. Full source code as well as binaries and documentation are also at lakesys. I have no doubt that this package as it stands will support networking of multiple ST as well as mixed systems (I routinely do file transfers, telnet sessions and electronic mailing with Macintoshes and PCs located in the greater SF Bay area). Glenn Elmore -N6GN- N6GN @ N6IIU-1 glenn@n6gn.norcal.ampr glenne@hpnmd.hp.com
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 *)david@bdt.UUCP (David Beckemeyer) (10/18/88)
I have done several consulting jobs where clients have requested
MIDI networking. While I was able to achieve reasonable performance
for a transaction network, where relatively little data is transferred,
the performance of a Remote Call Procedure file system implementation
was so slow as to make MIDI practically unusable for this purpose.
For UUCP connections it would be as reasonable and as useful as any
other 9600+ bps UUCP connection. We have developed a UUCP that runs
under MT C-Shell, and many customers are using MIDI for local UUCP
connections between STs.
There are two problems with MIDI as a true LAN. First the raw rate of
34 Kbit is ten times slower than a floppy drive. Second the ST MIDI
hardware cannot sustain continuous 34 Kbit/s transfer, so the data must
be error corrected (especially if it's mounted as a read/write file
system), giving you an effective data rate far below the 34 Kbit/s level.
In real life, a point-to-point MIDI connection, after adding in the
error detection protocol overhead and retransmissions due to lost
MIDI interrupts (the MIDI interrupt priority is lower than other ST
interrupts, so some get lost), gives you an effective data rate of only
about 10 Kbps.
You can get higher rates using the RS-232 at 19.2 Kbaud or, even better,
using the syncronous mode of the ST serial port we have achieved rates
comparable to a floppy disk. Another place to look is the bi-directional
parrallel (printer) port on the ST. It is nearly as fast as a hard
disk, but it is CPU intensive (no DMA), so it isn't too good for
multiuser applications, but might work for a dedicated server.
--
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, AZapratt@atari.UUCP (Allan Pratt) (10/19/88)
In article <404@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes: > In real life, [...] an effective data rate of only > about 10 Kbps. > > using the syncronous mode of the ST serial port we have achieved rates > comparable to a floppy disk. Another place to look is the bi-directional > parrallel (printer) port on the ST. I changed Bammi@mandrill's Zmodem so it used Midi (Bios device 3 rather than 1: easy change) and got nearly 20 K/s, and when I took out the BIOS trap overhead in the main packet-transfer routines (using PERFECTLY LEGAL, PUBLISHED INFORMATION), I am getting 22-23 K/s. Of course, I am not moving the mouse while the transfer is going on... If I did, the throughput would indeed fall down. The other two places (synch mode and parallel) are indeed interesting places! I hope this starts a flurry of activity in this area. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
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
brett@sylvester (Brett S Bourbin) (11/10/88)
Is there any source code in the public domain to do MIDI networking for the ST? I want to set up a very simple MIDI ring, where only a few bytes will be passed at a time, with a maximum of 16 machines in the ring. Thanks for any information you can pass on. - Brett __ __ _ __ _ | || | / || || \ Brett S Bourbin | || || || || | INTERNET: brett@SYLVESTER.UMD.EDU | || || || || | \_||_/ |__||__||__| Instructional Computing Programs College Park
hedger@inmet (11/11/88)
Try getting in touch with someone at Hybrid Arts.....they wrote a game called MIDI kill or something like that where you connected machines through the midi ports and killed smiley faces.....anyway they might be of some help. **************************************************************** * Keith Hedger hedger@inmet.inmet.com * * Intermetrics inc. uunet!inmet!hedger * * 'flipper suffered for their music....now it's your turn' * ****************************************************************
Jan@cup.portal.com (Martha L Dycus) (11/14/88)
Are you thinking of Midi Maze? It sounds like it.
brett@umd5.umd.edu (Brett Bourbin) (04/29/89)
Does anyone have any source code to do MIDI networking on the ST? I am looking for source to some sort of ring network system for MIDI linked applications. Thanks in advance. --Brett S Bourbin __ __ _ __ _ Instructional Computing Programs -- Univ. of Maryland | || | / || || \ | || || || || | INTERNET: brett@rover.umd.edu or brett@umd5.umd.edu | || || || || | DELPHI: brettb BIX: brettb BITNET: brett@UMDD \_||_/ |__||__||__| College Park Computer Science Center, College Park, MD 20742
glenne@hpnmdla.HP.COM (Glenn Elmore) (05/01/89)
You might try the KA9Q TCP/IP package. The most recent release, 4-21-89, compiles under MWC 3.0. I don't know for sure that the MIDI driver which was in earlier releases is still present, but source code for the earlier driver is available. See rec.ham-radio.packet or louie.udel.edu as likely places for code and further information. Glenn Elmore -N6GN- N6GN @ K3MC glenn@n6gn.norcal.ampr.org glenne@hpnmd.hp.com
hyc@math.lsa.umich.edu (Howard Chu) (05/03/89)
In article <810009@hpnmdla.HP.COM> glenne@hpnmdla.HP.COM (Glenn Elmore) writes: > > You might try the KA9Q TCP/IP package. The most recent release, 4-21-89, >compiles under MWC 3.0. I don't know for sure that the MIDI driver which was >in earlier releases is still present, but source code for the earlier driver >is available. The MIDI "driver" in KA9Q merely uses the BIOS functions for reading and writing the MIDI port, same as it does for the serial port. I don't think that would be much use for OS9. However, this makes an interesting point - the MIDI port *is* just a serial port, really, controlled thru a 6850 ACIA. The keyboard is also accessed thru a 6850. Assuming your keybord driver works, that'd be the best place to start looking for code to drive the MIDI port... -- -=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1] and You Too can have a Personal Electronic Relationship with God!
EHARNDEN@AUVM.BITNET (Eric Harnden) (05/05/89)
that's an odd question. midi is sort of inherently networked. anybody in the loop can talk to anybody else, assuming they have anything valid to say to each other. and why a ring? the standard midi network configuration is a star (which my partner insists i refer to as a buss), and is implemented by a midi patcher. what purposes are here? that would help clear this up a little. in brief answer... no. i've never heard of any explicit midi networking software. several people are working on what might be called 'studio handlers', that up/download and distribute multiple files with a single 'snapshot' command, but that's sort of it. Eric Harnden (Ronin) <EHARNDEN@AUVM> The American University Physics Dept. (202) 885-2758
hyc@math.lsa.umich.edu (Howard Chu) (05/05/89)
The ST version of KA9Q allows use of the MIDI port... You could connect a bunch of STs together that way, I suppose. To get out onto a "real" net you could use a PC with both SLIP and ethernet as a router. If you really want speed, you can use the ST's bidirectional parallel port for ST to ST connection, although you can only connect two machines that way. I guess MIDI is the only way to chain a bunch of machines together. (Well... You could go ST - parallel - ST - rs232 - ST - parallel etc...) The current ST version only does asynch rs232, but you could probably add support for synchronous mode... TOS should be able to handle 38400bps without dropping characters, you can program the timers for 61440bps, but then you'd probably have to rewrite the rs232 interrupt handlers. I'll probably add 38400 for the upcoming ST KA9Q release. -- -=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1] and You Too can have a Personal Electronic Relationship with God!
kbad@atari.UUCP (Ken Badertscher) (05/06/89)
There was a company at the World of Atari show in Anaheim last month who were showing a working MIDI network. I spoke with one of the developers, but I can't for the life of me remember his name or the name of his company! (sorry...) But there *is* a midi network out there, and it does work. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>
I0908@DKAFHS1.BITNET (05/08/89)
Date: 08 May 1989, 10:34:20 SET From: Cornelius Caesar BITNET / EARN: I0908 at DKAFHS1 To: info-atari16 at score.stanford.edu I have a friend working for the company DM Computer GmbH, Pforzheim, West Germany. They sell a network using a glas fiber cable with an opto-coupler hooked to the midi port. The network is of the master/slave type and works. They are currently developing a much faster network which goes through the ROM port. Prices are outside the hobby market: about DM 1500,- (i.e. $ 800) for a configuration with master, 2 slaves, cables and software if I recall it correctly. I can ask him for additional infos if necessary. Cornelius Caesar Karlsruhe, West Germany