Intellec MDS questions

William Layer wrote: You have a "Series II" version of the Intel MDS (Microcomputer Development System). The 225 means it was delivered from Intel as an 8085-based system and an intrgral single-density 8" diskette drive. The cpu card is the one with the series of switches you mention. Each one triggers the corresponding IRQ to the cpu. You can hit "0" to enter the debugger (or monitor) because when ISIS-II is booted there is a vector there into the monitor. "1" will reboot ISIS. The rest are masked by the OS, so if you hit them they just light up and will stay pending because the interrupt controller has been told by ISIS not to pass them through. Some of the In-circuit Emulators used IRQ 7 as I recall, and unmasked it to force a manual breakpoint. The white color just means it was produced in the latter part of its product life. Intel changed from blue to white for some reason. The salesmen from Intel, at that time, told me it was because the IBM PC was that color (or close) and Intel wanted to leverage that inertia. Sounded like sales BS to me. I have several blue ones, all working, and one white one (thank you, Joe!) but it doesn't work. It's my project machine. The MDS-800 was a different machine and preceeded the Series II. Your drives are probably marked with that name because they were originally meant to be used with an MDS-800. Later in the product life of the external drive subsystem, as Paxton has already said, Intel went to a different box where the drives were horizontal. The drives were the same drives, just oriented differently. It was much easier to work on the style you have, but it takes up more space. Hopefully, soon, there will be a bit more on the web. I'm trying to get something together on the Series II specifically. It really is a remarkable machine. Intel, at that time, called a "microcomputer" a system that contained as its cpu a "microprocessor". That was the distinction in terms. The MDS was meant to develop systems that used Intel's microprocessors in a system, hence the Microcomputer Development System's name. With tools cross-compile or compile them into relocatable object code, "locate" that code appropriately for your target system, and then, if your pockets were really deep, hook up an in-circuit emulator to your target system and load that absolute object code and debug it in real time. You could have an EPROM programmer connected and burn your absolute code into memory devices from the MDS. You have a connector on the back of your 225 marked UPP I believe. That was meant to control the Intel UPP (Universal Prom Programmer) using the software called UPM (Universal Prom Mapper). Later Intel offered the iUP-200/201. It connected through one of the serial ports and used the software IPPS. The iUP supported the newer types of memories and Intel even supported that one hosted by an IBM PC with a version of IPPS that ran on it. Interestingly (at least to me) also is the modules that plug into the iUP will also plug directly into the side of the Intel iPDS-100. That computer, running ISIS-PDS, has a corresponding IPPS to drive those modules. ISIS was Intel's operating system. Actually ISIS-II. I never used its predecessor so I don't know anything about that. The final version of ISIS-II that was released by Intel was 4.3 and included some nice enhancements that coupled with a firmware upgrade that went into the IOC (Input/Output Controller) card on the back panel of the Series II. I have recently sent that package to Randy and it is available on his web site for download. The enhancement also includes new firmware for the 8741 chip in the keyboard. ISIS-II was very similar in concept to CP/M, but different in structure. The disks were not interchangeable with CP/M logically, but there were programs available commercially from other vendors that ran on ISIS-II to read/write CP/M disks and vice versa. The "off the shelf" version of CP/M V2.2 from Digital Research would boot without any changes on an MDS-800 or a Series II with Intel's diskette controller board set. Many, MANY years ago, I modified significantly that BIOS so that it would boot on a Series II from the external double-density drives and read/write the internal single-density drive (when connected to the IOC) so that you can have the only real standard format for 8" diskettes supported. I can post that BIOS on Randy's site (with his permission and my thanks) if anyone is interested. I also wrote a BIOS for CP/M 2.2 that booted on an Intel MDS-225 with only the internal single density drive. I have an extensive collection of software for the ISIS-II OS for Intel MDS's, as well as CP/M programs configured for the MDS. As I find time I am transferring them over to a media that can be read today and the more interesting stuff I am posting. If your cpu card actually has an 8080A on it, then your system would be more accurately called an MDS-220. That's interesting because the model number 225 means it was delivered with an 8085-based cpu. Someone has replaced it with an older cpu card. The 8080-based cpu card has 32K bytes of ram. If you wanted to do anything serious you added an additional 32K bytes with a second memory card. The 8085-based card upgraded the speed from 2.6MHz to 4MHz and the ram from 32k to 64k. It also supposedly had better bus arbritation circuitry and was required by Intel if you used certain bus-mastering cards, such as the RPC (8086-based "Resident Processor Card" for 8086 executables). Your ICE-51 is and In-Circuit Emulator for the 8051 cpu family. I think it had two multibus cards in the MDS, but I don't remember that off the top of my head for certain. The "pod" is the buffering for the cpu signals back to those cards for emulating, tracing, breaking, etc. As you might gather from this post, I am prone to rambling about the Intel MDS's. Lately I have been on a kick to get mine working and have done a lot of repairs. So much of this is fresh in my mind. If you have any other specific questions, please feel free to ask. And if you need help there are lots of guys here with experience. Tony is especially good at hardware troubleshooting. He has helped me with diskette controller repairs. Sorry for the long post. Signing off now. Dave