Richard Thwaites and his IMS 5000 S-100 system

This page last updated NOv 5 2010. I keep track of some S-100 computer system owners on a dedicated Web page. Richard is one of them. - Herb Johnson

On March 2009, Richard Thwaites contacted me about an IMS 5000 Z80 based system, that he was considering to restore or discard. We discussed this and I encouraged him to dig into it and contact various people via the Usenet newsgroup "comp.os.cpm". From April 2009 thorough 2010, he discussed his progress and asked questions, in comp.os.cpm threads such as "S-100 resurrection in Australia". Along the way, he contacted a number of Z80, S-100 and CP/M interest groups and gave and recieved encouragements and information.

In a tribute to his persistance and to those who helped him, he got his system working, 18 months after he first considered what to do with it.

Below is his description of his system. It took until September 2010, but he got his system to boot CP/M again. Following that is his correspondence with me and others, as he learned about his system, acquired tools and gained local assistance. There's also a section on helpful resources and people on the Web.

- Herb Johnson

Description of April 2009

I've owned an IMS 5000SX s-100 system since 1981, in storage since 1992, but now I 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

conclusion Sept-Oct 2010

Here's what Richard reported in Sept 23 2010 in comp.os.cpm, and his follow-up a month later. - Herb

I'm delighted to report successful boot to CP/M after 18 months of twists and turns.This was ONLY possible due to advice and assistance from many on this list and some in other forums. Plus the amazing wealth of experience and software preserved on the Web, freely contributed by generous individuals.

I came to this project very naive about computer hardware. I have worn out the patience of some helpers, by not even knowing how to describe my problems accurately. I have learned a great deal about hardware and about CP/M along the way.

At this milestone, I specially thank Herb Johnson, who introduced me to this list and has offered extensive and patient advice in off-list exchanges right up until the last few days.

The resurrection was also only possible with the help of a local Australian who lurks on this list but prefers not to be identified - his professional hardware skills, diagnostic tools and S-100 experience were critical in fault-finding the hardware.

