View Full Version : IMSAI working (kind of) !

May 1st, 2015, 01:37 PM
Hello all,

I decided to spend some time with my IMSAI today, to attempt to get to the bottom of my suspected memory problems.

My IMSAI consists of:

Compupro CPU-Z
Compupro RAM-17
S100 Computers SIO

I also have the original IMSAI 8080 CPU card (MPU-A rev 4) and a few Compupro Econoram II 8K RAM boards. Plugged into one of the 2K RAM spots at F000H on the RAM-17, I have a system monitor EPROM that I cobbled together from the TDL Zap monitor and an Intel Hex file loader I also found out on the Internet.

Here's the scenario:

I can power up the system and run the system monitor to my heart's content. I wrote a simple memory test to load memory with AAH and read back, then alternate to 55H and read back, and go again and again for days on end. Not a great test, but it builds some confidence.

A while ago (many months, probably a couple of years), I acquired a Northstar floppy disk controller and some good folks here assisted me with getting a couple of boot disks. I struggled mightily with the controller but I could not get it to work fully. It seemed to be able to read disks properly but when I attempted to write to disk, it would destroy all data on the disk making it unusable. A nice fellow here volunteered to try the disk controller in his machine, and reported that the controller was fully functional in his system. That was good news, but discouraging for me as I could not get it to work in my system. Discouraged, I sold off the controller along with a bunch of other S-100 boards I had gathering dust, but I retained the IMSAI as described above. I figured that I had a memory problem of some sort, but I didn't have much of a clue of what to do next.

Here I am today:
My first try was to load a copy of IMSAI 8K BASIC that I have set up for my machine. Download seems to go fine, but BASIC doesn't run. I suspected the first step was to bring the CPU-Z down to 2 MHz instead of 4 MHz. That didn't seem to do much of anything for me. I fiddled around with the front panel to discover that when I reset the computer, it did not start at address 0 but at address 1. Since the CPU-Z is set to auto-jump up to F000H to run my system monitor, I didn't see that before. I replaced the CPU-Z with my IMSAI 8080 CPU to see that the address bit was no longer "stuck." I put "stuck" in quotation marks because I can still load my little memory test program hex file from my system monitor and get that to go just fine.

Since something does seem to be up with the RAM-17 board, I decided to try to put a couple of my Econoram IIs in the first 16K, leaving the upper 48K active on the RAM-17 board. It's a good thing that I have three of these Econoram IIs because only one was tagged as good, and the others were tagged as questionable. The good one did seem to be good. The second one had some issues, but with a few rounds of memory fill and memory dump, I was able to replace a couple of RAM chips with chips from the third board and seemingly get a couple of the Econoram IIs "working."

I tried loading the 8K BASIC again, and I got it to work - kind of. BASIC seemed to be working in immediate mode, but I could not type in a program - it would hang up when I entered the first carriage return on a line with a line number on it. Hoping for a break, I switched the two Econoram IIs and things got worse, but I found that one of the 4K banks of RAM was not responding, so I suspected the dip switches might be glitchy. A few more tries with changing the banks around and I made it to the point that I am now:

I can load IMSAI 8K BASIC and run it. I can type in a program and list it and I can run it. I can load a program by sending a file into the computer from the terminal and I can list it and I can run it.

For me, this is great progress, but I do not trust that I actually have solved anything really. It appears that I have the bottom 16K RAM working, but this has by no means been an exhaustive test. I have run my simple memory test on the RAM-17 board and also on the two Econoram II boards. My current situation has the two Econoram II boards as the bottom 16K RAM, the 16K RAM from 8000H to BFFFH on the RAM-17 is currently disabled to keep BASIC only using the lower 16K RAM, and the upper 16K RAM on the RAM-17 is not being used, except for the 2K occupied by my system monitor EPROM. Something is up with the RAM-17, but I do not currently have a tool to sniff it out. It's nice to see BASIC running in the IMSAI, but I am not entirely certain about the two Econoram IIs, either. They also should be thoroughly checked out.

