Software Modifications/Patches

Program Modifications and Patches – Menu

Putting Tape Software on Disk:

Backing Up Protected Software:


Putting tape FS1 on Disk – R Baker

Before starting, load the FS1 master tape a few times so that you know the correct volume setting for it. Then make sure your disk has at least 15 grans of free space. Under Disk Basic set Memory Size to 48896 and type in the following program. Check it and RUN it.

20 FOR J=0 TO 198
40 CK=CK+D
50 POKE -16640+J,D
100 DATA 243,205,201,1,33,81,191,205,207,68,175,205,18,2
110 DATA 1,203,40,33,0,160,205,150,2,205,53,2,119,198,1
120 DATA 50,63,60,43,11,120,177,32,241,1,16,1,17,0,161
130 DATA 33,0,160,237,184,33,240,159,54,0,43,16,251,33
140 DATA 152,191,34,155,119,33,0,0,34,135,119,34,136,119
150 DATA 33,128,91,34,230,160,195,96,191,83,84,65,82,84
160 DATA 32,70,83,49,32,84,65,80,69,13,33,128,191,205
170 DATA 207,68,205,73,0,205,135,2,33,0,161,1,203,41,126
180 DATA 50,63,60,205,100,2,43,11,120,177,32,243,199,83
190 DATA 84,65,82,84,32,82,69,67,79,82,68,73,78,71,32,60
200 DATA 69,78,84,69,82,62,13,1,128,49,17,0,131,33,0,67
210 DATA 237,176,1,24,0,17,87,131,33,175,191,237,176,199
220 DATA 243,1,48,49,17,102,67,33,102,131,237,176,195
230 DATA 102,67,243,49,0,98,62,67,205,156,73

If the DATA statements have any errors in them the message “BAD CHECKSUM” will appear. When the program is correct SAVE it onto disk. You will now need a very-good-quality blank tape on which an “intermediate” non-runnable copy of FS1 will be stored.

Still in Basic, type: SYSTEM ENTER /48896 ENTER. This will execute the machine language program just POKEd in. The first prompt you see will be to start the FS1 master tape running in the cassette recorder. Rewind it to the beginning and put it in PLAY. As the master tape is read in most of the code will be displayed in the upper right corner. When it is all in the next prompt will appear for you to put the blank tape in the recorder and set up to RECORD. The tape will start moving immediately. Once it’s going press ENTER. The intermediate copy of FS1 will be written onto the blank tape. Again the characters will be seen in the corner. At the end of the dump the disk will boot-up. Rewind the intermediate tape to the beginning and type BASIC2 ENTER to get into Level II. Just press ENTER for Memory Size. Now use the SYSTEM command etc. to load the intermediate tape just as if it were the master FS1 tape. If you get an error during the load, press RESET to boot the disk and start again from the BASIC2 entry. At the end of a successful load the disk will again boot-up. In DOS now, type:

DUMP FS1/CMD (START=X'8357',END=X'B480',TRA=X'8357')  ENTER

Don’t omit the two required blanks in the DUMP command; one after DUMP and one after /CMD. When the disk stops running it will have a copy of FS1 on it that you can run by typing FS1 ENTER.

Those interested in modifying the program will know how to take it from here. The coding is self-modifying and complex. Here’s a few notes on what I have found. The routine at 72F8H that writes the border on the screen is erased once it is used. At 4AEBH and 518FH are routines that will unpredictably modify memory when called. It is best to simply put a C9H at these two locations. The main keyboard scan routine seems to be at 4A75H – it may be possible to patch in added features here. “IN RANGE” is printed at 5176H, “STALL” at 4D0EH. The area 4407H-4475H (at least) is used for variables storage. If you succeed in finding and modifying the data base I’d like to hear about it.

Backing Up the FS1 Master Tape – R Baker

Before starting, load the FS1 master tape a few times so that you know the correct volume setting for it. Then enter Basic with a Memory Size of 32512. Type in the following program, check it and RUN it..

20 FOR J=0 TO 124
40 CK=CK+D
50 POKE 32512+J,D
100 DATA 243,205,201,1,33,91,127,205,167,40,175,205,18,2
110 DATA 1,203,40,33,0,122,205,150,2,205,53,2,119,198,1
120 DATA 50,63,60,43,11,120,177,32,241,1,16,1,17,0,123
130 DATA 33,0,122,237,184,33,240,121,54,0,43,16,251,33
140 DATA 109,127,205,167,40,205,73,0,205,135,2,33,0,123
150 DATA 1,203,41,126,50,63,60,205,100,2,43,11,120,177
160 DATA 32,243,195,204,6,83,84,65,82,84,32,70,83,49,32
170 DATA 77,65,83,84,69,82,13,0,65,78,89,32,75,69,89,32
180 DATA 84,79,32,68,85,77,80,0

If there is an error in the DATA statements the message “BAD CHECKSUM” will appear. When the program is correct, CSAVE it. Then at the READY prompt type SYSTEM ENTER /32512 ENTER. This will execute the machine language program just POKEd in. The first prompt will ask you to start the FS1 master tape running in the cassette recorder. Rewind it to the beginning and put it in PLAY. As the code is read in all but the first characters will appear in the upper right corner. At the end of the load a second prompt will appear for you to put the blank tape in the recorder and set up to RECORD. The tape will start moving immediately. Once it’s going press ENTER. The backup copy of FS1 will be written onto the blank cassette.

Putting tape SFINKS on Disk – R Baker

Purchasers of the SFINKS 3.0 chess program on tape may be interested to know that there is a simple way to put the game on disk.

Go into Level II Basic, setting Memory Size to 28000. Use the SYSTEM command to load the first part of the SFINKS tape as usual. When returned to the *? prompt, however, stop the recorder and press BREAK instead of /ENTER. Now type in this Basic program and RUN it:

10 POKE 17321,195 : POKE 17322,204
20 POKE 17323,6 : POKE 28668,175
30 POKE 28669,195 : POKE 28670,104 : POKE 28671,191

Enter SYSTEM again, and at the *? prompt type: /17280 ENTER. Put the recorder back in PLAY. The SFINKS logo should come up and the program should load normally, except that at the end of the load it will return to Basic READY. The game is now in the top of 32K memory with Start, End, and Entry addresses as shown below. It may be written out either to tape (using TBUG) or to disk.

