Many Australian computer manufacturers have come and gone, and many of those have left remarkably few artefacts by which to be remembered. This is often the case with business oriented companies such as ECS Microsystems.
This machine belongs to Michael N from the Adelaide Retrocomputing Group. Michael is in a position where he is able to intercept treasures such as the 4500 before they depart this world.
The ECS 4500 is a CP/M machine from about 1984. It uses a Z80 processor, has 80kB of RAM, and uses two Micropolis 77 track double-density 5.25″ drives (with a curious mod that i discovered).
The ECS is notable for the way it generates characters on the CRT and for its unusual disk format. More on these to follow.
Michael rescued two of these machines when they were pretty down on their luck:
As is often the case with computers that had detachable keyboards, the keyboards had been lost.
Fortunately, they did come with some manuals:
ECS 4000 Series Technical Manual
ECS 4500 Operating Guide
Time 4550 Operating Guide
These have been scanned, and Alan Laughton has uploaded them to the Microbee Technology File Repository:
The design is quite neat, with the plastic chassis with drives and CRT lifting off the rest of the system, which is mounted on a steel baseplate.
There is a card cage at the rear with two special slots (Power Supply Board and Video and Deflection Board) and 6 general purpose slots with:
Processor card
Memory Card
I/O Card
Video Control Board
Floppy Disk Controller Board
The slots are arranged as two columns of 4 cards.
The video deflection card was missing from the second unit so that put restoration of that machine out of reach.
There are additional I/O adapter modules at the bottom of the unit on an inset fascia.
Also mounted on the baseplate are:
A transformer/terminal block for the linear power supply
Power switch
A 5V regulator on a heatsink
An anode voltage power supply for the CRT
A small speaker
Brightness control
The earthing approach looks solid.
The transformer appears to be in good condition. It has a terminal block for setting the line voltage. This was set to 220V, but I have moved it to 240V to make life a little easier for the power supply. Perhaps there was a reason for pumping up the voltages, but the supply outputs look ok.
There is a power indicator for each supply on the backplane.
The +26V was a little high.
The drives are Micropolis 1015-2 77 track units similar to the ones on my Exidy Sorcerer.
There are a total of 7 cards in one machine. The Video Deflection card was missing from the second unit.
Resto Unit
Spares Unit
Description
Power Supply
Early Variant
Late Variant
Provides 5, 12, -12, -5, +26V. Note that the 5V regulator is mounted offboard on a heatsink at the bottom of the unit.
Video & Deflection
Missing
This provides all the analogue stuff for the video display. It’s quite unique. It’s also very rough with a lot of mods.
Microcomputer
Z80 processor, 8051 UART, 2716 ROMs and 16k RAM that can be switched in place of the ROM. The monitor will come up with just this card and the two video cards.
RAM
80k DRAM.
Video Control II
All the digital stuff to produce the video signals. No memory – it DMAs from main RAM.
Input/Output
Missing Z80APIO
Has Z80APIO
Provides parallel and serial ports. The parallel port chip is missing from one card.
Floppy Disk Controller
Bespoke floppy disk controller card. Writes a unique format.
Powering on the system quickly brought a stream of smoke from a resistor on the back of the Video & Deflection Board. The system can only be powered on for a few seconds at a time.
On closer examination the board has had a lot of mods. There are multiple track cuts, added components and changed components eg a resistor in a diode location.
There are no schematics, but there is a service manual. It has some block diagrams with some references to part IDs and some useful circuit description. It clearly indicates, though, that the high voltage circuitry changed a lot after serial number 10000.
Video control is unusual. Most CRTs use two deflection coils. The scan slowly downwards and quickly horizontally. Characters are formed progressively as a character line.
This system uses three deflection coils. The vertical deflection is performed in 25 steps under the control of a digital to analogue converter. Fly back is very fast: it can happen in the same time as the horizontal flyback.
Within each of the 25 lines each character is formed individually (I wonder if the lexitron does the same thing) using a series of vertical strokes.
This means that there are three deflection channels:
Vertical: 50Hz in 25 steps with each step lasting 800us.
Horizontal: Each sweep corresponds to one vertical step ie 800us.
Write: Quick – 1.06Mhz
The hot resistor was tacked on to the back of the board among a bunch of mods. It seemed to be associated with the write deflection circuit. It was not going to make any sense without a schematic. I suppose I could have just started swapping components and I would have gotten there in the end (as it turned out). That’s not a technique that teaches much, though, so I sketched out the circuit instead.
The hot resistor measured 56 ohms and was connected to the 26V supply and to the collector of Q8 which is involved in the generation of the write deflection signal. This circuit had been heavily modified. Part of that mod was to provide a power to the high voltage power supply. It also provides the cathode voltage (not shown on the block diagram in the manual). I found that this resistor continued to heat up even without the writing coil, the tube, or the high voltage power supply connected. That didn’t leave many places for the current to be going – just the unloaded cathode voltage circuit.
Looking at the Cathode supply, the tantalum appeared in good condition and the meter didn’t show a short. Putting it on a power supply did reveal a fault with a little more voltage. The tant was replaced with a couple of electrolytics and the burnt resister was replaced with a couple of smaller resistors in parallel.
As a side-effect of this exercise, I learnt about transistors (Q8 in this case) operating in an inverted mode. Nifty.
With this resolved, the screen came to life but with a limited horizontal deflection and no vertical deflection. I found that touching pots gave a significant effect and after some cleaning a full picture appeared – filled with rubbish – but that’s a different story.
The vertical step D/A uses a resistive ladder. It has five adjustment pots. It looks like the 3rd bit is not quite right. Actually, they all look like they need some adjustment.
I did discover that some of the heatsinks are live so some electrical screw drivers are a good idea.
Once i got the screen working i was presented with rubbish.
I needed to image the ROMs for posterity, and that also revealed that one of the ROMs had lost its mind. Fortunately, the ROMs in the spare Microcomputer card were good.
With this and some messing around with the onboard RAM, i was able to get a myriad of outcomes, some of which included evidence of the power-on monitor starting up.
The sockets are great and despite cleaning i could not the system to start. I changed to the spare Microcomputer card and was excited to get a monitor prompt.
I added an empty RAM card and started adding RAM, checking as i went. There was only one faulty 4116.
I added the rest of the cards one at a time with the same result. I could go no further without a keyboard.
The machines did not come with a keyboard, so i needed to knock something together.
The technical manual gave me some clues:
The keyboard clock was about 75kHz.
I wrote some keyboard code for Arduino Uno. It needs direct port reads and writes to be fast enough. I worked out pinout for the keyboard connector and made up cable to the Uno.
Initially I had no joy at all, but found a broken pin on the interconnect between the board and the I/O module used for the keyboard. This deceived me with the pinout – I had 5V and the data input reversed – lucky there was a current limiting resistor. Once fixed, the keyboard recognised when a key was hit but made no sense of the data.
The data seemed to be making it to the shift registers, but the control of the shift registers looks a bit random. There is a monostable involved. Perhaps a dead tantalum. I’ve had a few lately. Back to buzzing out circuits.
This is roughly what I found:
It’s not 100% accurate – I used a 2716 instead of the 2708 just because the symbol was already there, and I’m lazy.
The start bit triggers the monostable and, once it works its way through the registers, it disables the clock.
The monostable times out after about 250ms when it clears the shift registers which re-enables the clock. I found some glitches at the input to U50C which became pulses at the output and prematurely cleared the shift registers. I don’t know why the little filter is there, but it gives an opportunity for noise as much as it removes it. I halved the resistance and the problem went away.
The ROM is small but quite large for character mapping – 1024 possible inputs and 256 possible outputs. When the clock stops, 16 bits are captured in the shift registers. The first one is the start bit. The next 10 feed the EPROM. The last 5 may not be used at all, but could be used eg for a hard reset.
The manual suggests the scan codes are converted to ASCII. I needed to feed in the unknown scan codes. Being a 2708 i could not read the EPROM with my programmers (i can now). I had to catch up with Andrew P at the ARC to borrow his EPROM reader.
I was impatient though so I attempted to work it out.
There are a lot of codes to enter, and the system doesn’t respond to many of them. Often, it gives the same response to several codes. Sometimes the response is one-way and requires a power cycle. The manuals give some clues but not enough.
Curiously there is a monitor command that goes into a terminal mode where everything goes out the serial port. I had already discovered that depending on when I entered this character I sometimes got a “t” or the screen cleared and machine hung – this is the terminal mode!
I connected an oscilloscope and used its RS232 decoder to check the ascii characters. The port requires a null modem to transmit. It worked fine.
This was a much better way of seeing what was generated for each code, but there were still several codes generating the same ascii characters or the same ascii characters with the eighth bit set.
I used the first code that created a character to make a map which I added to the Arduino code. It’s kludgy to use the Arduino serial monitor, but it seemed to check out ok. It was good enough to try to boot the machine.
With a semi-operational keyboard, it was now possible to issue a boot command.
I had already imaged the disks that came with the machines. This was two or three years earlier when Michael have first acquired the machines.
I put the disk images on to a Gotek running FlashFloppy. At first there were just errors, but it was good that the machine was even trying to read the emulated disks. The select lights were coming on as expected.
Often it looked like the machine had thought that the code had been loaded and had attempted to run it (the ROM was being switched off) but the screen was full of garbage. I thought it could be a RAM problem.
I was able to initialise a disk using the monitor “v” command. When I read it back with a greaseweazle and looked at the image in the HxC software, it did seem like the initialisation had worked.
I left the gotek attached, and while I was messing with the keyboard mappings I was surprised to find that it had booted. This only happens with the first image which is the 64k version of the system. Ok, i thought, i’ll run with that for now!
The three DIR entries above were with different scan codes.
I was dismayed to find that the mappings did not seem to work, but in many cases changing to alternative scan codes fixed the problems.
One of the disks does suggest that there was a “new keyboard”. The ROM would allow for different mappings for different keyboards, perhaps.
Still, only one disk image booted. When I looked at the images with the HxC software they seemed to have the wrong number of tracks. I did these images a couple of years ago using one of the drives in this machine, but it didn’t seem entirely reliable then. Since then, I have acquired several of the same 77 track 100TPI drives (although this machine seems to push that to 80).
I re-imaged several disks using the single Micropolis drive unit from the Exidy Sorcerer, and this returned much better results with the gotek.
A couple of the system disks complained that the “floppy disk gate was not closed”. I thought this must have been a door closed signal that’s being expected. What it was trying to say is that the controller expects Ready on pin 6 because that is where it is on Micropolis drives. On a gotek it is on pin 34 and pin 6 is unused. I added a wire on the controller to connect pin 34 to pin 6.
Warning: This description is lengthy and technical. The punch line (TLDR) is that ECS runs the drives at about 285rpm rather than 300rpm and that messes with a lot of tools.
I had previously done some work on the two drives in this unit but neither of them was good. One had a dud tacho in the spindle motor. I had previously used the other to copy some of the disks, but I was not sure how well it was working.
The other two were very dirty:
Blew out the leaves, webs, dust
Cleaned out the grease on the door lock and head shaft and re-greased.
Cleaned heads
Replaced missing felt in top “head”.
I put both viable drives on ImageDisk and formatted a disk on each and then ran an alignment test. All good. Then I swapped the disks and not all was good. There was a discrepancy on tracks 76 to 77. This resolved with cleaning the lead screw.
The format is interesting; 80 tracks on a 77 track device for a start. There are no physical sectors – just tracks with each track having a CRC. According to the technical manual each track has 6144bytes of data with two bytes of preamble and a single byte sync. The checksum is 2 bytes. The total count is 6149 bytes. This means that if one bit is out the whole track is dead. There are 48 logical sectors.
That gives 491k on a single sided disk cf 180k on an IBM single sided disk or 6.144k per track compared to 4.6k for IBM. That’s 4:3. How? There is no sector overhead and the whole track is used – very tightly. At 250k/s this data would take 197ms to write. One rotation at 300rpm takes 200ms so this is tight.
According to the Micropolis manuals, the drives spin at 300±6rpm. The period can be as small as 196ms. The normal bit rate for double density 5.25” drives is 250k/s. That’s 49kbit/track or 6.127kB/track. That means that there would not be enough space for the ECS track data.
I imaged all the disks using the Sorcerer single drive unit and greaseweazle v4. It was a struggle to gets disks to operate reliably with the sorcerer and I can’t be 100% confident that the single drive unit is perfectly aligned. It has been working fine for reading and making sorcerer disks though. The Sorcerer drive runs very close to 300rpm.
Looking at the fluxes with the HxC software, it appears that the bit rate is a little higher than the “standard” 250kb/s. Instead of seeing intervals of 4, 6, and 8us (as expected for 250k MFM coded data), there intervals are 3.8, 5.6, and 7.4. This is reading “factory” disks at about 300rpm. This is about 265kbit/s. That’s 52kb/track or 6.49kB/track which is sufficient to hold the documented track data.
Nominal 4us
Nominal 6us
Nominal 8us
Disk 10 (299rpm)
3.8
5.6
7.4
Disk 11 (299rpm)
3.8
5.6
7.2
Disk12 (298rpm)
3.9
5.5
7.4
So the data rate for the ECS system is higher than the norm or, noting that both of the drives seemed to be running quite slowly, it is also possible that the data rate is normal but rotational speed is lower.
Regardless, I would expect that reading and writing with the same drive would preserve the data rate ie the archive drive speed should not matter.
I tried some experiments:
Sorcerer drive =300rpm
ECS Drive = 277rpm
In principle, it is possible to write SCP images back to disk, but in practice the errors pile up. It’s usually better to convert to HFE and then back to SCP which has the effect of “tidying things up”. HFEs can also be used in a gotek.
The HxC software may handle the strange timing well – or it may not. It’s hard to say. It certainly gets confused about rotational speed when using the track analyser. It looks like to tries to change RPM to correct the data rate.
a. Read disk 31 using sorcerer drive to SCP. b. Convert to HFE. This averages the timings – 7.75us. c. Write HFE to sorcerer drive. This writes clean timings to disk. d. Read back using sorcerer drive. e. Convert to HFE. f. Surprise result: The data rate has increased again. I smell a rat; 7.75us is now 7.5us.
a. Read disk 31 using sorcerer drive to SCP. b. Write SCP to sorcerer drive. c. Read back using sorcerer drive. d. Convert to HFE. Same result: The data rate has increased again. 7.75us is now 7.5us. This cuts HxC out of the loop. This is a greaseweazle thing!
a. Read disk 31 using sorcerer drive to SCP. b. Convert to HFE. c. Write HFE to ECS drive. d. Read back using ECS drive. e. Convert to HFE. Another surprise result: The data rate has slowed down. 7.75us is now 8.0us. The drive is running slow: 277rpm.
a. Read disk 31 using sorcerer drive to SCP. b. Convert to HFE. c. Write HFE to Sorcerer drive. d. Read back using ECS drive. e. Convert to HFE. f. Another surprise result: The data rate has slowed down. 7.75us is now 8.1us. The drive is running slow 277rpm, whereas the sorcerer was very close to 300rpm.
I had expected that the data rate would be preserved if I wrote to and read from the same drive. It was not. I still can’t work out exactly what is going on here, but I suspect that greaseweazle is correcting the data rate to 250kb/s when it writes.
It eventually dawned on me that I could observe the data rates on the real machine and I could also have it write to a floppy disk. This quickly confirmed that the data rate is 250kb/s so the drives were definitely intentionally set up to run slowly.
I suspect (pure speculation!) that the original design forgot to allow for inaccuracy in the rotational speed (it is not clear whether the time during the index pulse is useable). Using nominal timing, the available period is 200ms. At 250kb/s this is 50000 bits or 6250 bytes. Recall that 6149bytes need to be written, giving only 100 bytes or 3ms margin.
Perhaps variation in rotational speed or in the index pulse timing caused issues in practice, and the remedy was to drop the rotational speed by 5%. This does have the effect of increasing the bit density on the media by 5% and, given that 80 tracks are used rather than the specified 77 this makes the bit density on the inner tracks much higher than other computers. Track 68 on this machine has the same bit density as track 77 on others eg the sorcerer. This could be expected to make the inner tracks less reliable than other computers.
It turns out that ECS printed up new strobe labels with 21 ticks instead of 20 and stuck them on the drive band wheel so that the drives could be easily adjusted to about 285rpm. This combined with the use of 3 tracks above spec probably means that the specified bit density is very high on the inner tracks.
If I write the disk back using the sorcerer drive and then use the disk in one of the slow ECS drives, then the data rate will be lower than the original. This is odd indeed.
If I write the disk back using a slow ECS drive and then use the same drive, the data rate will be correct. Also odd, but perhaps convenient.
Unfortunately, the data rate produced by the Goteks (with FlashFloppy) using the HFE created with the sorcerer drives is incorrect. The cleanliness of this data seems to allow them to generally operate anyway, but they are less than ideal.
The disks have been re-imaged using 285rpm. These images can be written back at 285rpm and all is sweet. The HxC software struggles with the low disk speed. Sometimes it works, sometimes it crashes, but mostly it just processes the data incorrectly so it is no good for HFE conversion. The bit streams are fine though, so maybe one day it will be good. I created HFEs using greaseweazle, and they work fine in the goteks – generally better than the 300rpm versions.
3 of the drives appear to be working ok. The last one has a tacho fault in the spindle motor. It can be a spares unit. One unit had a cracked power connector solder joint. That is probably a result of the constant connecting and disconnecting.
One had a screw broken off (holding the base cover). I drilled it out. It wasn’t pretty. I ended up redrilling and tapping the holes for 4mm screws (some of the originals were missing anyway. I think the covers and screws (and possibly taps) were an ECS thing anyway.
Alignment is tricky. The usual goto is Imagedisk, but it doesn’t recognise the ECS formatted disk. I have chosen a gold standard drive – one that seems to work well with existing disks – and have used it to write an “alignment disk”. This disk has been formatted in imagedisk. I only had to adjust one drive.
Note that one of the drives is a later version that is not covered by the schematics in the maintenance manual.
The images have been sent to Alan Laughton to add to the Microbee Technologies File Repository. Because the disk format has not been deciphered, the files have not been extracted.
It took some time to resolve the ambiguities in the scan code mapping, but that seems to be working well now.
The adapter has been moved into a small box and the PS/2 keyboard added. The PS/2 library did not handle control characters which made things a bit kludgy (as per the Lingo keyboard emulator) with key sequences having to be used.
To resolve this, the library was modified to work with control keys. Mappings were also adjusted to support function and arrow keys.
The original Arduino Uno was replaced with a new unit. A track has been cut to disconnect the 5V from the USB connector. This is so there is no conflict powering the adapter from the ECS 4500. A 1A resettable fuse has been added on the 5V line from the ECS 4500. The protected power is routed to the Uno and the PS/2 keyboard.
Lastly, the reset circuit was reverse-engineered and the keyboard adapter code modified to allow a reset to be generated by typing Ctrl-R Ctrl-E Ctrl-S.
