Classic Computer Magazine Archive COMPUTE! ISSUE 25 / JUNE 1982 / PAGE 88

Bits And Pieces

Elizabeth Deal
Malvern, PA

Ms. Deal has been working with Commodore machines for several years. Many of the tidbits below represent questions people have asked her. You're bound to learn something you didn't know.

  • It's sometimes hard to tell where the screen boundaries are. Annoying, if the cursor jumps the line or the screen scrolls when you don't want it to. Cheap solution: fill screen with the full white square character and put borders on the picture using 1/8" or 1/16" vinyl tape sold in stationary or art supply stores. Do it on the right and bottom edges of the screen. Watch for parallax!
  • Don't use SYS4 within a running BASIC program (to get to the monitor). Location 4 is busy at that time and you'll crash. Use SYS 1024 or call the Monitor instead (64785 on Upgrade).
  • Most, if not all, tape load errors are preventable. Keep tapes clean. Clean the cassette unit immediately after getting the first VERIFY ERROR or a bad ST value. Use Radio Shack freon head cleaner or grain alcohol and Q tip. No rubbing alcohol. Don't permit the Q-tip to get tangled up in moving parts inside.
  • If you can't find any pencils in the house turn to your PET. They are all under there. A real "world computer" would have legs either too small for pencils to roll under or big enough for a person's hand, if you want my opinion.
  • Recent Commodore printers (4022) have a trace of descenders and work quietly, but slower, than the old ones. It is easier to flip character sets than previously. They don't get stuck any more. Surprise – the values are opposite from those in the PET itself. Quote from the manual: to set text mode (upper and lower case) 10 poke59468,12 : open7,4,7 : print#7 : close7, and to set graphics mode (graphics and upper case) 10 poke59468,14: open8,4,8 : print#8 : close8. Note that two secondary addresses are used, 7 and 8.
  • Both Osborne PET/CBM GUIDES, the red and white books, incorrectly describe several aspects of array storage on the PET. The general logic is all right, but many details have been mangled. BASIC 4 users should be aware of the fact that their character strings occupy two more bytes of storage per string than previous BASICs. All users should note that the Osborne books, in text and/or some illustrations, reverse the low-high order of addresses, and that the description of storage of character strings is in error.
  • Update on Partitions: to set up partitions in the PET, it is always necessary to reset the "beginning of BASIC" pointer and to put zeros in the first three bytes of a partition (NEW). Assuming two partitions, the way to get going is via the monitor. For instance, to set up a partition at $6000 (24576 decimal), type SYS4 and:
    .M  0028 0028
    .:  0028 01 60 03 60 03 60 03 60
    .M  6000 6000
    .:  6000 00 00 00 xx xx xx xx xx
    

    To reenter a previously established partition, it's a good idea to check the presence of that zero in the first position, otherwise BASIC can't work. Do the check while in the Monitor changing your pointers. Otherwise, if you exit with the zero missing, BASIC will not function and you probably won't be able to get back into the monitor without a reset (power turned off, then back on).

Existing program files can be loaded into a partition using "Toolkit" 's APPEND command (tape only). Existing programs in ASCII format can be so loaded via the XEC command of "Power" (tape and disk).

Saving programs from a partition has to be done by the Monitor's .S command in case of the Toolkit. In Power, saving a program as an ASCII file (relocateable, by definition) does the job automatically.

For many applications a method described in COMPUTE!, November, 1981, #18, "Inverse Partitioning" should simplify the task.

  • Supermon (SM) [a machine language monitor extension program which appeared in COMPUTE!, December, 1981, #19] is handy in resetting the top of BASIC pointer in case of continuing shrinkage of your PET's memory while you POKE and rePOKE some undebugged machine code program. Assume that SM is the SYS address given by the loader during original setup. Doing SYS SM at any time will set the pointers to the original condition. By the same token, if you have some code below (lower address) Supermon, don't use its SYS command, use PET's SYS4. PET recognizes Supermon's commands by checking a pointer at $03FA-03FB. If you crash and reset the PET, this pointer has to be fixed by SYS SM.
  • Wedge relocates itself to the top of the PET, next to the screen. The code uses ROM routines and contains no location-sensitive addresses. It can be block-moved anywhere in memory with the Supermon's Transfer command, so long as you notify the CHRGET routine of the move: change $0071-0072 (low byte-high byte of Wedge's address) to point to the new location.

While Wedge is loading itself it uses some screen area for working storage (evidenced by a quick flash on the screen). This can be deadly if you plan to put Wedge below some existing code, as the code will turn to mush. There are several ways around it: use the old DOS-Support program which doesn't jump its boundaries, or load the Wedge first to a lower location, followed by the desired program, or load the Wedge next to the screen and move it.

  • Wedge is hard-coded to be available only with disk as device 8. Untested suggestion: it can be used with a differently numbered disk device if you poke the device number in two locations in the Wedge code. Use Supermon's Hunt command to find two 8's. They are in A9 08 (LDA #$08) code sequence. No other 8's exist in the code.
  • Wedge's handy curiosity: you can quickly obtain the names of the floppies and bytes free from both drives by saying such things as >$10, or >$01, or >$55 or $>XX or whatever.
  • While developing a long BASIC program (or when putting it away for some time) it's a good idea to document it. Otherwise, later it won't seem to resemble any of your thoughts. The meanest thing is the structure of the program – "what does it do and when?" You can't modify a program without knowing that you won't stick a line in a place that breaks up a subroutine or without knowing where it might even be executed.

A cross-reference program is a good thing to use, for instance Cursor (tape-magazine) published Jim Butterfield's fast, machine code Cross-ref routine for disk users (only, I think). It lists variables (in alphabetical order) and lines (in numeric order) indicating places where those variables or numbers are used.

Here is a halfway approach I sometimes use. It's good for tape people. And it can, of course, be used with Cross-reference for a complete picture.

Devoting some space at the end of a program to housekeeping, I can list all subroutine entry points and all GOTO references, like this:

2000  <S> : ON S GOSUB 450, 500, 510, 320, 620, 800
2001  <G> : ON G GOTO 60, 100, 150, 250, 455

The syntax in <S> and <G> guarantees against those lines ever executing, even if I were to lose control of the program, since a SYNTAX ERROR would result. ON X GO X, however, is seen by me, Cross-reference, Toolkit and Power as a perfectly valid list of addresses. They get renumbered correctly and, if I keep them clean and up to date, I stand a better chance of knowing how the program is built. It's primitive, but it works.