To save it on disk as a normal /CMD file, RESET and use the DOS “DUMP” command:


The syntax of this command may vary with your DOS, so check it in your manual.

Backing Up Super Utility Plus v2.1 – R Baker

To use these instructions Trakcess V1.3 or later will be required, with two disk drives. Always use as a target (destination) disk one that is known-good and completely erased.

Use Trakcess’ Duplicate command to copy all 35 tracks of the original disk, but skipping Tracks 4 and 5. These two tracks have “bad” sectors on them that the original disk checks for during program load. Now put your original away and select the target disk (the copy you just made). Go to Track 3 and Read sector TN=03 SN=00. Use the editor to examine the data read in. On or about the 28th byte of the sector you should see this code: C2 C0 42. Change this to 00 00 00. Now go to about the 39th byte and do the same thing to the C2 C0 42 code there. Leave the editor and from the main menu Write this doctored sector back off to the target disk. You should now have a working copy of SU+ V2.1. What you did was to remove the check for bad sectors on Tracks 4 and 5.

Another mod you might want to make is to disable the comforting but time-consuming memory verification that V2.1 performs during its load. To do this, read in Sector 00 from Track 3 again, as above. Locate this code at about the 78th byte of the sector: 21 00 00. Zero this and all bytes down to and including the C2 BB 42 code at about byte 101. Now Write this sector back off to the target disk.

Backing Up Super Utility Plus v2.2 – R Baker

To use these instructions Trakcess v1.3 or later will be required, with two disk drives. Always use as a target (destination) disk one that is known-good and completely erased.

Kim Watt does make available to you a back-up copy at a reasonable price. Nonetheless, you will want to be able to make your own – if not for long-term safety then to allow you to have several copies “hard-configured” for the work you do.

To remove the protection from the disk, so that Trakcess will automatically duplicate it:

Use Trakcess’ Duplicate command to copy all 35 tracks of the original disk, but skipping Tracks 4 and 5. These two tracks have “bad” sectors on them that the original disk checks for during program load. Now put your original away and select the target disk (the copy you just made). Go to Track 3 and Read sector TN=03 SN=00. Use the editor to examine the data read in. On or about the 28th byte of the sector you should see this code: C2 C0 42. Change this to 00 00 00. Now go to about the 39th byte and do the same thing to the C2 C0 42 code there. Leave the editor and from the main menu Write this doctored sector back off to the target disk. You should now have a working copy of SU+ V2.1. What you did was to remove the check for bad sectors on Tracks 4 and 5.

Another mod you might want to make is to disable the comforting but time-consuming memory verification that V2.1 performs during its load. To do this, read in Sector 00 from Track 3 again, as above. Locate this code at about the 78th byte of the sector: 21 00 00. Zero this and all bytes down to and including the C2 BB 42 code at about byte 101. Now Write this sector back off to the target disk.

Backing Up Med Systems Disks – R Baker

To use these instructions Trakcess v1.3 or later will be required, with two disk drives. Always use as a target (destination) disk one that is known-good and completely erased.

Med Systems will be familiar to you as a company that has always tried to offer quality software at a low price. Their maze games in particular are unparalleled in complexity and graphic presentation. Med has dabbled in protection before, I believe, on their Human Adventure disk. I never received any requests for special help on that, so I assume it was dog meat for Trakcess. Their newer schemes are more involved, but the only one that requires any effort to break is on the Labyrinth/Deathmaze disk. The others I’ve seen (Asylum and Microworld) can be directly Duplicated if you specify, for all bad sectors encountered, a length of 256 bytes and IBM type.

There are two ways to duplicate the L/D disk. You can either construct the one funny track required to satisfy the protection-checking code on the disk, or you can zap the protection right off the disk so that no oddball sectors are required. Both ways will be described here.

To make an odd but useable copy of the Labyrinth/Deathmaze disk: use Duplicate as usual, but for the bad sector on Track 3 specify a length of 768 bytes, non-IBM type. Note the SN of this bad sector, which on my disk was 4E. Then Take Track 3 of the source (original) disk. Look at the track data in memory, and locate the start of sector 4E (or whatever SN you found). Do this by finding the sequence of code FE 03 00 4E … The FE follows a long string of FFs, and is the ID Address Mark, or IDAM. This FE-TN-00-SN sequence of code is called the ID pack for the sector. If you can’t locate the FE, try (T)aking the track again. About twenty bytes after this ID pack will be an F8 byte, which is the DAM or Data Address Mark. The next byte is the start of the sector data. On my copy this next byte was XX. Note the address in memory at which this byte is located. Now return to the main menu and select the target disk (the copy). Go to Track 3, and Write to sector TN=03, SN=4E (a non-IBM sector) the code beginning at the address noted above. In other words, answer the “Take it from where in memory” prompt with this address. Once the sector has been written you should have a working copy of the game disk.

To remove the protection completely from the disk, proceed as above using D to make a copy. For any bad sectors encountered, specify a length of 256 bytes, IBM type. Put the original away, and select the target disk (the copy). Position the head at Track 1 and Take this track into memory. Go into the editor to examine the track data in memory. Look through it until you find a block of sector data that begins with 18 2F. This is to say that these bytes should appear right after the F8 DAM for the sector. On my copy this sector data showed up about XXX bytes into the track. Now look back about twenty bytes at the ID block for this sector and note the sector’s TN and SN values. I found TN=01, SN=58. Having these, return to the main menu and Read this sector into memory. Then go back into the editor. The cursor will be over the first byte of sector data which, remember, should be 18. Move the cursor about 133 bytes down into the sector to where this code appears: 3E 76 01 B8 0B etc. Overwrite this code with 3E 40 33 33 ED 4B 04 B7 C3 C3 B7. Now go about another 70 bytes down in the sector until you find the code B7 C0 21 04. Change the C0 to 00. Return to the main menu and Write this much friendlier sector back to the target disk – which should now be a useable copy of the game disk, without any odd-length or broken sectors.

Backing Up BIG 5 Games – R Baker

To use these instructions Trakcess v1.3 or later will be required, with two disk drives. Always use as a target (destination) disk one that is known-good and completely erased.

