Sleep 1: MSI Floppy Drive

29 March, 2020


MSI Floppy Drive article from the May-June 1976 edition of the Creative Computing Magazine.

Transcript available
[Music] Helping you fall asleep. I'm John Chidjie. You can follow me on the Fediverse at, on Twitter @johnchidjie or on the network at engineered_net. Sleep is supported by you, our listeners. If you'd like to support the show, you can do so via Patreon, with a thank you to all of our patrons, and a special thank you to our Patreon silver producers, Oliver Steele, Kevin Koch, Joseph Antonio, and John Whitlow. And an extra special thank you to our Patreon gold producer, known only as R. Visit to learn how you can help. Thank you. So now that's out of the way, let me talk to you. Just for a few minutes. Creative Computing Magazine, May/June 1976. MSI floppy disk. It is generally acknowledged that a floppy disk is required for sophisticated data handling and storage with a microcomputer. Midwest Scientific Instruments' FD8 floppy disk memory unit contains a GSI model 105 or 110 disk drive and a controller that may be interfaced with any system having two bi-directional data ports. However, the FD8 is primarily for use with the M6800 based systems such as the Southwest Technical Products 6800 or MSI's own system since most of the options and and software supplied for the FD8 are compatible with 6800 based systems. The floppy disk controller in the FD8 is not intelligent since it relies on the host computer for major functions of its operation. This isn't really a disadvantage, but merely means that designers of the FD8 made a trade-off – more software and memory requirements in return for less hardware. CPU time isn't usually at a premium in personal computer systems and anyone willing to buy a floppy disk should also be willing to buy another memory board. The controller has a sector buffer so that I/O operations may be done independently of the speed of the CPU. Hard-sectored diskettes (not IBM standard) must be used. The FD8 is configured for 256 bytes per sector, 16 sectors and 77 tracks per diskette, for a total of 315,392 bytes of storage per diskette. Under normal conditions, a handful of these tracks are reserved for use by the system, but the rest are available to the user. The controller may be jumpered for 32 sectors per diskette, with 128 bytes per sector, but MSI software does not support this format. As we mentioned before, the FD8 is interfaced with two bi-directional parallel data ports, provided by a single PIA chip. MSI sells an interface card designed especially for use with the FD8, but other interface boards could be used. MSI supplies a floppy disk operating system for use with the FD8. To be used, the FDOS must be read from the system diskette into memory at 2400 hex. There are three ways to do this. First, MSI supplies a disk bootstrap program on a cassette. This program is loaded and executed at 2400 hex, and then it loads the FDOS from the diskette and executes it. The same cassette also contains a program called MinidOS, which is, as its name suggests, a mini floppy disk operating system. MinidOS can be used to read or write sectors on the diskette to or from memory in the computer. So in its crude way, miniDOS could be used to read the FDOS from the diskette into memory at 2400 hex. MiniDOS must be loaded starting at location 7700 hex, where most people don't have any memory. The third method which we chose is to get a PROM board with a disk bootstrap program on it. MSI sells just such a PROM board and supplies the Disk Bootstrap program in two 1702A EPROMs. Actually we're a bit surprised that they used 1702As because 1702s are just too slow for the 6800. But the 1702As are just barely fast enough. But it does work and it's much faster and more convenient than bothering with cassettes every time you want to use your disk. Using a disk bootstrap prom board, one merely tells the mikbug (mic bug) monitor to execute the bootstrap program located at C000 0x and you're off. The MSI FDOS is easy to use. Commands are entered as keywords such as load, save, run, copy and catalog. These commands permit you to do such things as load and save files, Print a directory, attempt to recover damaged portions of a diskette, initialize a new diskette, etc. File names may contain up to six characters. We did note a rather nasty problem with the FDOS. It does not check for duplicate file names when you ask to create a new file. In other words, you are permitted to create 27 files with the same name. Subsequently, you can only access the file that was created first, because that's the file the FDOS will see first when it looks in the directory. At any rate, the FDOS supports the following file types. System files. System files contain programs that are considered part of the operating system software. This includes basic, assemblers, a text editor, and utilities such as one to pack the diskette to recover space taken up by deleted files and another that lists the directory, including passwords and system files. To run a system file, merely type its name, such as 'basic', and then the program is loaded and run. It is also possible to create your own system files by making the first character of a file name a dollar sign. The file is then considered to be a system file. This is a nice feature, but unfortunately it is not possible to delete a system file, so it must be used carefully. Text files. These are files created by the co-resident text editor Assembler. They may be assembly language programs or just general text. Object files are output produced by the Assembler. Machine code files. These are files you create by directly saving a portion of memory on the disk. An example might be an old version of BASIC, which was previously loaded from the audio cassette before you had a floppy disk. BASIC programs. BASIC programs may be saved on the diskette both in a packed and in a pure ASCII format. In the packed format, the keywords are condensed into BASIC's internal format. In pure ASCII format, the program is saved on disk exactly as it appears when it is listed. The reason for the difference is that a packed program takes up less space on the disk and may be loaded more quickly, but an ASCII program can be appended to a program that is already in memory. Additionally, programs saved in pure ASCII would be compatible with a text editor. At present, the text editor in the Co-Resident Assembler Editor isn't much different than a basic editor. However, MSI plan to come out with a much more sophisticated text editor in the future. When they do, it would be very handy to be able to edit BASIC programs with the fancy text editor. BASIC. Since most personal computer users want to use a high-level language with their systems, we'll take a closer look at MSI's Disk BASIC interpreter. MSI's BASIC is based on the 8K BASIC written for 6800 by Robert Uterwick. However, the POS and SGN functions have been removed. In return, there are many more useful features, including trace, question mark as an abbreviation for print, and most importantly, statements, commands and functions for handling programs and data files on the disk. MSI Disk Basic takes up nearly 12K of memory, so 24K or even 32K are required to run reasonably large programs. Saving and loading of programs is accomplished in a straightforward manner, with the load, save, replace and change commands. The change command is used to save a program in ASCII format, so the command is not really very suggestive of its function. Well, maybe they were running out of command keywords. Data file manipulation is somewhat more complex. A create statement or command is used to reserve space on a disk for a data file. Then, an open statement must be executed to access the file in a program. The open statement assigns a channel number to the file, so that the file is subsequently referred to by number, not name. When the file is opened, it may be accessed for input, output or update. I/O is done in fixed-length records. A field statement is used to define the record format for a file. For instance, field number 10, A$=40, C=5, X$=20 means that when a record is read from file number 10, which was opened previously, the first 40 characters of the record will be put put into variable $a. The next 5 will be put into variable $c, a number, and then the next 20 characters go into variable $x. So the total record length is 40 + 20 + 5 or 65 bytes. GET and PUT statements are used to do input and output of a data file. With the example of a FIELD statement used above, GET #10 would read a record from file #10 and place the information in the appropriate variables, while a 'put' would have the opposite effect. The 'open for update' feature is interesting. When a file is opened for update, one may change records of the file in place, using a rewrite statement similar to 'get and put'. Note that at any time no more than three files may be open, and only one for output. Random access within data files is provided by a 'set' statement, which permits you to set the file pointer to any record within the file. For example, set #20=n would set the file pointer to the nth record in the file. Lock # is used to determine the location of the file pointer, and EOF # is used to detect end of file conditions. Finally, a close statement is used when processing of a file is complete. Overall, the facilities in MSI Disk Basic for processing data files are complete and most people would find them adequate for their applications. There does seem to be some overlap in the functions of the Open for Output and Create statements. Both Open for Output and Create can cause a data file to be created on the disk and since the FDOS allows duplicate filenames, you can end up with a rather unpleasant problem. MSI Disk Basic also has a program 'Chaining' which we feel all Disk Basics should have, and a means for one program to call another from disk, and for the sub-program to return to the next statement in the main program when completed. A nice touch, we thought. MSI also plans to introduce a basic compiler, not an interpreter, which will data files. MSI also plans to introduce a basic compiler, not an interpreter which will be able to use data files, print using for formatting of output and an on error option which permits trapping of errors within a program Rather than have your nice application program go blah in front of the dumb user (that's a bit mean) The compiler is a 2-pass compiler which produces an assembly language version of your program then you assemble a program using the disk assembler. According to MSI, the compiler is much faster than the interpreter. For instance, a card shuffling program, which ran for 90 seconds under the interpreter, ran in 3 or 4 seconds using the compiler. Indications are that the compiler used a 1.6 MHz 6800 CPU is faster than most of the other basics available for microcomputers. This should be an interesting product, especially for business applications. Summary. The FD8 manual contains a step-by-step construction list, schematics, drawings, calibration instructions, an explanation of how the FD8 works, and documentation for the software including source listings of the disk drivers and diagnostic routines on a cassette tape as well. We have found the FD8 to be a reliable product. At one time, we did have some trouble when we made a factory recommended modification to prevent accidental write operations. A very bad thing if it happens. We had no problems, but we decided to make the modification anyway. We botched the job. Really. And managed to get a tiny sphere of solder between two pins on the the connector which runs from the disc to the computer. The result was that the disc would operate normally for about 30 seconds when it was turned on and was then unable to step the head back towards track 0 after it had been moved out. We called MSI and they immediately suggested that the connector on the FD8 might have been shifted to the side causing two pins to be shorted together which made a driver get very warm and also not work very well. We went back and checked on the connector on the FD8 which was okay but armed with this information we decided that there was a short and found it readily. The big question for those considering the purchase of a floppy disk for their 6800 based system, whether they should opt for the FD8 or some other product such as Southwest's dual mini floppy or SmokeSignal's triple mini floppy. There's no clear-cut answer and we haven't had any experience with the other units so we won't make a recommendation. The mini floppy units get only 90 or so kilobytes on a diskette, which isn't that much considering that a few big files and some system software will easily chew that up. It is true that both SWTPC and Smoke signals get you up and running with a floppy disk for less money than MSI and that it is sometimes very handy to have more than one drive for copying files, processing one file against another etc. Of course MSI's controller can handle up to four drives by daisy chaining and two full-sized floppy drives will outperform two mini floppies with only a small difference in cost like only 100% or so. Also we hear that the SWT PC and MSI disk operating systems and basics are similar. Ultimately price performance will be the deciding factor for both hobbyists and application oriented users. Thank you.
Duration 16 minutes and 26 seconds Direct Download

Show Notes

Course Material:

Other shows on the network:

Episode Gold Producer: 'r'.
Episode Silver Producers: John Whitlow, Joseph Antonio, Kevin Koch and Oliver Steel.
Premium supporters have access to ad-free, early released episodes with a full back-catalogues of previous episodes


John Chidgey

John Chidgey

John is an Electrical, Instrumentation and Control Systems Engineer, software developer, podcaster, vocal actor and runs TechDistortion and the Engineered Network. John is a Chartered Professional Engineer in both Electrical Engineering and Information, Telecommunications and Electronics Engineering (ITEE) and a semi-regular conference speaker.

John has produced and appeared on many podcasts including Pragmatic and Causality and is available for hire for Vocal Acting or advertising. He has experience and interest in HMI Design, Alarm Management, Cyber-security and Root Cause Analysis.

You can find him on the Fediverse and on Twitter.