|
(This article was first published in the ICPUG
Journal NOV / DEC 1989 issue.
Permission from Joe Griffin to republish on the Internet has been
received.)
Jiffy-DOS Revisited
In the last journal, I reviewed Jiffy-DOS and mentioned that I was awaiting
the arrival of a Jiffy-DOS ROM for the 1581 and Version 6 of the kernal.
Both have now arrived and been installed. I have just completed a long
series of tests, involving all the combinations of Commodore stock ROMs and
JiffyDOS ROMs which were available. Though I did find a MINOR problem with
"Big Blue Reader" when used with the Jiffy-DOS Version 6 kernal,
I came to the conclusion that the enhanced facilities of the Version 6 far
outweighed any problems.
For me, the single biggest advantage of Version 6 is that
the ' wedge' commands work, not only with Jiffy-DOS and serial drives but
also with any drives connected over the Brain Box I.E.E.E. interface. Thus,
I can inspect a file on my 8250 without disturbing any program in memory.
Other new features in Version 6 include a built-in file
copier and support for the RAM expansion units. Commodore kindly put their
RAMDOS into the public domain and I was able to obtain a copy while I was
visiting Betty Clay this summer.
One change in Version 6, is that while Version 5 allowed
listings to be paused by depressing the space bar ( like on the 8096 );
in Version 6 the same effect is achieved by holding down the control key
(more like the C-64).
On the 1581, Jiffy-DOS reduces load / save times by about a
quarter in 80 column 128 mode and in C-64 mode I found that load time came
down to one third and saving a 69 block file was reduced from 36 seconds to
15. I have checked that the Jiffy-DOS 1581 ROM still works with Superbase.
( Last time, I reported that the 1581 ROM contains a bug on BAM update. To
get over this, Superbase needs to do a direct memory execute. If the code
in Jiffy-DOS had moved, this could cause massive problems.) Also, the new
ROM does not itself cure the bug.
1581 ROM Bug
Last time I mentioned that there is a bug in the code in the 1581 drive
ROM. The bug can be demonstrated by using the program given below, which is
taken from page 75 / 76 of the 1581 User's Guide. Type in the program and
run it a few times on a blank, formatted disk. Then display the directory
of the disk, the 'blocks free' should be a few less than the 3160 of an
empty disk. Now remove the disk from the drive and re-insert it, then again
list the directory. The number of blocks free has mysteriously gone back up
to 3160! If you look at the sectors which should have been written, you
will indeed find that the data in them has been altered but they have not
been allocated.
100 open 15,9,15:rem device 9 is 1581 on my system
110 open 5,9,5,"#"
120 print#5,"i think therefore i am" : rem print into buffer
130 t=1:s=1
140 print#15,"b-a";0;t;s:rem allocate block
150 input#15,en,em$,et,es
160 if en=0 then 210
170 if en <> 65 then print en,em$,et,es:stop
180 if et=0 then print "disk full" : stop190 if et=40 then
et=41:es=0
200 t=et:s=es:goto 140
210 print#15,"u2";5;0;t;s:rem block allocated,
now write it
220 print "stored at";t;s
230 close 5: close 15
240 end : rem now list directory
Although the copy of BAM held in the drive RAM has been updated, this is
not written back to the disk. When the disk is removed, the RAM copy is
replaced with a fresh copy read from the disk and the updated, but not
written, version is lost.
The fix for this problem is quite simple, but h took a lot
of effort to get it out of Commodore. In order to write the copy back to
the disk, a routine within the disk ROM needs to be executed. In Superbase,
Tom does this only if the BAM has changed. It would be too wasteful of time
to do it every time the sector is written, as it might already be
allocated.
One problem is that the entry point given is specific to
the 318045-01 ROM in the 1581. If the code is moved at all, then the fix
will fail and Superbase will probably crash. As reported above, Version 6
of 1581 Jiffy DOS does not move this code, so there are no problems there.
I have written to Creative Micro, outlining the problem and the entry for
the fix, so hopefully, they will ensure that future mods to Jiffy DOS do
not screw up.
So the sixty-four thousand dollar question is "What is the entry
point?".
Answer $B612 ! To incorporate it into the above program, an extra line of
code needs to be added, thus:
215 print#15,"m-e";chr$(18);chr$(182):rem execute
code at $b612
If you want to use direct access programming, rather than stick to the
standard DOS files, then you will need to use the above Memory-Execute
command whenever you want to allocate or free blocks. However, K you don't
intend to do anything crafty, then you won't need this fix.
Superbase Open-heart Surgery
A few weeks ago, I had a phone call one evening from a member who had just
experienced a major crash with Superbase - could I help. After making
soothing noises and optimistically asking about backups, I offered to look
at the disk for him. He had been running on a 1581 drive when in the
middle of a 'FIND' command, the system returned to the menu. I suspected a
soft read error on the disk and confidently told him that I anticipated
getting everything back.
Two days later when I got home from a bad day at work,
there was a package from Roger. His covering letter explained that the file
should contain 2293 records and that the Utility program only managed to
recover 164. He also said that before the crash there were about 1300
blocks free and after the crash this had gone up to 2700 or thereabouts.
Very odd!
A quick directory of the disk confirmed my worst suspicions - this was a
copy of a Superbase program disk. Anyone who has looked at one of these disks will know that the BAM does not necessarily reflect the block usage on the d
isk. Using this disk as a data disk is inviting trouble.
The first step of recovery was to make a backup (a full
backup of every sector, not a Superbase one of allocated sectors only). I
used the 1581 Toolkit, as it allows use of the RAM Expansion Link, giving
only two disk swaps. Then the original disk was put away and was not
touched again ( until I made a boo-boo ).
Being a natural doubter, I ran MY copy of Utility128 on the
disk. Like Roger, I retrieved the grand total of 164 records. Ah-ha, I
thought, we have a problem.
Back in September/October 1987 the Wizard of OZ ( Paul
Blair ) published a Superbase Snooper program in these pages. I have copies
of the program for both the 128 and the C-64 and after two or three nights
of intensive study, code disassembly, hair tearing and many cups of coffee,
I discovered that by changing ONE BYTE of Paul's code for the 1571, I could
use a in burst mode on the 1581. Looking at the file with the snooper,
showed that the tail end was largely intact but the the front end was a
real mess. After about I block, the index was corrupted. Even in the intact
parts, some records were corrupted.
Over to that essential tool 'Super Disk Doc' (or rather my hacked version
which works on the 1581). The first block of the index was examined. This
pointed to the alleged position of the second block; in this instance
it was in the middle of a sequential file on track 31 - curious and not too
useful ! . It appeared that the drive had lost track of the BAM and
although sectors on tracks 31 to 35 were used by the database, they had
been overwritten by other files.
At this point it dawned on me that a long struggle was
ahead, so I prepared a set of sheets with columns for current track and
sector, next, last, first key, last key and the magic code 'OK'.
Fortunately the index sectors were easy to spot as I stepped through the
disk with SDD. Each time I found one I entered the details on the sheet,
for later use. Using this, I worked my way through the index sectors until
I came up to the sectors which I had found to be intact at the end of the
file.
The list produced by this exercise showed a number of index
sectors on tracks 31 to 34. These tracks were used by SEC) files and were
the cause of the corruption. As an example, the first index sector (2,28)
pointed to 31,21 as the next. The next sector I found was at 3,0 and
pointed to 31,21 as its previous. By modifying the pointers in these two
sectors, it would be possible to skip the intervening one and restore a
valid chain, albeit with loss of some records.
After a session doing this with SDD , the recovery was
ready to begin and I made a stupid mistake. I did not backup the work so
far, of which more later.
1 once again ran Utility128, secure in the knowledge that I
would manage to recover about 1700 records. When the program had completed,
I was able to discover that I had recovered the magnificent total of 164
records ! . I swore.
Having noticed that throughout the file there were a number of corrupted
records, I modified the snooper to print the informative message
"Entry Corrupt" K the data in the key field in the record did not
correspond with that in the index. A couple of counters were also
installed. When this program was run on my modified index, I found 1998
satisfactory records and 123 corrupt ones. This was better. I added a few
lines of code to print both the good records and the keys of the corrupted
ones to files on my 1571. This was superb, we were really getting places.
Well, almost! Remember my lack of a backup. Having made the code mods to
the snooper program, I saved it... onto the data disk, making that even
more corrupt.
Once I had called myself a silly billy ( or something in
that vein ), I retrieved the original data disk and made a backup ail over
again. Fortunately I had kept notes of the file link changes so it didn't
take too long to remake them and then make a backup of the modified disk (
stable doors? ).
Back on stream again, the data was extracted onto a 1571
and was then imported into a recreated database on a fresh 1581 disk. As
expected there were 1,998 records in the file. At this stage it would have
been easy to say to Roger, "Well, there are 90% of your records, carry
on." However, it was likely that some of the records pointed to by the
missing index sectors were present on the disk, if only we could get hold
of them.
Knowledge of the way Superbase fills a disk helped to find
a method of locating these records. Superbase starts at track 2 and works
on through increasing track numbers. A further mod to the snooper allowed
it to write to an array, to indicate whether a sector was corrupt, used by
an index or used for data. in the latter case, a record was made of whether
it was used once or twice. When the snooper had finished its run, the
contents of the array were printed out in suitable form, as shown in the
following table:
Track Sectors 0 to 39, grouped in 10's
1 ********** **********
********** **********
2 ********** ********** ********i2
2221**2222
3 i*2222121i **22212212 2222i1***2
222i222222
4 2i21222222 12222122i2 1*12222i1*
*1222i2222
Where a '2' occurred, two records had been read from the sector; a '1'
indicated one retrieval only and an asterisk '*' indicated that no records
had been retrieved from that sector. The letter 'i' indicated an index
sector and a ' c' showed a corrupted record. The sectors of interest were
those which had not been accessed, or which had been accessed once only.
Examination (again using SDD ) showed which contained records and a list
of these was prepared. A final modification to the snooper program allowed
it to access these sectors directly and extract the records to the 1571.
The 179 records recovered were then imported into a second file on the
1581. Of these, 47 were found to be duplicates of records already recovered
and were deleted. (it had been deemed unproductive to determine which
record of two in the sector had already been recovered, so both were
extracted.) The remaining 132 records were not merged into the main data
file, as they would require checking; some may have been deleted
records.
At the end of the day ( or several days ) I had retrieved 2130 records out
of 2293 or 93% of the file. I was well satisfied, I hope Roger was.
What I did not learn was why the problem had occurred. Roger had used a
program disk for his data. I assume that with the invalid BAM on this disk,
once he started writing to it, portions of the data file were not allocated
in BAM on the disk and were thus liable for overwriting.
|
