• Please review our updated Terms and Rules here

Owning and operating an S-100 bus computer

JNZ

Experienced Member
Joined
Sep 4, 2015
Messages
167
Location
Utah
A few weeks ago I made a thread asking about the feasibility of owning and operating an S-100 bus computer. I learned about N8VEM, Zeta 2 SBC and alternative ECB cards, signed up for the N8VEM wiki, and discovered there's still a reasonably active homebrew community creating new ECB and S-100 bus cards.

And now, thanks to the great generosity of new_castle_j of this forum, I was able to obtain a homebrew S-100 bus computer with a few cards! He sent it to me for the cost of shipping, along with documentation, extra 8" disks, and an extra front panel project he had. He also very helpfully sent me a copy of the EEPROM from the Z80 board, as well as physical and digital copies of the machine's boot disk. I'm extreme grateful for this; thanks again!



(Cat for scale)

The machine is built up around an S1-MOD 12-slot fully terminated motherboard by Delta Products of Huntington Beach, CA. The manual actually has no copyright or publication date anywhere on it (one of its peculiarities), so I'm not sure exactly when the machine was assembled. Likely in the early to mid-80s, based on the boards I'll describe in a moment. It's contained in a hand-built oak case, which has one side for the board and the other for two 8" disk drives. The case itself is quite well built, having dado joints to recess the panels and a removable top to grant access to the S-100 cards.



The linear PSU has, and in addition to the rectifier output that goes to the S-100 bus, a few Molex-style connectors that provide regulated power to the 8" drives and other peripherals. It appears to have an additional in-line fuse, and, disconcertingly, there's an unshielded screw terminal in which (fused) 110V AC is broken out to the drives. There's no back to the case, probably for airflow reasons...so little fingers or a curious cat could, in theory, touch live AC.



I haven't yet investigated the make of the disk drives, and I also had difficulty getting both of them to latch. A metal bracket came out in the packaging, so it may have been damaged in shipping (FedEx actually packaged it themselves, so this isn't the fault of new_castle_j.

Now for the good stuff!