Big Five has a unique attitude toward protection which bears mention here. Their tape versions are apparently unprotected. All mine went nicely onto disk using LMOFFSET. Even the disk versions, when purchased on tape, are not protected. You only get stuck if, to avoid all hassle (!?!?!!), you shell out the extra cash for an on-disk copy. Then you get the works, including nasty little threats in the code, a bunch of oddball sector lengths, a tricky loader, a detailed check of the tracks for special formatting, and to top it all off, a routine that ERASES THE DISK if the checks fail! And they might fail, too, if your system burps while loading. In that case you can return the original to Big Five (with a big $5) for replacement. Unless they no longer exist or distribute that program… It seems that they HAVE discontinued both Galaxy Invasion and Robot Attack (which I thought were the best two arcade games on the market). The reason given is that Atari thinks Big Five made unauthorized use of THEIR game ideas… What does all this big-fish-eating-little-fish mean to the customers? It means they had better watch out for themselves, that’s what.

To duplicate a Big Five disk, begin as usual by using Trakcess’ D command to make a copy. Then put the original away, and select the target disk (the copy). Do a (S)can of Track 1, and look at the TN’s and SN’s presented. Ignoring the order in which Trakcess displays them, pick out the sector which would be second according to its SN. For example, if the SN’s are 42, 48, 44, 46, then the sector you want has SN=44. Note its TN also, and go back to the main menu and Read this sector into memory. Examine the data read, and locate the following sequence of bytes: C0 3E E4. Change the C0 to C9, and Write the sector data back out. You should now have a working copy of the game disk. From now on, run it instead of your master. If it gets trashed, make another copy and send ME the $5.

Hidden controls for FASTEROIDS

In addition to the game’s normal key functions, it will also respond to the keys 06 during play. These have the following effects:

Pause game.
Practice mode. Allows you to try the game at higher skill levels.
Abort the game and display the score.
Save scores to tape.
Load scores from tape.
Increase speed of play.
Stop the movement of the asteroids, allowing you to fight just the aliens.

How to Back Up The Sargon II Tape -and- How to Put Sargon II on Disk; by R Baker

The new Sargon II chess program is now available. The ads are hopelessly vague, but those of you who have a copy know that it is much faster, and significantly stronger, than the original Sargon. Anyone not a serious student of the game will find it tactically formidable, although it is still weak positionally and in the endgame. This is true at reasonable rates of play. Overall, the program represents an impressive improvement, and certainly plays the best TRS-80 chess yet.

Another significant change, unmentioned in the ads, is that the Sargon II tape is copy-protected. After you spend your $30 (!), you find that Sargon II has a short program on the front end that loads in first. This program, using a special format, then loads in the actual Sargon II code. This format is incompatible with the standard TRS-80 utility programs, and is used solely to keep you from making a copy of Sargon II for someone else.

The bite is that this copy-protection also keeps you from making a back-up copy of the master tape for yourself, and from putting the program on disk! Both of these are entirely reasonable actions, and Hayden should have allowed for them. They know that the CTR-80 recorder is notorious for eating or glitching tapes. And, certainly, no one with a disk system wants to be forced back to tape. Hayden may someday offer a disk version of Sargon II, but it is far from imminent. Even if they do, anyone buying the tape version in the meantime will be stuck with it.

So you’ve bought the Sargon II tape and you need a backup or a disk copy of it – What can you do? Well, for one thing you can write to Hayden and complain. That might help the next guy. In the meantime, one of the two procedures below should solve your problem.

Backing-up the master tape (requires TBUG):

The idea here is to load Sargon II normally, and then load the radio shack ‘TBUG’ Monitor program. TBUG is used to punch out a standard system tape copy of the Sargon II code. Also, a short routine is added to make the break key work correctly during play. Made on your own machine, this system tape should load more reliably than the master tape, and it will save the master from wear and tear.

To do this, power-up Level II basic and load the master Sargon II tape according to its instructions. When the game comes up running, press the reset pushbutton (or break and reset, if you have the expansion box). Now you’re back in Level II basic. Load TBUG according to its instructions. When it has loaded, and you have the *? prompt under system, type /17312. You will get the # prompt of TBUG.

Before the system tape is written, the break key code must be entered. Type:


And TBUG will go into the modification mode at this address. Carefully enter the following 18 pairs of hex numbers. No use of the space bar or enter key is required; TBUG will automatically step to the next address after each number pair is written:

3E C3 32 0C 40 3E 00 32 0D 40 3E 50 32 0E 40 C3 00 50

The last number pair should have gone into address 770E. If you make an error, press x and start over with M76FD. When this is all done, press x to return to the # prompt of TBUG. Put a good-quality blank tape in the recorder, and set up the machine to record. Now carefully type in the following. Note that you do not type the blanks. TBUG will automatically supply them:

P 4A00 770E 76FD SARGON

As soon as you key the “n” in “Sargon”, the tape will start and a regular system tape copy of Sargon II will be created. To be safe, type it again for a second copy.

Incidentally, you can also make a spare copy of the TBUG monitor itself by typing:

P 4380 497F 43A0 TBUG ENTER

Your new Sargon II system tape is, of course, loaded under the system command by entering the filename ‘Sargon’. When the tape has loaded, and you get the *? prompt, just enter “/” or “/30461” To run Sargon ii.

Putting Sargon II on disk:

Briefly, the technique here is to read the Sargon II tape into memory normally, under Level II BASIC. Using BASIC, two short block-move routines and a break key routine will be tacked onto the end of the Sargon II code. Then, with the ability to move Sargon II around in memory, we will first move it out of the way of dos, and use the trsdos utility ‘tapedisk’ To put it onto disk. The second block-move routine (and the break key routine) also go to disk. Then, whenever Sargon II is called from dos, it will be slid down into its proper place and executed.

First, power-up Level II BASIC by holding down the break key while you press the reset button. Load the Sargon II master tape according to its instructions. When the program comes up running, hold down the break key and push reset again. Push enter for memory size. Now carefully type in the following one-line BASIC program. Check it, and run it:

1 FOR J = 1 TO 43 : INPUT K : POKE 30460+J,K : FOR L = 1 TO 80 : NEXT L : NEXT J

