International Personal Robotics Conference

If you are among the many experimenting with little personal robots, such as Heathkit's HERO, you may be interested in attending the above named conference in Albuquerque next April 13-15.  They are expecting around 4000 to show up from all over the world.  You can meet such well known robotics experts as Joseph Engleberger, Nels Winless and others.  It's a fair bet you'll find Jack Lewis of Micromation there.  For more info, call Betty Bevers of IRPC at (303) 278-0662, or write to them at 1547 South Owens St. #46, Lakewood, Colorado 80226.


DOS 3.3 Checksummer Debate Update..........Bob Sander-Cederlof

A letter from Bill Basham (Diversi-DOS author) defending the practice of omitting the automatic VERIFY after SAVE to gain speed, was published in the September 1983 Softalk (page 37, 38).  At the top of page 38 Bill claimed that the checksumming method used by DOS was of no value at all, because the checksum only depended on the last two bytes.  In other words, Bill claims that errors in the first 340 bytes of a sector will not be caught.

Diversi-DOS is a fine product, and many thousands are enjoying its advantages.  Nevertheless, Bill is wrong about the checksum.  It does indeed catch errors throughout a sector.  For a complete explanation, see the February 1984 Softalk.  David Wagner clearly explains how the checksummer works, and refutes Bill's claim.  See his letter on page 40.

You can look at the code, too.  We printed a full commented source listing of this code in the June 1981 issue of AAL.


Peeking at the CATALOG.....................Bob Sander-Cederlof

Have you ever wanted just a quick peek at the catalog entry for a file?  Maybe you want to know where the track/sector list is?  Or maybe you want to see if there are any control characters in the name?  Or if the number of sectors is more than 255?  You need to peek, because CATALOG won't tell you these details.

After all these years, I found out a simple way to do it.  That is, assuming you can OPEN, SAVE, LOCK, or otherwise somehow make DOS go looking for the file.

After DOS has found the file, it leaves the directory sector containing the filename in the buffer at $B4BB-B5BA.  DOS also leaves an index to the very byte at which the information on your file is found.  The value in $B39C, if added to the address $B4C6, gives you the address of the start of the entry.  $22 bytes later it ends.

A minute ago I saved the contents of this and a few other short articles on a file named V4N5 SHORT SUBJECTS.  Then I left my word processor, typed CALL -151 to get into the monitor, and...  Well, here, look for yourself:

       ]CALL-151
       *B39C
       B39C- D2        (offset from B4C6)
       *C6+D2
       =98             (first byte of entry)
       *98+22
       =BA             (last byte of entry)
       *B598.B5BA
       B598- 0C 0E 00 D6 B4 CE B5 A0
       B5A0- D3 C8 CF D2 D4 A0 D3 D5
       B5A8- C2 CA C5 C3 D4 C3 A0 A0
       B5B0- A0 A0 A0 A0 A0 A0 A0 A0
       B5B8- A0 07 00

The first byte at B598 is the track, and the second is the sector, where the track/sector list for this file is stored.  The third byte is the file type (00 means an unlocked text file).  The last two bytes are the file size.  All the bytes in between are the file name.

If you are interested in the entry for a file you cannot reach directly, perhaps because there are hidden characters in the name, just LOCK, UNLOCK, or whatever a file above or below it in the catalog.  Then peek at B39C and B4BB...B5BA to find the entry you are really interested in.

Bill and I found this technique extremely useful on the most recent consulting job we handled.

We also took advantage of the fact that the track/sector list of a file read or written on can be found at the beginning of the file buffer.  If there are three buffers (MAXFILES=3), and if the file in question was the only one being accessed at the time, the T/S list will be found at $9600...$96FF.  You can get the data you need immediately, without even finding your favorite ZAP utility.


--------------------

Yes, ProDOS is Now Being Shipped

We bought an Apple //e last weekend, and it came with system disks for both DOS 3.3 and ProDOS.  There was no DOS Reference Manual, although a little of DOS is mentioned in the Owner's manual.  There is a very nice ProDOS User's Manual, 150 pages of text and photos and drawings.


I Can't Believe He Typed The Whole Thing!

One of our readers took a few evenings and typed in the source code of the whole CX ROM from the Apple //e Reference Manual Addendum.  This is the code from $C100 through $CFFC, which is listed on pages 23-49.  He added some of his own comments to the source, which more fully explain what is going on in there.  The source for the F8 ROM is on the disk too, but without many comments (pages 3-18 of the addendum).  Naturally, the source files are in the format of the S-C Macro Assembler.

We think having the contents of these ROMs on disk could enhance the //e in two ways:  you can make a larger size copy of the listings, so they can be read and studied in normal room light; and you can experiment with improvements to the code.  If you have a PROM burner that will burn 2764s, I think you can even replace the chips....

If you'd like a copy, send us $15:  we'll mail a copy of the disk to you, and pass along a percentage to the energetic typist.
