Inside the IBM PC style enclosure are 5 little big boards – one of which acts as a master to control drives and printers. The monitor is an IBM terminal, which is much younger than the computer.
The other four little big boards support 4 users via serial terminals. Each of these is connected back to the master via a serial line. These cards all run Turbodos. Each provides 64kB of memory for running CP/M programs.
The master provides access to a floppy disk drive and a SCSI hard disk – emulated with a SCSI2SD.
I connected it up to a serial terminal, but I couldn’t get anything out of any external serial port. The hard disk did not spin, so it may be a lost cause.
I had no boot disks for the floppy disk, although i thought it may be possible to create some from the 8″ disk collection. Many of the disks were related to Pulsar – both CP/M and TurboDOS.
Working in the case was a little cumbersome, so I pulled the system right down to the boards:
It consists of:
1x Master LBB with STD and Floppy Drive Interfaces
4x Slave LBB (with a variety of options which are probably not used)
2x SASI/Dual Serial Boards
1x Mitsubishi M4854-342 High Density Floppy Disk Drive
1x NEC LR 56913Hard disk drive with Adaptec ACB-4000 SASI adapter
1x Sysquest removable disk drive with Adaptec ACB-4000 SCSI adapter (external to computer and mounted on it’s own baseplate)
There is a lot of variation amongst the slaves. Perhaps from card swaps over the years, or perhaps this machine was put together using whatever was in stock. Serial port connectors can be straight or right-angled, a bare header, or a shrouded header, sometimes with release levers.
Each of the slaves is connected via serial to the SASI/Serial cards. The master owns the bus and therefore the SASI/Serial cards. The slaves must not attempt to use the STD bus, so where the interface is loaded it has to be nobbled with track cuts.
There seems to be no reason why the slaves need to be in the unit – they could just as easily be located elsewhere but there is not a lot to be gained as either way a serial connection is required.
The serial ports on the master were used for printers.
I tested each of the boards with an MP7A Monitor ROM in a different chassis.
The master little big board does come up ok, so probably it was silent at switch on because that’s how the boot ROM rolls.
Two of the slaves were ok, but the other two were not working. One had a bad solder joint and the other had lost 12V connectivity because the track is very close to the board edge was severed. The damage would have occurred when I levered the board out of the backplane (there was no other way).
I could not get the master to boot from the floppy disk, even after adjusting the phase-locked loop as per Pulsar instructions. I parked that board and used a spare, which did boot.
From there the configuration tool was used to setup the slaves. There are a lot of questions about each slave. I took the easy options with automatic login of the privileged user.
The 7500 system uses a 5.25” drive rather than an 8″. As it turns out, the floppy disk drive in this unit, Mitsubishi 4854-342, is intended as an 8″ replacement – it even claims to be a 77 track drive although i suspect it’s good for 80.
The 50 pin host interface is connected to the 34 pin drive interface via a simple adapter. All up, this means that the 8” images can be written to HD 5.25” disks.
Looking at the simple 50/34 adapter board, I suspect that the drive has a couple of signals that may not be present on a 5.25” interface – Ready and 2Sides. I imagine that 2Sides is always asserted because there is no way for a 5.25″ drive to know if a disk is single sided. 8″ drives can.
The drive was cleaned and lubricated and tested ok with Imagedisk.
8” Pin
8” SIgnal
5.25” Pin
5.25” Adapter
Comments for Emulation with Gotek
2
TG43_L
Not used
4
6
8
10
2SIDES_L
2
REDWC_L
Not driven by controller or gotek. Pull down
12
14
SIDESEL
32
SIDESEL
16
18
HEADLOAD_L
4
Not Used
20
INDEX_L
8
INDEX_L
22
READY_L
34
DISKCHG_L
24
26
DS0
10
DS0
28
DS1
12
DS1
30
DS2
14
DS2
32
DS3
6
DS3
34
DIRC_L
18
DIRC_L
36
STEP_L
20
STEP_L
38
WDATA_L
22
WDATA_L
40
WGATE_L
24
WGATE_L
42
TRACK0_L
26
TRACK0_L
44
WRTPRT_L
28
WRTPRT_L
46
RDATA_L
30
RDATA_L
48
50
16
MOTORON
I wrote an HD floppy disk from 8″ disk image 8_257_02 (Pulsar Turbo V1.3 Master Configuration Sys 14 Config V24 Single User) using greaseweazle.
The system has two SASI cards that I thought might accept a SCSI2SD card.
The drive configuration comes up in two places – firstly in configuration of the master or single user system configuration program, and then again when the drive is formatted.
In both cases, the following information is required:
SASI card number: 0 worked for one card but I tried multiple numbers with the other card without success
Drive Number: It allows 1 or 2. 1 seemed to be SCSI ID 0.
The configuration also deals with partitioning. The default partition size is 4MB which is the optimal size. With large drives, that’s a bit of a nuisance because you need a lot of partitions. Having some optimal 4MB partitions and a larger sub-optimal partition seemed like a reasonable compromise.
The drive selection gave some geometry, but the specifics probably don’t matter with a SCSI2SD. The SCSI2SD was set up with a simple 32MB disk at ID 0 with 512B sectors. Termination needs to be on.
The process went like this:
Create a fresh single user floppy disk
Run the Configuration program and select modify
Set up the hard disk as above
Format the hard disk using HFORM30 with the same disk parameters
At this point the new drives were available starting at E: but when the directory was listed it appeared the disk was read only and the directory looked corrupted. It didn’t seem to matter if the format was done first and then the configuration.
The “Creating Boot Tracks” section of the System Initialisation Procedure mentioned a program called ERASEDIR but really just in the context of making faster hashed entries. Running this program on each of the drives resolved the issue. It says to run this after BOOTDISC (which writes the boot tracks).
So:
Run BOOTDISK and write to E: – only the first partition can be a boot partition. It can also be written to A:.
Run ERASEDIR on each of the new drives from e: to the last one.
Copy all the files from the A: to E: using DO DCOPY A: E:
When the system is powered up, it looks for a bootable drive. If a boot floppy is in A: it will use it; otherwise it will boot using E:.
Programs were then copied on to the solid state disk from a gotek. TurboDOS supports multiple user areas so the these can be used as directories. User 0 files marked a global can be accessed by all users.
All users are assumed to be using Televideo 950 terminals. A lot of the software on the 8″ disks was configured to use this popular terminal.
Pulsar was an Australian computing company located in Melbourne, Victoria. They made STD cards and computings systems based on the STD bus and often using TurboDOS.
TurboDOS is a multiuser/multiprocessor operating system that can execute CP/M programs.
Eight Z80 processors and two 80186 processors share an 8″ floppy drive and a SASI/SCSI hard disk, supporting 9 concurrent users. Each Z80 user gets their own 64k in which to run CP/M-80 programs, while the lucky 186 user scores 256kB in which to run CP/M-86 programs.
The master board, a 80186 board, loads the operating system from disk and, once it is up, it transfers the operating system to each of the slave cards.
All the rack-mounted cards are bona fide eighties cards. The rack and the 8″ drive are also of the time. The re-construction is new. I was able to find only very scant details of the Pulsar 9000, but i did have a complete set of cards and some software handbooks. It looked like a project!
Generously given to me by Michael from the ARC Group.
The Model I was originally released in 1977, but this one was made in about 1980. It has 16k of memory and has been highly modified.
It also came with an expansion unit with RS232 interface and 32k of additional memory. There was no disk drive, but that was only a minor obstacle.
It also came with an original monitor (probably not the ideal one to use with the expansion box), buffered cable to connect the computer to the expansion unit, a box which turned out to be a high resolution graphics mod, a joystick, and dust covers.
At its core this is a Cromemco 68000 system. It lacks the Cromemco chassis and Cromemco disk drives but it has a complete card set including:
a DPU Dual Processor Card with Z80 and 68000
a MCU Memory Control Unit
a 512MSU Memory Storage Unit connected to MCU via a MBus ribbon cable.
a 16FDC Floppy Drive Controller
2x TUART Twin UART
The chassis is an Australian made SME unit. I constructed the drive chassis based on an old STD chassis. It includes two Mitsubishi 8″ drives, a Mitsubishi 5.25 77 track drive and a gotek.
I have since added a modern IDE/CF Card for solid state storage and a modern 8MB RAM card.
It runs a very impressive unix-esque operating system called Cromix Plus. It supports up to 5 users via serial terminals. It can run 68000 programs and most programs written for CP/M. Each user can run multiple tasks.
I will probably do a lot of posts on this machine because it is fairly unusual and involved a lot of work. I do want to mention upfront that the solid state solution in this machine was made possible by the ever innovative John Monahan and software efforts of Damian Wildie.
Andrew, a friend from the ARC Group, has supplied me with a lot of funky gear including a box of S-100 cards, a couple of chassis, several 8″ floppy disk drives, and about 500 8″ floppy disks.
I never imagined that i would get an opportunity to work with S-100 bus. Components are difficult to find and, when they do appear, people expect an arm and a leg for them.
I had no idea if any of the cards were related to a particular system so all i could do was catalogue them and see if any patterns emerged. One pattern did emerge – there were several Cromemco cards including:
a Single Card Computer (SCC)
a 64KZ Dynamic Memory Card
a DPU Dual Processor Card with Z80 and 68000
a MCU Memory Control Unit
a 512MSU Memory Storage Unit connected to MCU via a MBus ribbon cable.
a 16FDC Floppy Drive Controller
a TUART Twin UART
Not knowing much about Cromemco, i started reading and a new world opened up. The Cromemco community seems to exist primarily as a Google Group with a huge repository on GIT. This proved critical because i did not have a skerrick of software or doco. There was nothing related on any of the 8″ disks that i had.
The repository includes a vast array of manuals, disk images, software etc.
I realised that there were sufficient cards to be able to build a system capable of running Cromix (a Unix look alike). It would consist of:
a DPU Dual Processor Card with Z80 and 68000
a MCU Memory Control Unit
a 512MSU Memory Storage Unit connected to MCU via a MBus ribbon cable.
a 16FDC Floppy Drive Controller
a TUART Twin UART (optional)
I’m not sure where these cards came from. Perhaps they had been used in a bespoke design or stripped out of a Cromemco system. If the latter, then the chassis and drives have not made it into my hands. I will need to use a third party chassis, drive enclosure, and drives. Also, notably missing from the list, is a hard disk controller such as the Cromemco WDI-II but i did see that it was possible to run a skeleton Cromix system from floppy disks. That would be good enough for me (until it wasn’t).
It was also possible to build a system capable of running Cromemco DOS (a CP/M look alike) and that seemed like a less intimidating option to start with. It would consist of the following:
a DPU Dual Processor Card with Z80 and 68000
a 64KZ Dynamic Memory Card or an MCU Memory Control Unit and a 512MSU Memory Storage Unit connected to MCU via a MBus ribbon cable.
a 16FDC Floppy Drive Controller
And there was an even simpler machine that could be built using just the SCC.
I started with the SCC and then used it to help locate faults in other boards. Then i moved onto the CDOS system which was also handy for finding faults in the 68000 system.
The Cromemco Single Card Computer (SCC) design dates back to 1978 and this particular unit appears to have been made in 1978 or early 1979.
It has a Z80 processor running at 4MHz, 1kB of RAM, space for 8k of 2716 ROM, three parallel ports and one serial port.
The board was ROM-less but the binaries for the usual ROM set, MCB-216 were available online. These ROMs provide a monitor and 3k basic.
This means that with the addition of a terminal it’s possible to have a single card capable of executing programs that can exercise the S-100 bus.
I burnt the code into a couple of EPROMs, hooked up a terminal, and gave it a whirl. It fired up as if 45 years meant nothing. It starts up basic to start with but QUIT sends it to the monitor and B in the monitor sends it back to basic.
Programs can be saved to memory including to EPROM on particular Cromemco boards. They can also be saved to or read from the serial port.
The Monitor includes a memory test. I used it to check out a number of memory cards, with some success.
The Cromemco 64KZ appeared to be working fine. One board didn’t work because it expected pSTVAL to be driven and the SCC does not drive it. This was when i started to understand that the S-100 bus was not as “standard” as i had thought.
The main outcome was that i had a Cromemco memory card that was likely to be functional.
Cromemco CDOS is a lot like CP/M and can run CP/M programs.
There were sufficient cards to build a simple CDOS system. This is an interesting system in itself but is also a stepping stone to a Cromix system.
The cards are:
a DPU Dual Processor Card with Z80 and 68000
a 64KZ Dynamic Memory Card
a 16FDC Floppy Drive Controller
The DPU is overkill for CDOS but there is one very important CDOS program that is useful to the DPU: the 68000 memory test. That would prove to be handy later.
The 16FDC floppy disk controller has some handy bonus features: a serial port for a terminal and a monitor ROM running Cromemco RDOS.
A TUART can be added to provide parallel interfaces or additional serial interfaces for printers or other devices.
The RDOS Monitor version in the ROM is 2.01 which is capable of booting an operating system from a 5.25″ double density floppy disk – but not from an 8″ disk. The card itself has a 34 pin interface for 5.25″ drives and a 50 pin interface for 8″ floppy disk drives.
I connected a 40 track drive and created a disk from a CDOS image retrieved from the Cromemco GIT repository.
Continuing what had so far been a good run, the RDOS monitor came up after a few key taps (to autodetect the baud rate)and giving a b (boot) command initiated a successful CDOS boot.
I really should have stopped and had a good play with CDOS, because my lucky run came to a halt shortly after this.