[Note: discussion of the hardware debugging are in notes from Richard which I've included here on this page. - Herb]

Others on this list who offered direct help and advice are Max Scane, Keith Harrell, Roman Sigmund, James Moxham, John Monahan, Andrew Lynch, Barry Watzmann, Dave Dunfield, John Crane, and and many more indirectly.

It turned out that the hardware issues were not too many, but hard to identify.

* A few tantalum caps around the VRs had blown. So for good measure all tantalums were replaced on every card.

* The DRAM, once it could be properly tested, had only one faulty 4116 that happened to be sitting in a parity-check slot. It had problems with the us driver chips on that board

* Several buffer chips and a small number of other logic chips were tracked down as faulty and replaced. The crystal on the I/O board was replaced.

[note from Herb: Richard discovered the following months into his efforts, but did not post this in Sept 2010: ] The most significant breakthrough came [in Aug 2009. A local person] 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. .... This discovery prompted my memory. The last time I had my machine serviced locally (1992)....The service company must have swapped the EPROM for some reason, possibly test purposes.

[After discovering my previous ROM had been replaced], I built a ROM monitor to progressively prove the hardware interfaces: first the serial monitor, then keyboard input. With that the monitor could povide rudimentary software debug - read/write/test ports and RAM. [Note: the monitor code was from a "cut-down Zapple-based monitor" - Herb]

Then I re-wrote a routine for "goto breakpoint and display registers and flags" without using RST instructions.

The final hurdle was to construct Initial Program Loader code as discussed [previously] in this thread.After looking at a range of options and suggestions, I went back and built the load code using mostly warm boot code from my original BIOS source, adapted with reference to a compiled BIOS I lifted from the system tracks of a known-good (twenty years ago) disk (an image made with Dave Dunfield's ImageDisk) and cross-referencing to the Digital Research CP/M 2.2 Alteration Guide [manual].

It was quite an experience today to see that "A>" and to start reading all those 5 1/4" floppies, stored for twenty years and data still good. Now I have to remember what all that data and Assembler and MBasic programs were about - it must have seemed important at the time.

Next steps are:

1. Get 2nd FDD going so copy/backup is again possible (FDD B stopped responding 20yrs ago).

2. Set up for simple file exchange with PC environment via serial ports

Any recommendations on simplest way to do this with serial protocols at CP/M and DOS ends?

Thanks again to all helpers, Richard

p.s. I'm happy to share the ROM Monitor source code with anyone interested. It tests and confirms console, RAM, diskette, keyboard, then goes to Zapple-like menu of modules to read/write/test ports and RAM, plus execute to breakpoint and examine, or boot to CP/M. Fits in 2732 EPROM with plenty of room for extra modules.

Oct 22 2010: The zip file MINIMON9.ZIP contains assembler sources, a comprehensive Readme, and some ancillary macros for my ROM monitor "Minimon", version 9. It is directed to the restoration and maintenance of Z80/8080 machines below Operating System level, and to assist in customisation of CP/M. The new feature of most general interest may be the "Load" module, which loads a binary file (or keyboard input) from a serial port to any memory location *without any operating system or disk drives*. In fact this allows for operating system components to be loaded from external storage or an external development environment, then run or tested with Minimon's debug capabilities. Also testing of EPROM code prior to burning.

Minimon cold boots from EPROM with a sequence of tests to check response of Console, RAM, Diskette, and Keyboard, then presents its menu or boots directly to CP/M. It will start to function with minimum hardware of just CPU and EPROM, and becomes increasingly useful when there is Console and RAM. Comments and suggestions welcome. - Richard

from the README: "This core elements of this code are based upon upon several 8080/Z80 monitor/debug programs, especially: John Monahan's MASTERv420 monitor program; the original TDL Zapple monitor (8080 mnemonics); Digital Research ddt.asm (8080 mnemonics); N8VEM project's dbgmon.asm by Andew Lynch, Dan Werner and others; IMS International CP/M 2.23 bios.asm"

file transfers to/from MS-DOS systems

On Nov 2010 Richard reported as follows:

"Kermit, ZModem etc would have required me to write my own overlay, because my S-100 system (IMS 5000) was not among those with listed support. They are much more capable than I require."

"On the Walnut Creek CDROM (courtesy of Peter Dassow's archive) I found a ready-made IMS5000 system overlay for Modem7, dated 1983. This is fine for my needs and contemporary with my system."

On the PC end, I tested Kermit and other programs but found that Hyperterm, using XModem protocol, was simply easier to use. I'm getting good file transfers with CRC error-checking."


Richard initially found my S-100 Web pages, including my pages on IMS S-100 systems, and contacted me. Here's other Web sites where he found support. - Herb

"My main inspiration for ROM monitor was John Monahan . His monitor is adapted for very different hardware and different usage priorities than mine - but I used the framework as a starting point. In turn, he acknowledges [Technical Design Lab's] Zapple as his [monitor's] starting point.

"I found the TDL Zapple Monitor Manual as a PDF on Rich Cini's [IMSAI Web page]. It includes the original Zapple code listing from 1979 - in fuzzy dot-matrix font [part of which I scanned and converted to Z80 mnemonics]. [Note: ask me if I have this source. - Herb]

"On the Vintage Computers Forum, s-100 topic, I found plenty of hardware experts willing to offer opinions and assistance on different approaches to solving issues one by one.

"At the N8VEM project website I found out about the SIMH Altair Z80 CPM2.2 simulator which gave me a very efficient way to assemble and debug code, work with code salvaged from disk images, try out different assemblers, and read the experience of others doing that kind of software work. Its far faster than native s-100 CP/M and avoids wear and tear on old hardware. Plus it's the only way to work with CP/M if your CP/M machine is not working! The limitation is that you can't check anything that uses specific hardware interfaces such as FDD.

"N8VEM is also the home of the Andrew Lynch / John Monahan project that is issuing a series of redesigned s-100 boards on subscription. I have bought some prototype boards and built a rudimentary bus extender to safely probe bus signals at labelled pins. I've also bought [other boards for possible future use]." - Richard

[Note: Richard previously acknowledgee Dave Dunfield's ImageDisk utility and IMS disk image from Dave's site. ALso, a Web search will find some of these early S-100 documents and programs on other Web sites and archives. Also check my list of S-100 and CP/M Web pointers. - Herb]

Walnut Creek CDROM (courtesy of Peter Dassow's archive)


2009 Correspondence

Here's a March 15 2009 letter I got from S-100 owner Richard Thwaites, with a problem.... - Herb

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'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.

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.

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.

- Richard

Herb replies:

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 think it's completely worthwhile [to restore your system]. 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.

In my opinion, [your plan B] 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.

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

Richard continues:

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. - Richard

Herb Replies:

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 from Richard:

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.

late March 2009 in comp.os.cpm:

[Richard posted his situation in Usenet newsgroup "comp.os.cpm" and got a number of responses. - Herb]

Richard 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. - Richard

"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.

Herb Johnson wrote:

I think at this point, floppy drive problems are a separate 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!

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.

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.

Two, describe EXACTLY what it ACTUALLY does or does not do.

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.

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

Richard replies:

See pages 26-27 of the attached [IMS manual] for boot ROM sequence. [What it's actually doing] That's going to take some testing once I know how to work out what is going on at the data level, using scope.

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.

It doesn't get that far in the boot sequence. 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.

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?

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.

Herb replied:

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.

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.

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:

> 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


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

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 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 2009

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 2009

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

2010 correspondence

Richard did not report results until the fall of 2010. I asked him what happened since the summer of 2009, his last reports. He described the hardware debugging as follows:

"I wasn't posting much from Sept 2009 because from them until recently I was working through hardware analysis with the assistance of my local hardware buff. He likes building stuff, and it took a few months for him to design and build a (replica) Front Panel to give us our window into points of failure. Once that Front Panel was built, we could test systematically and replace faulty or suspect components one by one."

"[The front panel was] based on the Ithaca Intersystems FP [front panel] schematics, with some reduction in chip count and some features not implemented (eg no run-to-breakpoint), and it's built in wire-wrap with a separate panel holding LEDs and switches connected by three straps."

[The DRAM parity problem was] just one faulty DRAM chip - sitting in a parity-check slot. The parity LED lightup was, in the end, a red herring. Parity interrupt is disabled. The DRAM problems were one bad DRAM chip, one or two unreliable buffer chips, and no proper initialisation via EPROM. [And] the mystery of the TurboDOS ROM swap will never be solved. The service shop that must have done it went out of business last century."

"Over the same period, I was learning about ROM monitors. Once we got to the point of having console i/o and ROM access, I was looking around for examples to get maximum value from ROM for diagnostic purposes." - Richard

Sept 3-19 2010 in comp.os.cpm

With help from several on this list and others, my IMS5000sx hardware is basically fixed and ready, and can run code from EPROM and i/o with peripherals.

EPROM space is limited to 2kb on a 2732. My Original Initial Program Loader code was lost years ago when somebody swapped the EPROM. So I'm having to reconstruct EPROM code to boot CP/M 2.2 from 5.25" FDD.

I'm building this into a cut-down Zapple-based monitor with basic testing and debugging. The main design criterion is compact code, not execution speed. The tighter the code, the more monitor capabilities I can fit in 2048 bytes.

I have full CP/M BIOS source, but the upd765 routines in that are far more complex than necessary for initial program load - they test every conceivable variable at every point, which is fine for a running BIOS but takes up too much EPROM space.

All I need is to read 15 x 256byte sectors from track 0, 16 sectors from track 1, write them to RAM address D000H, then jump to D806 for BDOS entry point and warm boot CP/M. Then BIOS can do its thing.

I've searched high and low, including this forum and Digital Research archive, but all documents or examples seem to be for other cases - eg for 16-bit implementations.Various "skeletal" loaders always leave out the key upd765 instruction sequence!

Can anyone suggest a source for suitable example Z80 code, or step-by- step coding tutorial for 8-bit upd765 FDD controller? Any help appreciated.

- Thanks, Rick

Note: responses from myself and others prompted these comments:

In fact my particular system disks are configured without any cold boot sector. Sector 0 is blank. I have read disk images of several boot disks and confirmed that. The full system needs to be read into RAM from EPROM code.

I do have DMA, but if non-DMA read uses fewer bytes of EPROM code, I would be interested to look at that option. The NEC upd765 specsheet gives bit-level explanations of commands, but I didn't find information there on correct sequence of commands and data flow, or on the difference between DMA and non-DMA read routines.

There are also a bunch of disk select, disk ready, motor status etc commands that fit somewhere in the sequence. At my level, I think I'll need to rely on existing code known to work with this controller and in 8-bit.

I went back to my original BIOS source (that is ORIGINAL AS DISTRIBUTED WITH MY SPECIFIC SYSTEM) and noted that the "warm boot" BIOS code loads all of Track 0 from Sector 2, then all of Track 1 from Sector 1.

It then jumps to a "Cold Boot" location in the loaded BIOS, does some more initialisation and re-loads from disk if necessary.

I'm now working through how to adapt that code to do the initial load from EPROM. I'll deviate as little as possible from the distribution code, but some locations and calls need adjustment to be compatible with the EPROM monitor code. I also have to work out which (if any) of the error-handling and parameter-checking routines can be skipped for initial load.

The BIOS itself does not make EPROM calls. EPROM first loads itself to RAM 0000, then switches out the EPROM (via Phantom signal) and the code loaded from EPROM continues to execute in RAM starting at 0000.

When control has been passed to BDOS loaded in high RAM, BDOS overwrites low memory with its jump table and RST call addresses. So the Monitor is only available up to the point BIOS is loaded without error and control is handled to BDOS. Monitor code will load again only on hardware reset.

That's OK with me. When CP/M is working, I don't need the monitor and can use CP/M debugging tools.

Once I know it is working, I might adjust the EPROM code to load CP/M by default, and only jump to monitor on error or on a keypress.

I think I'm fairly close now, but not quite there yet...

- Rick

Rick reported success on Sept 23rd 2010 - see the top of this document for details and a review. - Herb