The program will prompt you with ? to enter each of the forty-three decimal numbers listed below. Type them carefully, pushing ENTER After each complete number :

1 253 44 17 0 74 33 0 128 237 176 62 195 50 12 64 62 0 50 13 64 62 80 50 14 64 195 0 80 1 26 45 17 25 173 33 25 119 237 184 195 0 0

After the last one has been entered, the ready prompt will reappear. If you see that you’ve entered a number incorrectly, press break and run the program again.

Now make sure there is a disk in the drive, with the TAPEDISK utility on it. Still in Level II BASIC, type

System ENTER

And at the *? prompt, type: /30490

The disk will boot up normally. At ‘DOS READY’, type


This utility should load and run, and give you a ? prompt.

Next, be sure that the disk in drive zero has at least 10 grans of free space and no write-protect tab. Type in the following exactly. Note the mandatory blanks :


When the disk stops running, it will have a copy of Sargon II on it. Push reset, and at dos ready type:


The program should come up ready to play.

Sneak Circuit on the Starfighter – R Baker

I think that one of the finest action games yet is Adventure International’s “Starfighter”, by Sparky Starks. Hats off to a great piece of work, that really does provide hours of entertainment. It isn’t cheap, but there is genuine value for the money. In a world where perhaps one program out of five really turns out to be worth the cost, this is a winner. I can’t help but compare it to 80-Space Raiders, by Bosen Electronics. The latter is apparently a similar game at a similar price, but I found to be very poorly designed and absolutely no fun to play. Sophisticated internally, maybe – but not a finished product. Perhaps someday it will be.

One of my few complaints about Starfighter concerns a glitch in the keyboard scan routine while in the Combat mode. This isn’t really a software problem. Rather, it results from the fact that the construction of the TRS keyboard allows “sneak paths” to be created. If you are interested in the electrical reasons for this, consult the TRS keyboard schematic in the tech manual. All you really need, though, is a copy of the TRS’ “keyboard matrix” diagram. It shows which keys can be read and at which addresses. This information has been published many times, such as in The Alternate Source V1N5 pg. 3. For convenience I have reproduced the diagram here:

Hex                                                     Dec.
Addr.                                                   Addr.
3801H:   @     A     B     C     D     E     F     G   :14337
3802H:   H     I     J     K     L     M     N     O   :14338
3804H:   P     Q     R     S     T     U     V     W   :14340
3808H:   X     Y     Z                                 :14344
3810H:   0     1     2     3     4     5     6     7   :14352
3820H:   8     9     :     ;     ,     -     .     /   :14368
3840H:  ENT   CLR   BRK   UA    DA    LA    RA    SPC  :14400
3880H:  SHF                                            :14464

Value:  01H   02H   04H   08H   10H   20H   40H   80H
Bit:     0     1     2     3     4     5     6     7

Example: to check for ‘R’, read address 3804H and test for a value of 04H. To check for the combination ‘PRT’, test for a value of 15H (values in a row add). It is also possible to test directly for bits being set in the value returned.

Reading the TRS-80 Model I Keyboard Matrix


This “matrix” type of keyboard allows great flexibility, as you can see. But it also allows sneak paths. These are not often a problem, for two reasons: first, a keyboard scan routine usually checks for a value at a location, rather than testing for a bit set. This acts to lock out some of the possibility of error. Second, even if bit testing is used, it is unlikely that the user would be pressing just the right multiple combination of keys to create a spurious but acceptable single-key entry. Sneak paths are really only a problem when key combinations MUST be allowed for.

What are these sneak paths? Consider the case where you intend to detect the ‘N’ key by reading location 3802H and testing for bit 6 to be set. Assume that the user for some reason presses ‘LTV’. Note that this combination forms a rectangle with the ‘N’ key as its missing corner. One way of describing the sneak path is to say that the ‘L’ signal “sneaks” down the Bit 4 column to ‘T’, where it is connected to the 3810H row. Then it “sneaks” along that row to ‘V’, where it gets on the Bit 6 column. It “sneaks” up that until it gets back to the row being read (3802H). Now the signal is at ‘N’ – so it appears that ‘N’ was pressed, too! Bit 6 at 3802H will be set.

You can quickly pick out any number of combinations that will give unexpected results:

  '9.F'       ==>  'AF'
  '@HI'       ==>  '@A'
  'ENT SPC P' ==>  'PW'
  'L DA RA'   ==>  'LN'

A short test in BASIC will convince you of this. See what happens when you press various combinations of keys while this is running:

10 CLS
30 GOTO 20

To check the different keyboard rows, use 14337, 14338, etc. in place of XXXXX here. As a particular example, specify row 14338 and press ‘L DA RA’ where DA and RA are left- and right-arrows. A value of 80 (50H) will be returned. Now press ‘LN’. You will get the same value.

In the example earlier, if what you really wanted to do was check for ‘N’ without allowing for any combinations to be recognized, you would certainly just test for a 40H to be returned from row 3802H. This is obviously safer than bit testing. But if you had to allow for multiple keys in a row to be pressed together, perhaps because they perform completely separate and simultaneous functions in your program, then you are perforce susceptible to the sneak path. If ‘LN’ must be allowed, you cannot just read 3802H and decide for sure whether or not that’s what was pressed.

This is the situation in Starfighter. That game always has a lot going on, and many keys are independently active at one time. Some need to be held down while at the same time others are being pressed and released. At least this is true if you ever want to be a Star Lord… Usu [… SOURCE DISK FILE HAD GARBAGE HERE …] Dempting to track and at the same time fire on an enemy ship, it is frequently true that the ‘L’, ‘down-arrow’, and ‘right-arrow’ keys will be pressed simultaneously. Starfighter uses bit testing for the Combat keyboard scan, so it thinks that ‘N’ was also pressed. Unfortunately, ‘N’ returns you to the Navigation mode – always at the worst possible time.

It is difficult to decide, in software like this, exactly how to handle the keyboard inputs. You might identify all the combinations that you intend to allow, and test specifically for those values. This is one “right” way to do it. If there are too many values, you could also try to lockout the combinations you don’t need. That might also be very involved. Perhaps the answer is to compromise and lock out the combinations that you don’t need AND can’t tolerate.

