root@beldar.UUCP (05/15/87)
[] I wish it weren't true, but: The VD0: driver (asdg-rrd) Disable()s interupts for periods of time >= 600 microseconds!!! When it is IDLE, no less! Why is this obnoxious? Try servicing 31.25KB serial interupts at ~300 mikes each (i.e. MIDI rates) under these circumstances; it can't be done! VD0: is a MIDI killer... aaarrrggggh! And now the story. I recently bought a MicroBiotics Starboard II with a meg in it, and was delighted. Also I installed the ASDG RRD from Fred Fish 58, and was even more delighted until my MIDI software failed to work. Since I wrote it, it was easy to discover that the problem was due to data overruns on input. That's funny, it's been running fine for months now, how come it died? Well, could it be the StarBoard? Go back to 1.1, don't addmem, everything is peachy. Do the addmem, all is still copacetic. Hmmm. Try 1.2, sans RRD. That works. Now I smell a rat. Install VD0: - instant death. Ergo... VD0: is diseased. Notice that nothing else was running during any of these tests; VD0: sucks up time at priority 7 even when it is idle! Lest you doubt my veracity, the interupt routine I wrote for MIDI input is only ~25 instructions long (VERY tight assembler), never Disable()s, checks for additional input that showed up during servicing, and has worked fine for quite a while now. Anyone care to mail me a copy of someone else's PD recoverable ram disk? Or supply some penicillin to cure my VD: ? ---- Chris Anderson Xyvision, Inc. UUCP: ...!mirror!beldar!chris
walton@tybalt.caltech.edu.UUCP (05/17/87)
In article <30000006@beldar> root@beldar.UUCP writes: > >I wish it weren't true, but: > > The VD0: driver (asdg-rrd) Disable()s interupts for periods > of time >= 600 microseconds!!! When it is IDLE, no less! > It isn't true. I just saw Perry Kivilowitz at the LA Amiga show, and mentioned this posting. He categorically denies that there are any Disable() calls in the ASDG-RRD. There are Forbid()'s, but no Disable()'s. I suggest you call ASDG about your problem. >---- Chris Anderson > Xyvision, Inc. > UUCP: ...!mirror!beldar!chris Steve Walton, guest as walton@tybalt.caltech.edu AMETEK Computer Research Division, ametek!walton@csvax.caltech.edu "Long signatures are definitely frowned upon"--USENET posting rules