Prices Subject To Change

Horrors! A deranged madman has locked your unconscious form inside of a deserted creep house at a crazy carnival. You awake to some sobering facts: a bomb is set to explode, and only 30 real-time minutes stand between you and eternity. Somewhere, somehow you must locate and defuse the explosive — but we'd be less than honest if we thought you had more than a ghost of a chance! Brrrr — a real cliffhanger!

Something's gone very, very wrong at the Toxic Dumpsite where the treatment and burial of deadly contaminants take place. The entire plant will explode like the Fourth of July in less than 30 minutes — unless you can avoid the many traps and protection systems and shut the plant down in time. Of course, time is the one luxury you haven't got...!

Avoiding the printer-not-ready problem

Model I only

We all know of the consequences of attempting to send data from the TRS-80 to a nonexistent or temporarily out of service printer. You end up hanging the system and losing your program and data. The culprit in this situation is the routine in ROM that handles printer output. This ROM routine only checks to see if the printer is ready for data arid if it is not, it sits patiently waiting. If the printer doesn't exist, or mysteriously went out to lunch, then the system hangs up and it is "bye bye" to in-memory data.

Obviously, what we need is some type of routine that can check the printer before trying to send data to it. The routine would also make sure that all is right, and if not, let us know so that we can take better action than just pressing RESET and retyping all of our data.

The Model I/III is a memory mapped computer, as are many on the market today. Memory mapping only means that rather than sending data to a port (a la serial interface), data for a particular device is sent through a memory location in RAM. For the video, these are locations 15360 to 16383, and for the parallel line printer, the location is 14312 decimal. That's 37E8H for you hex nuts out there.

Like PEEKing and POKEing into video memory, we can PEEK at location 14312 and see what the status of our line printer is. We can do this because when you aren't sending data to the printer to be printed, the printer is sending data to the computer to tell it whether or not it is ready to handle data.

Now that we know where to look to check the condition of our printer, the question remains, how do we use this information to prevent printer hangups? First, we need to know just exactly what a particular printer's READY status value is. With so many printers on the market, it is a fair guess that there is more than one READY signal being sent.

Listing 1 is a complete and formal test procedure for determining several possible status values for various printer conditions. Listing 1 is self prompting and will allow you to determine values for the following conditions: printer ready, printer in off-line mode, printer power switch off, printer power line unplugged, printer initiating, printer busy/buffer full, printer

Jerry Latham, Midwest City, OK

initiating without paper, printer out of paper and no printer attached.

Depending on the sophistication of the printer, there are several other conditions that could be tested. These might be conditions like: no ribbon installed, paper hanging, print head overheat, etc.

So that we can carry the same thoughts and values from program to program, see Table 1 for a list of variable names and their uses that I derived for the Epson MX-80 printer. If you want to hurry and run the tests to find out all of your printer's status values by using Listing 1, please do so. A word of caution—test for "no printer attached". It is necessary to disconnect the cable from the printer to the computer expansion interface. This should be done with the power OFF to prevent possible damage to the printer, the computer or both. The program in Listing 1 waits until the end to do that test.

If you do not have a TRS-80 Model I, it will be necessary to do a little research and find where the printer is memory mapped. In all listings, the variable PP% is used to hold this value and it is set up in line 10 of each program. Change this value as required for your particular computer. Once this change is made, you may proceed with the tests.

Another possible area of conflict with other systems is in line 690 of Listing 1. Here, we get a string 255 characters long. The purpose of the section in Listing 1, lines 640-760, is to fill the printer's buffer and force it to print and send busy signals to the computer. I was using an MX-80 for these tests, and its buffer is 80 characters long. Sending 510 characters in a row was more than enough to do the job.

Once you have a list of the status codes your particular printer sends to your computer, you can start planning how to use them in your programs. Listing 2 shows how to do your printer checks and how to set up a subroutine that will diagnose your printer's status and control further processing based on that diagnosis. It is a fully commented version.

The important thing to notice in this example program is that checks on the printer are done before trying to send any data to it. If this is not done, then you risk the possibility of system lockup.

Listing 2 was designed using the Epson MX-80 values for printer status checks. Substitute the values you got with Listing 1 for the constants in line 10. Of course, don't forget to substitute your system's printer memory mapped location for the constant PP% in line 10. No other changes should be necessary.

Since Listing 2 is so well REMarked, I won't duplicate the effort with a line-by-line account of the program's operation. I will, however, make note of a couple of things that are not readily apparent in the program. First, no explicit check is done to see if the printer is just initiating (ST%). Instead, a check is done in line 120 to see if it is initiating without paper. If the printer is found to not be ready (and yet no specific error is found), then line 140 sends the program back for another loop. This will cause a wait-until-ready condition while the printer is powering up normally. Line 100 informs us that the printer is off or unplugged. It doesn't mention the fact that you may have a blown fuse. This could possibly cause this status value to be sent to the computer also.

One suggestion I offer if you elect to use this routine is to locate the subroutine (lines 80-200) close to the front of your program to speed execution time. Use a GOTO statement to skip the routine when first starting the program run. Another suggestion is to put a check for PRINTER READY as one of the first executed statements in your program so you can catch any errors before you start typing in data.

0 0

Post a comment