Path: utzoo!attcan!lsuc!ncrcan!ziebmef!mcp
From: mcp@ziebmef.uucp (Marc Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: SDB and tracing through the ROMs
Keywords: SDB, BCPL, breakpoint
Message-ID: <1988Dec27.223345.29513@ziebmef.uucp>
Date: 28 Dec 88 03:33:44 GMT
Reply-To: mcp@ziebmef.UUCP (Colin Plumb)
Organization: Ziebmef Public Access Unix, Toronto, Ontario
Lines: 70

I'm trying to reverse-engineer the disk validator, and encoutering a few
snags.  Could someone help me out?

What I'd really like to do is put breakpoints in the ROMs and work through
things that way, but I haven't yet found the magic flag that write-enables
the WCS.  The only likely sounding thing, the "memory overlay bit" on
PA0 of 8250 A, crashes the machine.  Obviously not what I want.

Against the day whan I find out (I could use help there, too), does SDB
mind encountering breakpoints in a foreign process?  I suspect it would
get upset if it hit one while the program it was debugging was stopped, but
if I put my test program into an infinite Wait(), would things work, or
does it mess around with the task structure?  The features to debug
device drivers suggest that something's possible, but the docs don't
go into any detail.

Also, in the interim, my attempts involving patching the rn_RestartSeg
vector to go through a jump to the real code I set up in RAM cause
machine crashes.  Can someone tell me what I'm doing wrong?

Current procedure:
OpenLibrary("dos.library", 0L) and find the root node.
Look at the rn_RestartSeg vector.  It holds 0x3ffc6c, a BPTR to
0xfff1b0, a reasonable place in the ROMS.  Disassembling this
location reveals:

00fff1b0: 0000 0000	ori.b	#0,d0
00fff1b4: 0000 038d	ori.b	#-73,d0
00fff1b8: 2401     	move.l	d1,d2
(more reasonable-looking code)

The first word looks like the NULL pointer to the next segment in the
SegList, the second, I don't know (by the docs I've seen, it should
get executed, but although it's harmless, it sure looks like a count
or something), and the rest is code involving a lot of shifts and (a0,dn)
addressing modes.  BCPL compiler, anyone?  (1.3 kickstart, BTW.)

So I try to patch in my own code.  I declare a static array (char code[20]),
round up to the nearest longword, stuff the current contents of
rn_RestartSeg into the first word, two nops after that (since I'm not sure
where the executable code starts in a segment), and then an absolute jump
to 0xfff1b4 (I've also tried with 0xfff1b8).

I patch rn_RestartSeg to hold a bptr to my fake segment, and, while I can
unpatch it again safely, if I insert a floppy (removal is okay) while this
patch is in place, boom!  Guru time.

For the technically oriented, I patched rn->RestartSeg to hold 0x7f2d,
0x1fcb4 in the APTR world, and at that address is found:

0001fcb4: 003f fc6c		ori.b	$6c,usp
0001fcb8: 4e71			nop
0001fcba: 4e71			nop
0001fcbc: 4ef9 00ff f1b4	fmp	fff1b4

I can't see what's wrong with this.  I haven't tried inserting a breakpoint
yet; I wanted to get this obviously trivial thing working first.

So... suggestions?  My eventual aim is to have my format of floppy auto-
recognised when a floppy is stuck in the drive, which I decided was
best achieved by patching in my rn_RestartSeg disk validator, which
would read the boot block, check the DOS type, and possibly punt to
the old one, but might do what the current disk vallidator does
(whatever that is), but using a different handler.

In furtherance of this, I'm trying to reverse-engineer the disk validator.
Any help at any stage of this descent to detail would be appreciated.

-- 
	-Colin (utai.toronto.edu!ncrcan!ziebmef!mcp for now)