Restoring an Intel SDK-86 to "mostly like new" condition

On Mon, Oct 29, 2012 at 1:14 PM, Alexandre Souza - Listas <pu1bzz.listas at gmail.com> wrote: Did you/can you test your RAM? Do you have access to a system tester like a Fluke 9010A (with an 8086 pod, as well)? Not many folks have them, but if you do or can borrow one, they are nice for RAM tests, ROM test, bus tests, etc. I don't know anything about the D3625A PROMs, but one thing that might be handy is to make a pin-swabber socket. It's easy for JEDEC or near-JEDEC parts, a bit more work for oddball parts. The idea is to provide a socket for a 2K or 4K EPROM and stuff in a 2716 or 2732 which should work fine with your Beeprog. Of course if you have a ROM emulator, that's even easier to work with. Reading odd EPROMs is a lot easier than writing them, so the trick here is to fit in standard EPROMs to make it easy to put your own code on the machine. The idea is to be able to write some very simple "blink the LED"-type programs with a small handful of instructions and watch for success and make the programs incrementally more sophisticated so you can first be certain that the bus and ROM work, then RAM, then I/O chips, etc. In the early stages, you can use/make a simple logic probe or just use an oscilloscope to watch for the "output" of your program. Later, you would be able to spit out text via your UART, once you know more things are working. For really dead systems, there was a trick for the 6502 that might or might not work here... it involved taking a real 6502 and bending out the data leads and wiring them up to Vcc or GND so that no matter what address they fetched, the data returned was always a NOP instruction. This would cause the CPU to start up and run an endless cycle of NOPs, turning the address bus into a binary counter. You can then check the decode logic by watching chip enable (/CE) inputs strobe every time through the memory map, and by knowing what that map should look like you can verify how often /CE gets asserted at the ROMs, the RAMs, and the I/O chips. This trick won't find everything, but if, for example, you never see /CE at the RAM, you know where to start narrowing down the search. It's particularly effective with pre-PAL designs where you can trace the decode logic from gate to gate. I don't know if this trick is possible with an 8086, but if it is, it's a code-free way to explore some of the logic. -ethan