70 jc
F
FBACKUP4
F
F(A Backup utility with automatic Format for Model 4.)
F
FLance Wolstrup
F20311 Sherman Way #101
FCanoga Park, Ca. 91306
F
F
F
Fl2
Fjb
FThe Model 4 operating system (as of this writing, TRSDOS 6.2) hasFan extremely powerful BACKUP utility. However, the neccessity to useFthe FORMAT utility separately when you wish to copy a diskette hasFalways annoyed me.
FAfter some procrastination I decided to write my own BACKUPFutility. The plan was to have the destination disk formattedFautomatically, then copy each source track to the correspondingFdestination track, and then finanally to verify the validity of theFtrack writes. My plan changed when I saw Montezuma's CP/M BACKUPFutility, named DUP. There, indeed, was a 'fun' program. It formats theFdestination track, reads the source track, writes it to theFdestination track and then verifies the write, all the time displayingFthe track number and a graphic block that moves to indicate whichFfunction is being performed.
FThat's what I wanted. So, I set out to write my program. As I own aF'standard issue' Model 4 (one with just 2 internal single sidedFdrives), my needs are modest--strictly double density formatting andFthen copy from a single sided 40 track source diskette to a singleFsided 40 track destination diskette.
FDidn't seem too difficult.... Boy, was I wrong.
F
Fg1
FHOW DO YOU FORMAT A DISKETTE?
F
FI knew, like most computer users, that the FORMAT utility preparesFthe diskette by writing certain information on it, but I had no ideaFwhat that information was. I consulted the TRSDOS manual and read theFsection on FORMAT/CMD. It referred me to the Model 4 TechnicalFReference Manual. Good, now we were getting somewhere.
FThe Technical manual was somewhat helpful. SuperVisor Call 55F(@WRTRK) does indeed write a track of formatted data. Unfortunately itFdoes not explain exactly what that formatted data should be. InsteadFit says, and I quote: "The data format must conform to that describedFin the disk controller's reference manual."
FNot being the owner of this particular manual, I made calls to, andFvisited, several Radio Shack Computer Centers. They were not aware ofFthis manual, nor could they order it for me. And to my question ofF'How do you format a diskette?' the best reply I received was: "TypeFFORMAT and press the ENTER key." Overwhelmed I mumbled, "Gee thanks",Fbought a 98 cent package of disk labels and left.
FTrips to the library and the local book stores brought me the sameFresult: Nil. Pleas for help left on a dozen bulletin boards were leftFunanswered. This was getting frustrating, but in one respect it madeFme feel good: I was not alone in my ignorance.
FSuddenly it dawned on me that I had had the information I neededFall the time right in front of me: FORMAT/CMD.
FI stripped FORMAT/CMD of its owner password that, as in all otherFTRSDOS 6.x.x. utilities, is UTILITY, send the program through myFdisassembler and got a print-out of the code.
FAfter countless hours spent commenting the source-code, guessing onFsome of it, using DEBUG to single step through portions of theFprogram, I finally began to see some semblance of order.
FFORMAT/CMD uses a buffer starting at 3100H to lay down the formatFcode for the entire track, which is as follows:
F32 bytes of 4EH from 3100H to 311FHThis is the initial pre-trackFfiller.
F12 bytes of 00H from 3120H to 312BHMore filler.
F3 bytes of 0F5H from 312CH to 312EHStill more filler.
F1 byte of0FEH at312FHSector ID address mark.
F1 byte of 00H at3130HThis is the track number.
F1 byteof 00H at3131HSide number - 0 for single
Fsided disk.
F1 byte of 00H at3132HSector number.
F1 byte of 01H at3133HSector length - 1 means 256
Fbyte length.
F1 byte of 0F7H at3134HThis generates CRC parity
Fbytes.
F22 bytes of 4EH from 3135H to 314AHPre-sector filler.
F12 bytes of 00H from 314BH to 3156HMore filler.
F3 bytes of 0F5H from 3157H to 3159HStill more filler.
F1 byte of0FBH at315AHSector data mark.
F256 bytes of alternating 6DH and 0B6H
Ffrom 315BH to 325AHThis is the actual data
Fwritten to disk.
F1 byte of 0F7H at325BHThis generates sector data
FCRC.
F24 bytes of 4EH from 325CH to 3273HPost sector filler.
F12 bytes of 00H from 3274H to 327FHMore filler.
F3 bytes of 0F5H from 3280H to 3282HStill more filler.
FThis completes the data to write the first 256 byte sector ofFformatted data. Since there are 18 sectors per track, the bytesFstarting at 312FH (Sector ID address mark) to 3282H (Still moreFfiller), need to be written 17 more times to the buffer. When that hasFbeen done, a post-track filler of 512 bytes of 0FFH to the bufferFfinishes out the complete track information.
FIn the buffer we now have a pre-track filler, 18 sectors worth ofFdata and a post track filler. The only problem is that all 18 bufferFlocations that indicate the number of the sector are numbered 00H.
FFORMAT/CMD uses the following sector numbering scheme:
F0,9,1,10,2,11,3,12,4,13,5,14,6,15,7,16,8,17.
FThis is done so the disk controller can access the sectors in fewerFrevolutions of the diskette.
FThese sector numbers need to be loaded into their repective bufferFlocations, and they are:
F3132H=0 (0 is already there), 3286H=9, 32DBH=1, 352EH=10, 3682H=2,F37D6H=11, 392AH=3, 3A7EH=12, 3BD2H=4, 3D26H=13, 3E7AH=5, 3FCEH=14,F4122H=6, 4276H=15, 43CAH=7, 451EH=16, 4672H=8 and 47C6H=17.
FAt this point track 0 can be formatted by using the @WRTRKFSuperVisor Call. (SVC 55).
FBefore the next track can be formatted, the Track Number bufferFlocations must be updated to indicate the correct track number. TheseFlocations are:
F3130H, 3284H, 32D9H, 352CH, 3680H, 37D4H, 3928H, 3A7CH, 3BD0H,F3D24H, 3E78H, 3FCCH, 4120H, 4274H, 43C8H, 451CH, 4670H and 47C4H.
FArmed with this information, I went to work at the keyboard, andFBACKUP4/CMD was born.
F
F
FBACKUP4/CMD - How to use it.
F
FYou are first prompted to type the number of the source drive.FDepending on the number of drives configured in the system, it can beFany number from 0 to 7. Pressing the <BREAK> key will reboot to DOS.
FThe program then prompts for the destination drive number. Again,Fthis can be any number from 0 to 7, depending on the systemFconfiguration. The destination CANNOT be the same as the source.FPressing the <BREAK> key here brings you back to the source driveFprompt.
FNext you are prompted to insert the diskettes in their properFdrives. When this is done, press any key and BACKUP4 will go to work.
FWhen the backup is completed you are asked if you want to makeFanother copy. If Y<es>, the program goes back to the source prompt. IfFN<o> or <BREAK>, you are told to make sure a DOS diskette is in driveF0. Then pressing any key reboots to DOS
F
F
FADVANTAGES AND DISADVANTAGES.
F
FIf your needs are like mine, single sided - double density - 40Ftrack backup, the advantages of using BACKUP4 are manyfold. First andFforemost, it can completely replace FORMAT/CMD and BACKUP/CMD on yourFsystem disks, thereby increasing your disk space by 10.5K. FORMAT/CMDFand BACKUP/CMD uses a combined total of 13.5K, BACKUP4/CMD only takesFup 3K. The second advantage is, it is faster than using the twoFaforementioned programs. They format and backup a diskette inFapproximately 110 seconds. BACKUP4/CMD does it in 83 seconds. Thirdly,Fit will not only backup system and data disks alike, but it will alsoFcopy the infamous 'backup limited diskettes.' (for your own use,Fplease.)
FThe disadvantage is that the program is limited to single sided,Fdouble density, 40 track backups.
FI think the trade-off is worth it.
F
F
FFINAL NOTES
F
FBACKUP4/CMD was written using the old Model I/III EDTASM package,Fpatched to work with Model 4 and should work with any of the 'real'FModel 4 assemblers. My thanks goes out to Douglas Payne for writing aFgreat article on how to patch EDTASM. (MODEL 4 EDTASM FOR FREE. 80FMICRO, August 1984, page 43.)
FAnother tip of the hat goes to Michael J. Wagner's incredible book:FMACHINE LANGUAGE DISK I/O & other mysteries. Though written for ModelFI & III, much of the information applies to Model 4. Unfortunately IFdid not discover it until my program was almost finished, but it didFhelp me verify the layout of the track format, as well as explainingFthe reason for the individual format bytes.
FI have commented each line of the BACKUP4 source code to the pointFof redundancy. This is done for two reasons. First, to make theFprogram understandable to a novice A/L programmer. Second, to avoidFmaking this article overly long by including lengthy explanations ofFeach routine. Just remember, when typing in the code, these commentsFcan, and probably ought to be left out. The source code is in excessFof 40K because of the liberal comments, but assembles down to 3K
FIf anyone has questions and/or comments regarding the program,Fplease contact me by mail, and I will respond as speedily as possible.FMy address is: Lance Wolstrup. 20311 Sherman Way #101. Canoga Park,FCa. 91306
F
F  