(These boards have been posed for this picture, and aren't necessarily in the best order)

The machine has the following boards:

* Jade "The Big-Z" Z80 microprocessor board, JGZ80 RevC (1979)



* Jade "The Memory Bank" 64K dyanmic RAM (1981)



* CompuPro Interface 4 3-channel Serial I/O w/ CENTRONICS and Universal Parallel Ports (1983)



* Jade "Double D" double density disk controller (1980)



The Z80 board also came with an RTC protoboard that the original owner (before new_castle_j) had created:



Thin IC socket extenders were stacked up to allow it to plug into the Z80 slot and hang on top of the board. As new_castle_j pointed out, modifications to the EEPROM or on the boot disk may contain code that interfaces with this custom, undocumented board. The board doesn't have it own dedicated Z80A--that processor is just extended up from the Z80 S100 board. The Jade Z80 board also seems to have some modifications done to it, but I haven't figured those out yet.

There's also this custom front panel board of unknown functionality:



Edit: And this board has an NCR 5380, which is a SCSI controller chip! Apparently this is a complete (or partially complete?) SCSI controller of some sort, with what looks like a 50 pin ribbon cable connector.



More and larger photos are available here: http://imgur.com/a/ZR4D9

In part 2, I'll describe what I've done with the machine so far, in my efforts to get it up and running.
 
Last edited:
Awesome! Looks like you've already cleaned it up nicely. I'm imagining plugging the hole in the front to the right of the floppy drives with front panel containing a dazzling array of blinkinlights and switches, setting a monitor on top of the case and calling it a Desktop machine.
 
A few weeks ago I made a thread asking about the feasibility of owning and operating an S-100 bus computer. I learned about N8VEM, Zeta 2 SBC and alternative ECB cards, signed up for the N8VEM wiki, and discovered there's still a reasonably active homebrew community creating new ECB and S-100 bus cards.

And now, thanks to the great generosity of new_castle_j of this forum, I was able to obtain a homebrew S-100 bus computer with a few cards! He sent it to me for the cost of shipping, along with documentation, extra 8" disks, and an extra front panel project he had. He also very helpfully sent me a copy of the EEPROM from the Z80 board, as well as physical and digital copies of the machine's boot disk. I'm extreme grateful for this; thanks again!

That's so cool. I got my Vector MZ from a local friend.
 
Hi All;

JNZ, You can't complain about the price.. And I am Not saying You have in any way..
Congratulations, the Wooden Case looks nice..
Also, a Thank You to New Castle for doing this for You..

THANK YOU Marty
 
Yes New Castle is very generous. He donated a couple systems to me for the price of driving and picking them up. It got me into the S-100 realm. Yours will be more of a challenge with a homebrew collection of cards.
Keep us posted !!

Larry G
 
I agree that the front area would look great with a custom panel, filled with switches, 7-segment displays, LEDs, and so on!

Part 2:

The first thing I did with the machine is photograph it, disassemble it, inspect everything, and clean it all with rubbing alcohol. I began to unsocket and reseat all the ICs, starting with the Z80 board, but stopped after I nearly broke a few leads by bending them. Even without breaking them, I'm sure I induced metal fatigue. As I don't have spare logic chips (yet), I stopped this plan before I got to the big chips, such as the EPROM. This may have been a bad idea, however...

I next inspected the PSU and checked some voltages. Everything seemed okay, with the transformer putting out 13.30 V, 28.89 V, and 9.23 V. These went into the rectifiers, and the bus itself received the rectified but unregulated DC power.

I started to compile a memory map of where the boards were registered in memory, so that I could understand what the EPROM code would be doing. I came up with the following:

Code:
Z80 EPROM - F000 - F3FF
Z80 board USART output addresses: 0x20 - 0x21 

"Double D" FDD controller - FE00 - FBFF

CompuPro Interface 4 output addresses = 0x10 to 0x17
	"READ" or "INPUT" ports
		Relative port address

		00	- Data port, read received data
		01	- Status port, read UART status info
		02	- Mode registers, read current UART mode
		03	- Command register, read current commadn

	"WRITE" or "OUTPUT" ports
		Relative port address
		
		00	 - Data port, write transmit data
		01	 - SYN1/SYN2/DLE register, write sync bytes
		02	 - Mode registers, write mode bytes
		03	 - Command register, write command bytes

The EPROM dump begins like this:

Code:
; z80dasm 1.1.3
; command line: z80dasm -t -g 0 -a -l JADE.BIN

	org	00000h

l0000h:
	jp 0f59fh		;0000	c3 9f f5 	. . . 
	jp 0f020h		;0003	c3 20 f0 	.   . 
	jp 0f5b8h		;0006	c3 b8 f5 	. . .  
	jp 0f5c3h		;0009	c3 c3 f5 	. . . 
	jp 0f5d0h		;000c	c3 d0 f5 	. . . 
	xor a			;000f	af 	. 
l0010h:
	ld (00004h),a		;0010	32 04 00 	2 . . 
	ld a,04eh		;0013	3e 4e 	> N 
	out (011h),a		;0015	d3 11 	. .  		; 0x11 appears to be CP4 SYN1/SYN2/DLE register

I couldn't figure out what's in F59F, F5B8, F5C3, or F5D0. F020 is 20 bytes into the EPROM. The F59F, etc., has to be memory mapped ROM, no? It makes no sense to jump to uninitialized memory. I may be wrong about where the FDD EPROM is mapped, or maybe CPU execution doesn't start at 100h. Maybe I'm missing data from 0h?

I put the Z80 board in the machine and began the process of figuring out how to tell what was going on. I ended up using the custom front panel, which only displayed all 1s for the address and bus lights. This led me to think the panel was malfunctioning, but inspection revealed no problems, and the board's logic seems very simple.

It looked something like this (but the CPU may have been in a different state):



This eventually led me to inspect the Z80 board again. And, oh no! The EPROM was in upside down. This is actually visible in the full size version of the picture I took while cleaning the board, but it would take the eyes of an eagle to see it from the photo. I didn't notice it while inspecting it, sadly.



Question 1:

I don't know what happens when you insert an EPROM in this board backwards, but I'm sure it's nothing good. Is it still intact? Does it need reflashing? Is it fried? Is the entire board fried?

I reversed the EPROM and used the front panel to step through the CPU state and saw the following:

Run 1:
Code:
Address	Data
00 00	FF	; RST 38H
FB F0	00	; ?? (probably pushing SP on stack?)
FB EF	01	; ?? (~PWR is high here, indicating DATA bus is invalid at the moment, I think)
00 38	FF	; In ISR, RST 38H
FB EE	00	
FB ED	39	; 
00 38	FF
FB EC	00
FB EB	39
FB EA	00
FB E9	39
00 38	FF
FB E8	00

Run 2:
Code:
Address	Data
00 00	FF
FB F6	00
FB F5	01
00 38	FF
FB F4	00
FB F3	39
00 38	FF
FB F2	00
EB F1	39
00 38	FF
FB F0	00
FB EF	39
00 38	FF
FB EE	00
FB ED	39

I didn't write down the machine state, and didn't know when it was doing a machine instruction fetch cycle or busy doing IN, OUT, or an interrupt.

Question 2
It would seem to me that the board is continually executing a RST 38H. What's at 0038H? Another RST 38H. Why? I'm not sure.
 
Last edited:
Some more things I noticed on the "Big Z" Z80 CPU board:

* C26 appears to have been clipped or broken off, perhaps accidentally or perhaps with a bad desoldering job. Same with C22. C26 is listed as 1.5 uF, along with a bunch of others, but the silkscreen is very different from the rest of those, and also isn't marked with polarity.

* Y1 is 4 MHz, not 16 MHz or 32 MHz

* The bus wire connector "L" is populated with a wire connector, as is "F," but no wire runs between them.

This leads me to believe that the manual I was able to get online doesn't reflect this revision of the board. Hopefully the DIP switch settings are the same as the manual.

It's also possible that these are part of the modifications necessary to get this custom RTC board to work.
 
Last edited:
I also found out that it's a 2716C EPROM, so I'll need a programmer that can deal with it, and possibly a replacement EPROM.
 
I'll send you another Eprom, or two, I see that there's also a newer version of the JGZ80 ROM image on Don Maslin's archive.
 
I'll send you another Eprom, or two, I see that there's also a newer version of the JGZ80 ROM image on Don Maslin's archive.

Thanks! You can contact me on email and I'll pay for the chips and shipping, if you wish. 2716 EPROMS and especially the programmers seem slightly costly.

I also did some research and found that the 28C16 should be a drop-in replacement for the 2716. I ordered two of those and an EEPROM programmer.

Does that mean that the 2716C EPROM is certainly fried? What is the machine doing when it keeps calling RST 38H?
 
In the past few days I've come to understand the existing code in the EPROM better, learning that it's (probably) trying to use the on-board USART to output system messages. I attempted to connect a USB serial port I've previously used on real RS-232C devices, only to have the machine now enter a state where it doesn't reset on power-on or reset. I've begun the troubleshooting process in the manual (thanks new_castle_j for finding the Rev. C manual for my "Big Z" board). I verified the 7805 VREG was putting out ~+5V (+5.36V), and then discovered that pin 6 of the Z80A wasn't receiving a 4 MHz clock. I'm investigating the clock generator portion of the circuit now, trying to identify what could be the cause. I'm not sure why this would manifest itself as soon as I tried to connect a serial port, however. When I connected the USART I triple checked that GND was among the signals I connected (TX->RX, RX->TX, and GND->GND), so that no voltage differential for GND would exist in the TX and RX lines.

I also commented that C22 was missing, and the manual describes errata where the C22 value should be changed, or it leads to strange reset operation. I added 1 uF aluminum electrolytic cap, as I don't have a tantlum of the same value at the moment. Hopefully this is okay.

Also, I previously described C26 being broken off--well, C26 is a 0.001 uF cap used in the oscillator circuit.
 
Last edited:
This whole area of the board is quite suspicious.



In its present state, both C26 (unpopulated) and C27 weren't connected. C26 appears to be a filter cap for the power rail of U21, a hex inverter (74LSO4N), but C27 seems far more important. It's a 0.001 uF cap that sits between two hex inverters, and without which one side of the 4 MHz crystal doesn't connect to anything at all. It appears that the copper annulus has delaminated from the surface of the PCB, perhaps due to handling when I put the board in. There's corrosion that's seeped under the solder mask, and perhaps the annulus was just barely making electrical contact for a long time now, and finally gave up the ghost. Note too the bottom lead below the annulus, which is folded over. Half that annulus is missing. Something's clearly gone horribly wrong on this part of the board! Too much heat when soldering? Contamination? Oxidation of the copper or whatever substrate holds it onto the PCB?

This is after my initial cleaning with rubbing alcohol. Although gentle and with a toothbrush, it's possible it aggravated the problem.

That glob to the left of the annulus is one lead for C26, and it's actually a via, if you can believe it. Gross!
 
Last edited:
I received my Chinese EEPROM programmer and two AT28C16 EEPROMs. After much difficulty getting it working (it didn't play nicely with Windows 8, and one of the two EEPROMs refuses to clear the 64 bit for every cell, so the memory reads 0x40 when I try to clear all bits), I was able to reliably flash ROMs. I tried a number of times with the Jade System Monitor V4, as well as the modified ROM that came with it, before finally assembling the V2 version of the ROM myself.



Success!

Thank God for that front panel board. It's extremely helpful in debugging, especially because I don't have an S100 bus expander board yet.
 
It's Alive!! It's Alive!!

Fantastic progress. Were you able to determine if the upside down EPROM got corrupted?

I see an option to "Load" (write direct into memory) in the Monitor code, I'm guessing that it is
expecting to see HEX character input at the console. If you can figure out how that works, you
may want to load in a memory diagnostic program and check out the memory board.
I've used the memdiag.asm and memdiag.doc files from https://github.com/ezet/i8080-emulator/tree/master/diag
You would just need to modify the console I/O parameters section, then compile into HEX. A terminal emulator program like TeraTerm would be able to transmit the HEX characters to the console, and once it's all written into memory, jump to H100 and run. One thing to be mindful of is if the Monitor program is expecting Intel HEX format or RAW HEX (without the checksum values), I'm guessing it would expect RAW.
 
Fantastic progress. Were you able to determine if the upside down EPROM got corrupted?

Unfortunately my cheap Chinese programmer wasn't able to read the EPROM, so I can't do much with it yet. In theory this could be caused by a fried EPROM, but I can't determine that for sure unless I can find another 2716 (the FDD controller might have one).

Also odd is that the CPU board wouldn't read my EEPROM until I started poking around with my oscilloscope probe, and then it suddenly loaded valid data. Something must've been loose, even though I reseated everything. Not sure what was happening, but it's the first time I ever saw valid data on the data bus. The name of the game with this Z80 board is intermittent failures.


I see an option to "Load" (write direct into memory) in the Monitor code, I'm guessing that it is
expecting to see HEX character input at the console. If you can figure out how that works, you
may want to load in a memory diagnostic program and check out the memory board.

You read my mind. I had to figure out the code, but I learned that the load command works by taking an address in (two ASCII chars for HEX vals), a space, and then a repeating stream of sets of two chars, separated by spaces. The data is loaded into memory as you enter it. '#' terminates the program and returns execution to the monitor (if you haven't corrupted it).

Now that I've figured this out, I can compile that memory check (or write my own) and load it up. I'm not sure how to begin execution at an arbitrary address yet, but it should be simple enough to figure out in the ROM monitor code.

You're right about it being RAW HEX. Though I don't know what the Intel format looks like, I don't see anything in the load program to deal with special/metadata bytes in any way.
 
Memtest looks good!

Code:
MICROCOSM ASSOCIATES "SUPER MEMORY DIAGNOSTIC" VERSION 1.01 (C) 1979

TOP OF MEMORY=EFFF

MEMORY QUALIFICATION TEST IS IN PROGRESS

TEST MEMORY IN "AUTO" MODE (Y OR N)?y

TEST MEMORY IN "AUTO" MODE (Y OR N)?Y

TESTING MEMORY,FROM 1000 TO 2000
PASS=0001, TOTAL ERRORS=0000
RANDOM PATTERNS TEST
WRITE SATURATION TEST
GALLOPING PATTERNS TEST
-t
?
-T

TEST MEMORY IN "AUTO" MODE (Y OR N)?Y

TESTING MEMORY,FROM 1000 TO 2000
PASS=0001, TOTAL ERRORS=0000
RANDOM PATTERNS TEST
WRITE SATURATION TEST

The manual tests also seem to succeed just fine!
 
Wonderful, so now you have an operational computer, CPU, Memory, and I/O, just the basics, everything else is just peripherals. Floppy disk support on this machine is the next challenge I guess. You've made such quick work of everything so far, by the way, how did you deal with C26 and C27?
 
Wonderful, so now you have an operational computer, CPU, Memory, and I/O, just the basics, everything else is just peripherals. Floppy disk support on this machine is the next challenge I guess. You've made such quick work of everything so far, by the way, how did you deal with C26 and C27?

C26 I left unpopulated until I need to order a bunch of parts from Mouser, as it's just a small power cap for the HEX inverter*. C27 I repaired by bending the annulus back and reflowing the joint, trying to cover up as much of the exposed trace as I could. I also cleaned things up some more, to try and prevent any further corrosion. If water or water-based flux got under the soldermask, though, I'm not sure if the reaction will be stopped by simple cleaning.

I've learned that the front panel won't work with the FDD controller in place, perhaps due an issue covered in an errata memo from Jade. I could cut some traces on the FDD controller to make it compatible with that front panel, probably.

I agree about the FDD controller being the next to tackle. I used the V2 monitor to dump and disassemble the controller firmware, but it's long and complicated. I still don't understand what's at memory location F5B8-F5D0, which are called at the very start of the computer's modified V4 Jade ROM. According to how I've read the switches, the FDD controller is located at FE00-FBFF. This area of memory isn't called until the second instruction in the modified V4 ROM.

There *are* valid instructions extending partway into F5B8, but jumping to F59F makes no sense, as it's partway through an instruction.

If anyone's trying to follow along with WTF I'm talking about:

The Jade V2 monitor ROM I'm using: http://pastebin.com/WEMZFcBz

The modified Jade V4 custom ROM that was on the 2716 EPROM: http://pastebin.com/68W0qjgV

The disassembled contents of memory starting at F020: http://pastebin.com/4e9nsiHx

* Or it might also be part of a low-pass filter for that clock generator IC (U11? The Xeroxed schematic is fuzzy)
 
Back
Top