mogwaay wrote on 2022-08-26, 10:10:

feipoa wrote on 2022-08-26, 06:02:

I was wondering if the OP has tried to read from the floppy drive once the system is already booted to the DOS prompt, or if the […]
Show full quote

I was wondering if the OP has tried to read from the floppy drive once the system is already booted to the DOS prompt, or if the issue is specific to booting from a floppy disk? As it sounded like you are also having DMA sound issues, our failure modes are likely different, but I thought I'd toss in my experience a similar problem when using a VLSI 200 series 286 motherboard.

I have notes indicating that on my system, which doesn't have any trace damage, that booting to the floppy w/Harris or Intel 286 installed doesn't work, but floppy read would work once the system was already booted. I also noted that replacing the Harris 286 CPU with an 486SLC based upgraded, it allowed bootable access to the floppy. I thought that there might be some issue with my particular board, but another member here has the same board and noted the same symptoms. Thus, if you happen to have a 386 or 486 upgrade chip, it might be worth trying. Also try reading from the floppy once already booted. And try different diskette drives/cables. I've run into cases where certain 286-thru socket 5 systems didn't like some disk drives.

Source:
Re: Evergreen 486 SuperChip - settings for DIP switch?

feipoa wrote on 2021-12-08, 18:43:

What has been perplexing me about my 286 is that it cannot boot from floppies using a standard Harris 286-12 or 286-16 CPU. It tries to boot, but just hangs there. If I boot to a DOS prompt using the HDD, I can use the 1.44M floppy drive just fine. The interesting part of this observation was that if I use the SuperChip 486SLC CPU, I can boot to 1.44M floppies without issue. What could be causing the system not to boot to floppies with a standard Harris 286?

I think Lee (OP) had same issues whether he was booting or in DOS. He could read 1 sector files fine in DOS but not larger. He also showed a clip trying to boot a floppy and it seemed to work initially but then crashed (I think it was a bootable version of OMNIDISK, maybe FreeDOS based boot floppy?). Nice ideas tho, maybe he could try a new CPU?

How easy is it to find a 286 chip ?

You could try lowering cpu clock all the way down.

rasz_pl wrote on 2022-08-30, 12:59:

You could try lowering cpu clock all the way down.

I did try with turbo off and on.

I might have some time this weekend to setup and run through a few tests and LA tests.