With the Starfighter problem limited to one case, this last approach gives an acceptable solution without too much effort. Whenever an ‘N’ is supposedly detected by finding Bit 6 of 3802H set, we will read address 38FDH to see if any other Bit columns have a key pressed in them. This checks the whole keyboard. Of course Bit 6 of 38FDH will be set, because it is set for Row 3802H. So we ignore Bit 6 (a compromise). If any other bits in 38FDH are set, we conclude that ‘N’ alone was not pressed – other keys are down. This doesn’t mean that the ‘N’ is the result of a sneak path, it just means that it could be. To be safe, we refuse to recognize an ‘N’ unless all the keys in Bit columns 0-5 and 7 are up. Then we know that ‘N’ can’t be the result of a sneak path. The practical result of this is that when we really want to return to the Navigation mode, we simply release all keys except ‘N’. This is acceptable in the game. In point of fact, we could still have any of the other keys in Bit column 6 down, but they alone can’t be the cause of a sneak path.

The actual patches differ for the tape and the disk versions of Starfighter. And they will only work exactly as shown if you happen to have exactly the same version of the game that I do, located in the same place. If they don’t work for you, then perhaps now that you know what the problem is and how to fix it you can find the required patch points in your copy of the game. Failing that, perhaps AI can help you. Here at any rate is what worked for me.

Also note that these patches only fix the problem in the Game mode. The Simulator mode (disk version) will still jump back to Navigation.


Disk version:

Fire up your trusty zap utility, insert a backup copy of the Starfighter disk …..wait….what? You say you don’t have a backup copy? Did those guys send it to you on a protected disk? How about that… You paid them $30 and they did this to you? Well, now you know where part of that money went – it paid somebody to make things extra hard for you. Think about that the next time you order a protected disk.

Fortunately, the disk is not heavily protected, meaning that if you have a copy of Trakcess or Super Utility Plus, you should be able to make a backup copy easily. Otherwise you will have to work on the master disk. This is not good practice, but the risk is small in this case since the zaps are minor. Keep a write-protect tab on until you are ready to actually write the new information onto the disk, and keep a record of exactly what bytes you change, and especially their previous values. Then you can go back if necessary. Values are in hex:

Track 03, Sector 00, Byte 80

Change whatever is there (I had random BASIC text) to

CA 7A 58 3A FD 38 47 3A 02 38 E6 BF B0 C2 7A 58 C3 B2 5C

Track 05, Sector 02, Byte 35

  Change E6 40 C2 B2 5C CD 00 to
         E6 40 C3 C0 42 CD 00

While the zapper is still warm, you might also want to correct the annoying misspelling of “competence”. You will find this in three places:

Track 06, Sector 07
Track 09, Sector 00
Track 0C, Sector 07


Tape version:

By this I mean having the tape version on disk, as a /CMD file. If you are running a 48K tape system, you can still make these changes, but you will need a monitor that can punch out merged machine-language programs. Even if you have disk, you may have offset the /CMD file to a different location than mine (8000H-BE06, entry BE09). In that case you will have to locate the equivalent of location 9661H in the patch below. This address refers to the code after it has been read from disk, but before it has been moved to low memory. It is the Combat mode keyboard scan routine. In context it is:

                LD    A,(3802H)
                AND   40H
        9661H:  JP    NZ,5CB2

If you find these instructions in a different place, use your address instead of 9661H. The rest should be the same.

Assemble the following code as SFFIX/OBJ, and then use Misosys’ CMDFILE utility (a super piece of software that you all should have) to attach it to the end of your Starfighter /CMD file. Do this by first loading in Starfighter and then SFFIX/OBJ. Then write the whole thing off to disk, specifying the same base addresses and keeping the Starfighter entry point.

; This code loads after SF and patches into it, before SF is
; moved down to be run:
        ORG     9661H           ;SF's check for N
        JP      VALIDN          ;Go to our code to validate
; The above patch directs SF to this code during the Combat
; keyboard scan.  We doublecheck for 'N' alone:
        ORG     0C000H          ;Above all SF code
VALIDN  JP      Z,587AH         ;Back to SF if no N
        LD      A,(38FDH)       ;Is any other key down?
        LD      B,A             ;Remember this...
        LD      A,(3802H)       ;Any besides N in this row?
        AND     10111111B
        OR      B
        JP      NZ,587AH        ;Back if so - N may be bad
        JP      5CB2H           ;Else really a good N.
        END     0BDF9H          ;Entry to my SF.

Good luck and good hunting! D for Drive!

Duplicating ACORN Copy-Protected Disks

The disks tested to date are ASTROBALL, TENPINS, and KING OF THE JUNGLE. The procedure is probably valid for other Acorn disks as well.

The protection scheme used is to have some hidden bytes at the very front end of Track 0. These will not show up in any of the sectors on the track (in fact the track has only the one boot sector). Upon booting, the code does a Track Read and then checks for the presence in memory of these special bytes.

There are two ways to duplicate the disk. One way is to create a special Track 0 that has these bytes at the beginning, followed by the boot sector. This can be done using Trakcess. A much easier and better alternative is to modify the code so that it no longer checks for these special bytes. Then they do not need to be present, and any disk duplicator can make copies successfully, without manual editing.

Presenting the simple zap first: use Trakcess or some other copier to duplicate the original disk onto a blank. Duplicate as many tracks as appear to have sectors. Note that the special bytes in the Track 0 format will not be reproduced. Now zap the copy disk on Track 0 (Sector TN=00, SN=00) as follows. Read the sector into memory. About 195 bytes into the sector, locate the three bytes

20 FA 7E

and change them to

3E 7E 00

That’s it. The copy should work and be easily duplicatable. What we have done is remove the check for the special byte 7E in the Track 0 leader.

The longer technique, that does not yield an easily reproducible copy, is given next for information. First duplicate all tracks except Track 0 using any copier. Now, using Trakcess’ (B)uild command, create a track with one sector: TN=00, SN=00, SL=01, IBM type. Build it in memory.

Now use the Edit command to modify the beginning of this track. First, starting at the fourth byte of the track, overwrite what’s there with:

00 00 00 00 00 00 FC FC 7E 7E

