All of the material in this manual is copyrighted by PERCOM DATA COMPANY. No portion of it may be copied in any manner without the written permission of PERCOM DATA COMPANY. PERCOM does not guarantee this software in any way and shall not be liable for any damages resulting from its use.
Throughout this manual references will be made to TRS-80 (tm) and TRSDOS (tm). These are trademarks of Tandy Corporation, Fort Worth, Texas, which has no affiliation with Percom Data Company. MicroDOS is a trademark of PERCOM DATA COMPANY.
At several places within this manual references are made to the "TRSDOS & DISK BASIC Reference Manual" published by Radio Shack. This manual is available from Radio Shack (catalog number 26-2104).
It is assumed that the reader of this manual is experienced in the use of Radio Shack Level II BASIC (tm). If this is not the case steps should be taken to master Level II before continuing in this manual, as it assumes such knowledge as a prerequisite for using MicroDOS.
A great deal of time and effort has gone into the creation of PERCOM MicroDOS. In spite of this it is still possible that this software may contain some "bugs". If you should discover a problem with MicroDOS, please let us know about it. The best way is to send us a letter describing all of the factors present when the error occurred. Be sure to include all information necessary to recreate the problem, as it is very difficult to solve a problem that cannot be recreated. [cite: 1071]
It is best NOT to phone us about a software problem. There is no guarantee that someone familiar with the program will be available when you call, delaying the solution. It is also very difficult to describe software problems over the phone, and even more difficult to solve them that way.
Disk files created by MicroDOS are NOT compatible with TRSDOS or other disk operating systems. Attempts to read MicroDOS compatible disk files or programs with TRSDOS will fail. While a utility program exists for MicroDOS to read TRSDOS BASIC program files, the syntax of disk I/O statements in TRSDOS BASIC may not be correct for MicroDOS. It will be necessary to modify such programs to be compatible with the MicroDOS BASIC syntax.
You may also transfer programs from one system to the other by saving the program to cassette while under one DOS then loading the program from cassette while under the other DOS.
MicroDOS is configured for the disk drives sold by Percom Data Co. The Percom disk drives permit operation on 40 tracks with a track to track step time of 20 milliseconds. If you are not using MicroDOS with a Percom disk drive it may be necessary to alter these parameters. Disk drives sold by Radio Shack are capable of only 35 tracks of storage and will not step faster than 40 milliseconds.
If you are using MicroDOS on a system which contains one or more Radio Shack disk drives you must apply the following patches for proper operation.
1. Load MicroDOS and exit to BASIC.
2. To change the number of available tracks to 35, enter the following:
POKE 17554,35 : CMD"M",0
This will set the track limit to 35 and will write the modified MicroDOS to drive #0.
3. To change the track to track step time to 40 milliseconds, enter the following:
POKE 17556,3 : CMD"M",0
This changes the step time and writes the modified MicroDOS to drive #0.
Buying a new software item is like buying most new things -- there is a tremendous urge to try it out right away before reading instructions or anything else. If you want to use MicroDOS "instantly" by all means do so. The diskette provided contains several sample programs to play with.
PLEASE DO NOT REMOVE THE WRITE PROTECT TAB FROM THIS DISKETTE! It is there for your protection to prevent inadvertent destruction of data on the diskette you purchased. Play with MicroDOS, experiment, and enjoy it. When you are ready to learn more about it return to this document. The MicroDOS PRIMER at the end of this manual contains a quick summary of the MicroDOS commands. [cite: 1090]
A Disk Operating System (DOS) is, loosely speaking, one or more programs which provide access to a magnetic disk storage device. Typically these programs are large and complex and place many restrictions on the programmer. Data to be stored on disk must be organized in "files" which must be "opened" to be used and "closed" when no longer needed. Such restrictions are a necessity on large computer systems to maintain efficient, orderly usage.
Traditionally microcomputer Disk Operating Systems have been designed as replications of big computer systems, taking a heavy toll on the limited resources of the much smaller machine. The philosophy at Percom is that a DOS for a microcomputer should make minimal demands on available resources while providing essential functions in accessing the disk. These functions include program save and load and a simple means of storing and retrieving data. Random access of the disk should be as easy to perform as sequential access.
MicroDOS was designed around these principles. Its requirements are small -- less than 7K of memory and only 5% of a diskette. Once MicroDOS has been loaded into memory (by power-on or reset) it is no longer dependent on the disk for anything. This, along with the low memory requirement, makes a 16K one-disk system quite useful.
Up to four disk drives may be accessed under MicroDOS. These drives are referenced using numbers from 0 through 3. The cable position for drive 0 will be either the connector closest to the Expansion Interface or that furthest away from the Expansion Interface. On cables made by Percom Data Company position 0 is the furthest from the Expansion Interface.
Data within a track is stored in segments called "sectors". Under MicroDOS the unit of disk storage is one sector. Sectors on a disk are accessed by number. The first sector on the first track is number 0, while the number of the last sector on the last track will depend on what model of disk drive is being used. Numbering of sectors on a diskette is similar to the numbering of elements of an array in BASIC[cite: 1113].
In accessing a sector under MicroDOS the drive number and the sector number are combined in a single 5-digit number of the form DSSSS. The first digit, D, represents the drive number and may range from 0 to 3. The last four digits, SSSS, are the desired sector number.
Examples of DSSSS coding:
Note that leading zeroes are not required in a DSSSS number. Due to this fact sectors on drive 0 may be accessed using a sector number alone, although there is no harm in also specifying a drive number too. Note also that if a drive number is specified leading zeroes are required on the sector number.
MicroDOS is a machine-language program which resides in less than 7K of RAM memory. The purpose of MicroDOS is to provide the BASIC programmer with the necessary tools to use a mini disk drive for data storage and retrieval. Unlike other Disk Operating Systems, MicroDOS exists in conjunction with Level II BASIC, not apart from it.
When the computer is first turned on (or the RESET button is pushed) the Level II ROM loads MicroDOS from the disk on drive 0. From that point on all communication with MicroDOS is done through the use of BASIC instructions. Once MicroDOS has been loaded (by power-up or reset) it is not necessary to keep the MicroDOS disk mounted. MicroDOS resides entirely in memory, thus it does not need to have a "system" disk available as with other Disk Operating Systems such as TRSDOS.
For some functions it is necessary to issue commands directly to MicroDOS. This is done using the command 'CMD'.
Before a new diskette can be used by MicroDOS it must be "formatted". This MicroDOS command performs the formatting operation on a diskette. 'D' is an expression indicating the drive number of the disk to be formatted, and must be in the range 0 to 3. Following a 'CMD"F"' all sectors of the disk will be initialized to an "empty" state.
Since MicroDOS must be on a diskette to be loaded into memory, there must be a way to get it from memory back onto a diskette. This is done by issuing 'CMD"M",D' where 'D' is an expression indicating the drive which contains the diskette that MicroDOS is to be written on. The diskette must be formatted. MicroDOS will be written on sectors 0 to 19 of the indicated disk.
This command is simply a shortcut. It first performs 'CMD"F",D' and then 'CMD"M",D'. As before 'D' is an expression for the drive to be operated on and must be between 0 and 3.
By using 'CMD"H",A$' a message of up to 128 characters may be displayed every time MicroDOS is loaded. 'A$' is a string expression which contains the message to be displayed. If more than one line is necessary the "down-arrow" key is used to end each line. It is very important to note that this command effects the copy of MicroDOS in memory ONLY. Therefore to make the command work it is necessary to ALWAYS FOLLOW 'CMD"H"' WITH 'CMD"M"'[cite: 1167].
To solve the confusion of startup prompts, MicroDOS allows up to 128 characters to be "pre-entered" and stored in the DOS for use at start up time. This is done using 'CMD"K",A$' where 'A$' is a string expression containing the characters to be "auto-typed" at power up. Since the "ENTER" key cannot be embedded in a string the "down-arrow" key is used instead. At power-up the "down-arrow" is converted to "ENTER".
MicroDOS allows BASIC programs to be saved on diskette and loaded into memory as needed. The commands necessary to do this are described in this section. Note that programs saved by MicroDOS are saved in a "memory-image" form, i.e. the program on disk looks exactly like it did in memory. Therefore it is not possible to read programs from disk as data and print them.
The 'LOAD' command loads a program beginning at the sector designated by the DSSSS expression. If ',R' follows the command the program is RUN as soon as it is loaded. Should an attempt be made to load a program which is larger than available memory, an 'OUT OF MEMORY' error will occur. In that event no part of the program will be loaded. The 'LOAD' command performs an internal NEW so no part of a program in memory will remain when 'LOAD' is performed. Note that since the string space reserved by CLEAR is not affected by NEW, it may be necessary to CLEAR a smaller string space to 'LOAD' a large program.
The 'SAVE' command is used to save programs from memory to disk. 'DSSSS' is an expression indicating the drive and first sector to be used in saving the program. It is the responsibility of the user to insure that the sectors written over by the 'SAVE' are unused. No check is made during the save. At the conclusion of the save the command displays the last sector used. This should be noted to prevent overwriting the program in future disk access.
The 'MERGE' command works like the LOAD command with one important exception. There is no implied NEW prior to 'MERGE' and any program in memory is NOT cleared out. Lines from the incoming program are merged in with those of the program in memory. In cases where a line from disk is already in memory, the disk line will replace the one in memory. If memory is exhausted before the 'MERGE' is complete an 'OUT OF MEMORY' error will occur and memory will contain as much of the program as would fit.
Under MicroDOS each disk sector has the capacity for 255 characters (bytes) of data. Data is passed back and forth from the disk using strings, which also have a 255 character capacity. Therefore, for a data item to be recorded on disk, IT MUST FIRST BE CONVERTED INTO STRING FORM. Only two statements are needed to store and retrieve data to and from disk. They allow for simple management of data on disk. In the next section more complex and powerful techniques are discussed.
Data is put on the disk using the 'PUT' statement. The data to be output must be in a string variable ('A$' above) and a 'DSSSS' expression must be given to indicate where on the disk the data is to be put. The following example shows how the word 'HELLO' could be put on sector 50 of the disk in drive 0:
100 A$="HELLO" 'LOAD THE DATA INTO A STRING
200 PUT A$,50 'OUTPUT TO DRIVE 0, SECTOR 50
Numeric data must be converted to string form before being put on the disk. In this example the number 3.141592653 (the constant Pi) is put on sector 24 of the disk on drive 2:
100 PI$=STR$(3.141592653) 'CONVERT NUMBER TO STRING
200 PUT PI$,20024 'PUT TO DRIVE 2, SECTOR 24
While experienced programmers may shudder at the lack of efficiency in these methods, their purpose is to show clearly and simply how data may be recorded on disk.
To retrieve strings from disk the 'GET' statement is used. Data is read from the sector identified by the 'DSSSS' expression and transferred into string variable 'A$'. The prior contents of 'A$', if any, is lost. In the following example sector 50 of drive 0 is read and the result displayed.
100 GET A$,50 'READ SECTOR 50, DRIVE 0
110 PRINT LEN(A$);A$ 'DISPLAY RESULTS
Sample Output
Note that the LEN function may be used to determine the actual number of characters read. Numeric data may also be read, but since it was recorded as string data it must be read back as string data. The following example reads the value of the constant Pi from sector 24 of drive 2:
100 GET A$,20024 'READ THE STRING
110 PI=VAL(A$) 'CONVERT TO NUMBER
120 PRINT A$;PI 'DISPLAY RESULT
Sample Output
The loss of digits from the PUT example is caused by the use of single precision variables.
The techniques previously discussed for data storage and retrieval are simple to use and moderately efficient for storage of text. However, they are very inefficient for storage of numeric information. MicroDOS offers another method which, while more complex, offers much more efficient use of the disk. In this method data is read and written using "Field Buffers" which are special holding areas in memory. MicroDOS provides four Field Buffers which may be defined by the user. Data fields may be defined within these buffers for easier manipulation by the BASIC program. How these buffers are used is best shown with an example. Suppose we want to keep a list of names, addresses, and phone numbers on disk. Each name will be 20 characters or less, each address will be 40 characters or less, and each phone number will be 7 characters. Using the technique previously discussed each entry in the list would require a sector -- one for name, one for address, and one for phone.
The 'DEF FIELD' statement is used to name areas within a Field Buffer for easier manipulation by the BASIC program. 'N' is a numeric expression identifying which Field Buffer is to be referenced. In this case three fields are defined. They are 'NA$' (name) as 20 characters, 'AD$' (address) as 40, and 'PH$' (phone) as 7. Suppose that sector 48 of drive 2 contains the following string: "R. Shack 1111 Tandy Trail 5550000"
The following program shows how this data is read and accessed using a Field Buffer:
100 GET #1,20048 'READ THE SECTOR
110 DEF FIELD #1,20 AS NA$,40 AS AD$,7 AS PH$
120 PRINT NA$
130 PRINT AD$
140 PRINT PH$
Result if RUN:
Note how the DEF FIELD allowed data to be "broken down" into pieces for simpler processing. In addition three separate data items are stored on a single sector. While this is a great improvement, there is more that can be done. Notice that out of 255 characters possible on a sector, this example uses only 67 of them, wasting 188 characters! A few calculations show that the 67 character sequence can be put in one sector 3 times, leaving 54 characters unused.
How is this done?
First we need to get some terminology out of the way. Whenever we have a group of fields which logically "belong" together we will call that grouping a "record". In the preceding example one "record" consists of a name, an address, and a phone number. What we would like to do is get three records on one sector.
There are several ways this can be done. Probably the most obvious is to give each field in each record a different name as N1$, A1$, P1$, N2$, A2$, and so on. This requires a lot of typing and will usually require a longer statement than the 255 characters allowed by Level II. If the fields are processed one at a time we can put a "dummy" record at the front of the field definitions to skip over the unwanted records. In the following program a sector is read and all three records in it are printed:
100 GET #1,20048 'READ THE SECTOR
110 FOR I=0 TO 2 'LOOP 3 TIMES
120 DEF FIELD #1,I*67 AS XX$,20 AS NA$,40 AS AD$,7 AS PH$
130 PRINT NA$ 'PRINT CURRENT RECORD
140 PRINT AD$
150 PH$
160 NEXT I
Notice that this program looks pretty much like the previous one except for the addition of the FOR--NEXT loop and a new field 'XX$'. The first time through the loop (I=0) the dummy field XX$ will have a length of zero. This will position NA$, AD$, and PH$ as the first items in the sector as in the previous example. However, in the second pass through the loop (I=1) XX$ has a length of 67 (one record). The fields NA$, AD$, and PH$ are now offset 67 characters into the sector. We are actually accessing a second record in the same sector.
If all this seems hard to understand, keep in mind that the field variables NA$, AD$, and PH$ are not data items in themselves, but are actually NAMES of data items. As an example of how this works suppose that your newspaper deliverer is very dull-witted and only leaves a newspaper at house number 123. Further suppose that there is only one sign with the numbers 123 on it for use by the entire neighborhood. The only way for everyone to get a newspaper is to move this number from house to house as each paper is delivered. Accessing data in a multi-record Field Buffer works the same way. The variable names ("house numbers") are moved from record to record ("house to house") so the proper data is retrieved.
But suppose we wish to access all the records of a sector at once. How can we do this? The best way is by using arrays. By mapping each element of an array over a record in the Field Buffer we can have access to all records at once. Using our name, address, and phone number example we could do it this way:
100 DIM NA$(2),AD$(2),PH$(2) 'DEFINE ARRAYS
110 GET #1,20048 'READ THE SECTOR
120 FOR I=0 TO 2 'START LOOP
130 DEF FIELD #1,I*67 AS XX$,20 AS NA$(I),40 AS AD$(I),7 AS PH$(I)
140 NEXT I
200 FOR J=0 TO 2 'PRINT LOOP
210 PRINT NA$(J)
220 PRINT AD$(J)
230 PRINT PH$(J)
240 NEXT J
At first glance you may be tempted to say that this won't work. It does look a lot like the previous example, but the array subscripts are the big difference. Because of subscripting NA$(0) is NOT the same name as NA$(1). So what we are doing is giving each record in the sector a unique name rather than moving the same names from record to record.
Thus far we have had a great deal of discussion about how to read data into a Field Buffer and access it, but nothing at all about how the data gets on the disk in the first place. Before data can be put into a Field Buffer the fields need to be defined as they were before using the 'DEF FIELD' statement. Getting data into these defined fields is where things get tricky. Recall that we said earlier that the variables created by the 'DEF FIELD' statement were NAMES of data items rather than data items themselves. Suppose we try the following example program:
100 DEF FIELD #1,10 AS A$
110 A$="HELLO"
120 DEF FIELD #1,10 AS B$
130 PRINT B$
When we print 'B$' we expect to get a friendly "HELLO" greeting. Surprise! We get nothing of the sort! (What we get depends on whatever garbage was in Field Buffer 1 before we started.) What happened? Examining the program, line 100 seems alright. We named the first 10 characters of Field Buffer #1 as 'A$'. The "gotcha" comes in line 110. It appears that we are moving "HELLO" into variable 'A$', but in reality what we are doing is moving the NAME 'A$' to the data item "HELLO". Thus we can print A$ and get "HELLO", but we can't seem to find it in the Field Buffer. Yes, this is confusing, but it is done this way to make the computer more efficient. So how do we get data into the miserable Field Buffer?
Enter the heroes! The statements 'LSET' and 'RSET' are used to MOVE data from one variable to another. Data is left-justified or right-justified depending on which form is used. If we had used 'LSET' in line 110 of our previous example program, the result would have been that the first 10 characters of Field Buffer #1 would contain "HELLO ". Notice the five trailing spaces. These are provided automatically by 'LSET'. Use of 'RSET' would have resulted in " HELLO". If, however, we had defined 'A$' as having only 4 characters, both 'LSET' and 'RSET' would have resulted in 'A$' containing a four-letter word describing a place that is warm year-round and I don't mean Florida!
Now that we know how to get data INTO a Field Buffer we will look at an example program to produce the data that we read in our previous examples, the name, address, and phone number records.
100 FOR I=0 TO 2 'START LOOP
110 DEF FIELD #1,I*67 AS XX$,20 AS NA$,40 AS AD$,7 AS PH$
120 INPUT "ENTER DATA";N$,A$,P$ 'GET DATA
130 LSET NA$=N$ 'PUT IN FIELD BUFFER
140 LSET AD$=A$
150 LSET PH$=P$
160 NEXT I 'CONTINUE LOOP
200 PUT #1,20048
The last line, 200, actually records the data on disk. In previous discussions of disk I/O using string variables, the amount of data written to disk was always equal to the length of the string variable from which the data was written. Likewise, the string variable into which the data was read from the disk, is made the same length as the incoming data. When using Field Buffers MicroDOS must have a similar method to determine how many characters to actually write. The rule that is used is that the length of the Field Buffer is assumed to be as long as the total length of fields defined by the longest DEF FIELD statement. If necessary a dummy DEF FIELD can be executed to establish the proper length for the Field Buffer. Following a GET to a Field Buffer the length of the Field Buffer is set to the length of the data read. However, the length may be changed by subsequent DEF FIELD statements. For this reason, it is best to do a DEF FIELD after a GET and before a PUT so the proper length will be written to disk.
While this scheme may seem restrictive, it does insure that no "garbage" data is transferred to or from the disk. The programmer may determine the current length of any Field Buffer using the function 'LOF'. The format of the function call is 'LOF(N)' where 'N' is an expression indicating which Field Buffer's length is to be returned. Note that '#' is not required preceding the Field Buffer number expression. Programmers familiar with the use of 'FIELD' in Radio Shack Disk BASIC should pay particular attention to the concept of length in conjunction with Field Buffers. Radio Shack Disk BASIC assumes a length of 255 bytes and always transfers that many characters with each GET or PUT. MicroDOS users desiring this feature should always do a dummy DEF FIELD for 255 characters immediately before each PUT.
Our discussions involving I/O using Field Buffers have all been oriented toward strings up to this point. How does one handle numeric data efficiently? Since only string fields can be defined in the DEF FIELD statement, numeric data must be converted to string form. Earlier we did this with the 'STR$' function. This results in needlessly long strings, however, there is a better way.
The 'MKX' functions make numbers into strings. These strings, however, contain the numbers in their internal form and are not directly printable. 'MKI$' makes its integer argument ('I') into a string two characters long. 'MKS$' makes a 4 character string out of its parameter 'S', and 'MKD$' builds an 8 character string from the parameter 'D'. Let us refer to an earlier example of storing the mathematical constant PI on disk:
100 PI=3.14159 'DEFINE CONSTANT
110 DEF FIELD #1,4 AS PI$ 'DEFINE FIELD
120 LSET PI$=MKS$(PI) 'CONVERT TO STRING
130 PUT #1,10045 'WRITE TO DISK
In using the 'MKX' functions one must be very careful to define strings of the proper length for the type of number being converted. Refer to the following table:
| NUMBER TYPE | REQUIRED STRING LENGTH |
|---|---|
| Integer | 2 characters |
| Single prec. | 4 characters |
| Double prec. | 8 characters |
These functions solve only half of the problem. There still must be a way to get strings back into numeric form.
The 'CVX' functions perform the string to number conversion. 'CVI' converts string parameter 'I$' to an integer. 'CVS' converts 'S$' to a single precision floating point number and 'CVD' converts 'D$' to double precision. Note that these functions CANNOT be used to change the type of a number, i.e. do not use 'CVI' on a string that was created using 'MKS$'. As a partial protection against this, a 'Function call' error will occur if the string parameter for any 'CVX' function is not the proper length for its number type.
Several of the functions available in MicroDOS have been discussed in previous sections. In this section all other functions that MicroDOS provides are explained.
The 'LOC' function is used to get various bits of information from MicroDOS. 'N', the parameter, indicates what specific information is desired.
If 'N' = 0, MicroDOS returns a DSSSS number for the last drive and sector accessed. This call is useful in keeping track of where a program writes its last data.
'LOC' with a parameter of 1 returns the largest possible sector that can legally be accessed under the current version of MicroDOS. This number will vary depending on the model of disk drive your MicroDOS was designed for.
Advanced programmers will find the most use for 'LOC' with a parameter of 2. This call returns the status (in decimal) of the 1771 Disk Controller following any disk I/O which results in an error. It is up to the user to analyze the status to determine the problem.
A call to 'LOC' using an argument of 3 returns, as previously discussed, the number of sectors which could not be verified during a format using 'CMD"F"' or 'CMD"I"'.
For convenience to the programmer knowledgeable in machine language, any constant preceded by '&H' will be interpreted as a hexadecimal constant. The number may be from 1 to 5 hexadecimal digits. Constants of this type always represent signed integers. Hex constants may not be used as response to an INPUT statement or in a DATA statement. Note that octal (&O) constants are NOT supported by MicroDOS.
Searching a string for the first occurrence of a substring may be rapidly accomplished using the 'INSTR' function. String variable or expression 'S1$' is searched for the first occurrence of the substring specified by variable or expression 'S2$'. The first parameter, 'N', is optional. If present it indicates at what position within 'S1$' the search begins. A value of 1 is assumed if 'N' is not present. The value returned by 'INSTR' is the position in 'S1$' where 'S2$' was found, or zero if no match could be found. In the following examples string 'A$' contains the value "ABCDEFG":
| Function call | Result |
|---|---|
| INSTR(A$, "BCD") | 2 |
| INSTR(A$, "XY") | 0 |
| INSTR(A$, "ABCDEFGHI") | 0 |
| INSTR(3, "ABC") | 0 |
| INSTR(3, "123123123", "12") | 4 |
Additional information may be obtained from the "TRSDOS & DISK BASIC Reference Manual".
The 'MID$' function in Level II BASIC allows for extraction of a substring from a string. MicroDOS adds the capability to use 'MID$' as a statement to replace a portion of a string. The form of the statement is 'MID$(S1$,N,M)=S2$' where 'S1$' is the string being modified, 'N' is the starting position of the replacement, 'M' is an optional length of the replacement, and 'S2$' is the source of the replacement characters. Note that the length of the string 'S1$' is never changed by this statement. If the replacement string 'S2$' is too long it will be truncated. The following examples show the use of the 'MID$' statement:
100 A$="ABCDEFG"
110 MID$(A$,3,2)="1234" 'REPLACE 2 CHARS STARTING AT 3
120 PRINT A$
Result if RUN:
130 MID$(A$,5)="XYZ" 'REPLACE STARTING AT 5
140 PRINT A$
Result if RUN:
When an error occurs during the execution of a MicroDOS statement or command, BASIC will display an error message. Many of these messages are the same as those produced by Level II BASIC. However, there are some messages which are unique to MicroDOS. The following list describes these messages and their causes:
This message is produced whenever a hardware error occurs during a disk operation. Possible causes include a drive door being open, a missing diskette, or a bad spot on the diskette. If this error occurs, use the 'LOC(2)' function to determine the exact nature of the error.
This message occurs when an attempt is made to write to a diskette which has a write-protect tab over the notch on the side of the diskette. To write to the diskette, the tab must be removed.
This message indicates that MicroDOS was unable to find the sector specified in a DSSSS expression. This may be caused by an incorrect sector number or by a diskette which has not been properly formatted.
While MicroDOS does not use a directory in the traditional sense, it does have a limit on the number of programs that can be saved using the 'SAVE' command if a specific naming convention is used. This error indicates that no more programs can be saved on the diskette.
Several utility programs are provided on the MicroDOS diskette to perform various tasks. These programs are written in BASIC and may be LOADed and RUN like any other program.
This program provides a more "user-friendly" way to format diskettes than using the 'CMD"F"' command. It prompts the user for the drive number and provides warnings before formatting begins.
The 'COPY' program is used to copy the entire contents of one diskette to another. Both diskettes must have the same number of tracks for the copy to be successful.
This utility displays a list of the programs stored on a diskette. It only works for programs saved using the 'SAVE' command.
This section provides a quick reference to the MicroDOS commands and statements.
| COMMAND | DESCRIPTION |
|---|---|
| CMD"F",D | Format diskette on drive D |
| CMD"M",D | Write MicroDOS from memory to drive D |
| CMD"I",D | Initialize diskette (Format and Write MicroDOS) |
| LOAD DSSSS | Load program starting at sector DSSSS |
| SAVE DSSSS | Save program starting at sector DSSSS |
| PUT A$,DSSSS | Write string A$ to sector DSSSS |
| GET A$,DSSSS | Read sector DSSSS into string A$ |
Because MicroDOS disk files and programs are not compatible with TRSDOS, a specific procedure must be followed to transfer BASIC programs from a TRSDOS diskette to a MicroDOS diskette. While MicroDOS can read TRSDOS program files, the syntax for disk I/O often requires modification to match the MicroDOS structure. Alternatively, programs can be transferred by saving them to cassette under one DOS and loading them from cassette under the other. To transfer a program directly from disk, follow these steps:
CMD"K",""CMD"I",0
PRINT "A="; PEEK(16548)PRINT "B="; PEEK(16549)PRINT "C="; PEEK(16633)PRINT "D="; PEEK(16634)
POKE 16548, (Value for A)POKE 16549, (Value for B)POKE 16633, (Value for C)POKE 16634, (Value for D)
LISTing it. Finally, use the SAVE command to store the program onto the MicroDOS diskette.sidecar.txt snippetFromBack].That's all there is to it! If you are going to continue to run in MicroDOS, you may need to adjust some I/O statements to ensure full compatibility with the MicroDOS syntax.