Tiny update: I managed to run the Quadtel BIOS ROMS Lee dumped in MAME's ibm5170 emulator and they worked fine with emulated 1.44MB floppied so the ROMS aren't corrupted or broken or anything. I also could break into the IRQ 6 ISR (INT 0E - located at f000:c6ed) and it would be called ~5-6 times when accessing a disk in DOS and thats probably right, a seek, read sector or two and then getting the resutls a couple of times for each access (I'm not really sure what DOS does exactly when accessing floppy sectors on listing dirs, etcs...). Anyway nice to have a kind-of debug-enabled emualtor of the BIOS for this if we want to confirm anything about what it's supposed to be doing...

Im not familiar with mame/mess and its debuggability. Can you set traps on IO and see what is being accessed during IRQ6 when reading floppy files?

rasz_pl wrote on 2022-09-01, 21:36:

Im not familiar with mame/mess and its debuggability. Can you set traps on IO and see what is being accessed during IRQ6 when reading floppy files?

I'm not that familiar with it either! It doesn't seem to give much visability to IO requests, however as I'd found the BIOS interrupt service routine for IRQ 6 requests, I could break on that so shows where it jumps to on a IRQ 6. Doesn't tell you much as all the ISR does is set a flag, reset int and return - it's up to the other floppy code to detect that flag change and then process the results. I had started hunting in Ghidra to find the floppy read/write code in the BIOS so could probably find the code that looks for the flag and responds to the IRQ6. I also mean to use DEBUG to to run the simple 2 sector reading code test as previously used and then I can see what is supposed to happen, which might explain when it's not. Only thing I think at the moment is the drive params are not being set correctly due to CMOS batter weirdness - maybe even due to a NVRAM corruption/fault as it's a bit weird Lees boot issues with the battery connected. However I'm not sure it wouldn't explain why sound card DMA requests were failing as that wouldn't use NVRAM settings.... this is a toughy for sure....

maybe easier to look for floppy IO port accesses in the code.

mogwaay wrote on 2022-09-02, 11:05:

rasz_pl wrote on 2022-09-01, 21:36:

Im not familiar with mame/mess and its debuggability. Can you set traps on IO and see what is being accessed during IRQ6 when reading floppy files?

I'm not that familiar with it either! It doesn't seem to give much visability to IO requests, however as I'd found the BIOS interrupt service routine for IRQ 6 requests, I could break on that so shows where it jumps to on a IRQ 6. Doesn't tell you much as all the ISR does is set a flag, reset int and return - it's up to the other floppy code to detect that flag change and then process the results. I had started hunting in Ghidra to find the floppy read/write code in the BIOS so could probably find the code that looks for the flag and responds to the IRQ6. I also mean to use DEBUG to to run the simple 2 sector reading code test as previously used and then I can see what is supposed to happen, which might explain when it's not. Only thing I think at the moment is the drive params are not being set correctly due to CMOS batter weirdness - maybe even due to a NVRAM corruption/fault as it's a bit weird Lees boot issues with the battery connected. However I'm not sure it wouldn't explain why sound card DMA requests were failing as that wouldn't use NVRAM settings.... this is a toughy for sure....

is it possible to change the bios to output debug or step through once you find the correct section ? Good call looking at the code I typed in that was set to read one or more sectors. I was very busy with work recently so no chance to set anything up.

sure, you dont even need to modify bios, you can patch interrupt handler after boot

What we are interested in is code issuing 'Sense Interrupt Status Command'
"This command when issued resets the interrupt signal and, via bits 5,6 and 7 of the Status Register 0 identifies the cause of the interrupt"
Somehow we arent reaching this bit.

if irq 6 handler really looks like Re: Headland based 286 with corrosion - locks up when reading from floppy disc then the only other place of interest is int 15 function 0x9101.

leejsmith wrote on 2022-09-06, 15:20:

is it possible to change the bios to output debug or step through once you find the correct section ? Good call looking at the code I typed in that was set to read one or more sectors. I was very busy with work recently so no chance to set anything up.

That would be hard to patch the BIOS, but I can step through on Emulator if needed. Might be able to do that on your machine too using the Shadow BIOS and Debug - actually that could be cool if Shadow BIOS option works - drop breakpoints in Debug to the Floppy routines and then run the little read-2-sectors-code....

What I've tinkered with:
- Found that MAME lets you set IO r/w Watchpoints so I looked at it setting the DMAC during the read-2-sectors test code and it looked totally fine (didn't check the A16-19 reg):

30 to 0xC - dmac_ff_reg fine
30 to 0x4 - dmac_ch2_addr_reg - 30? Low byte
74 to 0x4 - dmac_ch2_addr_reg - 74? High byte, so 7430 is where it's going to start writing to? Ah, might be the rebased memory address - 1723:0200 = 17430 - boom that's perfect too...
FF to 0x5 - dmac_ch2_count_reg - FF to the count low byte
03 to 0x5 - dmac_ch2_count_reg - 03 to the count high byte - perfect that's 3FF or 1023 - 2 sectors
02 to 0xA - dmac_mask_reg - yup unmask DRQ2

- Found the code in the BIOS that waits for an IRQ6/INT0E and set breakpoints on that and INT0E and they are called 4 times on first trying the read 2-sectors, which looks normal (recalib, detect rate and seeking track and get results) and then on 2nd go it does 3 interrupts (not sure why just 3, probably skips recalibrate command) and then a third time just the 1 (skips recalibrate, detect rate and seek as all set and just waits for results). All correct.

- Checked to see if the PIC mask is being set (IO 0x21) after reading 2 sectors - like masking off IRQ6 - but nope, nothing there...

What I don't get is what causes the machine to lock up and end up executing random code instead of just giving errors? My best guess at the moment would be either the DMA is writing rubbish to DRAM directly as it doesn't seem to use external RAM (ie no, MEMW) and instead goes straight to the on-board DRAM and that's clobbering the Vector table at the start of RAM - but that's weird that it's only for >512 bytes of memory (2+ sectors).

Other idea is that it's sketchy signals on Interrupt requests/CPU Hold Requests/Not providing Int vectors nicely on INTA but if that's the case why is it fine for 1 sectors DMA writes and every other interrupt in the system that's happening all the time?

For me if Lee ever wants to look at this board ever again, would be to add the Hold Request, Hold Ack, Int Request and Int Acknowldge lines to the LA and see what they are doing. I'd also only use the Debug read-2-sectors code crash as this is the most specific and most repeatable test - should also remove some of the OS from the picture.

Could still be the BIOS and OS - might also be worth trying another version of DOS or the BOIS and running the test to check it's not a problem - but I still don't think that's going to be the issue here...

Anyway just wanted to feedback my 2cents that's been going through my head - as I say I love a good PC troubleshoot 😉

mogwaay wrote on 2022-09-09, 20:58:

What I've tinkered with:
- Found that MAME lets you set IO r/w Watchpoints

Thats exactly what I was asking about earlier 😀

mogwaay wrote on 2022-09-09, 20:58:

What I don't get is what causes the machine to lock up and end up executing random code instead of just giving errors?

if you look into LA captures its not random code, its looping around same IO pattern inside interrupt 6, like its stumbling into something it doesnt like and repeating ad nauseum instead of acknowledging interrupt and exiting with error code.

It would be illuminating to set IO watchpoints on 3f0-3f7h and 370-377h and grab a log of all the data read/written and the addresses of bios code that called those accesses during one floppy read.

mogwaay wrote on 2022-09-09, 20:58:

Other idea is that it's sketchy signals on Interrupt requests/CPU Hold Requests/Not providing Int vectors nicely on INTA but if that's the case why is it fine for 1 sectors DMA writes and every other interrupt in the system that's happening all the time?

I would readily blame bad fdd controller if not for the fact it apparently works in another computer

rasz_pl wrote on 2022-09-09, 23:38:

if you look into LA captures its not random code, its looping around same IO pattern inside interrupt 6, like its stumbling into something it doesnt like and repeating ad nauseum instead of acknowledging interrupt and exiting with error code.

It would be illuminating to set IO watchpoints on 3f0-3f7h and 370-377h and grab a log of all the data read/written and the addresses of bios code that called those accesses during one floppy read.

I would readily blame bad fdd controller if not for the fact it apparently works in another computer

What did you see in the LA traces that made it look like it was still executing code in the IRQ6 ISR? I couldn't make that out without Data/Addr lines, etc
..

Could grab all the FDC IO calls and dump to a file, might try that, tho would be a lot to wade through ... I still think this isn't anything to do with the BIOS as it works on emulation fine and if it was doing something stupid, then it would be weird that it works great for 1 sector transfers, as many times as you like. It needs IRQ6 plenty for 10x single sector reads, why do they all work great... FDC would be suspect but Lee's used 2 different FDC cards (8 and 16bit) and these in other machines where they work fine, so can't be that...

if hw was ok, to lock up it would need to be in an inf. loop/garbage AND have disabled interrupts - or the vector table is corrupt - or CPU is halted by HOLDREQ/READY signals? Any other ways to lock a machine good?

Other thing I've got is the floppy params are messed up and that by setting the FDC sector gaps wrong is messing up the read to the 2nd sectors. However if that was the case I'm sure you'd just get an error like sector/id not found or something not lock up...

Still confused 😅

Oh another half-thought was just the length of time the DMAC was being used, maybe it has a different clock that's getting out of sync? But the DMAC only has the bus for a single byte transfer at a time, regardless of 512 or 1024 bytes...

'ere ya go - reads/writes to FDC ports after running the simple int 13 read-2-sectors code from Debug... See anything interesting?

And here is another trace checking 370-7 also (nothing there).

The last trace might have some duplication in it as MAME debugger is a pain to copy and paste out of...

Yeah I just reviewed my traces, and MAME is missing stuff, as I can't even see the FDC read command being written.... I've done another here just focussing on 3F5 and can at least see the read command being made (E6, 00, etc...).

As I find myself idle here are my annotations of the last log of just 3f5 r/ws:
---

1unknown command
2Stopped at watchpoint 1 writing 03 to 000003F5 (PC=FC6B2) - CMD: Specify
3Stopped at watchpoint 1 writing DF to 000003F5 (PC=FC6B2) - Normal/safe SRT & HUT
4Stopped at watchpoint 1 writing 02 to 000003F5 (PC=FC6B2) - Normal HLT & DMA ON
5Stopped at watchpoint 1 writing 0F to 000003F5 (PC=FC6B2) - CMD: Seek
6Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2) - Head 0, Disk 0
7Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2) - Cylinder 0
8Stopped at watchpoint 1 writing 08 to 000003F5 (PC=FC6B2) - CMD: Sense Int
9Stopped at watchpoint 1 reading 20 from 000003F5 (PC=FC740) - ST0 = Seek End, normal
10Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740) - Present Cyl No. = Cylinder 0, good
11Stopped at watchpoint 1 writing E6 to 000003F5 (PC=FC6B2) - CMD: Read Data; MT=1, MFM=1, SK=1
12Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2) - Head 0, Drive 0
13Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2) - Cylinder 0
14Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2) - Head 0
15Stopped at watchpoint 1 writing 01 to 000003F5 (PC=FC6B2) - Sector 1
16Stopped at watchpoint 1 writing 02 to 000003F5 (PC=FC6B2) - Sector Size 02 = 512B
17Stopped at watchpoint 1 writing 3F to 000003F5 (PC=FC6B2) - EOT - 3F, 99 - this is a little interesting, but as DMA terminates FDC it'll just keep reading till it gets a TC or Sector not found instead of overrun abnormal termination...
18Stopped at watchpoint 1 writing 1B to 000003F5 (PC=FC6B2) - Gap Length - 1B is pretty normal for 1.44MB
19Stopped at watchpoint 1 writing FF to 000003F5 (PC=FC6B2) - DTL - always FF I think...
20Stopped at watchpoint 1 reading 40 from 000003F5 (PC=FC740) - Status 0: Abnormal termination, interesting...
21Stopped at watchpoint 1 reading 01 from 000003F5 (PC=FC740) - Status 1: Couldn't find ID
22Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740) 
23Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740) - Cylinder 0
24Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740) - Head 0
25Stopped at watchpoint 1 reading 01 from 000003F5 (PC=FC740) - Sector 1
26Stopped at watchpoint 1 reading 02 from 000003F5 (PC=FC740) - Sect Size 02 (512)
27
28> So it failed and is trying again? 
29Stopped at watchpoint 1 writing 03 to 000003F5 (PC=FC6B2) - 
30Stopped at watchpoint 1 writing AF to 000003F5 (PC=FC6B2)
31Stopped at watchpoint 1 writing 02 to 000003F5 (PC=FC6B2)
32
33Stopped at watchpoint 1 writing E6 to 000003F5 (PC=FC6B2)
34Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2)
35Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2)
36Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2)
37Stopped at watchpoint 1 writing 01 to 000003F5 (PC=FC6B2)
38Stopped at watchpoint 1 writing 02 to 000003F5 (PC=FC6B2)
39Stopped at watchpoint 1 writing 3F to 000003F5 (PC=FC6B2)
40Stopped at watchpoint 1 writing 1B to 000003F5 (PC=FC6B2)
41Stopped at watchpoint 1 writing FF to 000003F5 (PC=FC6B2)
42
43Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740) - Status 0: Normal Termination
44Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740)
45Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740)
46Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740) - Cyl 0
47Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740) - Head 0
48Stopped at watchpoint 1 reading 03 from 000003F5 (PC=FC740) - Sector 3
49Stopped at watchpoint 1 reading 02 from 000003F5 (PC=FC740) - 512B
50>!

