This little program fixes two bugs I found in cdtv's file system (cdfs.library)
It only works for cdfs v24 rev 9; it won't do anything if you don't have that
version of cdfs.  It has only been tested on my unaccelerated a500 w/ a570,
v2.0 OS (should work with 1.3, though).  If you have any comments or questions,
I can be reached via internet email as dark@judy.indstate.edu.

To run, just type
run >nil: cdfix
on your cdtv or a500 w/ a570 sometime before you insert a disk which would
otherwise make it crash :)

-- description of bugs --

Problem 1 [direct transcript of my post to comp.sys.amiga.programmer]
As you probably know, the A570 and CDTV have problems reading non-CDTV
ISO-9660 disks [those that I have tried and read by other means are AB20 and
the OS/2 Devel. Kit.  After looking throught the ROM on my A570 over the last
couple of days, I found what I believe to be the problem.  Of course since
it's in ROM, I have no fix as yet, but I just thought I'd let you all know &
see what you think.  The problem is in cdfs (CD0:/cdfs.library), and the
following refers to cdfs 24.9 (22.10.91) @ $f35544.

The problem is after $f3654c:

$f3654c tst.l	-4(A5)
	bne	$f36558
	move.l	D4,-4(A5)
$36558 ...

Which I believe should read:

$f3654c	tst.l	-4(A5)
	bne	$f36558
	move.l	D4,D0
	add.l	D6,D0
	move.l	D0,-4(A5)
$36558 [not any more :)] ...

Of course fixing the problem in ROM would be relatively easy if I were
inclined to burn my own, since there are plenty of inefficient pieces of
code even immediately surrounding the offensive code that the addition of 4
bytes could be offset, for instance, by making a few bra.w xxx into bra.s
xxx in the near vicinity.

To better explain the bug:  The routine @ $F36464 checks the disk for
ISO-9660 descriptors.  In the routine, a buffer is allocated (A3 = "buf")
which contains sectors from the disk.  D4 ("i") keeps track of the number of
the first sector in the buffer, and D6 ("j") keeps track of the offset into
the buffer currently being on.  (D5 ("o") is D6*2048, or the actual
byte-offset into the buffer).  -4(A5) ("vold") stores the volume descriptor
when found.

[Note:  all iso struct names are from the "ctools" utility on ftp.cdrom.com]

There is a loop similar to:

/* irrelevant bs.. */
/* decl buf as struct iso_volume_descriptor *buf */
/* allocate buf = nsecs*2048 bytes; nsecs = 16 or 2 dep. on avail. mem. */
for(i=16;i<256;i+=nsecs) {
	dbprint3("\tp%lx.%lx\n",i,vold);
	readcd(buf,i,nsecs); /* read nsecs sectors starting @ i */
	for(j=0,o=0;j<nsecs;j++) { /* isiso: check for CD001 v1 */
		if(isiso(buf[j])) switch(buf[j].id) {
			case 0:
				/* irrelevant CDTV stuff */
				break;
			case ISO_VD_PRIMARY: /* @ $f3654c */
				if(!vold)
					vold = i; /* should be vold = i+j; */
				if(!memcmp(buf[j].data,'CDTV'+spaces,32||..)
					more irrelevant CDTV stuff;
				break;
			case ISO_VD_END:
				j = nsecs;
				i = 256;
				break;
		}
	}
}
/* yet more irrelevant bs */

Well, there you have it.  Simple error when assigning vold as commented..
Folks at Commodore:  How about either fixing it or telling me why this isn't
a bug?


Problems 2&3: [again, direct transcript from my post]

Well, I finally got around to making a patch which fixed the bug I mentioned
in the previous posting, and discovered several new problems, among which is
the fact that the bug I reported is not the "real" bug [i.e. the one making
cdfs crash].
The problems are as follows:
1) When cdfs interprets the date, it does the following: [dis output]
RF38632
   movem.l   D2/A2,-(SP)
   move.l    $0C(SP),A2
   move.l    $10(SP),A1
   moveq     #4,D1
   bsr	     RF386BA
   tst.w     D0
   beq.s     lF38662
   sub.w     #$076C,D0
   move.b    D0,(A2)+
   moveq     #4,D2
lF38650
   moveq     #2,D1
   bsr	     RF386BA
   move.b    D0,(A2)+
   dbra      D2,lF38650(PC)
   clr.b     (A2)+
   movem.l   (SP)+,D2/A2
lF38662
   rts

Note that when there is not a valid date, it returns via lF38662, which
should have been moved up one line, and thus causes rts to crash cdfs/the
system...  This is what causes AB20 to crash, as my patch verified after I
fixed this bug.

2) When cdfs reads [via cdtv.device, of course] the disk looking for the
   root node, it keeps track of where it found one [see previous bug
   posting], and continues searching for a CDTV-specific block (boot block?
   31-char filename dir? who knows?).  Then when it doesn't find a
   CDTV-specific block, it re-reads the disk for the previously-tagged root
   block.  This read returns an error of -10 90% of the time on my A570 for
   my two non-CDTV 9660 disks, and is the reason the OS/2 developers' disk
   couldn't be read.  Anybody have any idea what error -10 is, and/or how to
   fix the bug? [the solution I'm attempting at the moment involves just
   copying the sector into the buffer when it finds it rather than
   re-reading it]

Ah, well.  If I ever get this horrible patch to install itself directly from
disk instead of only from within the debugger (why?  I haven't a clue - it
doesn't matter if I single-step or not, it just works from within the
debugger - probably due to some messaging conflicts), and to fix that error
-10 bug, maybe I'll upload the patch to aminet or boing... [done]

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

I also included cdfs.sym, which is a set of symbols you can use to
disassemble cdfs yourself if you so desire and cdfs is located @ $f35544.

-----------------------------------------------------------------------------
Thomas J. Moore, Amiga Programmer | Parallel Processing:  The future of PC's
inet:  dark@judy.indstate.edu     | Must .... Kill .... Bugs.... AAARRRGGHHH
-----------------------------------------------------------------------------