nascom.info(Puts on begging hat again) Of course, if anyone wants to donate a nice disk system or a spare drive or even a copy of one of the several DOSs...
At the time, disk drives of any sort were rare and expensive things to get hold of. Thus, the main method of transfering software was via audio cassettes. These, of course, are of no use when you want to load software very quickly! For this reason the bulk of the "working" software was provided (and run from) EPROM ICs. These were not the most convenient of devices, requiring both a special programmer and a short-wave UV lamp unit! You will realise, though, that this accounts for the large number of EPROM sockets that we used to get through on a Nascom system... :-)
The Nascom-1 was, of course, ready to program from switch-on providing you didn't mind working in machine code via the built-in monitor program! Until the later Nascom-2 almost all programming was either hand coded or used one of the assemblers which appeared on the machine. The favourite of these was ZEAP. Many systems "grew" EPROM boards so that favourite software didn't need to be loaded each time it was needed and ZEAP almost always appeared on these when it eventually became avilable on EPROM.
The ultimate problems with EPROMs were, of course, restricted program size and high cost of the hardware. They were, therefore, not very suitable for software distribution. A cheaper method was needed.
THE CASSETTE ERA
The NASCOM computers had a single serial port. Links on the board could select this as 20mA loop, V24/RS232 or cassette. The 20mA loop interface was an interesting item to include - it was intended for connection to the old teletype machines and paper tape readers. You have to remember that during this period of home computing there were few peripheral devices available. Dot matrix printers were just becoming available but few home users could afford them. On the other hand, surplus teletype units and terminals were reasonably easy to obtain. So many NASCOM-1s ended up with golfball typewriters and KSR33 teletypes attached. The print quality was fine, but you thought twice before starting to print out a 1000 line program listing because it was going to take all evening! Portability was also out of the question.
These machines were seriously heavy (man... X-) ).
The NASCOM-1 used a proprietory cassette tape interface for data storage. This was perfectly acceptable at the time as there was very little to be compatible with! The tape system was *very* slow, both because of the actual data rate and also because of the data format used. A "1" was stored as a short tone pulse at 1.95kHz - a "0" was simply an absence of the tone. This crude system worked reasonably well at the low data rate used (once the bug in the tape read routine of the original NASBUG had been fixed). The problem was that this system was very susceptible to spurious "clicks" and " pops" and also suffered if low quality tape was used as "drop-outs" could be read as "0" bits. Because of this increasing the data rate was not always easy.
In later monitor ROMs the Write and Read commands superceded the old Load and Dump. These used an enhanced data format which was much more efficient and about 10 times faster! Obviously this caught on in a big way.
A design for an improved cassette interface for the NASCOM-1 was published in PCW. This used the "CUTS" (Computer Users Tape Standard) format - also known as the "Kansas City" format. This represents a "1& as a 2400Hz tone and a "0" as a 1200Hz tone. The interface was always known to NASCOM users as the "Cottis-Blandford" system after the designers. Of course this system was not compatible with the original system, but it was so much more reliable that the older system got left behind. The "standard" that emerged used this interface at 1200 baud. This was readable on both NASCOM-1 and NASCOM-2 systems, although the NASCOM-2 (and modified NASCOM-1 systems) could also use 2400 baud with a bit less reliability. Many program tapes were sold with 1200 baud data on one side and 2400 baud on the other.
THE MIDDLE AGES
Obviously, users got fed up of even fast cassette interfaces. They had a major drawback - being a serial data device they were useless for random file access. Databases had to hold all the data in RAM. This was of no use at all except in the simplest of applications. RAM was just too expensive to use for this and the time taken to save and load the entire database to cassette was ridiculous. It had to be done though, as a single power glitch could wipe out all the data at a stroke.
Experiments started with computer-controllable cassette decks. The NASCOM systems already had simple stop/start control available by connecting a relay to the board, but what was needed was a method of forward and reverse fast winding to specific points. I believe that a few people actually got systems like this to work (with varying degrees of success) by modifying message systems. A few commercial systems based on a Phillips mini cassette system appeared (See the Hobbit drive in the OEM section of this web site). These were all similar, using the same drive, but the tapes were not compatible due to the differing data formats used. The units were quite reliable (until recently some have been used for programming weaving equipment) compared to standard cassette tapes. The usual formatting method was to record a fixed number of "blocks" to a tape - irrespective of its length. This meant that search times were similar for any tape. By allocating blocks near the centre of the recording area as a directory the tape never needed to move more than half its recorded length to find the start of a data block. The system worked quite well, but it was still rather slow. As there was no method of detecting blocks during fast wind operations this was done by timing the wind time. Obviously, enough blank tape had to be left as leader and trailer areas on each block for this search method to succeed. This meant that wind times (and therefore tape lengths) were much longer than the data areas really needed. The system was very inefficient, but it worked and the cost was only a small fraction of that needed to implement even the cheapest, most basic, disk system.
I have seen a reference to a "stringy floppy" being interfaced to a NASCOM. I am currently trying to find information on this device. I know that Exatron produced one for the Tandy machines (I tried one and hated it), but I don't think it was the same device.
THE DISK ERA
Expanded Nascom System:
Nascom 2, 4x48K RAM boards, 4 double density, double sided mini floppies with
control card, colour programmable high resolution graphics, I/O board, 8A psu, keyboard case. All professionally built and tested and installed in a rabbit hutch. Apply at any Nascom dealer and watch him cringe.
The above hoax classified advertisement (from INMC NEWS issue 7) is the earliest reference to disks on the NASCOM computers that I can find. Of course, almost everything listed here had been promised "for release soon" by Nascom - and had failed to appear. I'm afraid that this was a very common phenomenon.
Several competing disk systems were advertised:
- Comp Computer Systems
- Airamco (in Scotland)
- Henelec (Henry's Radio)
- Gemini
- Nascom
I don't think the Airamco system ever got into production.
THE "WINNIE"
This had to be every user's dream. A real "Winchester" disk storing a whole 5Mb or even 10Mb of data! Hard disk technology had a long way to go at this time, but programs were small, often written in assembler, so 5M went quite a long way. Gemini had produced the GM829 (no support for 1.2Mb disks) and the new GM849 combined floppy/hard disk controllers and made the GM835 sub-system available to connect to the SASI (early SCSI) port.
This has brought us a long way from the original slow tape interface! I'm not aware of anyone ever interfacing other storage systems.
Once again, if anyone can help with information, pictures, hardware or software please contact me.