rac@sherpa.UUCP (Roger A. Cornelius) (03/07/89)
Reading John Dunnings request for the mac 65 de-tokenizer which Analog
published awhile back reminded me of the following "memo" I wrote to
myself after making a very time consuming mistake a couple of years ago.
I wish I'd had the Analog article at the time. It would have saved me
a lot of trouble.
In going over this after so long, I find some parts aren't very clear, and
you will probably need some knowledge of the Atari dos disk layout for it
to be of any use to you. The disk related stuff probably isn't relevent
if you're using SpartaDos. Maybe someone else will find it useful.
Roger
----------
MAC/65 "SAVEd" Source File Format.
I wrote this little doc file in case any of you ever need to recover
a "SAVEd" listing of a MAC/65 program. One day while programming away,
I assembled my object file on top of my source file (the only copy I
had), seemingly destroying it. The source file had been 59 double
density sectors long and the assembled object file was only 9. Since
DOS doesn't actually delete a file when you write over it, but only
marks it as deleted in the directory, I knew that the last 50 sectors
of my file were still on the disk. YOU CAN BE POSITIVELY SURE OF THIS
ONLY IF YOU HAVEN'T WRITTEN TO THE DISK SINCE YOU MADE THE SCREW-UP!!!
So now I just had to figure out how to turn it back into a file DOS
would recognize and MAC/65 would load. You can use any good sector
editor to change the file links, etc.
Although I did lose the first nine sectors of my source code,
fortunately I had an old listing which helped me in re-typing the first
part of my program. Since the first portion of an assembly program is
usually devoted to the equates used by the program anyway, figuring
this out wouldn't be too difficult, so you could probably get by
without a listing.
I used Disk Wizard II by C.A.P. software, for the disk editing.
This is the file structure MAC/65 uses when SAVEing a tokenized
source file.
The first two bytes in a tokenized (SAVEd) MAC/65 source file are
always "FE FE". This is a file header (similar to the "FF FF" header
in a binary loaded file) which identifies the file to MAC/65 as a
tokenized source file. MAC/65 won't load the file if this two-byte
header isn't present.
The next two bytes are the total number of bytes in the file in LSB/MSB
format minus the 2 header bytes and 2 byte-count-bytes. The formula to
find the number of bytes in the file would be:
(((Sector count-1)*125)+number of bytes in last sector)-4
You subtract the 1 from the sector count because the last sector
usually isn't full and you add the bytes from that sector in the next
step of the formula. If your file is in double density, you would
substitute 253 for the 125.
So if you had a 59 sector file and overwrote it with a nine sector
file, you would start with 50 sectors (the other nine have been
destroyed by the over-write). Now subtract 1 (for the last sector),
and multiply the result by 125 (or 253 if double density). Now look at
the last byte in the last sector of what used to be your file (sector
links will have been preserved starting at the first sector after what
was overwritten). The value in this byte is the number of bytes used
by your program in that sector. Add this value to the total you got
before and then subtract 4 (for the header bytes). The result is the
total number of bytes in what's left of your file. You can now insert
this value (in hex LSB/MSB format) in the third and fourth bytes of the
first remaining sector of your file.
Dos always uses the last three bytes of a sector (whether single or
double density) to keep track of what the next sector in the file is
and also the number of bytes in the sector. The last byte of a sector
contains, in hex, the number of bytes the file used in that sector.
This will always be 125 ($7D) or 253 ($FD) except for the last sector
of a file which may or may not use the full 125 (or 253) bytes of the
sector.
The next two bytes are the actual beginning of your program and make up
the line number, in hex-LSB/MSB format, of the first line of your
program.
The next byte is the statement byte count. Not the actual count of
bytes in a statement if you were looking at a listing of your program,
but the count of how many bytes MAC/65 used to save that statement to
disk, in tokenized form. Counting the bytes in a statement begins with
the first byte after the byte that contains the statement byte count
(the byte we're talking about),and continues to and includes the next
statement byte count you encounter. So, if you know you had numbered
your program by tens (i.e. 10 20 30 40 etc.) you can find the two bytes
which contain the program line number, and you know the next byte
following that is the one that contains the statement byte count. Now
look for the next successive line number you think you used, and you
can count the number of bytes for that statement. In this way, you can
unscramble what will almost assuredly be the scrambled first portion of
your program. It is very unlikely that the part of your program
remaining after the overwrite starts at the beginning of a statement.
And besides, you have to insert the two byte header and also the two
bytes which make up the byte count of the file.
By using this counting method, you can find where each statement begins
and thus have your program start exactly where it should on the disk,
as far as the byte count goes. If the first statement of your program
doesn't begin exactly at the sixth byte of the file, you will be able
to load it into MAC/65 but part if not all of the file will be
scrambled and most likely MAC/65 wont let you do any editing to it.
--
Roger Cornelius rac@sherpa
uunet!sherpa!racRCH@cup.portal.com (Ric C Helton) (03/09/89)
Roger Cornelius writes about retrieving source code from a file saved "on top of" his original file (a nightmare indeed!). He mentions that the methods might not be of use or interest to SpartaDOS users, but the idea is similar to a common practice Sparta prorgammers have access to. ICD, the makers of SpartaDOS, have a "SpartaDOS Toolkit" that contains a wonderful sector editor. You can mark individual sectors to resave into another complete file, and even editor the disks' directory sectors and maps. Just thought I would post this in case anyone was interested. (The editor, called DISKRX.COM, will also work on non-Sparta disks, without some of the options, of course!) -Ric Helton RCH@cup.portal.com -Freestyle BBS 404/546-8256