mogwaay wrote on 2022-09-10, 13:45:

What did you see in the LA traces that made it look like it was still executing code in the IRQ6 ISR? I couldn't make that out without Data/Addr lines, etc

https://github.com/midicdj1000/headland-286-files last-500-bad.sal
iordy during every IRG 6 signifies number of IO operation. There are 8 correct interrupts in the capture: 27, 27, 29, 26, 28, 27, 27, 32
non responsive interrupt iordy forms a repeating pattern all the way to the end of capture. 6 IOs, 3.8us pause, 100-110 IOs, 159us pause, repeat
Capturing full ISA bus snapshot will reveal what are those IO accesses telling us WTF is going on.

Now that Im looking at it again I see some more sparse iordy activity in what I earlier called "159us pause" that is curiously aligning with DMAAEN every 14 us (memory refresh), almost as if a signal was coupling/leaking, always trailing DMAAEN by 188ns.
when I think about it even harder Im spotting a lot of 62ns short signals, thats the max sampling rate of the capture (16MHz). Coincidentally 125ns (proper 8MHz ISA clock) + 62ns = ~188ns. Maybe this is the problem?

mogwaay wrote on 2022-09-10, 13:45:

Attachments

I suspect somehow this doesnt have a chance to run, or somehow fails:

1Stopped at watchpoint 1 writing 08 to 000003F5 (PC=FC6B2)
2Stopped at watchpoint 1 reading 20 from 000003F5 (PC=FC740)
3Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740)