Does anyone have a good memory test program that I might be able to download from somewhere as an Intel Hex file? If I could get a good tool, at least I might be able to build more confidence in my memory boards - or find the weaknesses and get them fixed, so I can build more confidence.

If I can only get a good set of memory in this thing, then I will be in a good position to finally move on and try another disk drive controller.

Thanks, in advance, for any advice or comments that you may have for me.


May 1st, 2015, 03:53 PM
Have you tried to put the Econoram at 0000h, followed by the Compupro RAM-17, and see what happens at the junction of the two. Will the first bit of the RAM-17 still be "stuck". The results may help in problem solving the RAM17...or may not.


May 1st, 2015, 04:31 PM
I'll email you a mid-range memory test program that runs a variety of test vectors. And yes, DIP switches are notorious for being the source of problems on older boards. If they're socketed, I'd just replace them all. Sometimes cycling the switches numerous times helps, but the problem typically returns. The failure is most typically an issue when a switch needs to be in the on or closed position.


May 1st, 2015, 04:43 PM
Hi Phil, thanks for your thoughts.

Yes, that's exactly what I have done. I have the first Econoram at 0000-1FFFH, the second Econoram at 2000-3FFFH and the RAM-17 at 4000-FFFFH. When I had all this RAM active, BASIC was not operating properly - that was when BASIC would work in immediate mode, but I could not enter a line of code with a line number on it. This keeps me thinking that there is a problem on the RAM-17. Later, when I disabled the 16K from 4000-7FFFH is when I was finally able to get BASIC to operate properly.

The weird thing for me is that I can load a small code snippet (my memory test program) and it will run fine. Also, since my system monitor at F000-F7FFH works fine, too. That is why I was so surprised to see the "stuck" bit down in low memory. It obviously is not stuck up at F000H.

Oh, well, thanks very much for your attention. Hopefully talking about it will help me figure this out.


May 1st, 2015, 04:46 PM
Hi Mike, and thanks a million for anything you might have to offer. I'll be glad to try out any code that you might be able to share. I'll post back here with whatever progress I make.


May 2nd, 2015, 12:40 PM
Here I am, back again.

Thanks a million to Mike for sending me the more exhaustive memory test code. I modified the code to interface through my system monitor and it worked great.

I first tested the 2 Econoram II boards. This first memory test was only from 0100 to 3FFF. They ran for over an hour of testing without a hitch. The test fills memory with a random 8 bit pattern and reads it back. Then it repeats over and over, each time with a new set of random bits. I got a report of a completed pass about every 1.5 to 2 seconds, so there were plenty of passes happening in over an hour.

Next, I enabled all of the RAM-17 memory above the first 16K RAM of the 2 Econoram II boards, and tested again. This time I was testing from 0100 to EFFF so the loops took longer. Again, over an hour, no problems reported.

Next, I took out the 2 Econoram II boards, and I enabled all of the memory on the RAM-17 board. I ran this test for over 2 hours, again without any reports of problems.

Last, I then loaded IMSAI 8K BASIC into the system with the RAM-17 board only (this is all the way back to where I began yesterday!) and the BASIC loads and runs fine!

Who knows? I suppose, since I had not used the IMSAI in a long time, something went awry? Maybe with all the plugging and unplugging, and exercising the DIP switches, maybe I limbered things up? Too bad I sold off that Northstar floppy disk interface! It would have been good to be able to go back and test that again, now. The only difference now is that the system is running at 2 MHz with no wait states, instead of 4 MHz with wait states inserted. Perhaps I had incorrect wait states selected? Maybe my big old IMSAI can only run at 2 MHz reliably? I do have a (passive) bus terminator installed, but heaven only knows if it actually does anything useful.

Well, for the time being, I am up and running again. A nice weekend adventure with a vintage S-100 computer!

As always, your thoughts and comments are very welcome.


May 2nd, 2015, 12:56 PM
I have found that the fingers of many S100 cards need a spray of deoxit and deoxit gold and a quick wipe with an old tshirt to work reliably. Maybe you had some oxidation on the fingers and the mechanical removal and insertion helped.

I'd still clean the fingers on the cards if you have problems before doing anything more.