Go back to the first byte of the track, and insert ahead of it 48 bytes of FF. This gives you the new Track 0 format. (P)ut it off to Track 0 of the copy disk. Then transfer the TN=00 SN=00 sector data from Track 0 of the original disk to the copy disk.

If you have problems with either technique, it may just be that the special byte value has changed from 7E to something else. To check this, Take a track read of the original Track 0. Look for the 00…FC bytes as above, and see what value byte follows them. Use this instead of 7E, in both techniques.

Putting and Running RESCUE AT RIGEL under Disk BASIC

RESCUE AT RIGEL is from the same stable as TEMPLE OF APSHAI. Many copies of the cassette version were sold in Australia and although not as cumbersome to load as TEMPLE, it does have some incompatibilities with Disk BASIC. The following modifications are not enhancements they simply allow the game to be saved to disk and to be played under a 48K Disk BASIC environment.

There are two separate modules on the tape: The RESCUE module (i.e., the actual game in BASIC) and the DATA module (for the graphics).

Step 1  

Under Disk BASIC, CLOAD the RESCUE module. For the TRS-80 Model III, make sure you have the cassette baud rate set to L. (or POKE&H4211,0 from BASIC). Make the following changes:

Add line 6, ‘POKE &H40B1,&HC0 : POKE&H40B2,&HFA’

From line 10, delete the expression ‘:ON ERROR GOTO 11’

Delete line 11 entirely

In line 16 change ‘KA=31485’ to ‘KA=&HFAFD’

Delete line 1100 entirely

Change line 1610 to

1610 OPEN”I”,1,”RESCUE/DAT”:K=0:FORI=1TO5:A$=”” :INPUT#1,A$ :GOSUB1950

Delete line 1660 entirely

Change line 1960 to

1960 MC!=USR0(KA+K)

Step 2: Save the modified RESCUE module as “RESCUE/BAS:dn1”.

Step 3: Type in, save then run the following program. In response to ‘Filespec…?’, reply ‘RESCUE/DAT:dn1’

1 'Data transfer routine for RESCUE AT RIGEL
2 'by Leonard J. Yates, 25 October 1984
10 CLS : CLEAR 1000 : ON ERROR GOTO 160
100 PRINT"Data transfer routine for RESCUE AT RIGEL"
110 PRINT"Place cassette in player, cue and press 'PLAY'"
120 LINE INPUT"Filespec for disk file (incl. drive no.):";FS$
130 OPEN"O",1,FS$: FOR I=1 TO 5: PRINT@256,"Reading data #";I
140 INPUT#-1,A$: IF LEN(A$)<>249 PRINT@256,"Data read error"
150 PRINT@256,"Printing data #";I : PRINT#1,A$ : NEXT I
160 CLOSE 1: PRINT"Data transfer complete" : PRINT : PRINT

Step 4: On the disk,you should now have two files: RESCUE/BAS and RESCUE/DAT.To run the program, type RUN”RESCUE/BAS” under Disk BASIC. Unlike the cassette version, there is no need to set memory size and the game will load and run in a matter of seconds.

Copying Copy-Protected VISICALC and SCRIPSIT

To make multiple copies of protected VISICALC and SCRIPSIT programs on a Model III:

NOTE: There are 2 issues with this … 1 is that the CRC in the below data does not equal the CRC check. The program can be forced, and seems to work on Superscripsit and on Visicalc v1.50 but it will bork a Visicalc v1.60 disk. I do not know if that has to do with the below code being off, or some security added to Visicalc v1.6.

  1. Make 2 backup copies as recommended in owner’s manual.
  2. Insert one of the backup copies, without write protection, into drive 0 and press RESET.
  3. Enter BASIC and press ENTER for FILES and SIZE questions.
  4. Enter the following program exactly:
10  Z=0: FOR X=28672 TO 28808: READ A: POKE X,A: Z=Z+A: NEXT
70  DEFUSR0=&H7000: X=USR(0)
90  DATA 49,240,111,33,136,0,229,241,33,0,64,229,253,225
100 DATA 1,20,1,17,105,112,213,221,225,33,120,112,245,197
110 DATA 213,229,205,66,68,5,5,5,5,205,54,68,17,48,0,33
120 DATA 137,112,1,0,5,126,254,126,204,101,112,254,94,204
130 DATA 101,112,25,16,242,1,0,5,17,47,1,33,153,112,54,239
140 DATA 35,54,92,25,16,248,58,115,112,61,50,115,112,225
150 DATA 209,193,241,205,66,68,5,205,60,68,195,45,64,62
160 DATA 16,119,201,128,104,0,137,112,0,0,8,0,0,21,1,32,3
170 DATA 0,31,32,0,16,31,64,0,32,31,96,0,48,31,128,0,64,31

5. Type SAVE “SUPER” and press ENTER. Then RUN the program.

6. The program will take 5 seconds to run, then will return to TRSDOS. You can now copy or backup VISICALC or SCRIPSIT.

Copying Copy-Protected SUPER UTILITY PLUS to a CMD file

To make a CMD file of a copy-protected Super Utility Plus Disk:

  1. Start by booting SUPER UTILITY PLUS.
  2. Remove the disk and replace it with a SYSTEM disk with at least 29 free grans.
  3. Configure the utility to your system.
  4. Enter the memory utility by typing a 7.
  5. Enter the memory display by typing a 1.
  6. At the prompt enter EB00H for the address, H for hex entry mode and a M for modify, then place the cursor over EB01.
  7. Enter the following hex code
    F3 21 00 60 11 00 40 01 00 8B ED B0 31 4C 41 ED 56 C3 15 40
    F3 21 00 CB 11 00 EB 01 01 8B ED B8 76 C7 00 4B 34 4B 41 4A
  8. 8. Hit ENTER then BREAK.
  9. 9. Jump to memory by entering 8 and at the prompt for the address enter EB15H.
  10. 10. The system should boot to DOS.
  11. 11. Dump memory from 6000H to EB28H with an entry point of EB01H.
  12. 12. With NEWDOS/80 it would look like this.

Converting Superscripsit to LDOS

The TRS-80 Model III version of Superscripsit can now be patched to operate on the Model III version of LDOS. The latest version of Superscripsit (version 1.2.01) includes a Job Control Language (JCL) file called HARDDISK/JCL which contains all the patches to allow Superscripsit to operate under the LDOS system.

