UCBVAX:@sri-unix (09/08/82)
Date-Sent: Thu Aug 26 11:26:17 1982 To: uok!duke!decvax!ucbvax!dan at Mit-Ml Cc: bsteve, mwm, uok!duke!decvax!ucbvax!info-micro at BRL Via: Ucb-C70; 7 Sep 82 20:51-EDT Via: Brl; 7 Sep 82 20:58-EDT Via: Brl-Bmd; 7 Sep 82 21:07-EDT Via: Brl; 7 Sep 82 21:47-PDT Dan, More gotchas in trying to port OS-9 to a system using the FDC-2 that you might be interested in-- The 6809 doesn't know from vectored interrupts. The interrupt handler in OS-9 recognizes this, and goes through its very own list (in priority order) of devices to see which one (or perhaps ones) caused the interrupt. It does this by reading from the device's status port, masking out extraneous stuff, and exclusive or-ing a value with the result (so that bits being off can show that the device is doing something as well as bits being on). If the result is non-zero, it invokes a routine that does the appropriate thing for the device. WELL...this is based on an assumption, reasonable or not, about how devices work. Unfortunately, the NEC uPD765 violates that assumption. Unless you're running in programmed data transfer mode, it simply interrupts. To find out what happened/whether it was the FDC that caused the interrupt, you have to ship bytes to the FDC to issue a Sense Interrupt Status command and wait for the results. Depending on how the kernel's interrupt handler works, it may still be possible to get the thing to work. I can set up the mask and flip bytes so that the FDC *always* claims that it caused the interrupt, so that every single interrupt from ANY device whatsoever may require that I send out a Sense Interrupt Status command. (After all, the possibility of simultaneous interrupts might imply that it has to go through the whole list to make sure it caught everybody.) This is truly obnoxious . I suppose that the designers of the chip/board were working on the assumption that vectoring interrupts would always disambiguate (let no one tell you that the S-100 bus isn't designed around the 8080 and its descendants), but NEC's hiding of interrupt information may make the system run extremely slowly. This piece of design, combined with Ithaca's grounding the NEC chip's Terminal Count pin (so that you can't abort FDC commands, and you have to cause ALL i/o to appear to terminate abnormally to get it to terminate at all) and the outrageous amount of redundant information you have to feed the uPD765 with every single command is pushing me closer to considering the FDC-2 a VERY expensive paperweight. James Jones (...!duke!uok!uokvax!jejones)