The Input Output board that was originally in the unit did not have PIO so it has been replaced with the spare card. This may allow the use of a parallel port printer.
Ports from left to right looking from the rear:
25 Pin Female D
Daisy Chain Serial Port on RS232 Buffer board. Do not use.
25 Pin Male D
Serial Port on RS232 Buffer Board. This sis connected to the 8251 on the Microcomputer Board. This port is the terminal connection for dumb terminal built into the monitor ROM and initiated with “t” at the monitor prompt. 9600, 8 bits, no parity. A null modem was required to connect to a PC.
25 Pin Female D
Serial Port on Datacon board. This board is connected to the SIO on the Input Output Board. Level shifting is done on the Input Output Board. 2400, 7 bits, odd parity. May be configured as the printer port.
25 Pin Female D
Parallel Port on Intercon Board. This is different from the original configuration which used a Concat Board. The Intercon Board is connected to PIO Port A on the Input Output Board. This may work with a parallel printer but without success so far.
System configuration is important to make these devices work.
The DIP switches on the I/O Board may have an effect. There is some info in the manuals, but it is patchy.
Virginal system disks seem to be absent so it is necessary to construct a couple based on my best guess of what was on them.
There seem to be two main categories of operating system: 64k and FAST. There are different versions of both. The FAST (File Access Storage & Transfer) uses the addition 32k above 64k to improve performance, eg by providing disk buffering.
The Checklist in the documentation is quite specific about the FAST files, so a disk has been prepared based on that list. RUN.COM could not be found.
The 64k version described in the manuals is version 8.3, but the coverage is not comprehensive. The constructed system disk is my best guess based on what is usually on a CP/M 2.2 disk. There are three different formatting programs.
Fresh disk images were created using a pair of goteks. This was mainly done for the FAST 2.22 operating system. A clean OS disk was created and the used as seed for various other disks including basic, wordstar, dbase etc. This was done using a pair of goteks running flashfloppy.
The new disks worked fine both as images and when written to floppy media, but it was not clear what speed flashfloppy would use for writing disks. Looking at the images in the HxC software it seemed that it was writing at 281rpm sometimes.
Just to be completely safe the images were written to floppy media on the machine and then re-imaged at 285rpm. These disks are numbered starting at 101.
It was never my intention to buy this machine. I drove out to Lewiston (just north of Adelaide) to collect another purchase, and the seller asked if i would be interested in this mammoth. It had apparently come from a South Australian government department, but had been subsequently used by the seller and his family for several years during the eighties.
I did some quick research and found that it was a word processor – not really my cup of tea. In the end, i bought it for about the value of the two drives. It also came with a daisy wheel printer, a long and heavy-duty printer cable, a couple of manuals and some beaten up looking disks. The screen looked like it had some kind of disease, which was later identified as CRT cataracts.
I was happy to find that the drives were Shugart SA400 drives because these are the first really successful 5.25″ drives.
Backing up the disks was an exercise in itself, but once done, i set the machine to work. I replaced a shorted tantalum and gave the drives some love. I started the machine up and, surprisingly, the machine booted into its word processing program.
Mild joy was short-lived: the keyboard did not work, and it was the microcontroller that had failed. At this point i should have pulled the drives and some other spares and sent it off to the recyclers. Instead, i built a teensy based replacement for the microcontroller and reverse engineered the keyboard. This act of madness yielded a system that was close enough to demonstrate the machine as a word processor.
Along the way, i had picked up hints of CP/M being available for this machine. I periodically did google searches to see if there might be some images kicking around and to my surprise about 3 years later they appeared on archive.org (thanks to the person who did that – dasher perhaps).
Once written, with some help from an Adelaide Retro Computing Group member (thanks Mick S), the machine was able to boot to CP/M and take on a new life as a computer.
If the success of a vintage computing purchase is measured by the hours endured to get it working (the primary entertainment value), then this machine has certainly delivered.
For a little history of Lexitron see the video here:
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.
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!
An enthusiast build – and i couldn’t even be sure that it’s complete.
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.
One of the challenges is that the relationships between all this kit was not obvious. This one i was only able to sort out because i found the source for some boot ROMs on one of the floppy disks. Even now i’m not sure if i have the original RAM card but the one i’m using does just fine.
It uses the following cards:
Compupro 8085/86 CPU Card
Jade DD Floppy Disk Controller
A handcrafted wire-wrapped Serial & Parallel I/O and Speech Synthesiser card
A parallel card with real-time clock
Intersystems 256KDR
A recently constructed EPROM Card
I have not connected an 8″ drive to it as yet, but it boots JADE CP/M 2.2 from a gotek. The disk images are from the original floppy disks.
This is one of several machines that came from a ARC Group member, Andrew, who was rehoming his brother’s collection. Andrew has been remarkably generous, and that generosity has made a lot of things possible that otherwise would not have been.
The Exidy Sorcerer represents the transition from S-100 microcomputers to more integrated designs. The computer unit with integrated keyboard has 48k of memory, rompac cartridge slot, video out, serial and parallel I/O ports, and an expansion bus. When used alone, the machine typically had a a basic ROM cartridge and programs were loaded from and saved to cassette. The machine has quite high graphics resolution compared to the other computers. Graphics were drawn using programmable characters.
This machine appears to have been used by a business. The expansion unit connects to the computer via the expansion port. It provides 4 S-100 slots. This was used mainly for a disk controller – in this case a hard sectored micropolis unit that operates with up to four unusual 77 track 100 TPI disk drives. It boots Micropolis DOS, Exidy CP/M, Lifeboat CP/M and SOftware SOurce CP/M (i don’t have a complete system disk for this Aussie rolled version).
The disks are challenging to read and write, but fluxengine did the job for me, and greaseweazle is now also capable of working with these disks. Hard sectored disks are unusual. Fortunately i have enough but i have a virtual sector generator as well so that soft sectored disks can also be used.
I have also added an 8kB memory card to the expansion unit at the same memory location as the rompac slot. Basic can be loaded into the card so that programs for the rompac basic can be executed.
The Micropolis drive controller is in the expansion unit. It includes two PROMs that hold the 256 bytes of boot code. This is executed from the Sorcerer monitor with GO BC00. I found that the code was not executing as expected and when i compared with PROM images to those discovered on in the TOSEC:
These 82S129 PROMs are quite difficult to find, so i made up an adapter board for an EPROM. I used wire wrap sockets to connect into the existing PROM sockets. This has been working fine.
In principle the files on the CP/M disks can be extracted using cpmtools. This, however, requires knowing the disk definitions.
I was able to work out the skew table by looking at the directory sectors on track 2. I guessed the directory size for the 2.2 format.
There were actually two different CP/M formats for the two different CP/M implementations on the disks: Exidy CP/M 1.4 and Software Source CP/M 2.2.
I was able to make some guesses based on the sector arrangement, and when i looked at the images i could see the order of the directory sectors. They both use a skew of 5 but start with different sectors – which explains why each CP/M only works with their own disks.
The directory size was a guess.
I thought i had nailed the format, but later i realised that there were some issues.
The two CP/Ms that I have use 2kB blocks. Each directory extent can accommodate 16 block pointers, but they are not all used. I think there was a rule that an extent could only represent a maximum of 16kB (multiple extents can be used for bigger files) so the CP/Ms that I have only used 8 pointers and just waste off the other 8.
With the original diskdefs cpmtools would read fine but when writing it would use up to 16 of the pointers. This befuddled CP/M.
The fix was not obvious but I found a comment on one of the other diskdefs suggesting that
logicalextents 1
wasted half of the entries (which is what I want) so I gave that a try and it worked.
My Sorcerer uses a Micropolis hard sectored floppy drive system. It uses 16 sectors, each of which includes a 256 byte data section and 19 bytes of bonus “metadata” used by Micropolis DOS (MDOS). This metadata is ignored by the CP/M implementations (Exidy & Software Source) that i have encountered.
The drives have an unusual track spacing of 100TPI. This is unusual so imaging has to be done using the actual drive units.
FluxEngine is a very low cost imaging solution that support Micropolis hard sector disks as used on my Sorcerer. At the time, Greaseweazle did not support hard sectors. It has since been added. I’ll do a separate post on that.
I connected to the drive using a straight through cable and using drive:0. This selects the second drive in the dual drive unit (drive 1). For the single drive unit, DS1 (the second drive select) must be selected.
I used FluxEngine on a new PC, so there would be no USB bandwidth issues. My older machine does seem to work reliably, but if it gets busy then FluxEngine will sometimes throw a bandwidth error.
Initially i used my single drive unit (which I call Drive 2) mainly because it was compact. Once I started working my way through the disks, I found I was getting lots of errors. I thought that I might do better with the dual drive unit (I call the top drive “Drive 0” and the bottom drive, “Drive 1”). I found that Drive 0 was a little better than Drive 2 and that Drive 1 was the best drive to use.
The results were a little disappointing but some further reading of the FluxEngine doco:
hinted that I could fiddle with decoder.bit_error_threshold to perhaps get better results. 0.2 is the default. 0.4 improved things a lot. 0.5 was the best. With the wrong setting, a lot of empty (?) sectors were read. I also increased the retry limit.
Drive 1 remained the best performing drive. I tried messing with the alignment on Drive 2, but I could not noticeably improve its performance. I did some poking around with the scope but no obvious differences between the dual and single units leapt out at me.
Out of 87 disks, I was able to read 19 without any errors being reported. I was able to read another 18 with only a small number of errors. A further 38 disks didn’t yield anything usable. Some were shedding oxide, but most 24 were successfully reformatted. Many were unlabelled, so perhaps no great loss.
Disks that were formatted with MDOS were read using the 275byte sector size. CP/M disks were read with 256 byte sector size. My understanding is that CP/M doesn’t use the “metadata”, and the 256 byte size is much easier to view.
There were some examples of where I was able to copy a disk on the real machine, but FluxEngine was unable to read the disk without error, eg Disk 24. The copy read fine. This meant that there was potential to improve the yield by making fresh copies on the real machine. Ie The real disk controller is still doing a better job in real time than the flux engine does in slow time. That’s the advantage of inside knowledge, perhaps.
I attempted to copy all the errant disks to intermediate disks, which I subsequently imaged. I did this for the CP/M disks using COPYDISK. This yielded another 13 good images! I think this confirms that FluxEngine is way less tolerant of problems than the sorcerer system. Even many disks that had a lot of issues came good.
I repeated the exercise for the MDOS disks, which gave another 8 good images.
I was able to write back both CP/M and MDOS images:
The write process verifies each track by reading back so even the writes need the bit_error_threshold parameter.
Writing also work through the virtual sector generator to a soft sector disk. The disk can be read by the system if the virtual sector generator is used.
I was very impressed with FluxEngine. David Given has done an amazing job.
