Intel MDS-II Model 230 Development System Restoration


We disassembled the system to inspect it and to take pictures of everything.

We disconnected the DC outputs that connect the power supply to the Multibus backplane and to the I/O controller board on the back of the chassis. We plugged the AC power cord into a Variac, set the Variac for a low voltage output, and turned on the power. Unfortunately nothing happened. We are in the process of determining why the AC power isn't getting to the fans and power supply.

With the Variac set to 30 VAC output we see 30 VAC on the internal floppy power cable. That should mean that the power cord, fuse, voltage selection switch, and power switch are all OK. We checked the resistance of the thermal cutout. It was just a few ohms, so that is OK.

We reassembled the chassis, reconnected all of the internal DC power cables, and powered up the system with 30 VAC input. This time the fans started running slowly, so there was AC power to the power supply. We slowly increased the AC voltage and the DC voltages to the backplane all look OK.

We plugged all of the boards into the chassis and powered it up. The LEDs for switches 0, 1, and 2 and RUN lit. Nothing was displayed on the CRT. We fiddled with the brightness control and could sometimes see a pattern on the CRT while the control was moved.

We set the LOCAL/LINE/DIAGNOSTIC switch on the back to diagnostic, and after a few minutes the CRT displayed INTELLEC SERIES II IOC DIAGNOSTIC V1.1. We ran the GENERAL and KEYBOARD/CRT diagnostics and the passed. We did not run the DISK diagnostics because this system does not have an internal floppy diskette drive.

With the LOCAL/LINE/DIAGNOSTIC switch set to LOCAL everything we type on the keyboard is displayed on the CRT.

With the LOCAL/LINE/DIAGNOSTIC switch set to LINE and reset the system. The CRT displayed SERIES II MONITOR, V1.2 and a prompt. We tried a few commands and it looks like it is working.


We connected the diskette chassis from the MDS-800 to the MDS-II, put a CP/M diskette in drive 0, and pushed the reset button. It cleared the screen and displayed the monitor prompt on the CRT. We tried ISIS V3.4 and ISIS 4.1 and got the same results. Maybe the boot sequence for the MDS-II is different from the MDS-800? Time to read the manuals.

The MDS Monitor doesn't display on the CRT anymore. We removed all of the boards but the IPB, and still no monitor prompt. We reseated all of the chips on the IPB and no change. Maybe the IPB CPU board (most likely) or the IOC I/O Controller board (less likely) is not working correctly.

The power supply voltages to the Multibus chassis are all OK.


We noticed that IC A27, and Intel B3222 DRAM Refresh Controller, on the IPB has a corner broken out of the chip. Hopefully the chip is still functional.

We looked at the signals on the B3222 chip. After power up Pin 3, CYREQ, has 400 nS negative going pulses every every 2 uS. The RUN LED is on bright at this time. Pin 4, STARTCY, has 100 nS negative going pulses every 15 uS after power up. Pin 18, BUSY, has 600 nS negative going pulses every 15 uS. Pin 19, REFON, has 800 nS negative going pulses every 15 uS.

After a while, or after a reset the RUN LED is dim and there are no pulses on pin 3, but the other three signals on the B3222 are active but have a 15 uS period. After another reset or power cycle there are no signals on pin 3, but periodically there is a flicker of activity.

This behavior looks OK, but the lack of a CYREQ signal is concerning.

The image on the right shows the signals on IC A31, a 74ls155 decoder. It is used to generate the DRAM refresh CYREQ signal based on the bus address being in the RAM address range, either the MRDC/ or the MWTC/ signal being active and the INH1/ signal being inactive. The yellow signal is pin 1, DATA1, cyan is pin 2, STB 2, magenta is pin 3, SEL B, and blue is pin 5, 1Y2.

In this 'scope image we don't see any activity on pin 5, MEMR/ so it will not create a CYREQ signal. We see lots or RAM address decodes on pin 1, but not coincident with a MRDC/ in pin 2 and and INH1/ signal on pin 3. After a power cycle we see one MEMR/ cycle, shown below for 4 ms a few seconds after a reset.

In this case pin 1 went high when the RAM address range was selected, Pin 2 was MRDC/ going low because a memory read was active, pin 3 was high because INH1/ was inactive, and the result was pin 5 MEMR/ went low to generate a CYREQ signal. This correct signal sequence was rare and hard to trap.

We need to chase the signals further upstream to determine why we are not seeing the correct sequence of signals. The leading edge of the INH1/ signal has a slow rise time that could indicate a damaged driver chip.


We bought some 327 light bulbs on eBay so now the power switch lights up.

We had several suggestions that the Boot and Monitor EPROMs might have lost their contents. We made new 2716 EPROMs with the same revision level EPROMs, but it didn't change the behavior.

