InterMedia Technical Development
Being in charge of the product development it is the area I have memories of, and can explain many of reasons for the path we took. It was also a time of very rapid changes in PC and the whole IT world.
Software choices
Whilst I was working with my previous company I used a program called PL/M, a simplified version of PL/1. When I decided to work on my own, I had to buy a compiler and had two options. Pascal was very popular at the time, but also a program called 'C'. Not many people were aware of it, but in my mind it was similar to PL/M, but much less verbose. I purchased a SuperSoft C86 licence and started work using MS-DOS.
The limitation of C86, MS-DOS at the time was that the code segment was limited to 64KB and so was the data segment. The Z100 only had 192KB of RAM. I started work on DTP (Disk Transfer Program) but soon started to run out of space. I could only support a few handlers at any one time. Forunately, the compiler did have an option of overlays. I therefore could specify a specific area of memory for a read handler, and another area for a write handler. The core program was then designed so a handler could be developed in isolation making it very easy to have multiple programmers working on different formats at the same time. It also meant that if a customer required an update, it could be just a simple single file on a floppy disk - electronic transfers where at least 10 years away.
Each handler had a standard interface. A single call to a fixed function that returned the addresses of the key handler functions. These were, Initialise handler, Read disk directory, Open file, Read next file buffer, Close file. I am pleased to say that this basic structure remained the same for the next 30 years, although details were tweaked, such as 32 bit mode for MM/PC in 1998. Thus code written in 1984 was still largely valid many years later
After a year or so we moved onto a different compiler that supported more than 64KB code and data segments, but this compiler did not support the existing style of overlays. The solution was to write a program that acted after the main linker and would allow the software to work in the same way. The compile process changed (simple batch files) but the program source code remained compatible. What I had created was infact very close to an early DLL, Dynamic Link Library.
About 1987 it was clear that the world was becoming fully IBM PC compatible. The Z100 was close, but not the same. A very important point was that the Z100 had a S100 interface bus, and the IBM PC has a ISA bus. See below, this required new hardware.
About 1987 we moved to using a PC compatible Zenith, A Z248 with probably 512K of RAM and 20 or 40MB hard drives. A 20MB drive then cost about £750 and once formatted has about 17MB of user space. The software remained with DOS, slowing moving to DOS 6.2. Windows was starting to be used but it was with V3.1 that I think general acceptance occurred. Early 1990s software was ported to Windows and the program renamed IMWIN (InterMedia for Windows).
The software for the handlers remained 95% original, though we had a small conversion program to update the handlers to be compliant with with the Windows, Borland compiler. For the Windows interface we used a third party library, possibly called CommonView but please correct me if wrong.
The program remained 16 bit, but use was made of the built in DLLs for each handler. Thus a handler could be compiled without refrence to the main system making development, and updates extremely simple. A competitor at the time , KeyWord had a system that required updates to be a complete system. In 1990, 12MB of data was many floppy disks, and no high speed (or slow speed) internet. Electronic file transfer was via a 1200 baud modem and a specific buletin board. Internet and easy transfers was still several years off.
Come late 1990s, the requirement for disks was becoming limited, but tapes conversion was very important. As with floppy disks, there were many 'standards' and InterMedia was in an indea place to provide a solution. We therefore wanted a solution aimed entirely at tapes, and so IMDrive was developed. It was also a chance to start again but using Microsoft Visual Studio as a 32 bit program. The windows interface was using MFC . This was the final InterMedia product, and it became renamed MM/PC as part of eMag Solution in 2000.
Disk interface hardware
Floppy disk come in all shapes and forms. In 1983 the 5,25" was probably the standard, with a capacity of about 360KB, double sided. 8" floppies has a single side, single density at about 128KB, up to double sided double density at 1.2MB. Most disks were soft sectored with MFM encoding.
There were a lot of disks we call hard sectors. These had extra index holes inthe centre of the disk, each hole was used to mark the start of a sector. Soft sectored disk have just a single hole to mark the start of the track. A normal disk controller will not read hard sectored disks. Then we have formats such a Apple 3.2 and 3.3 that used GCR encoding, rather than FM or MFM. Sirius also used GCR, and I think variable speed. Variable speed is used so the disk spins at different speeds for each group of tracks.
To solve the above problems, I developed an S100 interface board to read all variations of disks. It had a companion board to write disks. These boards acted as a software security key, but mean they had to be redesigned to work an IBM PC compatible system.
The version for the IBM compatible took a slightly different approach. The new board featured a process (80186) with 512KB - later 1MB of RAM. The software on the board would read the floppy disk without the main program intervention. Data was therefore sometimes cached before being requested.
The disk controller board then interfaced to a box with multiple disk drives, or to a stack of disk drives. The drives supported were as below
This is the InterMedia GT disk controller board
Translation tables
A very importnat part of InterMedia for DOS and InterMedia for Windows was the ability to manipulate data. We did this with slots for 6 translation tables, and two protocols. The translation tables at the lowest level would do character substitution of a single character to another character, or string. A simple application would be from EBCDIC to ASCII.
The next level would be to convert a string to another string, including possible general or numeric wild chars. Extra features allowed flags to be set, so a string conversion would only take place once an earlier event had occured. There were also counting tables so an event would only take plave once say 5 strings had been found.
As a package the tables were a powerful way to manipulate from possible typesetting systems, or database, or word processing systems. They worked equentially in line with any disk reading.
Protocols
Protocols were programs for specfic tasks. Typically to read a word processing format. Many WP systems had data stored in a non sequential way, this had to be interpreted to obtain a sequential text file.
IMIC2
IMIC stands for InterMedia Inter Change format. It was a standardized set of codes for both European characters, eg accented letters, and also for formatting codes, such as underline or bold. Did it work. The answer is rather mixed. It was very good at taking a WP file and getting text centred,. underlined etc. When it came to trying to convert ruler lines and tab stops, it was less reliable. The intention was to beable to take a formated say Word Star document and convert to a MultiMate document. However, being very general purpose it had limitations, but it did have the potential of thousands of combinations, with maybe just 50 programs. Most users were happy with just the basic attributes, and here it worked well.