It depends on what you mean by 'work'. If you mean 'ODT does not operate correctly', or 'the CPU won't run', I can assure you that neither of those is correct. Here is a recorded log from a session earlier today on a system here next to my desktop: it contains a KDF11-A (in slot 1Left of a Q-Q backplane) and a console DLV11-J (in slot 1Right), and no other cards: ^@^@ 000000 @777560/000000 @777564/000000 777566/000000 777570/? @777640/177777 777 @/000777 @777640G Cmd: 177640 @^@^@ As you can see, ODT is working,and the console registers are all responding OK. The thing at the bottom is that hack of putting a small program in the PARs (UIPAR0, in this case). The "Cmd:" prompt is where I told my console program to send a 'break' down the serial line to the -11, stopping the CPU. (The 'run' light had been on, after the "777640G".) (Note: The PAR hack doesn't work in J-11 CPUs; they won't do instruction fetches from PARs.) To confirm that I'm not BSing you, can someone else on the list please do this on their KDF11-A, and confirm that it produces the results I show about? Thanks. If that's with just a non-LSI11 CPU card and the console serial line, the machine has a problem. As you can see above (the "777560/", etc were my type-in), you should be able to talk to ODT on a KDF11 (and I tried a KDJ11 yesterday, it worked too). (I don't recall if the LSI-11 types _anything_ when started with no working memory at 0; if anyone wants to know, I can fairly easily try it, I have a bunch of working LDI-11's, both quad and dual cards). Noel