Richard Thwaites and his IMS 5000 S-100 system ---------------------------------------------- I keep track of some S-100 computer system owners on my Web page: http://www.retrotechnology.com/herbs_stuff/s_owners.html Richard Thwaites discusses work on his IMS 5000 S-100 system with me, on this page. But also look in Usenet newsgroup "comp.os.cpm" for April 2009, where he discusses it further in the thread "S-100 resurrection in Australia". Here's his description of his system, followed by our correspondence. PS: This page is not yet "processed", so you should look at it with a word processor which "wraps" text. - Herb Johnson Introduction ------------- I've owned an IMS 5000SX s-100 system since 1981, in storage since 1992, but now have time and desire to resurrect it. With some good advice from Herb Johnson I've done some restoration maintenance such as replacing the higher-value capacitors on all the boards and checking all power and physical connections, but have now reached the limit of my (amateur) technical knowledge. I'm looking for any contact particularly in Australia or New Zealand (but especially in Canberra) who might be able to assist with local knowledge on things such as parts and expertise. There were people in Canberra who knew this gear 15 years ago, but I've not been able to find anyone recently. System configuration is: 64Kb Dynamic Ram Board IMS C00464 MCi 2A 1533 I/O Board IMS c00442 MCi 2A 1771 Z80 CPU Board IMS C00451 MCi 2A 1770 S5000 Floppy Control Board IMS C00431 MCi 2A 1754 4281 S100 Backplane IMS C00540 MCi 8A 1596 System 5000 Power Supply IMS C00411 MCi 2A 1753 S8000 AC Power dist Board IMS C00511 Tandon 5.25 FDD TM1002A 171000-001 s/n 01359193 1267T Tandon 5.25 FDD TM1002A 171000-001 s/n 01359096 1237T On power-up it gets nowhere beyond lighting up the parity-error LED on the 64k memory board, so I believe the Initial Program Loader ROM is a possible fault. UARTS are not initialising so no terminal access is available. Richard Thwaites Correspondence -------------- This page started with a March 15 2009 letter I got from S-100 owner Richard Thwaites, with a problem.... > Dear Herb, > > I found your site last night when I was on the point of throwing out my Industrial Micro Systems 5000SX machine and its VT100 terminal. > > Now I am wondering whether it might be worth saving. The reasons would be sentimental, not really practical. > > I bought this machine new in Hong Kong in 1980 and had it with me in Peking where I was a foreign correspondent until 1983, then I brought it back to Australia. I selected it because it is designed for use in industrial environments and has massive power supply surge protector capacitors and transformers. This was necessary at that time in China, where power supplies were very spiky and unreliable. > > I was then a journalist and used it for word-processing (Wordstar), and an accounts program and text database application that I wrote in Microsoft Basic. This was long before Internet, so I also set up a program for the serial printer port to emulate a telex machine, so that I could deliver my reports direct from WordStar to the international telex network (though a small custom-built adaptor box to drive the 50v telex interface on the public telephone network). That introduced me to 8080 Assembly Language programming. > > The machine came with complete documentation including source code for the BIOS program. CP/M 2.2 also came fully documented for Assembly Language programming and with a compiler. > > Back in Australia I used the machine to write a book, other writing and for normal household PC-type uses. I also wrote in Assembly Language a small full-text searching program for use in my workplace, where CP/M machines were storing unformatted text records that needed regular searching and no such function existed in word-processors of the time. In 1992, I retired the IMS and bought a PC for the graphics capabilities (under family pressure). > > Unfortunately all the documentation was "lost" about that time by the local business where I had the machine serviced for occasional component failures. The machine has been in my basement since then. I think this is a great story. If it is possible for you to keep this system, please consider doing so, and showing it to others. Consider saving it as an artifact of 1980's technology, to show others what was possible and common in 1980? In computer terms, it is a "museum" piece. If there is some local place to show technology, consider providing it to them - with some history and interpretation, as you have given to me. While some "museums" or organizations may frankly laugh at the idea, you may find some support somewhere, or start your OWN facility, or just show it when you have opportunity. IMS systems were reasonably popular, and S-100 systems were certainly in wide use in the 70's and early 1980's, despite the IBM PC and other more "commercial looking" systems. YOu've given good reasons for that. > I'm now retired and wanted to get it back into commission. I have fired it up twice and each time there were capacitors exploding and burning on the 64K memory card. Reading the article linked from your site about exploding caps, I realise this is a common issue. > > The question is: if I replace the busted caps, won't others just keep popping? If I go to the trouble of replacing every tantalum cap that I can find, how can I be sure that the explosions haven't damaged some of the ICs? What would it cost me to get enough caps to eliminate that exploding cap problem on 64K memory card, Z80 processor card, I/O card and driver card for the twin Shugart double-sided floppies? I have never been a professional technician and lack professional testing gear other than standard multimeter, but have done a lot of amateur tinkering and soldering projects over a lifetime. I'll do the replacements if it is worth while. I think it's completely worthwhile. The "exploding caps" simply short out and burn and of course stop shorting. There's likely no further damage EXCEPT that the large currents may burn up the copper traces on the circuit board, so make sure you still have "continuity" from the voltage regulator or the power pin on the S-100 connector, leading "backwards" from the capacitor. Use schematics, or similar caps on other IMS boards, to determine the proper capacity and voltage of the cap that burned up. Use a higher voltage rating than the power provided - 25V for caps getting +18 volts, and so forth, leave lots of room. You can use an ohmmeter to test caps for PARTIAL shorts, sometimes they develop low resistance before failure. YOu may need to cut one "leg" of the cap to measure the resistance, it should be of course very high, megahohms or so. Don't touch the cap when measuring, your fingers have lower resistance! But replacing all the tantalum caps (they look like candy, they are usually brightly colored little drops) is probably a good idea. Look for a mail-order or Web based parts distributor to get the best price for parts. Buying locally at an electronic parts store probably would cost much more. If you know any radio amateurs, they can direct you to amateur radio "flea markets" where on some weekend, you can go to buy parts - but sometimes the mail order companies are STILL cheaper. > Plan B would be to abandon the s-100 architecture, put in a low-spec old PC motherboard with a salvaged small HDD to replace the IMS bootstrap ROM, load the IMS BIOS (or a substitute) from file, set up a Z80 and ANSI terminal emulation environment, and drive the floppies, VT100 and dot-matrix printer from that, in the original CP/M 80 environment. This would look and behave like the original but with major organ transplant, and give me access to the old applications. In my opinion, this is a bad idea. I see no point in throwing away the "real" S-100 computer, just to show the case and pretend. There is of course no problem in using CP/M under emulation - any laptop or PC can run an emulator. You will have a lot of trouble running 8-inch floppy drives from a PC, and most emulators DON'T use PC floppy drives directly as CP/M floppies. Emulators often use MS-DOS file systems but read the files through the CP/M emulator; they may use one file as a CP/M "virtual disk" of many CP/M files. Check the emulators for details. But if you are going to run the actual system, preserve the WHOLE system. In my opinion of course, I work daily to preserve S-100 history. > I believe I might need to tinker with FDD driver software because IMS used a specific interlace pattern, before PC industry standards were established. To get access to my old CP/M files into the PC environment, some years ago I wrote a Basic program that will read the 5.25 FDD files sector by sector and then rearrange them in the correct de-interlaced order. They can then be read and used by DOS programs. I recovered an entire book manuscript that way. > Do you know anyone who has done something like my Plan B, or has made a software emulator for the bootstrap ROM that loads BIOS from disk in s-100? I still have the IMS BIOS Assembler source code on (IMS format) diskette, but I don't have the documentation or a working system that will run it. I haven't worked out yet how to compile a BIOS that will load from HDD into an emulated Z80 environment and then take over the program BIOS calls. If taking this route, I will look into the MYZ80 emulator more closely - that might be my solution. There are two sorts of emulators. One is a general CP/M emulator, which runs "generic" 8080 or Z80 CP/M programs which use the CP/M "console" and "printer" features of CP/M. Then there are specific hardware emulators which support specific hardware by brand and model. I don't think there are IMS emulators. BUT, you may be able to modify one of these yourself! I have a whole Web page on how to run CP/M, which links to a lot of this stuff: http://www.retrotechnology.com/dri/howto_cpm.html > > If I go to Plan B, would you be interested in the s-100 cards? I would be happy to give them to you for the cost of postage (probably about $20). So far > I have not identified anyone in Australia who collects s-100 items. > Plan C is to write it all off and send the gear to landfill. I feel loyal to this machine but we bury our dead pets and relatives, don't we? > I'm sure you will be frank with your response. Any advice based on your long experience would be welcome. > > best wishes, > Richard Thwaites > Australia. I'm in the United States. I think it would cost you much more than $20 US to ship them. It's your decision but 1) determine your actual cost and 2) tell me exactly what boards you have. As for "burying" them in a landfill, we don't bury our relatives if they are NOT YET DEAD! While I don't of course equate computers to humans or even animals, I hate to see a complete system, even without docs, get scrapped out. SOmeone will want it for old parts if not for use, I think if you ask around with some persistence. An alternative is to post your system as available and describe it in the Usenent newsgroup "comp.os.cpm". There may be someone there who has a connection in Australia and who would be interested in your system. It's *possible* someone would pay $100 AU to have you ship the whole system outside the country, but it's not a highly prized system like an IMSAI or Altair. So, let me know what you have and what you think of my responses, and we will go from there. NOte the brand and model of each board and the backplane (sometimes called the motherboard), and the floppy drives. Thanks for contacting me! Can I post your letter on my Web site? Next day. ------------- Thanks - your advice was really useful to me. You are welcome to use the correspondence on your site as you see fit. Inspired by your enthusiasm, I did some more digging and FOUND MY ORIGINAL DOCUMENTATION buried at the bottom of a box of old 8080 Assembler and Basic programming books. Including full CP/M 2.2 documentation and IMS BIOS customisations. So now I have all schematics with full specs. I've identified about 40 tantalum caps on the four cards. Researching the markings, the ones 4.7mf or larger are all ITT brand which I believe were made in UK, with a two-piece molded cylindrical case which has a bad reputation for shorting. I've ordered replacements (gumdrop style) for all of them from a Sydney distributor for about US$30 including postage. So plan A is back on the rails for the time being. It remains to be seen whether the VT100 is still fully functional. Powering it up off line, it looks like some of the pixels may be missing from its graphic-enlarged fonts, and response to keyboard is a bit erratic. I haven't even cleaned it out so could be as simple as dirt. Maybe some deterioration in ROM during years of hibernation? I haven't researched this yet, but might need to see if there is some way to refresh the ROM. I have VT100 user manuals but not service manuals. I'll chase that up after I have the IMS back in operation to test TTY function. I can use TTY emulation from a laptop to cross-check. I'll let you know how it pans out. regards, Richard late March: ---------- [Richard posted his situation in Usenet newsgroup "comp.os.cpm" and got a number of responses. - Herb] > Herb Johnson wrote: >> Rich wrote: >> The fail signal reported by IMD TestFDC is "!No FDC interrupt". This >> is the same signal as when a drive is tested with a diskette inserted >> but the drive door not closed. I hoped I might find a mechanical >> switch not functioning, but the disk detection is done electronically >> after the mechanical conditions are active and motor on. > > You never told me anything about this. I had to go back to your prior > posts, to see that "IMD" must be some other system. I got confused! "IMD" is not another hardware system but my (too obscure) reference to Dave Dunfield's ImageDisk software that includes the TestFDC utility, running on a DOS PC with the Tandon drives attached, one at a time, as FDD A for test purposes. > I think at this point, floppy drive problems are a seperate issue. > If your computer gets to the point where it does a drive "seek" to >try to load the boot tracks, that would be progress! It doesn't get that far in the boot sequence. > But I suggest, at best, you confirm one of your floppy drives is >functional, and put that one on your failing IMS system, I presume >set as "drive 0" or "drive A" or whatever your docs and experience > tell you is the "boot" drive. At this point, all the drive has to > do is blink its "drive active" LED, to show some progress. I've done that. One drive functions OK attached to a PC, but the other gives only a single blink at power-on, responds to a "motor on" signal from the controller, then fails the "ready" test. So I have one working drive. > Otherwise, I think it would be helpful if you did three things. > > One, describe what your computer SHOULD do from the time you power it up, in boring detail. See pages 26-27 of the attached [IMS manual] for boot ROM sequence. > Two, describe EXACTLY what it ACTUALLY does or does not do. That's going to take some testing once I know how to work out what is going on at the data level, using scope. At ANY point, you can note what is going on and what SHOULD be going on. More instruments give you more details, and also oblige you to check and verify more things. > > Three, be clear that you have a working serial terminal, >hooked up correctly to your IMS system. That's not hard to > establish, if your terminal actually works. Currently, the test terminal is a Kermit session on a PC, that has worked OK with other connections. With the logic probe, I've now tested the IMS serial port A assigned to console, and it seems to be showing wrong signals on wrong pins, but I'm still figuring that out. > The problem is, Richard, that you can't assume everyone "knows" what your computer > "should" do, including yourself. All these S-100 systems are different. Hey, > I've known a lot of these systems. They ARE all different. So, try to be clear, > it's actually very difficult to do that so don't feel bad about this. > > Of course, the point of looking for a local person to help you, is to get around >these issues of reporting what is (or is not) going on. It's tough to fix systems > via email. that's why I'm reluctant to work that way, day after day. > > herb April 4th: ----------- >First, the good news. Two people have contacted me off-list. One is a guy in Melbourne (ONLY 600 miles away) who has restored a S-100 system > and offered to advise me. The other is someone offering an 8k static RAM board for sale. That would not be enough to load CP/M as > currently configured, but would it be enough to test machine function? Simple suggestion. Get a 64K RAM card, not an 8K ram card. Otherwise you have to guess at what your ROM will do and what CP/M will do. Even with buying a 64K card, you may have to adjust it so that part of the RAM will not compete with (be at the same address) as your ROM. It will be, in some ways, yet another thing to "fix", yet another thing that could be "broken" or not be compatible with your system. >Also, attached is the IMS Implementation Guide I promised you, which answers a number of the "unknowns" > you have referred to, such as boot sequence. As I read it, the system will not try to load CP/M from >diskette until it has tested and initialised RAM. And, it may be that it would try to "initialize" that 8K RAM card, see that there is 50K of NO RAM, and "fail". >As I learn more, I'll try to be more precise and not assume anything. I now possess a logic probe and am looking at setting up a scope. I'll report progress on comp.os.cpm. Sounds good. At this point, I'm not likely to check every step of what you will be doing. Other people enjoy that kind of activity, but it really takes me a lot of time to look at docs and schematics, sort out the details, and make a judgement. that's really the mode YOU, and whomever you work with locally, will have to be in. > [As to our previous correspondence:] >> Herb wrote: > [I wrote earlier:] The fail signal reported by IMD TestFDC is "!No FDC interrupt". > "IMD" is not another hardware system but my (too obscure) reference to Dave Dunfield's ImageDisk software that includes the TestFDC utility, running on a DOS PC with the Tandon drives attached, one at a time, as FDD A for test purposes. You should let people in comp.os.cpm know, that you pulled both floppy drives and tested them on a PC. The details of those tests are less important, than the apparent fact that you got one drive to "work" on a seperate computer. Provided you hook that drive up to your IMS system as the "A" drive for boot, AND you set all the jumpers correctly, then that drive will not be a problem source. As I said: >> But I suggest, at best, you confirm one of your floppy drives is functional, and put that one on your failing IMS system, > I've done that [with a PC and the IMD program]. One drive functions OK attached to a PC, but the other gives > only a single blink at power-on, responds to a "motor on" signal from the controller, then fails the "ready" test. So I have one working drive. >> >> Otherwise, I think it would be helpful if you did three things. >> >> One, describe what your computer SHOULD do from the time you power it up, in boring detail. > > See pages 26-27 of the attached doc for boot ROM sequence. OK. Follow that closely. >> Two, describe EXACTLY what it ACTUALLY does or does not do. > That's going to take some testing once I know how to work out what is going on at the data level, using scope. At ANY point, you can note what is going on and what SHOULD be going on. More instruments give you more details, and also oblige you to check and verify more things. >> Three, be clear that you have a working serial terminal, hooked up correctly to your IMS system. > Currently, the test terminal is a Kermit session on a PC, that has worked OK with other connections. With the logic probe, I've now tested the IMS serial port A assigned to console, and it seems to be showing wrong signals on wrong pins, but I'm still figuring that out. So you have verified the "terminal" (A PC in terminal mode) is working. But not the connections to your IMS system. At a previous point, I mentioned the fact that "transmit" lines on a serial port are at minus voltage, "recieve" lines at a postiive voltage, when read with a voltmeter or oscilloscope. You can use that information to test both your "terminal" lines and the IMS's "console port" lines. Let me be specific. The PC's "transmit pin" should be negative; the IMS's "recieve pin" should be positive; connect the two together. The PC's "recieve pin" should be positive; the IMS's "transmit pin" should be negative; connect the two together. COnnect ground to ground between the two. Note: when these lines actually have data on them, the voltmeter will see voltages positive or negative, because they are CHANGING. I am talking about conditions when there are no "characters" transmitted or received. I hope you know what I mean by transmit, recieve, and ground on RS-232 serial connections. There are also "handshake" signals: RTS, DTR, DSR, CTS. HOpefully you don't need to worry about those. Herb Johnson (Dave Dunfield) wrote in comp.os.cpm in April 2009: > Does this system have a boot ROM socket? > > I can provide a small (<500 bytes) 8080/Z80 Rom monitor that works > without requiring ANY ram - it provides basic read/write memory > and high speed loop reads/writes which are quote handy for "scope > debugging". Even if the console UART is not working, the polling loop > for that is helpful to debug it. > > Having even such a simple window into the system can provide a > wealth of clues on memory problems... I've brought up several > "completely dead" system using it. > > Dave Dave - The IMS Model 440 I/O Board houses Initial Program Loader ROM with this description: "2048 x 8 EPROM The 2716 is a high=speed, bit-erasable and electrically programmable EPROM packaged in a 24-pin dual in-lin package. EPROM address is shunt- selectable." This socket interfaces to the s-100 control, data and address bus lines, plus the Program Interval Timer which then interfaces to the interrupts bus. If this is compatible with your ROM monitor, looks like I could certainly do with it. BTW I have been gratefully using your ImageDisk utilities to check out my 2 x Tandon TM100-2A FDDs by connecting them, one at a time, to a PC. When identically jumpered as A and fitted with the required terminal resistor block, one functions drive fine as DD DS, the other is recognised by your TestFDC utility but stalls on test (or any read operation) for lack of an interrup signal. Any suggestion where I should look for the fault causing that? I've also used ImageDisk to make working backups of my 5.25 floppies, some of them 28 years old. Of those images I've inspected, some of the oldest record a few bad sectors, but the errors seem to be just one or two bytes that I ought to be able to repair with hex editor, especially where I have more than one copy of files. ImageDisk could not guess the interleave pattern of the IMS 5000 diskettes. The IMS BDOS uses a translation routine rather than a sector translation table - 16 sectors per track per side, plus buffering 256Kb logical sectors into 512Kb physical sectors. I can send you the IMS documentation on that if you are interested. I've previously used the DOS utility DiskDump to make a raw diskette image byte for byte in a DOS file, and wrote a little application in QBasic to read the raw file, scan the CP/M directory and reconstitute files into DOS-readable form using the sector information written in the directory. It should work with any interlace format so long as the physical sector byte counts are known. Maybe ImageDisk has that capability, but I haven't found it yet. Thanks for your advice and info. - Richard Thwaites -------------------------- Some follow-up in late April, in comp.os.cpm, in thread "Re: S-100 resurrection in Australia" >> > > I can provide a small (<500 bytes) 8080/Z80 Rom monitor that works >> > > without requiring ANY ram - it provides basic read/write memory >> > > and high speed loop reads/writes which are quote handy for "scope >> > > debugging". Even if the console UART is not working, the polling loop >> > > for that is helpful to debug it. > > >> > > Having even such a simple window into the system can provide a >> > > wealth of clues on memory problems... I've brought up several >> > > "completely dead" system using it. > > >> > > Dave Dunfield Dave - The IMS Model 440 I/O Board houses Initial Program Loader ROM with this description: "2048 x 8 EPROM The 2716 is a high=speed, bit-erasable and electrically programmable EPROM packaged in a 24-pin dual in-lin package. EPROM address is shunt- selectable." Dave - is your ROM monitor the same as the monitor facility in your EPROM programmer project info? Or do you offer a programmed EPROM for a 2716 24-pin socket? (I emailed your site support address but perhaps got it wrong somehow) If any group member has IMS International system files, I would dearly appreciate a copy or even a listing of the file IPL.ASM that contains the EPROM Assembler source. My EPROM is marked IPL v.1.3, but any version would help. It is the one thing missing from my original 1981 system diskettes, though I have everything else, including prose description of the IPL boot sequence. - Richard Thwaites ------------------------- Some follow-up in mid-May 2009: I've been getting some off-line advice from two people - one an experienced Australian technician with a different s-100 system (but 600 miles from Canberra) and another in Austria (not Australia) who owns an identical IMS 5000 system with the same problems as mine. I've swapped docs with the latter and he has sent me binary downloads from the EPROMS he has for three different IMS systems. This is not as good as having the commented IPL.ASM files, but I've been able to use DDT in my simulated CP/M environment (AltairZ80) to disassemble those binaries into Assembler mnemonics. So at least I can trace what the EPROM is trying to do step by step. The blockage remains the RAM card, which does not allow the EPROM code to run properly as it requires RAM for stack. I don't know yet whether the RAM card parity error is the only thing that is blocking the system from booting, but I am certain that the RAM card is generating a parity error on (any?)read access, and that in this system that parity error is fatal to the system initialisation. If the RAM card is powered up in the chassis without the CPU card present, the parity error LED remains off. So the error is not generated by a power-on self check on the card itself, and is not on by default. If the CPU card is also present, the RAM parity error LED switches on immediately. This occurs whether or not the I/O card (where the IPL is located) is present. So the parity error is not being generated by instructions read from the IPL EPROM, but by some read request generated from the CPU card. My advisor in Melbourne (Max)is helping me look for known good 4116 DRAM chips as the most practical means to isolate faulty chip(s) by substitution. If your research suggests other ways in which RAM card error can be pinned down and corrected, I would be delighted, thanks. Did I mention that I have already tried disabling the parity check by use of a jumper on the RAM card, but this did not have any obvious effect? I'm thinking that maybe this jumper only disables an error signal to the s-100 bus, but does not result in override of a parity error or fault in memory read-back. It's not clear (to me) from the documents precisely what that jumper disables. I'm keeping my eye out for a compatible RAM card to substitute, but will also look for replacement dram chips for my own card. Any suggestions on sources for chips or cards? Or an effective way to isolate faulty chip(s) for replacement? In the mean time, I'll keep exploring the virtual CP/M with view to building refreshed/repaired system diskettes for the IMS system. Eventually I can write those out to correct IMS diskette format using IMD. Until I can get functioning s-100 RAM, I can still go some way to rebuilding the peripheral system (FDDs and Console) using CP/M simulated system on PC platform, hoping to migrate back to s-100 when it is viable. regards Richard June 18th: ---------- Finally a S-100 guy and comp.os.cpm reader local in Canberra has contacted me - IMSAI owner, trained engineer, all the right tools etc.. and willing to help. Together we have done all the tests and jumper options that you have suggested and then some. Also swapped out all chips on the 64K memory board. Still getting parity error triggered on the RAM board. Even with parity error signal disabled, still not getting boot from floppy or even drive select. Have also been able to check IPL EPROM source code to confirm what should be happening and it is the same as outlined in the Implementation Guide. The +5v VR on the RAM board is reading about 5.25, which is right on the edge and could be an issue. Another area of suspicion is the terminator circuit on the backplane. If not functioning properly, it could be messing up signals on the bus itself. The VR on the backplane driving the terminator is reading -1.3v and +5.8v. How do those values compare to what you would expect? The backplane is the one item in the system for which I have no documentation or schematics, and I don't see such documentation listed on your website either. Strange if this was not a standard inclusion. [I told Richard to make sure the termination circuit has NO negative voltages, as all S-100 terminators use about 3.8V to drive bus resistors. The 5.25V voltage is not so bad. I suggested getting a ROM monitor with his serial port specified, which was offered to him during his comp.os.cpm conversations. I'll send him some more docs. - Herb] Aug 16th: --------- There has been some progress on my own IMS system. A local guy (who seems to prefer to be anonymous) has emerged who has the skills, tools and goodwill to help me work through it. The most significant breakthrough came last week. He was able to read off the EPROM code. I had collected some EPROM codes from another collector in Austria. The amazing discovery was that the code in the EPROM currently in my machine was clearly code to load TurboDos. My machine has NEVER run TurboDos but has run CP/M 2.23 since the day I took delivery. This discovery prompted my memory. The last time I had my machine serviced locally (1992), I had already de-commissioned and replaced my IMS with a PC for work purposes, so I must have stored it without testing it on return from service. The service company must have swapped the EPROM for some reason, possibly test purposes. Needless to say, that company no longer exists. I do have appropriate IMS 5000 IPL code in a file, though it is from a system that had a Winchester drive as drive B. We have disassembled it and can see it follows the steps described in my documentation. So the next step is to verify that code against the specific settings, ports etc for my hardware, then burn a new EPROM with it. We may add monitor code to the EPROM for test purposes. On another track, I have located an IMS 5000 TurboDos disk image (Teledisk format) from the Rechner archive. I also have one from Dunfield's IMD image collection, though that is for IMS 8000 with 8" floppies. I'll have a go in the next few days at creating a TurboDos boot disk to see whether the "wrong" EPROM will in fact boot TurboDos. One feature of the TurboDos EPROM boot code is that it does not contain the dynamic RAM DRAM initialization routine. My local adviser is very confident and very determined that we will get this system back to life. He is very systematic and we both are interleaving this project with other priorities in our lives, so this may not happen quickly. Thanks for your help and continuing interest, Richard (Last updated, Aug 17 2009)