lepreau (08/13/82)
Not too surprisingly it turns out that Able is right and the v7 driver is wrong. The following was found by others here and Ken O himself, who stopped by while I was at Sigplan. Now that's not bad, when the president of the peripherals company drops by to help you debug your drivers! (No this is not a paid advt and he's not giving us free boards...) According to the DM11 specs in the 1976 DEC peripherals handbook (the last decent one) "The LINE register must not be changed until BUSY is cleared.... [BUSY] is set when Scan is cycling, Reset at end of Clear Scan or Init.... Must be tested for 0 before changing the registers." Well, the 4.1 driver is ok but the v7 and 2bsd ones are not. Here are the changes to the v7 dhdm.c: Add this line: + #define DMBUSY 020 And these 3 lines go right before each spot the line reg is set, i.e. before: addr->dmcsr = d&017; to get: + addr->dmcsr &= ~SCENABL; + while (addr->dmcsr & DMBUSY) + ; addr->dmcsr = d&017; There are 3 such places, 2 in dmopen and 1 in dmctl. -Jay Lepreau, lepreau@utah-20, harpo!utah-cs!lepreau
dmmartindale (08/17/82)
I will venture a guess that the delay wasn't really necessary on PDP-11's running DEC DH's since the scanner is hardware and probably stops pretty fast. So the driver didn't bother waiting even though the manual says you should. Then Able brings out something which meets the specs, but is perhaps a little slower because it's actually a processor (or maybe it's just that the VAX is too much faster than an 11) and the driver breaks. There's too much code like this still sitting around, and I have to complement the Berkeley folks for cleaning up some of the holes. Dave Martindale
thomas (08/20/82)
We first noticed the DH bug on a PDP 11/40 (running RSX, of all things) which is the front end for our DEC-20. The VAX code was always correct. Rumor has it that the new DEC DHs have the same 'problem'. =Spencer