EMUSIC-L Digest Volume 28, Number 4 This issue's topics: MIDI crystals (is this new age?) (8 messages) Your EMUSIC-D moderator is Joe McMahon. Please send articles to emusic-L@auvm.american.edu (or EMUSIC-L@AUVM.BITNET). Administrative mail should be directed to xrjdm@scfvm.nasa.gov. Digests will be distributed semi-monthly to monthly. For faster response to questions, subscribe to EMUSIC-L@AUVM.BITNET (or emusic-l@auvm.american.edu). The EMUSIC-L discussion group can alo be accessed via bit.listserv.emusic-l on Usenet. Subscribers to this list may send articles to EMUSIC-D@AUVM.BITNET (or emusic-d@auvm.american.edu); they will be reviewed and forwarded to EMUSIC-L. Back issues are available from xrjdm@scfvm.gsfc.nasa.gov. This is a manual operation, so requests for things like "all back issues" will take a long time. ------------------------------ Date: Tue, 7 May 91 14:04:38 BST From: "Benjamin M. J. Ellis :->" Subject: Re: Crystals and MIDI (hay is this new age 8-)? Basically: ARRRRRGGG!!! Sorry, it must be exam time! Anyway... About all this baud rate and stuff: Metlay is basically right, 32.25KBaud was chosen because it is a microprocessor clock multiple (ie: 31.25K * x = 1M, 2M, 4M etc...) There are a load of very fluffy stories going around about the MIDI baud rate, but what is boils down to is this: MIDI was designed around RS-423 (sic.), first it had a baud rate of 19600 or something silly, which wasn'T fast enough, so they just up'ed it to a silly number, 31.25K happened to be that number. I've just finnished (another) report on the origins of MIDI bla bla bla, and really know one can give me a sensible answer as to why 31.25 was chosen (there are a few very good ones, but the thing is none of the major manufacturers can agree on one... shame, a bit of a waste of history really!). Anyway, one thing is for sure: IT NOTHING TO DO WITH TV CRYSTALS! TV crystals work at silly frequencies, 'cos of NTSC and other silly things like the number of lines per screen. Also note that most serial to paraller converter chips (UARTs etc) need a clcok frequency that is well above the baud rate, 'cos they same in the middle of bits, and any UART worth its weight in plastic does multi sampling and error checking, but that is a whole other (HUGE) topic... So... 31.25K was chosen 'cos, well, why not? and its a factor of xM, which is nice for using it with thing like: the 68HC11... oh and on last thing, the clock rate MUST be a multiple of the baud rate: You can't read MIDI with a 31KHz clock, no way hozay! Oh, for the records: my Bass Guitar to MIDI converter worked, so if anyone wants any help or advice about designing 68hc11 or 68000 based MIDI processors, let me know, I'm gonna start working on a sax controller in the autumn! -Benjamin An Englishman in England... ------------------------------ Date: Thu, 9 May 91 19:13:17 PDT From: "Michael R. Kesti" Subject: Re: Crystals and MIDI (hay is this new age 8-)? >Metlay is basically right, 32.25KBaud was chosen because it is a >microprocessor clock multiple (ie: 31.25K * x = 1M, 2M, 4M etc...) I find this to be creative use of terminology (in other words, I have no idea what is meant)! 8-) >So... 31.25K was chosen 'cos, well, why not? Well, either there is a reason, or there isn't. In fact, there is a reason, and it's rediculously simple. Say you want to use a readily available (read cheap!) crystal for for CPU's clock generator, like 4.00 MHz. This is a nice value, as lots of crystal makers offer this frequency, and it's an appropriate frequency for the kind of CPU's that are to be used in MIDI gear. Now, to generate a bit rate, we'll have to divide this down, ususally in a divider string provided by the UART itself. We'd like to use round numbers for this divider (at least in must be an integer, and preferably a power of two) so let's try 128. 4,000,000 / 128 = 31250 This looks good, as it is a rate most UARTs can handle, and uses cheap parts. If we wanted to use a "standard" rate like 38400, we'd need a divider of: 4,000,000 / 38400 = 104.166... This is not so pleasant a number, being neither an integer, nor a power of two. What's more, the nearest integers result in deviations from nominal that exceed tolerances. If we truely want to use 38400, an oddball (read more expensive) crystal must be used. The designers of MIDI chose to allow the use of the cheaper crystal (which results in less expensive gear) rather than go for compatibility with commonly used RS232 bit rates. Engineering is chock full of these kinds of decisions; all systems represent design compromises. At the time it probably looked like a good tradeoff. In retrospect, the use of 38400 would have made RS232 to MIDI converters a piece of cake, and may have been the better way to go. Remember though, that when MIDI was designed, not many computer systems could reliably do 38400 (and they saw that 19200 was just too slow), so compatibility was pretty much a moot point! I hope this helps to clear up MIDI's "mystery" rate. ============================================================================ Michael Kesti Grass Valley Group, Inc. | "And like, one and one don't make mrk@gvgspd.GVG.TEK.COM | two, one and one make one." !tektronix!gvgpsa!gvgspd!mrk | - The Who, Bargain ========================================================================= ------------------------------ Date: Fri, 10 May 91 09:15:27 BST From: "Benjamin M. J. Ellis :->" Subject: Re: MIDI crystals (is this new age?) *Micheal R. Kesti writes: *>Benjamin MJ Ellis writes: *>Metlay is basically right, 32.25KBaud was chosen because it is a *>microprocessor clock multiple (ie: 31.25K * x = 1M, 2M, 4M etc...) * *I find this to be creative use of terminology (in other words, I have no *idea what is meant)! 8-) Okay, its simple really, 31.25 Kilobps is a factor of 2M, 4M, etc as you say bellow: * *>So... 31.25K was chosen 'cos, well, why not? * *Well, either there is a reason, or there isn't. In fact, there is a reason, Ah... sorry problem here: *and it's rediculously simple. Say you want to use a readily available (read *cheap!) crystal for for CPU's clock generator, like 4.00 MHz. This is a *nice value, as lots of crystal makers offer this frequency, and it's an *appropriate frequency for the kind of CPU's that are to be used in MIDI *gear. Now, to generate a bit rate, we'll have to divide this down, ususally *in a divider string provided by the UART itself. We'd like to use round *numbers for this divider (at least in must be an integer, and preferably a *power of two) so let's try 128. * * 4,000,000 / 128 = 31250 * Cool yeah, but why not use 62.5Kbps??? Its faster, is a /64, which is easier to derive, requires less logic... Okay... 62.5Kbps to fast... why not use 15.625Kbps??? You seen, 31.250 is really arbitraty, is not a physical constraint, (62.5Kbps would have worked just as well, still within the limits of the opto isolators at the time)... its just really ODD! *This looks good, as it is a rate most UARTs can handle, and uses cheap parts. *If we wanted to use a "standard" rate like 38400, we'd need a divider of: * * 4,000,000 / 38400 = 104.166... * Now THAT is nutty 8-) *This is not so pleasant a number, being neither an integer, nor a power of * ...Engineering *is chock full of these kinds of decisions; all systems represent design *compromises. *38400 (and they saw that 19200 was just too slow), so compatibility was *pretty much a moot point! It took them a while to realise 19.2 was too slow... we were || that far from a 19.2 MIDI system... lucky escape huh? 8-] *I hope this helps to clear up MIDI's "mystery" rate. Ah, the plot thickens! -Benjamin UKC England. ------------------------------ Date: Fri, 10 May 91 09:58:00 EDT From: "William R(ay) Brohinsky" Subject: Re: MIDI crystals (is this new age?) In a way, we were doubly lucky. The question of `why not 62.5Kbaud' can be answered by the prevalence of 1Mhz microcontrollers. They may be able to `talk' at 2400 baud, using an external UART or something, but they don't talk at a 2400baud rate. (enough slower in some instruments [electronic measuring equipment, not musical] to really frustrate a PC with a 25Mhz clock!) A 1Mhz clock on a 6502 meant that most operations could be done in one or two cycles (nice pipelining, but still primitive in those days.) The Z80, with 4-cycle instructions, going one per clock, was slower in some ways. (Note that the 8080 family tended to higher starting clock frequencies, but the actual machine cycle that did the job was quite slow, 8 or 16 times slower in some cases, depending on the clock generator chip). If a program could be built out of only one or two byte instructions, you could actually see 500kinst-700kinst operation speeds. With three or more CPU cycle instructions (and most programs that are non-trivial, like what's needed in a synth will have a predominance of 3-byte instructions) you'll see around 350Kinst/second. When you consider that each byte at 31.25Kbaud (acknowledging that baud infers each bit, including stop and start bits, so the chars come at 3125 times per second, that leaves 320 microseconds between characters. Since some microseconds are eaten just by loading that character (byte, actually) into a register, you are not left with a high percentage of time for processing on it. In some ways, it may be better because, by the time the whole event is in, you've had all that time to process the last one with only the time necessary to load up the parts of the next one to slow you down. But this means that you won't get this event's action until the next one is mostly in, which means a latentcy in addition to the transient times of optoisolators, and other delays... Using 62.5Kbaud would cut the total time down to 160microsec between the initiation of each new input. We were lucky- this would have effected the total amount of time available for processing, overloading the processors with byte-shuffling! And you think MIDI's too slow? In actual fact, MIDI is now slow because we put so much on it. But if they had settled on a higher speed THEN, when the technology was so slow, we might not be able to use MIDI for one channel well! Then where would we be now? Well, the advent of the 2Mhz microprocessor would have been a big selling point, rather than an unhailed development. We'd now be seeing instruments with 16- and 32- bit processors running at elevated Mhz speed, just to keep the byte transfer from eating up too much _percentage_ of processing time. We'd all have garages full of obsolescent leading-edge technology that was useless at the time, and still is. Or, more likely, we'd all be playing analog. raybro . ------------------------------ Date: Fri, 10 May 91 11:58:00 EDT From: greg@IHLPM.ATT.COM Subject: Re: MIDI crystals (is this new age?) For some strange unexplained reason I feel an urge to submit some comments on Raybro's last posting... > The question of `why not 62.5Kbaud' can be answered by the prevalence of > 1Mhz microcontrollers. They may be able to `talk' at 2400 baud, using > an external UART or something, but they don't talk at a 2400baud > rate. (enough slower in some instruments [electronic measuring equipment, > not musical] to really frustrate a PC with a 25Mhz clock!) By this I assume you mean that while the bits of any given byte fly down the wire at the rates specified for 2400 baud, the micro isn't handing the UART (internal or external - it shouldn't make much difference) another byte until well after it has finished transmitting the previous one. This would result in delays from one byte to the next. However, if the UART is able to interrupt the processor it shouldn't be a problem for even a slow micro to maintain a 2400 baud link at near 100% line occupancy. 2400 baud means over 4 milliseconds per byte, relatively lethargic compared to MIDI's 320 microseconds per byte. I would guess that your "electronic measuring equipment" is not using a UART, but instead has a subroutine that clocks out bytes through a bit in a parallel port that is connected to an RS-232 line driver. When a byte is to be sent the routine uses delay loops and such to flip the bit on and off as specified by the ones and zeros in the byte, timed according to the baud rate. While the byte is being sent the processor is dedicated to the timing task. After the byte has gone out if the processor has any other real time tasks to attend to it runs off to do them, and then when it has another chance it pumps out the next byte. Depending on the real time demands of the application it could be a while before it gets around to that next byte. When you say that your 25 MHz PC is frustrated I assume that either the software is timing out or something and assuming that the measuring equipment has gone south, or that it calls a routine to gather data from the measuring equipment that waits for multiple bytes of data to come in and ignores any other activities (such as checking the keyboard or updating the screen or ???) until they are all there. This would cause delays in reacting to keyboard input, or erratic screen output (or something worse - like a nuclear meltdown :-) ). In any of these cases I would think that the software on the PC needs attention - there is no reason it shouldn't be able to deal cleanly with this equipment as long as the equipment is capable of providing the data it is responsible for in a timely enough manner. Having said all that I must agree that your point about a micro handling a byte every 160 microseconds (at 62.5 K baud), even when interrupt driven (and still having some real time left for other tasks) being a tall order is valid. Even at 31.25 K baud (MIDI's rate) a 1 MHz processor will be quite busy while data is coming in. If the 6502 needs 1 or two cycles per instruction it could execute between 160 and 320 instructions while each byte was coming in. If the interrupt routine could be coded in about 40 instructions (and that might be a little conservative considering error checking, and queueing of the incoming data), just handling the intrrupts would be consuming 1/8 to 1/4 of the processors cycles. 62.5 K baud would be a real squeeze. And one more point... > which means a latentcy in addition to the transient times of optoisolators, > and other delays... The optoisolator shouldn't be contributing any effect to the latency of MIDI data into the UART. The problem that optoisolators cause shows up when you try to stack several units on a MIDI bus using THRU ports. Much MIDI equipment with THRU ports simply passes the output of it's optoisolator to another MIDI driver circuit (saving the cost of another UART to support the THRU port, retiming the data and cleaning up the edges). The UART produces nice sharp rising and falling edges for each bit. The optoisolator's rise and fall times are not quite as fast and the rising and falling edges coming out of the optoisolator are now at somewhat of an angle. While this is no problem for a receiving UART to cope with after a single optoisolator, when several optoisolators are daisy chained via the "economy model" THRU ports the rising and falling edges deteriorate further at each optoisolator. Eventually the edges are so ragged that some unit's UART somewhere down the line can't extract the proper signal and begins getting framing or parity errors. Enuf said, -- Greg Youngdahl AT&T Bell Laboratories Naperville, IL att!ihlpm!greg ------------------------------ Date: Mon, 13 May 91 09:01:00 EDT From: "William R(ay) Brohinsky" Subject: Re: MIDI crystals (is this new age?) Greg Youngdahl's comments are well recieved, as they are all relevent and pretty much accurate. As far as our measuring equipment, it is actually (in this specific case) a linear-stage actuator that is interrupt-bound during transmission (we must check with it to see if it has `arrived', because it hunts on a sub- micron level for minutes after arriving `close enough for jazz' to its destination. Thus, even though it has the ability to talk at a normal rate, it tends to loose things coming in-the UART has no buffer other than that maintained in the processor's memory space, and fully serviced by the already-overloaded processor. Guys, this is not how to build real-time equipment! (not with a 1Mhz 6800, anyway!) The PC software does need work, but the work that's needed is on the part of Microsoft. More often than not, and with RS-232 equipment that `works' very well (say, with an amiga, or even a RADIO-SHACK Model100, fergoshsakes!) will bollix the PC's serial port. The worst kind of offender is the one that sends a spurious null-byte, or the occasional line-feed char. This causes the interrupt to be fired on the PC: `we have something here', but the software that does the interrupt says-there's nothing here! Then, it attempts to reset the interrupt line, but the uart says `you haven't got it all yet' and re-initiates interrupt. Result: locked up program, and (if the re-initiation is fast enough) stack overflow and need for a full re-boot!!! This has happened with BasicA, QuickBasic, and C5.1. I haven't gotten that brave with C6.0 yet (actually, I'm re-doing the whole system to remove that equipment, and any others that cause these symptoms!) My moral here is: Do not implement serial comms lightly! IF you send to a PC, ensure that what you output is exactly what your spec says it will. If you are writing a from-scratch serial handler for the PC end, ensure that it traps spurious input, and also times out and clears the hardware after a suitable period of apparent innaction. Anything else is near-criminal, and will lose you customers. (You can bet that NRC won't get another actuator-controller order from anyone here!!) raybro ------------------------------ Date: Mon, 13 May 91 11:50:00 CDT From: greg@IHLPM.ATT.COM Subject: Re: MIDI crystals (is this new age?) Raybro (and all), This is straying from the EMUSIC topic, but since we've come this far I thought that posting one more follow up wouldn't be out of line. This may actually be of interest to PC MIDI hackers, the rest of you may want to skip this... > The PC software does need work, but the work that's needed is on the part > of Microsoft. [ description of symptoms deleted... ] > This has happened with BasicA, QuickBasic, and C5.1. I haven't gotten > that brave with C6.0 yet (actually, I'm re-doing the whole system to > remove that equipment, and any others that cause these symptoms!) It is fairly well known that DOS's (PC-, MS-, ??) support for the serial port is little better than non-existent. It may be functional for some trivial applications, but any serious use of the PC's serial port requires bypassing the operating system's services. You will need to write your own interrupt handler (preferably in assembler), intercept the interrupt vector, do your own queuing and flow control, etc. If you are using BasicA, QuickBasic, C (any version), or I would guess just about any high level language, any support their "library" provides for serial I/O probably is just an interface to the DOS BIOS functions. I have both Microsoft C 5.1, and Borland Turbo C++, and neither of them offers any enhanced serial port support, at least as far as I can tell. I think that if they did they would proclaim it as loudly as they do their graphics libraries. There are companies that offer serial communication libraries that are compatible with most compilers. Judging by the color glossy information they inundate me with it must be a reasonably profitable business. Depending on your situation this may be an effective approach. If I were doing something like that for work I imagine that the cost of one of these packages would be less than the development cost for similar routines (unless they have some type of licensing policy that requires you to pay a royalty to them for each package shipped or something). Other situations would depend on funds (of course), time available, and the competence, confidence and interest of the developer. Interrupt routines offer, shall I say, interesting debugging challenges. [ ...Suggestions for proper serial port handling deleted... ] > Anything else is near-criminal, and will lose you customers. (You can bet > that NRC won't get another actuator-controller order from anyone here!!) > > raybro I have to ask for a clarification here. The only NRC I'm aware of (in my limited experience) is the Nuclear Regulatory Commission, and I doubt that they are in the business of selling actuator-controllers. What I was wondering was if you had transposed the R and C, and instead meant NCR which I would assume to be National Cash Register, the company that AT&T is spending billions for? I wouldn't be surprised to hear they have a branch that makes actuator-controllers. Can you expand your acronym? Perhaps you can appreciate my interest :-). I'll try to stick to EMUSIC after this. Sorry to have strayed (but then people who weren't interested probably didn't read far enough to see my apology - oh well). Later, -- Greg Youngdahl AT&T Bell Laboratories Naperville, IL att!ihlpm!greg ------------------------------ Date: Mon, 13 May 91 16:17:00 EDT From: "William R(ay) Brohinsky" Subject: Re: MIDI crystals (is this new age?) I am also sorry for the bandwidth wasted on this, but if you're trying to hack a MIDI interface to the serial port of a PC, it's probably not unwarrented warnings... NRC=Newport Research Corporation, makers of fine, overpriced optical mounts, and electronic systems that just don't work. This is, of course, since we are in competition with them (for electronic holography, which we do well (AIH) and ESPI, alias electronic speckle pattern interferometry, which they do badly. AIH, by the way == "Ain't I Humble 8^), but is also utterly fair, since we were one of their first linear-actuator customers, and have recieved limp service on lousey equipment. Thus, take my rantings with a grain of salt, unless you're in the market for Electronic Holographic Interferometry or linear actuators... raybro ------------------------------ End of the EMUSIC-L Digest ******************************