We read through the Hardware Reference manual for this system. It is very detailed and has a good explanation of the boot sequence. After a RESET the 8080 CPU starts executing instructions at address 0x0000. The Boot EPROM at this point is at address 0x0000 and has a JMP 0xE806 as the first instruction. After this instruction is executed the Boot EPROM address is changed to 0xE800 and the 8080 CPU continues executing code at address 0xE806. The 8080 CPU disabled Interrupts, configures the interrupt controllers, RAM, and Serial Ports, and then tried to boot from diskette.

We connected the 'scope to the CS signals on pin 20 of the Boot and Monitor EPROMs. We see a sequence of 8 fetches from the BOOT EPROM at 3 uS intervals and a 2 uS pause, 4 fetches and a pause, 4 fetches and a pause, 4 fetches and a pause, 4 fetches and a pause, 2 fetches and a pause, 4 fetches and a pause, 2 fetches and a pause, 4 fetches and a pause, 4 fetches and a pause, 4 fetches and a pause, 2 fetches and a pause, and then a 200 nS CS, and then CS for the Boot EPROM goes high. We don't see any CS activity for the Monitor EPROM.

Looking at the source code listing of the Boot EPROM we see the instruction sequence JMP 0xE806, DI, MVI A 0x02, OUT 0xFF that need 8 fetches and then the OUT instruction causes the 2 uS pause. Then 4x MVI A and OUT for a total of 4x fetches each and another OUT for a total of 2x fetches. Then MVI A and OUT for a total of 4x fetches each and another OUT for a total of 2x fetches. Then a sequence of 3x MVI A and OUT for a total of 4x fetches each. and another OUT for a total of 2x fetches. This shows that most of the initialization code is running, but something breaks when it is configuring the RTC.

We added the START UP/ signal from IC A73 pin 10 and the SEL BOOT/ signals from IC A73 pin 7 to the 'scope.

Chanel 1 is the CS signal on pin 20 of IC A57 the Boot EEPROM, channel 2 is the CS signal on pin 20 of IC A48 the Monitor EPROM, channel 3 is the START UP/ signal on pin 10 of IC A73, and channel 4 is the SEL BOOT signal on pin 7 of IC A73.

I expected to see the START UP/ signal go inactive after the three fetches for the JMP 0xE806. This is when the address of the BOOT EPROM is changed from 0x0000 to 0xE800. I didn't expect to see the START UP/ signal go active again.

I expected the SEL BOOT/ signal to inactive after the boot code failed to boot from the diskette and then it jumped into the Monitor EEPROM. This happened before the initialization code was finished so it deactivated the BOOT EPROM and therefore we didn't see any more CS signals.

Something is really broken here. Time to figure out what it was doing when the START UP/ signal went active when it should not have.

The 8080 CPU is executing 5x fetch cycles and then START UP/ goes inactive switching the BOOT EPROM's address from 0x0000 to 0xE800. The 8080 is executing a JMP 0xE806 from the BOOT EPROM starting at address 0x0000, then a DI, then the MVI and START UP/ goes inactive so that the data of the MVI comes from 0xE808 not from 0x0008. It would seem that the START UP/ signal would go inactive after the OUT 0xFF instruction, and not earlier.

Time to look at the data bits.

The data from the Boot EPROM is:

  • C3, 06, E8, that is the JMP 0xE806


We updated the firmware in our Rigol 'scope, ran the full 'scope recalibrate cycle, and recalibrated the logic analyzer. Everything worked, so hopefully we can capture better data about the 8080 boot sequence.


We looked at the MEMR signal with channel 1 and the pins on the BOOT EPROM with the logic analyzer. When the OUT instruction is executed we see linearly descending signal on several of the data pins. We eventually determined that the the EPROM outputs are turned off at this time so it doesn't matter. We moved the logic analyzer probes to the data buffers A84 & A85 and get better results. We can also see the data written to the I/O ports with this configuration.

The Logic Analyzer broke again. A Logic Analyzer recalibrate failed. Channel 3 and Channel 5 don't work. We recalibrated the 'scope and the Logic Analyzer recalibrated. We will try again. Oops, Channel 5 is not working again. We will clean all of the connectors and try again.

After reset the bytes on the data bus are:

  • 0000, C306E8: JMP E806

  • E806, F3: DI

  • E807, 3E02: MVI A, 02

  • xxxxx

  • E82B, 3EB6: MVI A, B6

  • E82D, D3F3, OUT F3

  • E82F, 21CD04, LXI, H 04CD

We got all the way through the code up to where we start to initialize the RTC for 1 mS. At 0xE82D it wrote 0xB6 to the ITCP (Interval Timer Output Command Port) port at 0xF3. Then it fetched two bytes of the LXI H, RTCC and it hung with the MRDC signal active and the data lines all high (zeros).

I can see activity where the MRDC signal goes inactive every ms to it looks like maybe the RTC is affecting the CPU. There is no activity on the RTC signal from the 8253 chip, so we will need to go exploring. After about 5 seconds the CPU goes back to running full speed and is executing a loop with an I/O instruction in it. next time we can connect the logic analyzer to the address lines and see where it is going.