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

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

Richard Thwaites

conclusion Sept-Oct 2010

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

Resources

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)

Correspondence

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

follow-up

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