By W. R. MOSEID
This article appeared in VAST News, the newsletter of the Valley of the Sun TI99ers of Phoenix, Arizona.
When the decision was made to provide a new disk controller card to the T199/4A world, we began what turned out to be a long and arduous trip. The metal clamshell case was easy. Just use the one that had been designed for the CorComp 32K and RS232 cards. Then modify it slightly for a slot to accommodate the new circuit board that would project through the back of the case. This part would hold the connectors for the cables to the internal and external floppy disk drives.
Since all disk controller integrated circuits can control up to four floppy disk drives, we decided not to restrict people to three. With some careful planning, design and care a card could be produced which would support up to four disk drives with any combination from the following list of options:
Single- or double-sided
Single- or double-density
35 or 40 tracks per diskette side
Any combination of the above
Automatic density recognition
In order to allow the use of a variety of disk drive models, a feature was selected that allowed the owner to set the head step time. “Head step time” is the time it takes the disk drive read/write heads to “step” from one track to another. You can select one of four step times for each disk drive in your system. The times supported were 15 milliseconds, 10 ins., 6 ins., and 3 ins. This timing is set by positioning a set of DIP (dual in-line pack) switches to various on/off settings. The decision was made to place the DIP switches inside the case. Even though this meant the user would have to remove the case to set all the switch.es, this approach was selected for the following reasons:
• Safety for the card — Makes sure power is off when the DIP switch is set.
• Safety for the DIP switch — The chance of something hitting it or changing the settings were minimized.
• Lower costs to the consumer — Assembly time and material costs were tower.
• The 10 ins. factory setting works with most drives.
When the 99/4A power-up sequence was examined, several in.teresting things were discovered:
• Plato, Terminal Emulator If and other command modules have a special sequence that runs at that time. Once they get con.trol, they do not give it up and the power-up scan is not completed.
• In order to allow the user the ability to select the CorConip Disk Manager from the title screen, a special power-up screen had to be made to allow our rapid loader to execute on a single key-press.
Because of the way Plato, TEll and other modules operate during power-up, a choice of two different menu screens had to be provided.
The early timing studies were done with direct I/O using an assembly language pro.gram (NO GROM). At that time we calculated that the CorComp disk controller in double-density could run two to four times faster than the TI disk controller. This was demonstrated by the speed at which the 98- sector disk manager program loads into pansion memory. This is based on the w~ that the CorComp controller card accesses the diskette and transfers the information into the computer.
When TI designed its disk memory system, it was decided that a memory expansion would not be required. This way, with
the controller — the old standalone sidecar version — and a console, you could utilize BASIC with a disk system. To do this, the TI disk system and all of the modules that use floppy disks expect the information read from the disk to be in the console (VDP RAM) memory.
For example, when BASIC, Extended BASIC or the Editor/Assembler load from disk, they expect the information to be in console memory. If a memory expansion is attached, then Extended BASIC will move the information to the memory expansion after it is loaded. This moving process is very time consuming. Remember, each sector (256 characters) read or written must be passed through VDP RAM to be compatible with TI firmware/software. The table in Fig. 1. contains timing tests using GROM and VDP RAM.
The tests in Fig. 1 were conducted with default interlace selec.tions. Timing may be improved with different interlace selections for the various modules and languages.
With the speed increase indicated in the previous table, we nat.urally were curious how time is consumed having to use the VDP RAM as an intermediate storage area. The table below shows the time required to copy a disk. When the CorComp disk controller copies a disk, VDP RAM does not have to be used as an interme.diate storage place, thus saving time.
Measuring performance increase figures is always a challenge. This is due to the fact that the “statistics people” can make them do what they want. But you can see a performance increase in using CorComp disk controller and disk manager of up to about 296 percent, depending on several of the following factors:
• Diskette density
• The operation being done
• Diskette file type (Display/Variable is the worst)
• Language used (GROM — worst case)
• Kind of loader (Extended BASIC, Editor/Assembler, etc.)
• File sector location on the diskette
CORCOMP DISK MANAGER UTILITIES
When the CorComp utilities were designed we learned that TI changed Extended BASIC to prevent its scanning the peripheral DSRs for CALLs, such as CALL FILES, from running a program. To allow the utilities to function with Extended BASIC, a list of the utilities had to be provided in the Link Table in extended mem.ory. Thus the syntax for using the CorComp utilities in Extended BASIC is CALL LINK(utility name)(etc....)
Console BASIC did not possess this constraint. In BASIC, the utility syntax is CALL(utiity name, etc.).
The CorComp disk manager was written especially for the CorComp disk controller. We tried to think of all the features one would like in a disk manager. Just about all of the ideas are in the current disk manager. A decision was made to distribute the disk manager on diskette because it would be easy to easy to release an update and the cost to customers would be lower, compared to a module.
Figuring out all the technical details of how to achieve compatibility with the TI hardware, software and firmware was a hard and time-consuming effort. At times, some of the issues seemed almost too much to overcome. In the end, our perseverance and determination were rewarded and the disk controller card reached the market. All the known problems had been resolved by Novem.ber 1984. All other third-party cards are compatible with the Cor.Comp 9900 Disk Controller Card.
THE MANUAL
While writing the manual, we decided to try to present the material in a manner that would allow the beginner to follow the guide in a logical, step-wise manner. This allowed the user to learn how to use the card in a straightforward manner. The manual was also designed for the technically inclined. It required some 700 hours of effort before these objectives were achieved.
|
