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!
I refer to this system as a Pulsar 9000, but is actually really a loose interpretation of what a Pulsar 9000 might have been. It arrived as a collection of STD boards made by Pulsar, some STD subracks, some Pulsar enclosures, some TurboDOS manuals, some 8” floppy disks, and a few notes, brochures, price lists etc.
The work on the Pulsar 7500 helped to give some insights into how TurboDOS is used on a multiprocessor system, but this is a step-up in complexity and with less documentation. In particular, the specifics of how to install TurboDOS were missing.
The 7500 used Little Big Boards and SASI/Serial cards, and it arrived as a system. There was manual that confirmed the arrangement and how to boot it.
The cards had no labelling that indicated what they were, but matching the components with some brochures and price lists helped to identify them.
Amongst the cards were:
2x STD-6016 80186 CPU Cards – one with 256kB and the other with 1MB
10x STD-6080 Z80B CPU Cards
2x STD-6216 SASI Floppy RTC
The CPU cards were sold as masters or slaves. The type of card was probably just an EPROM change or jumper setting.
The STD-6080 cards are more powerful than the Little Big Boards in the Pulsar 7000. They have better inter-processor comms, including a network interface and through-the-backplane connectivity. They have no floppy disk interface.
Some of STD-6080 cards do not have the network interface installed.
The DIP switches possibly set the address of the card on the STD bus. Switch 7 appears to be the LSB. There are 6 cards that seem to follow a sequence of 0 to 5. There are another 4 cards that follow a sequence of 0 to 3. Perhaps two separate systems originally.
There is very little information available for these cards. There are some brochures but no manuals or schematics.
STD-6080 6MHz Z80B
The STD-6080 cards are more powerful than the Little Big Boards in the Pulsar 7000. They have better inter-processor comms, including a network interface and through-the-backplane connectivity. They have no floppy disk interface.
Some of STD-6080 cards do not have the network interface installed.
The DIP switches possibly set the address of the card on the STD bus. Switch 7 appears to be the LSB. There are 6 cards that seem to follow a sequence of 0 to 5. There are another 4 cards that follow a sequence of 0 to 3. Perhaps two separate systems originally.
There is very little information available for these cards. There are some brochures but no manuals or schematics. Some of the boards have the serial network driver – others don’t. I don’t intend to set up a serial network at present so it doesn’t matter much.
Based on the settings of the cards, the DIP switches operate as follows:
Switch
Function
Setting
8
Master/Slave
Set to On
7-3
Slave ID
On=0, Sw7 is the LSB. 0000 is slave number 1.
2
May be a part of slave ID. Not sure!
1
Don’t know. Maybe determines the network interface?
Set to On
These seem to be similar for the 80186 boards as well.
There is a 256k board and a 1MB board. The 256k board is labelled “master only”. I tried it as a slave, and although the boot sequence seemed to complete ok, there was no output from the serial port.
Before launching into a full build i decided to spend some time testing stuff out. Did the critical cards work? Did i have all the required disk images? What combinations work? Could i use a SCSI drive emulator with the SASI card?
I set up a small STD card cage with a power supply and used a 5.25” HD density 8” substitute drive for checking out the disk images. Disks were written with greaseweazle.
All the files, including the TurboDOS 1.4 Manuals and the Pulsar disk images, are available at the Microbee Technology Repository
Both STD-6016 80186 boards will boot from disk 8_287_01 using a STD-6216 SASI card.
The configuration utility on the boot disk allows setup of STD-6016 (80186) and STD-6080 (Z80B) slaves.
Adding a second 6016 board with the same configuration does not boot. Changing the DIP switches 8 on the second board allows the master to boot.
None of the STD-6080 boards will boot from their native disk, 8_288_01. They all boot as slaves to a 6016. There may not have been a master configuration boot ROM, or the configuration may be via a dip switch. This disk may not have boot tracks.
Once the system is configured to use a slave, the master is no longer available as a console.
The STD-6216 works with SCSI2SD, but I have not been able to boot from the SCSI2SD. BOOT looks like it can copy the boot tracks but no success. Perhaps some SCSI2SD tweaks might get it there.
The system won’t boot from floppy if the SCSI disk is on. It may be attempting to boot from the SCSI disk but failing in a big way. There is a SCSI2SD parameter to delay startup.
To configure the STD-6080 slave, the CONFIG program needs to be able to access the distribution files for the STD-6080 – particularly PROSLV8.SYS. I did this in a single user configuration by setting up the hard disk first and then copying over the STD-6080 files.
The STD-6080 slave cannot run the STD-6216 executables, so on startup it has to have access to its own files. It’s possible to switch to the master using MASTER, but there seem to be some limitations, eg the config program seems to gag. It’s fine with the 1MB card so perhaps less limitation with that card.
The distribution disk does appear to have a master system for the STD-6080, but I don’t seem to have ROMs to load it – unless it’s by configuration link.
Having demonstrated that it is possible to build a system using the 6016 and 6080 cards it was time to set up a more robust system.
I had a very large enclosure setup including the drive and an Adaptec SCSI interface card. It has a rear panel that supports lots of D connectors.
Although having 10 slave processor cards is overkill it would certainly demonstrate the capability of TurboDOS. None of the pulsar cages seemed to have the current capacity required for that many cards, but there was a spare Pro-Log cage that looked suitably robust.
The enclosure was designed for an 8” drive and the distribution disks are 8”. I had an unallocated NEC 8” drive from about the right period.
The power budget is as follows:
Device
+5V
+12V
-12V
+24V
Master 6016
3
0.1
0.1
10xSlave 6080
20
6 (I’d be surprised if it’s this high.)
1
Floppy Disk Drive
0.9
0.9
Hard Disk (est)
1
1.5
Fans
0.5
Total
25
7.6
2
1
Used
40
10
10
5 (will replace with 3)
I used 4 separate supplies which complicated the mains wiring a little but matched the loads. The -12V supply is the same as the +12V but wired for -12V. The fans run off it to provide a minimum load.
The main switch was originally a key switch, but without a key it needed to be replaced.
Any mains wiring that could come into contact with low voltage wiring was sleeved.
The card cage already had a power connector and loom so it just needed reterminating.
Layout was a compromise. The supplies had to be mounted with the terminal blocks accessed from within. The 8” drive pushed the cage back as far as it would go while allowing access to the power supply terminals.
Three fans were included – one to cool the power supplies and the other to cool the processor cards. The case lid was modified to allow for the fan inlets.
Note to self: I wonder if that poorly mounted crystal accounts for keystrokes not being seen by the seventh card (The order changed a bit).
I had two unallocated NEC FD1165 8″ Floppy Disk Drives. This is a half height unit that uses 24V for the spindle motor.
The heads on this unit are easy to access once the drive cover is removed. Annoyingly, the configuration links are on the reverse side.
This unit, in its standard configuration, refused to release the door latch which was a little inconvenient. I changed a solder link so that it was more willing – “in use”.
Section 2.8 of the maintenance manual:
Function
Label
Position
Setting
Drive Identification
DX
1
Device select 1 (first device select) – Drive A:
Head Load
HL
2
Head loads with device select
Radial Ready Jumper
RX
1
Ready Gated by Drive Select
Side Select Jumper
SS
1
Use side select signal
Write Protect Jumper
PR
1
Send write protect and enforces write protect
Door Lock
DL
2
HL.DSX + DLH DLH= Door Lock Hold
DR
2
DH
2
In Use (Solder)
IU
2
Read Data
RD
1
Enable read data
Busy Lamp Indicators
BU
1
BS
2
Weird setup!
T1
Installed
Prevent rapid head load/unload
One of the two drives (let’s call it drive one) had been dropped at some point in its life. There are some significant dents in the chassis and the top head was initially at an unexpected angle.
I repaired this when I was imaging the 8” disk collection, and the drive operated quite well during that exercise.
The second floppy disk drive was not reliable when I had previously attempted to use it but i had not investigated further.
I used the first unit to create system disks and these disks worked well.
While loading software on to the hard disk using the first unit, I noticed that some disks which had been successfully imaged with unit one were not being read by the system using the same unit one. Of course, the processing done by the greaseweazle is quite different from that done by a real floppy disk drive controller, so the performance is not necessarily the same.
I imaged my configured boot disk using greaseweazle with unit one. Drive two was swapped into the system. It did not work with the original disk or with a new disk written by drive one.
Drive two did boot if i wrote the disk using drive two. This suggested that the alignment of the two drives was different.
The second drive was able to read some of the disks that the first drive could not, but not all.
What followed was several days of frustration, which left me with the impression that these drives (in combination with the floppy disk controller and ancient floppy disks) are not quite at the peak of their performance.
I initially used just ImageDisk to align the drives. This is a little tricky because I have no reliable double-sided reference disks. I do have a reliable single sided reference disk. For the second side I checked alignment using disks that had been written back in the golden age when the writing drive was in its prime. I checked with several disks which may or may not have been written with different drives!
The drives were not optimum. I’m sure I aligned the first drive prior to imaging, but its possible the alignment has shifted (my shed temperature has dropped significantly). I adjusted the drives as best I could. Using the Microsoft Multiplan disk, the drives seemed solid from track 0 to track 76.
Changing to some other disks (with a smaller number of sectors) the performance seemed less consistent with marked variation between tracks. Adjusting the bottom head involves moving the stepper motor baseplate – three screws loosened and then using a screwdriver to muscle the baseplate in or out, noting that the tracks have about a 0.5mm spacing. Often drives have a mechanism that convert quite large adjustment to effect a small change in position. Not this one. It requires a very gentle touch to get it in the optimum position.
As for most drives, the top head is adjusted relative to the bottom head. It requires even more patience because it is mounted using two screws which, once released, allow a lot of movement over a 3mm x 3mm plane and a wide range of angles. Extreme patience is required. The maintenance manual doesn’t even describe this operation – recommending replacement of the carriage instead. Nevertheless, it is possible to manoeuvre the head into a good position. Both drives required adjustment.
Unfortunately, the PC disk controller was too sensitive (two easily satisfied), so i could not get the alignment quite right for the actual system, which is fussy. I still had trouble reading original disks.
I then turned to instrumentation. I used the test points (8/9) and an oscilloscope in differential mode to get some additional info – the magnitude of the signal. This is at the output of what may be a custom amplifier. As was clear during the imaging of the 8” disk collection, performance declines with track number. The signal to noise ratio is significantly worse on the inner tracks, even when optimum. It was also clear that the magnitude was not steady.
I also happened to have an SA 120 alignment disk, which is very good for aligning the bottom head, but not the top head. It’s single sided!
The test signal is at Track 38. 100mV/div. 20ms/div. It is the gold standard, but may be less than optimum for the disks if they have been written out of alignment. There may also be a better compromise position if the top head is just a little out.
The whole concept of reducing the write current on, what are smaller sectors, seems to be a solution fraught with peril. Maybe they should have stopped at 60 tracks. I’ve noticed repeatedly that failures are likely on these inner tracks.
Having used this method the second drive was pretty good but the first drive is still unreliable.
Along the way I found a few things:
When I configured the boot disk I added the card boot files to a disk that was close to full, so they got written to the inner tracks.
I found that on occasions the boot process gave up on the floppy disk and went looking for the files on other drives eg the scsi2sd drive. This eventually led me to find that the floppy disk only needs to contain osload.com. No boot tracks are required. Osload is happy to load the card boot files from E:, after which E: becomes the system disks. For whatever the reason, the ROM can find Osload on the floppy but not on the scsi2sd.
If the drive is configured as drive 2 (second device select) it still boots but the drive is B:.
I had one more try at the first drive. I spent a lot of time making sure that the alignment gave the same amplitude for both heads. I checked it with a disk written by the second drive. It was not identical, but it was pretty good. But still it would not boot from disks written by the other drive.
In desperation, I thought I would just try aligning the bottom head (and hopefully the top head with it) by nudging and trying to boot. Eventually a found the correct position. It was not a big change but it was definitely different from where I had it. So, in a boil over, the correct position is not where the maximum amplitude is – unless, of course, something moved.
I noticed discrepancies between the two drives, so I tried a new alignment technique. Noting that problems are exaggerated on the inner tracks, I used greaseweazle to read just the inner tracks. The Disks were written with the second drive and read back with the first drive. By adjusting the carriage alignment in very small steps and then reading back it was possible to improve the alignment until bad sectors were not read.
This proved to be quite effective. Although the alignment was good, it is simply the case that the first drive does not read as well as the first. One disk would not boot on the first drive, but would on the second. Reading with greaseweazle with either drive was fine – even with only one rev. Once the disk was written with the first drive it would boot on either.
Along the way I noticed that the floppy disk controller card offers some options wrt precompensation. There are some links on the card. I have no idea whether the settings are correct for the drive. No doco. No mention of precompensation in the drive manual.
I think I now have two drives that a reasonably aligned. I have loaded a lot of software off a variety of disks using the second drive. No doubt the alignment of the two is imperfect. The second drive seems to perform better – perhaps it is better aligned, but I think its read circuit just performs a little better.
Greaseweazle/HxC perform better than the physical drive controller. I guess that’s the advantage of processing power and the ability to post-process but i have had the converse as well eg the Sorcerer with the Micropolis controller.
