ag@floyd.ATT.COM (11/23/88)
Hi, y'all,
I have built a MIDI interface for my CoCo 3. The hardware seems to
work fine. Now I would like to try to write a stripped-down version
of the ACIA driver, so that the driver will keep up with the
31,250 baud rate. One question I can't seem to find the answer
to is how OS-9 handles interrupts. In the OS-9 manual, it mentions that
with the multipak interface, there are no real IRQ interrupts available,
just this pseudo-interrupt, VIRQ. The problem with VIRQ is that the fastest
I will be able to read MIDI bytes is once every 1/60 sec. Since MIDI data
can be available as fast as every 1/3125 seconds (1 start, 8 data, 1 stop),
I will definitely lose charaters.
I can connect the 6551 IRQ line to CART, but does OS-9 use the CART signal
at all? Can it be told to use the CART signal as an interrupt source by
setting some values in the GIME chip (around 0xFFA2, I believe)? If these
are all impossible, then should I hardwire the 6551 IRQ line directly to
the 6809 IRQ input?
Another similar question: Since the multipak interface switches only
CTS, SCS, and CART, how does a system with 2 RS-232 paks or 2 DC Modems
operate? Neither of these paks use the SCS signal for their enable.
How does OS-9 tell them apart (using /T1 and /T2, or /M1 and /M2)? And
how does the multipak keep from dual-sourcing the bus when trying to
read either one, since they are at the same address space?
So many questions, so little money....
Happy Turkey Day!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
________
/_______/| __________________________
| ||----->/ / Ag Primatic
| ||<----/_________________________/ ag@floyd.ATT.com
|_______|/ / / / / / / / / / / /
/oooooooo/ /_________________________/
/oooooooo/
---------
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=knudsen@ihlpl.ATT.COM (Knudsen) (11/29/88)
Congratulations, Ag! Now have you tried any freeware music editors on the beat (hint, hint)? Technically your drivers are not restricted to the VIRQ polling interrupt. After all, the ACIA driver(s) use interrupts directly. However, the MPI (actually the GIME's attempt to force all peripherals into a narrow band of addresses) forces some restrictions that are gradually becoming clear thru discoussions on these nets and mail lists. A fundamental requirement of OS9's interupt server is that the device's status register must be readable when the interrupt comes in. So if your MPI slot is switched to slot 3 and a pak in slot 4 throws an interrupt, the "whodunit" polling in the interrupt server can't see pak 4's device; instead, it may read slot 3's. (This is why Sardis and Burke & Burke don't get along). Also why the MPI only accepts interrupts from the CTS-enabled slot, so only the "currently active" device's interrupts will get thru. If you hotwire all 4 slots' IRQs together, you lose this protection, tho in practice the protection was no use anyway. As for running several serial devices at same address, this would require some fancy selective enabling of interrupts in the ACIA chips, and even then I don't see how two chips could co-exist at the same address AND slot. Ag, as far as recording MIDI performance under OS9, I think you'd have to block all interrupts (orcc #$55 in assembler) and run "raw RSDOS mode" during the performance, running sofware timing loop and just writing received bytes into memory (well you could take the time to parse them). Monitor the Coco keyboard for a keypress to break out of the loop. All multi-tasking and system clock stop during recording, just as with floppy disk accesses only longer. If you don't like locking up your system for minutes at a time, someone suggested to me to buy an outboard hardware MIDI sequencer, play your piece into that, then mass-dump it (in a few seconds) into the Coco for editing, etc. Reverse should work well too, tho not necessary, as I hope you know from UltiMusE. -- Mike Knudsen Bell Labs(AT&T) att!ihlpl!knudsen "Lawyers are like nuclear bombs and PClones. Nobody likes them, but the other guy's got one, so I better get one too."
ag@floyd.ATT.COM (11/29/88)
Hi Mike: > Congratulations, Ag! Now have you tried any freeware music > editors on the beat (hint, hint)? Jeez, you're persistant! Actually, NOW I need to know if the 6551 UART is what you assume for UltiMusE, and if the address of your MIDI interface matches the address of the RS-232 PAK! (I expect a negative answer to at least one of these questions!) > Technically your drivers are not restricted to the VIRQ > polling interrupt. After all, the ACIA driver(s) use interrupts > directly. I read in the OS-9 manual that any MultiPak device has to use the VIRQ interrupt. I'm not too sure, but I think I read that once the VIRQ service routine finds the interrupt, it passes control to the IRQ service routine. The problem is that a VIRQ interrupt can only be sampled once every clock tick at its maximum speed, which is way too slow for MIDI. > However, the MPI (actually the GIME's attempt to force all > peripherals into a narrow band of addresses) forces some > restrictions that are gradually becoming clear thru discoussions > on these nets and mail lists. A fundamental requirement of > OS9's interupt server is that the device's status register > must be readable when the interrupt comes in. OK, I agree with that. > So if your MPI slot is switched to slot 3 and a pak in slot 4 > throws an interrupt, the "whodunit" polling in the interrupt server > can't see pak 4's device; instead, it may read slot 3's. > (This is why Sardis and Burke & Burke don't get along). If the device directly decodes the address without using CTS or SCS, then it doesn't matter which slot is selected; any address can be read. This is how my (modified RS-232 Pak) MIDI interface works. > Also why the MPI only accepts interrupts from the CTS-enabled > slot, so only the "currently active" device's interrupts will > get thru. If you hotwire all 4 slots' IRQs together, you > lose this protection, tho in practice the protection > was no use anyway. I see what the problem is with the current set-up. However, I don't know if hot-wiring the IRQs (you mean CARTs, right?) will solve the problem. The GIME chip must have CART selected as an interrupt source, and I don't know if this is true under OS9. > As for running several serial devices at same address, > this would require some fancy selective enabling of interrupts > in the ACIA chips, and even then I don't see how two chips could > co-exist at the same address AND slot. I don't WANT to run more than one device at the same address. I was just wondering how OS9 can support two RS-232 Paks or 2 ModemPaks at the same time without any conflict. > Ag, as far as recording MIDI performance under OS9, I think > you'd have to block all interrupts (orcc #$55 in assembler) > and run "raw RSDOS mode" during the performance, running sofware > timing loop and just writing received bytes into memory > (well you could take the time to parse them). > Monitor the Coco keyboard for a keypress to break out of the loop. > All multi-tasking and system clock stop during recording, > just as with floppy disk accesses only longer. What about time-stamping the data as it arrives (in the interrupt routine)? Regardless of what process is currently running, the interrupt routine will get called every time a MIDI byte arrives. The current time can be read and stored along with the MIDI byte. Then, upon playback, the stored time could be compared with the elapsed time, and the MIDI byte could be sent out at the right moment. I think this could be done using the CoCo 3's built-in timer to generate an interrupt when it is time to send a note. In this way, you could keep everything running, and STILL use MIDI send and receive! > If you don't like locking up your system for minutes at a time, > someone suggested to me to buy an outboard hardware MIDI sequencer, > play your piece into that, then mass-dump it (in a few seconds) > into the Coco for editing, etc. Reverse should work well too, > tho not necessary, as I hope you know from UltiMusE. Sounds like a lot of extra hardware. I think I'll play with the CoCo a little bit more.... > -- > Mike Knudsen Bell Labs(AT&T) att!ihlpl!knudsen -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ________ /_______/| __________________________ | ||----->/ / Ag Primatic | ||<----/_________________________/ ag@floyd.ATT.com |_______|/ / / / / / / / / / / / /oooooooo/ /_________________________/ /oooooooo/ --------- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
pete@wlbr.EATON.COM (Pete Lyall) (12/01/88)
Re: coco 3, OS9 LII, and MIDI -
Kent Meyers and I attempted to adapt an existing 6850 ACIA driver to
work with the COCO MIDI 2 pak (a 6850 UART - I forget the address, but
*think* it's $FF60 or $FF66). It works, but *not* for steady stream
data, as you would likely want for handling a sequencer's type of
operations.
Two basic but mortal problems:
a) The F$move call which is used extensively in the system blocks
interrupts. It moves 64 bytes at a whack, then lets interrupts in. It
continues this cycle until all bytes are moved from the source to
destination memory maps. We tried reducing the number of bytes moved
to as low as 8. This helps, but didn't prevent data loss.
b) The screen scroll routines lock interrupts as well. These are more
severe, and can block for up to 500-600 microsends. Ouch. No easy
solution here unless you suspend screen I/O while recording, or
something similar.
Pete
--
Pete Lyall (OS9 Users Group VP)| DELPHI: OS9UGVP | Eaton Corp.(818)-706-5693
Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)
Internet: pete@wlbr.eaton.com UUCP: {hacgate,jplgodo,voder}!wlbr!pete knudsen@ihlpl.ATT.COM (Knudsen) (12/02/88)
In article <24727@wlbr.EATON.COM>, pete@wlbr.EATON.COM (Pete Lyall) writes: > Kent Meyers and I attempted to adapt an existing 6850 ACIA driver to > work with the COCO MIDI 2 pak (a 6850 UART - I forget the address, but > *think* it's $FF60 or $FF66). It works, but *not* for steady stream The correct address is $FF6E (contro/status) and $FF6F for data. Intercomp Sound's interface pak also uses this address so as to be compatible with all software, and I suggested to Ag that he put his there also. Unforch'ly he uses a 6551. >[discussion of how/when OS9 system blocks interrupts] Well, Pete, it looks like the only way we can record MIDI is to block interrupts ourselves, solid for the duration of the recording, and use our own timing loops to keep time. Alternately, add a FIFO buffer and self-timing counter to the interface a la MPU-401. Burke & Burke are coming out with a clone of this well-known interface and and adapter and driver for it. Funny, isn't it -- the more sophisticated your software (OS9), the more hardware you need to do the same job. (Or is it just overcoming some hardware (MPI, GIME) whose contribution is sometimes negative....?) --mike k -- Mike Knudsen Bell Labs(AT&T) att!ihlpl!knudsen "Lawyers are like nuclear bombs and PClones. Nobody likes them, but the other guy's got one, so I better get one too."