CP/M

home *** CD-ROM | disk | FTP | other *** search

/ CP/M / CPM_CDROM.iso / lambda / soundpot / p / seebios.lbr / SEEBIOS1.DZC / SEEBIOS1.DOC

Wrap

Text File | 1993-10-25 | 13.5 KB | 260 lines

SEEBIOS.COM ----------- by Raymond Rosenkranz, (C) 1986 3-1325 Franklin Terrace, Victoria, B.C. V8S 1C8, Canada Telephone: 604-382-7590 In the present file I explain (1.) the background, (2.) the purpose, and (3.) the functioning of the program I wrote and called SEEBIOS. A final section (4.) contains further remarks. 1. BACKGROUND ------------- You have probably noticed how slow are the screen-writing routines in Kaypro's CBIOS (CBIOS = customized [by Kaypro Corp.] BIOS). It is these routines that do the work for CP/M's functions no. 2 and no. 9. The non-programmer sees their slowness when he types past the right margin in WordStar and has to wait up to 3 (!) seconds for the screen to be rewritten. Exasperated by my CBIOS's sluggishness, I decided in my CP/M programming to bypass functions no. 2 (in Turbo Pascal: Write[ln]) and function no. 9 altogether when writing to the screen, and to address the Kaypro's video chip directly, instead. This decision was no sooner made than I ran into the first of many unexpected difficulties: where was one to get information regarding software control of the Kaypro's video chip? Luckily, I happened to find out about Micro Cornucopia's "Kaypro Schematic". Its descriptions and programming examples were sufficient to get me going. I soon discovered the amazing gain in speed achieved by taking control of the video chip. Micro C's instructions, however, turned out to be incomplete as well as partially outdated and incorrect (at least for post-1984 Kaypros). To make a long story short, I opened my Kaypro, noted the manufacturing data on my video chip, went to an electronics store, and copied the pages from the Rockwell microchip catalogue pertaining to the chip (R6545-1AP) in my machine. Next, I purchased the "CRT Controller Handbook", by Gerry Kane (Berkely, California: Osborne/McGraw-Hill, 1980). Both the Rockwell catalogue and Gerry Kane's book refer to programming possibilities not mentioned in the Micro C schematic. These possibilities are essential to genuine high-speed screen-writing, yet they are not easy to understand. Gerry Kane's book proved particularly helpful here: it put the flesh of explanation on the bare bones of Rockwell's technical specs. With these three helpers (the Micro C schematic, the Rockwell specs, and the "CRT Controller Handbook") I succeeded, at last, in formulating high-speed screen-writing loops that made my Kaypro's CBIOS routines look like a Model-T next to a Porsche. The very success of these loops, however, disclosed a technical defect in Kaypros that had, until then, been concealed behind their slowness: at random intervals all characters (or attributes) written to the screen from a certain point on were shifted either one character to the left or one to the right. After countless experiments in reformulating the screen-writing loops - none of them able to prevent these write errors - I concluded that the write errors were due to a timing problem in the Kaypro's circuits. Since I wanted to continue to use high-speed screen-writing in my programming but had no desire to meddle with the hardware I decided to correct these random errors through software, i.e., through test-and-correct loops in the screen-writing routine itself. (If while using SEEBIOS you notice a screen line flicker then what you saw was a write error followed by its correction.) The next difficulty to emerge was due to the way the Kaypro's CBIOS screen routines scroll the screen up one line when a Carriage Return (or Linefeed) is entered in row 24, or when a character is typed in column 80 of row 24. To make another long story short, it became necessary to locate the bytes in RAM where Kaypro's CBIOS stores the current offset of the chip's screen memory addresses. (If you don't know what "the current offset of the chip's screen memory addresses" is, don't despair: I'll explain.) This necessity was the mother of SEEBIOS's invention. 2. PURPOSE ---------- The primary purpose of SEEBIOS is reflected in its name: to observe the BIOS in action as it updates its scratch tables in RAM (i.e., the bytes that contain information it collects and utilizes during its operation) - particularly those associated with its screen routines. Prior to writing SEEBIOS I had located some of these bytes through trial and error. The correlations I observed between the variations in their values and CP/M's screen operations provided the hypotheses underlying the search algorithms employed in SEEBIOS. DDT, unfortunately, does not allow an inspection of RAM contents during CBIOS (or BDOS) operations: it only provides snapshots after the completion of an operation. This static display makes it extremely difficult to see the dynamic correlations between such operations and the contents of certain bytes in RAM. SEEBIOS, on the other hand, by virtue of its high-speed screen-writing procedures, allows one to observe these correlations. CBIOS values that can be observed 'in action' include: -cursor row -cursor column -cursor screen memory address -screen memory address offset -input buffer -input buffer pointers -CONFIG's definitions of the vector key pad and of the numeric key pad SEEBIOS is not limited to serving the primary purpose outlined above. Unlike DDT, SEEBIOS does not alter the contents of any area in RAM except the portion of TPA (Transient Program Area) occupied by SEEBIOS itself. In particular, it leaves the vectors in CP/M's zero page (addresses 0 - FF hex) and the CCP intact. This means that you can inspect not only CP/M's proper values in these areas but also auxiliary programs - such as key definition programs, desktop accessories, and the like - residing in high memory just below the CCP (an area that might otherwise be overwritten by DDT). 3. FUNCTIONING -------------- I wrote SEEBIOS in 8080 assembly code. Why not Z80 code? Because I don't have a Z80 debugger but do have DDT. And because writing assembly code without a debugger is something I leave to geniuses and fools. Even so, SEEBIOS is fairly bulky (8k) considering how little it actually does. The reasons for this bulk are: (a) SEEBIOS contains all help and prompt information so that it is always quickly available; (b) the screen-writing procedure is fairly intricate, partly because of its test-and-correct loop; (c) the algorithms seeking CBIOS's scratch tables are also quite involved. These algorithms, as remarked above, make certain hypotheses concerning CP/M's methods of counting, storing, offsetting, etc. For example, the algorithm to locate the bytes storing the row and column values assumes (a) that CP/M counts rows and columns from 0 to 24 (decimal) and from 0 to 79 instead of from 1 to 25 and from 1 to 80, and (b) that the row value is stored at an address immediately adjacent to and lower than the address of the column value (i.e., to the 'left' of the column value in a RAM display such as DDT's or SEEBIOS's). Given these and some other hypotheses, SEEBIOS searches for the bytes holding the row and column values, the cursor address, and the screen address offset in three stages: first, it locates the row and column values by running the cursor diagonally from the 0/0 (home) position and by checking which RAM values in the CBIOS area vary accordingly. Second, it prints spaces in row 24, column 80 and checks which RAM values receive an increment of 80 at each step. (80 is the offset added to the screen memory addresses at a 1-line scroll.) Third, it uses this knowledge of the current offset value to determine the cursor address by running the cursor diagonally again and checking which RAM values in the CBIOS area vary accordingly. To locate the cursor address one must know - as can be learned both from the Rockwell catalogue and from Gerry Kane's book together with the information about Kaypro's video chip initialization values provided by "Micro C"'s Kaypro schematic - that the Kaypro uses binary (or consecutive) screen memory addressing. This means that it assigns screen locations not to row and column coordinates but to a continuing count of 2000 screen locations from 0 to 1999. Thus, the uppermost and leftmost screen location has number 0, the one immediately below it (80 bytes 'away' from it, so to say) has number 80, etc.: ------------------------------- . . . . . . ---------- l l l l l l l 0 l 1 l 2 l l 79 l l l l l l l l-------- l---------l---------l l---------l l l l l l l l 80 l 81 l 82 l l 159 l l l l l l l l---------l---------l---------l l---------l . . . and so on. Since there are 2000 screen locations (in ASCII text mode, but more in graphics mode) the last screen location bears number 1999. (The count began with 0 and not with 1). However, screen memory locations actually range from 0 to 2047 (decimal) because 10 bits are used to address the chip. (Attribute addresses are another story altogether!) When Kaypo's CBIOS scrolls the screen up (as when entering a carriage return in row 24) it does not shift any memory contents - e.g., put the contents of location 80 into location 0 - but, rather, changes the initial display address: it begins the screen display not with (the contents of) location 0 but with (the contents of) location 80! The optical illusion created by this method is - a scroll. In this way, each 1-line scroll adds an offset of 80 to screen memory. This means that screen display begins with (the contents of) a location 80 bytes further 'down' from where it last began. At the same time, with only 10 bits available to address screen locations, the count gets reset to 0 at the transition from 2047 to 2048. This means that the maximum screen address - 2047 decimal or 7FF hex - may be located anywhere on the screen, rather than at the lower edge of the screen, as a result of repeated scrolls having been performed. Using SEEBIOS you can observe these peculiarities of the screen location addresses as they reflect both cursor position and scrolls. 4. FURTHER REMARKS ------------------ SEEBIOS directly addresses various ports on the Kaypro. It is conceivable that the ports on your machine are not the same as those on mine (I have a 1985 Kaypro 1). In that case SEEBIOS will not perform properly for you. SEEBIOS is capable of printing a hard copy of the currently displayed RAM contents - both the hex values and the corresponding graphic (ASCII and non- ASCII) characters displayed to the right of the hex values. The printing of Control and non-ASCII characters is accomplished by translation into printable ASCII characters: Control characters have their bit 6 set (i.e., 64 decimal is added to their binary value) and are printed in italics, non-ASCII characters (128 decimal to 255 decimal) have their bit 7 reset (i.e., set to zero) and are printed underlined. The non-printable ASCII character 127 (decimal) is replaced by a reverse slash ("\"). Since the value 255 (decimal), after having had its bit 7 reset, equals 127 it is shown as "\" underlined. This translation also allows you to recognize Control and non-ASCII characters at once. As supplied, the program supports an Epson-compatible printer. You may change the printer commands (italics, underlining, substitution) or enter escape sequences appropriate to your printer by patching (e.g. in DDT) different values in the following locations of SEEBIOS: (Note: in each sequence of bytes the first byte must specify the number of following bytes to be sent to the printer!) 01C2 through 01CB: 2nd byte specifies character to substitute for 7F hex; the remaining 8 bytes were left so that one could preface the substitution character with a printer command to switch to a different international character set, for instance, and follow the substitution character with a printer command to switch back to USA characters. I omitted these commands because they slow down the printing considerably on my "Panasonic" printer. 01D5 through 01DD: 9 bytes available to set underlining. 01DE through 01E6: 9 bytes available to set italic mode. 01E7 through 01EF: 9 bytes available to release both underlining and italic. SEEBIOS contains a complete, self-explanatory Help screen: call up SEEBIOS and press LINEFEED (CTRL-J) when prompted for input. -- Good luck! -- P.S.: I would be interested in any comments or suggestions you might have. P.P.S.: I plan in a further 'letter' to describe the programming necessary to achieve high-speed screen-writing by direct chip address rather than through Kaypro's sluggish CBIOS routines.