Afaik executing command 08 "check interrupt status" is what turns off Interrupt signal generated by FDC.

rasz_pl wrote on 2022-09-11, 06:17:

https://github.com/midicdj1000/headland-286-files last-500-bad.sal iordy during every IRG 6 signifies number of IO operation. T […]
Show full quote

https://github.com/midicdj1000/headland-286-files last-500-bad.sal
iordy during every IRG 6 signifies number of IO operation. There are 8 correct interrupts in the capture: 27, 27, 29, 26, 28, 27, 27, 32
non responsive interrupt iordy forms a repeating pattern all the way to the end of capture. 6 IOs, 3.8us pause, 100-110 IOs, 159us pause, repeat
Capturing full ISA bus snapshot will reveal what are those IO accesses telling us WTF is going on.

Now that Im looking at it again I see some more sparse iordy activity in what I earlier called "159us pause" that is curiously aligning with DMAAEN every 14 us (memory refresh), almost as if a signal was coupling/leaking, always trailing DMAAEN by 188ns.
when I think about it even harder Im spotting a lot of 62ns short signals, thats the max sampling rate of the capture (16MHz). Coincidentally 125ns (proper 8MHz ISA clock) + 62ns = ~188ns. Maybe this is the problem?

Ah, yes using IORDY as a proxy for IO requests, very good. Looking at these in detail is interesting. I'll have a look at what IO requests should be happening on conclusion of a floppy read. The FDC documentation isn't super clear about what clears an IRQ - Sense Int. is one of them but the SMC FDC37C78-HT datasheet (another FDC I'ved used in the past) also states that IRQ is cleared when reading from the buffer which makes sense: "The FDC will deactivate the IRQ pin and RQM bit when the FIFO becomes empty.". Usually Sense Int. is only called from Seek and Recalibrate commands, so don't think the lack of this command is necessarily why it's staying high...

mogwaay wrote on 2022-09-12, 11:48:

conclusion of a floppy read. The FDC documentation isn't super clear about what clears an IRQ - Sense Int. is one of them but the SMC FDC37C78-HT datasheet (another FDC I'ved used in the past) also states that IRQ is cleared when reading from the buffer which makes sense: "The FDC will deactivate the IRQ pin and RQM bit when the FIFO becomes empty."