The procedure to transfer Superscripsit to LDOS and apply the patches is as follows:

1) Make up a LDOS system disk which includes SYS files 0,1,2,3,4,6,7,8,10,11 and 12. Also include the FORMAT/CMD, PATCH/CMD, CONV/CMD and BACKUP/CMD utilities. Use the following syntax: “BACKUP :0 :1 (Q=Y)”

2) Place this LDOS system disk in drive:0 and a BACKUP COPY of TRSDOS 1.3 Superscripsit version 1.2.01 in drive:1.

3) Under LDOS perform a CONV :1 :0 transferring only those files pertaining to Superscripsit. Transfer SCRIPSIT/CMD, S/CTL, SYSTEM/CTL, HELP/CTL, ERRORS/CTL, all SCRxx/CTL files and the required printer driver files (ie. LP8/CTL, DW2/CTL etc). Do not transfer the TRSDOS utilities MEMTEST/CMD, HERTZ50/CMD, BASIC/CMD, CDNVERT/CMD, XFERSYS/CMD or LPC/CMD.

4) Remove the TRSDOS Superscripsit disk from drive:1.

5) Apply the patches to the Superscripsit files by typing “DO=HARDDISK/JCL”. The screen will display the file patches as they are applied. When the patches have been completed the screen should display the message:

"Patch(s) successfully installed"
"Job done."

After the file patches have been applied you may purge SYS 11 and the HARDDISK/JCL files from the LDOS Superscripsit disk if you require more space on the disk.

Backups of the new LDOS Superscripsit disk should be made immediately the conversion has been completed.

Converting Model I to Model III

Like many Model III owners who also own a Model I, I have been impressed with the capabilities of the Model III and dismayed at the lack of software currently available for the Model III. Most basic programs for the Model I which don’t use peeks or pokes to ‘undocumented’ memory locations will work pretty well on the Model III, but many machine language programs, especially those which use undocumented DOS calls or direct I/O to Model I memory mapped locations will not function well, if at all. THIS Articles will deal with conversion of Model I software to the Model III. Most of the information will relate to disk versions of the Model I and Model III, although some of the general guidelines will also be applicable to cassette as well.

First, let’s look at some important address changes:

  • 4049H – in the Model I, this is where the top of available memory is stored (TOP$). Disk BASIC and many other programs like SCRIPSIT, EDTASM (Apparat’s) and MNET-80’S lower case driver, look at this address in order to set up memory protection or to determine the amount of available buffer space. in the Model III. This has been changed to 4411H and it is used in exactly the same way.
  • 4467H – This is the address of an ‘undocumented’ Model I dos call which was used to display a message pointed to by the HL register. it doesn’t exist in the Model III TRSDOS, but is now available in the Model III rom at 021BH. One important Model I utility which uses 4467H is Apparat’s LMOFFSET/CMD. It will work just fine by changing all of the 4467H calls to 021BH.
  • 37E8H – This is the Model I’S memory-mapped parallel printer address. SCRIPSIT, RSM-2D and many other programs use this to output directly to the parallel printer. in the Model III, 37E8H can be ‘read’ or peeked to determine printer status, but not written to. In the Model III the parallel printer port is Z-80 port 0F8H.
  • 37ECH THRU 37EFH – In the Model I, these four addresses along with 37E0H-37E1H are memory-mapped to access the disk controller (see Bill Barden’s disk interfacing guide for details). THese addresses don’t exist in the Model III at all. Instead, ports 0F0H thru 0F3H are used, with port 0F4H as the drive select latch. Even knowing this, conversion will not be a simple matter, owing to the double density used in the Model III which makes timing very critical indeed.

So far, I have found that the most useful utility in making conversions from the Model I to the Model III is Small System Software’s RSM-2D. It allows the user to search for particular addresses in a machine language program and its disassembler is extremely valuable in checking how things work. Most of RSM-2D’s features will work as is on the Model III and a simple patch (given below) will fix it to output to the parallel printer. I have not yet been able to fix it so that the disk sector read and write functions will work, due to the changes noted in 4. above.

A patch to enable the printing function for RSM-2D. This applies to the 32k version and the 16K and 48K version can be patched by subtracting or adding 4000H to the addresses given here.

Use the Model III’s PATCH command to make the following four patches:

PATCH RSM32/CMD (ADD=0AC13,FIND=00000000,CHG=7E20F9C9)

That’s it and now RSM-2D’s printing function will work as advertised.

This article will describe the patches for a number of the Model I useful utility programs to allow their use on the Model III. These are all disk-based and the assumption is that they have been transferred over to a disk-based Model III with at least 32K of RAM, Using the Model III’s convert utility. the TRSDOS currently in use on the Model III is version 1.1 (more on that later). Since all of the changes are in the form of patch commands to be executed from the dos level, an easy way would be to combine the ones you want into a ‘do’ file using the ‘build’ command and execute them all at once.







4. SCRIPSIT/LC (RADIO SHACK’s standard disk version)


Comments: The patches given here allow SCRIPSIT to output to the parallel printer. I don’t have a serial printer, but since both Model I and Model III use the same RS-232 port assignments, serial printing should be ok. Be sure to use setcom to set up the parameters for your particular printer before going to scripsit. You’ll have to experiment to find out whether the ‘WAIT’ or ‘NOWAIT’ option should be used. these patches work for TRSDOS 1.1. I Understand you may have trouble with text file loads and saves under version 1.2. Radio Shack is fixing this, but for now, keep your patched SCRIPSIT on a 1.1 Diskette. I’ll try to update this whenever i get a copy of 1.2.



Comments: Obviously, this patch is for the 48K version. For the 32K version, the address should probably be B3C2. This patch is an absolute must to keep basic from clobbering the MNEXEC program.


For the Model I has a serial driver which reads the DIP switches and programs the RS-232-C card to drive a serial printer. To fix this for Model III use, the block of code from 661AH to 662FH must be zeroed. The following five patches will accomplish this:

PATCH SCRIPSIT/LC (ADD=6626,FIND=210F6B0600,CHG=0000000000)

Before executing SCRIPSIT, use setcom to set the interface to the parameters required by your particular serial printer. then when printing, use SCRIPSIT’s ‘P,S’ command to output the text to the printer. Incidentally, if you don’t want to use these patches, the same result can be obtained by using the TRSDOS ROUTE command:


