|
|
DOS Patches III |
"Stitch" in these improved patches for the PDD-2.
by Mike (The Tailor) Nugent
Extracted from Portable 100, Vol 6, No 3, March 1989
Copyrighted 1988 by Portable Computing International Corporation
Good news-I was wrong! In earlier discussions of patching the disk operating system (DOS) for Tandy's Portable Disk Drive 2, I stated that, since the patched DOS cannot be saved as a file, you must re-patch each time you install the DOS. 'Tain't so! Troublemaker/geniusRobert Holland, Sr., took me to task on that and showed how to save the DOS as a file. (See 'DEFUSR')
Thus chastised and inspired, I've further refined his method and am happy to present the improved patches. Those who've requested more technical explanations, read on. Sane people can skip straight to the patches (see "PATCHING THE DOS" below).
The need arose when Tandy's first DOS, FLOPPY.CO for the original Portable Disk Drive (PDD-1 ), proved hostile to the kind of file containing machine language packed inside a BASIC program. Such a file must reside at a specific address in RAM-usually the very lowest address-to work. If it gets moved, it malfunctions, usually causing a cold start.
FLOPPY.CO loads .BA files from disk into the lowest RAM address, pushing all existing files upward in memory to make room. If one of those pushed files is a packed file-WHAM! System crash.
No such problem with cassette, which loads .BA files intonthe "unsaved-BASlC-program" area just above existing.BA files. The computer maintains a pointer to this area to keep track of its position, and thencassette routine simply reads the pointer to find the program.Only files above this area (.DO and .CO files) are pushed upwardto accommodate the new file. All existing .BA files, being belowit, remain safely in place.
Why wasn't FLOPPY.CO designed to read that pointer and do the same thing? Who knows? It should have been.
So patches were developed to make the DOS do just that. You can save the patched code as a file named NEWDOS.CO (to indicate its modified state), and thereafter, you would use NEWDOS.CO instcad of FLOPPY.CO as DOS.
With DOS thus tamed, thc world was once again safe for packed programs like Micro Demon's Supera, P.G. Design's MENU.BA, Tri-Mike's DVORAK, etc.
BUT LATER ...
When Tandy introduced the Portable Disk Drive 2 (PDD-2), computers with packed files began going kablooey again. Hadthe PDD-2 DOS inherited its predecessor's genetic defect?
Precisely. Tandy had blown an opportunity to fix the flaw that made the old DOS hostile to packed programs. What they had not blown, however, was the opportunity to make the new DOS hostile to even more programs-including their own!
Was there somc logical reason? Well, sort of. To understand it, let's examine the way the computer handles .CO files.
All files are stored in low memory. Whereas .BA and .DO files operate right where they're stored, a machine language (.CO) file can operate only at the address for which it was written, usually somewhere in high memory. So the machine's designers had to provide a way to execute such .CO files.
Remember the term pointer? The variable MAXRAM is apointer to the highest address that any program may use (Model 100-62960; Tandy 200-61104). Memory from there on up is reserved as a scratchpadwhere the computer can track essential data such as file locations, the contents of the LCD screen, and other "housekeep-ing" information, so the computer is necessarily quite protective of this area. In effect, MAXRAM acts as the "ceiling"of memory, carefully guarding what's in the "attic" above.
HIMEM, another pointer, can be set via the CLEAR statement to point anywhere from MAXRAM on down, acting as a "false ceiling" or "drop ceiling." Most programs normally are not allowed to use memory from HIMEM on up, so that area between HIMEM and MAXRAM provides a safe place for .CO files to operate.
Take MYFILE.CO, a hypothetical 2959-byte Model 100 program, written to exccute at address 60000. The file actually occupies 2965 bytes (2959 bytes plus 6 bytes of header information) somewhere in low memory. It can't run there- it's only stored.
To run it, you'd first issue a CLEAR 256, 60000 to set the HlMEM pointer to 60000. This reserves a safe place for the file tooperate-between HIMEM (60000) and MAXRAM (62960). Then LOADM "MYFILE" puts a copy of MYFILE.CO (minus header) into the reserved space.
Now two copies of the file exist- MYFILE.CO stored in low memory (and showing on the menu) and an executable copy in high memory. CALL 60000 (its execution address) will now runthe executable copy.
So you can see that running a .CO file consumes twice its normal space requirement. The file on the menu is strictly for storage, while the high memory copy executes. And therein lies the drawback of normal .CO files: It takes two to tango, but only one dances!
Well, then, you can save space by having no menu copy. You can just keep an executable copy in high memory and CALL it whenever you want to run it, right?
Absolutely. That's what Tandy did. Putting only a tiny driver/checksum program ( called FLOPPY) on the menu, it parks the executable DOS in high memory where it must be fiercely protected.
Setting the HIMEM pointer isn't enough. All manner of other programs change HIMEM, endangering the DOS. Some may even LOADM other .CO files right on top of it, corrupting it, with disastrous results when you CALL it later. It needs tougher measures.
The MAXRAM pointer, normally fixed, can be lowered artificially by means of special machine language programming voodoo (beyond the scope of this article). The PDD-2 DOS uses this voodoo.
MAXRAM is somewhat sacred. Thou shalt not perform CLEAR with any address greater than MAXRAM; the computer won't let you. CLEAR 256, MAXRAM, a common statement in BASIC programs, can set HIMEM equal to- but never greater than- MAXRAM. So CLEAR statements can't disturb the DOS in the "attic" above the lowered MAXRAM.
But misguided POKEs can still pelt it, and LOADMs and RUNMs can still dump .CO files all over it. So there's another safety feature: FLOPPY,the driver/checksum program on the menu. When you run it FLOPPY does a checksum on the DOS to detect corruption. If DOS is indeed farkled, FLOPPY refuses to run it.
What seems a logical memory-saving scheme has some serious flaws. Any program needing DOS-occupied RAM is either refused admittance or corrupts the DOS, depending on its nature. Either case requires FREMEM.BA to kill FLOPPY and perform the neccssary reversevoodoo to normalize MAXRAM.
In the first case (refused admittance) you must run FREMEM.BA before the offending program, then reboot the DOS afterwards. With the numerous programs that DOS finds offensive, this process becomes a tiresome pain in the neck.
In the second case (trashed DOS), FREMEM.BA must alreadybe in RAM to clean up the mess before you reboot the DOS.Otherwise, you'll have to cold start, since the demented DOS can't load it from disk. Keeping FREMEM.BA in RAM is necessary for safety but tends to offset the intended memory savings.
Together, FREMEM.BA and FLOPPY use two directory slots and 411 bytes. FLOPPY's counter part in the DOS code, unnecessary in a normal .CO file, further offsets the perceived savings. And then there's the high memory permanently occupied by the DOS. Is it worth it?
Actually, for the price of a little "wasted" memory- and only at run time-the more conventional FLOPPY.CO has a lot going for it. Foremost is flexibility. It's one file in one directory slot, easily saved to tape and disk or uploaded to other computers. It's unobtrusive when idle, doesn't tie up high memory, and re-quires no cold starts. And when patched, it coexists peacefully with most any program. Not a bad set of credentials.
PATCHING THE DOS
To turn the arrogant PDD-2 DOS into a nice guy, too, boot the DOS, type the appropriate line below, and press ENTER:
M100- POKE 62116,154: POKE 62117,249: POKE 62118,0
T200- POKE 58799,149: POKE 58800,242: POKE 58801,0
These patches make the DOS load .BA files into the unsaved-BASlC-program area, for compatibility with packed files.
We're creating a normal .CO file, where a fresh copy loads each time it's run. Corruption won't occur, so we can dispensewith any checksum-related code (e.g., the first three bytes of DOS, at MAXRAM- we'll skip them).
When you save NEWDOS, you'll use a statement that resembles this: SAVEM "NEWDOS", Top, End, Exe, where you'll save from a Top address of MAXRAM+3 (M100-60003; T200-56675) to an End address one byte before FLOPPY's load point (M100-62700; T200-59393). And when DOS is uncorrupted FLOPPY jumps to MAXRAM+3 to execute the DOS; that's our Exe address (coincidentally, the same as Top).
With this, you're ready to save the code to a .CO file. Type the appropriate line below and press ENTER:
M100-Type SAVEM "NEWDOS", 60003, 62700, 60003
T200-Type SAVEM "NEWDOS", 56675, 59393, 56675
That creates NEWDOS.CO,weighing only 2704 bytes (2725 on the T200). Now run FREMEM.BA (use FLOPPY to load it from disk, if necessary) and then kill FREMEM.BA.
To run NEWDOS.CO, type CLEAR 256, Top: RUNM"NEWDOS" (in place of Top type 60003 for M100, 56675 for T200) and press ENTER. If you can spare a directory slot, you can save that line as a short .BA program that runs NEWDOS.CO for you, so you needn't remember the Top address for the CLEAR statement. To reclaim the high memory after using NEWDOS.CO, type CLEAR 256, MAXRAM and press ENTER.
By the way, if you ever forget the starting address of NEWDOS.CO, just type LOADM "NEWDOS" and press ENTER.NEWDOS attempts to load, and in doing so, it displays the Top,End, and Exe addresses of the file.Be sure to save NEWDOS.CO to the same disk you use to boot FLOPPY. Then if you ever accidentally kill NEWDOS.CO or havea cold start (which should happen less often now), just boot FLOPPY and use it to load NEWDOS.CO and FREMEM.BA. Run FREMEM.BA and then kill it. Voila! Back to normal.
Return to: | Documents | PDD2 |
11/03/97