afaik thats for non DMA single byte transfers, in DMA mode interrupt is generated after finishing the transfer

rasz_pl wrote on 2022-09-12, 13:33:

afaik thats for non DMA single byte transfers, in DMA mode interrupt is generated after finishing the transfer

Yeah I just picked it as one of the few example I've found of a uPD765 based FDC that explicitly tells you when IRQ is reset which is not the Senst Int Command - I believe that IRQ is also reset after a normal read/write/format/verify command once the results bytes are read in the result phase - Sense Int. Cmd not required.

To try and show this, please see a new 'trace' (really me tediously continuting through the debugger! I think it worked better this time as I was slooooow pressing the F5 Run button on every break) and as I understood these is only 1 sense int, probably after the seek command:

1Device ':maincpu' io space watchpoints:
2    1 @ 03F4-03F5 r/w
3Stopped at watchpoint 1 reading 80 from 000003F4 (PC=FC694)
4Stopped at watchpoint 1 writing 03 to 000003F5 (PC=FC6B2)
5Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
6Stopped at watchpoint 1 writing DF to 000003F5 (PC=FC6B2)
7Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
8Stopped at watchpoint 1 writing 02 to 000003F5 (PC=FC6B2)
9Stopped at watchpoint 1 reading 80 from 000003F4 (PC=FC694)
10Stopped at watchpoint 1 writing 0F to 000003F5 (PC=FC6B2)
11Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
12Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2)
13Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
14Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2)
15Stopped at breakpoint 1 [This at the start of  INT_0E aka the IRQ6 ISR in the BIOS]
16Stopped at watchpoint 1 reading 80 from 000003F4 (PC=FC694)
17Stopped at watchpoint 1 writing 08 to 000003F5 (PC=FC6B2)
18Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
19Stopped at watchpoint 1 reading 20 from 000003F5 (PC=FC740)
20Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)
21Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
22Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740)
23Stopped at watchpoint 1 reading 80 from 000003F4 (PC=FC74C)
24Stopped at watchpoint 1 reading 80 from 000003F4 (PC=FC694)
25Stopped at watchpoint 1 writing E6 to 000003F5 (PC=FC6B2)
26Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
27Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2)
28Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
29Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2)
30Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
31Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2)
32Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
33Stopped at watchpoint 1 writing 01 to 000003F5 (PC=FC6B2)
34Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
35Stopped at watchpoint 1 writing 02 to 000003F5 (PC=FC6B2)
36Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
37Stopped at watchpoint 1 writing 3F to 000003F5 (PC=FC6B2)
38Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
39Stopped at watchpoint 1 writing 1B to 000003F5 (PC=FC6B2)
40Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
41Stopped at watchpoint 1 writing FF to 000003F5 (PC=FC6B2)
42Stopped at breakpoint 1 [IRQ6]
43Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
44Stopped at watchpoint 1 reading 40 from 000003F5 (PC=FC740)
45Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)
46Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
47Stopped at watchpoint 1 reading 01 from 000003F5 (PC=FC740)
48Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)
49Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
50Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740)
51Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)
52Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
53Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740)
54Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)
55Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
56Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740)
57Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)
58Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
59Stopped at watchpoint 1 reading 01 from 000003F5 (PC=FC740)
60Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)

61Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
62Stopped at watchpoint 1 reading 02 from 000003F5 (PC=FC740)
63Stopped at watchpoint 1 reading 80 from 000003F4 (PC=FC74C)
64Stopped at watchpoint 1 reading 80 from 000003F4 (PC=FC694)
65Stopped at watchpoint 1 writing 03 to 000003F5 (PC=FC6B2)
66Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
67Stopped at watchpoint 1 writing AF to 000003F5 (PC=FC6B2)
68Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
69Stopped at watchpoint 1 writing 02 to 000003F5 (PC=FC6B2)
70Stopped at watchpoint 1 reading 80 from 000003F4 (PC=FC694)
71Stopped at watchpoint 1 writing E6 to 000003F5 (PC=FC6B2)
72Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
73Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2)
74Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
75Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2)
76Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
77Stopped at watchpoint 1 writing 00 to 000003F5 (PC=FC6B2)
78Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
79Stopped at watchpoint 1 writing 01 to 000003F5 (PC=FC6B2)
80Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
81Stopped at watchpoint 1 writing 02 to 000003F5 (PC=FC6B2)
82Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
83Stopped at watchpoint 1 writing 3F to 000003F5 (PC=FC6B2)
84Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
85Stopped at watchpoint 1 writing 1B to 000003F5 (PC=FC6B2)
86Stopped at watchpoint 1 reading 90 from 000003F4 (PC=FC694)
87Stopped at watchpoint 1 writing FF to 000003F5 (PC=FC6B2)
88Stopped at breakpoint 1 [IRQ6]
89Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
90Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740)
91Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)
92Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
93Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740)
94Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)
95Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
96Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740)
97Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)
98Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
99Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740)
100Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)
101Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
102Stopped at watchpoint 1 reading 00 from 000003F5 (PC=FC740)
103Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)
104Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
105Stopped at watchpoint 1 reading 03 from 000003F5 (PC=FC740)
106Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC74C)
107Stopped at watchpoint 1 reading D0 from 000003F4 (PC=FC71E)
108Stopped at watchpoint 1 reading 02 from 000003F5 (PC=FC740)
109Stopped at watchpoint 1 reading 80 from 000003F4 (PC=FC74C)
110User-initiated break

Oh and I jsut ran the normal int 13 routine from Debug for a 2 sector read (AX,0202).