Then, all output which normally would go to the parallel printer will go to the serial output. In this case, you would use scripsit’s normal ‘P’ command for printing.

Concatenating TABLE/CIM into DISASM/CMD

Before using DISASM, it will be convenient to concatenate the TABLE/CIM to it so the entire file can be loaded with one command rather than two. TABLE/CIM is entirely relocatable. This is accomplished as follows::

  1. From DOS LOAD DISASM/CMD (Or use whatever filespec you gave it). I will assume DISASM/CMD was re-assembled to load to a new high memory address of E65E hex.
  3. From DOS, call up RSM32. The 32K version is needed to avoid clobbering TABLE/CIM residing at 7292 hex and DISASM/CMD residing at E65E hex.
  4. With RSM32, use the M(ove command:
M 7292 765D E292

This will relocate TABLE/CIM from its 7292-765D memory location to a new location of E292-E65D hex.

5. Verify with RSM32 that memory bytes E65E, E65F, and E660 are zeros. If they are not, DISASM will do strange things. If everything has been done properly up to this point, these should already be zero and no changes should be required.

6. From DOS, re-write DISASM/CMD to disk, to include the symbol table:


7. DISASM/CMD is now ready for use in high memory. Play with it and get used to the commands. AND PRACTICE ON BACKUPS!!!!!.

Modifying ORCH-85 and PIANO-85 to Take Command File Inputs – By R. Baker

This article relates only to the Model I versions of either of these wonderful music programs. I have no information on the Model 3/4 versions, although the patches should be just as easy.

If you have a large number of ORCH or PIANO music files, you might like a way to more completely automate the playing of them. The Get command only plays a few pieces before you have to attend to it again. I wanted to be able to call for any number of songs, preferably with their titles stored in an text file on disk.

Since most TRS-80 DOSs now have some kind of “DO” capability, which will feed simulated keystrokes from a text file into an application program, it seemed most straightforward to make use of this. Unfortunately, the ORCH and PIANO programs do not take their keyboard input via the standard system device drivers. Instead, they call their own keyboard driver, and they won’t listen to a DO file input. To correct this the music programs must be made to call the DOS keyboard driver instead of their own. This technique works cleanly insofar as it has to, for reading and playing music files, but does not allow editing or composing etc. So don’t try to use the modified ORCH or PIANO programs for this. Use them only for playing music files under the control of the DOS.

The keyboard driver call is easily altered, as described below, by changing only two bytes in either of the programs (at 5EE1 for ORCH-85 or at 6268 for PIANO-85). This change alone will let you use text file inputs as commands. Thus you could have a DO file such as this (where ORCH4GET/CMD is the modified ORCH-85/CMD program):

G ROMEO etc...

and it would play all of the indicated songs. I was pretty happy with this, but also wanted to be able to call for some silences between the selections, to keep disk drive noises from interfering with the music. The best solution would have been to locate the code that reads and plays a file under the Get command, and patch in time delays there. I was unable to do this, so I considered just calling for some dummy or redundant (S)core operations for each song in my command file. This works fine but leads to very long command files, since you can only put one command on a line.

To tighten these up, I needed to make the ORCH or PIANO program recognize a substitute character for the Carriage Return (byte 0D). I enlarged upon the keyboard patch I already had, adding a filter action that would watch for “;” (byte 3B) and change it to 0D. This requires nine additional bytes of code, and the safest place I could put them is over the initial logo text. The remaining text can be modified to convey the same information still, if you like. With this filter patch in place, a command file such as this can be used:


In this example, after each piece is Read it is (S)cored twice to provide for a delay while the disk drives stop, and after it has (P)layed it is again (S)cored a couple of times to provide another delay before the disk drives restart.


The patches for both programs are given below. You will need the address of the keyboard driver for your DOS. To find it, boot the DOS normally and examine locations 4016H and 4017H. You can do this using DEBUG or by just PEEKing them from Disk Basic. The bytes are in the normal low-high sequence; eg. for DOSPLUS the driver is at 4DC0, and 4016H holds C0 and 4017H holds 4D. In the patches below, LL refers to the byte found in 4016H, and HH refers to that found in 4017H.

To actually make any of these changes, you should either use the “Patch” utility supplied with your DOS, or use a high-memory machine language monitor, or the DOS ‘LOAD’ and ‘DUMP’ commands, in conjunction with DEBUG. The details of doing this vary greatly with each utility, and are beyond the scope of this discussion. Also note that for DOSPLUS, at least, the DO file operations proceed from high memory, which does not appear to be affected by the ORCH or PIANO music programs. This may not be the case with DO or JCL operations under other DOSs.


These are the modifications for ORCH-85 (after configuring and saving as four or five voice, fast or slow speed). The program loads from 5900 to 6CAF, with entry at 6B27.

To make it take its command inputs from a DO file, modify the keyboard driver call at 5EE1: change CD 1D 62 to CD LL HH.

To additionally make ORCH-85 take “;” for a carriage return, a patch is put in the logo text at 5D70: change ” BOKELMAN” to CD LL HH FE 3B C0 3E 0D C9. Then at 5EE1 change the call to: CD 70 5D. Finally, change the number of bytes written for the logo (reduce by nine) at the two block moves that may be used: after 6300 and after 6C91, change the 01 2C to 01 23.


These are the modifications for PIANO-85 (after configuring and saving as fast or slow speed). The program loads from 5A00 to 6FA7, with entry at 6E86.

To make it take its command inputs from a DO file, modify the keyboard driver call at 6268: change CD A2 65 to CD LL HH.

To additionally make PIANO-85 take “;” for a carriage return, a patch is put in the logo text at 60F7: change ” BOKELMAN” to CD LL HH FE 3B C0 3E 0D C9. Then at 6268 change the call to: CD F7 60. Finally, change the number of bytes written for the logo (reduce by nine) at the block move: after 668B change the 01 28 to 01 1F.


The above changes have been made to create: ORCH4GET/CMD, ORCH5GET/CMD, AND PIANOGET/CMD. All assume a 3.54 MHz clock, and ORCH5GET/CMD is configured for five voices. The others are for four voices.