leejsmith wrote on 2022-08-19, 10:28:

The next video is now on Youtube
https://www.youtube.com/watch?v=6JJg_Gj08qU
I am going to take a break on this and work on some other projects at the weekends, If I do find anything that I think is worth trying I will do so.

@18:35 thats not how I would interpreted it. Its not "then it would start to write out data". Where would the data go before this writeout? There are no chipsets with hidden DMA buffers, the only place where the data goes is RAM. DOS has special space reserved for disk data https://forum.vcfed.org/index.php?threads/how … ers-work.72225/
you could try for laughs set BUFFERS=1 and see what happens, this would force DOS to limit reads to 1 sector at a time

That MEMW activity right after finishing DMA transactions @18:40 is IMO DOS executing TYPE command, copying internal floppy buffer to the SCREEN memory at 0xB0000 😀
looking at last-400-good you can see 46 single byte writes every ~200us (no clue what is being written here), and then a nice clumped 2000 bytes transfer. 80x25 = 2000, this is clearly a write to VGA card rewriting whole screen all at once.
protip: holding shift while selecting a slice of one channel adds nice measurement marker with statistics, falling edge count on memw = number of written bytes, same for dack.

@18:50 No way this is true, there are no magic dma caches in chipsets. What I said earlier in the thread and what might be happening is this Headland chipset having hardware design defect resulting in not issuing MEMW signal externally on DMA transactions. It evidently generates one internally (issuing memory write signal by memory controller) because data is being stored, but this behavior would limit working DMA exclusively to ram handled by onboard ram controller. DMA to ISA ram expansion cards would not work. This might of been missed by hardware designers? You could test that by writing a short test program that tries to read floppy directly to ram at 0xB0000 (graphics card text buffer). Another possibility is Headland chipset being so advanced/optimized that it knows where onboard ram is and where it isnt and issues MEMR/MEMW on ISA bus ONLY for addresses not handled by its internal memory controller.

@19:50 you dont see any memw because computer locked up = no code writes anything to video ram = no memw

There are no hidden DMA buffers!!1!111!! 😀 One way you could verify DMA is really writing data to ram but chipset is somehow not generating valid MEMW signals would be putting one of Logic analyzer probes on pin 21 of the SIMM socket (WE signal for ram modules).

I finally looked at your captures
last-400-good shows 5 512 byte transfers. Probably DOS parsing floppy FAT table followed by final 512 one sector read.
last-500-bad for some reason decides to read 7 sectors, probably because bigger file is in different spot on the disk forcing DOS to read more of the FAT structures to finally get to it.

now very good thinking on your part to capture IRQ 6! because the first thing that jumps at me is IRQ 6 not being deasserted! EDIT: wrote this before finishing watching your video 😀
If we look at correctly handled IRQ we see
- 2 or 3 bytes memr
- waiting ~17us
- continues to execute IRQ handler

now I dont know if those "2 or 3 bytes memr" are part of interrupt handler, or if PCs have slow interrupt latency of ~17us and it just takes that long for interrupt controller to signal CPU to stop what its doing and jump to interrupt handler.

If we look at last-500-bad failure case we see
- 3 bytes memr
- ... and nothing, the only memr activity on the bus is memory refresh every 14us - we know this is memory refresh because every memr corresponds to AEN. This is exactly how original IBM PC refreshed memory - a timer let a DMA channel read from RAM in a repeated cycle every 15 µs. You can even see Pentium still doing those AEN/MEMR cycles every 15 µs despite no need for them anymore (ram is on its own separate bus), its there for backward compatibility with very old and basic ISA RAM cards.

It now occurred to me that maybe your 286 also doesnt show all of its ram read/write cycles because you can clearly see IORDY activity every time interrupt handler is running - that tells us that code is being executed and is reading/writing IO registers.
Every IRQ6 handler reads/writes 20-30 IO ports before finishing
Bad read gets stuck in a tight loop querying some IO port, in fact if you zoom to ~6us per division and start scrolling right you will see a repetaring pattern of exactly the same IO accesses while computer is frozen - Floppy interrupt handler must be executing in some loop repeatedly querying some IO port, not liking what it saw and retrying.

Im a little sorry for you this repair is so tedious, but simultaneously absolutely loving every minute of the debugging going on here! 😁 This is my favorite vogon thread of the month, if not the year, by far!

What next. Since you have 16 channel salea slap probes on:
iordy,DMAAEN,irq6,ior,iow,A0 to A10
and capture failure case (freeze), this will let us know what addresses are those IO ports being read in the IRQ handler. I am trying to think how to also capture data being written/read with only 16 probes 😀 hmm, lets try:
iordy,DMAAEN,irq6,A0 to A4, D0 to D7

Combining and lining up both captures should show us the full picture. We will get to the bottom of this!

ps: floppy controller IO port description https://www.isdaman.com/alsos/hardware/fdc/floppy.htm
ps2: I still see green pins on the next ISA slot. Were there any damaged tracks under the first one? or was all of the damage incurred during the removal?

rasz_pl wrote on 2022-08-20, 06:59:

Another possibility is Headland chipset being so advanced/optimized that it knows where onboard ram is and where it isnt and issues MEMR/MEMW on ISA bus ONLY for addresses not handled by its internal memory controller.

my money is on this, it already has to steer the data bus accordingly so it isn't much additional sophistication to qualify the strobe assertion

From looking at the photos of the board I can only assume there is still way too much corrosion on the traces & vias that will impact signal integrity.

weedeewee wrote on 2022-08-20, 12:14:

From looking at the photos of the board I can only assume there is still way too much corrosion on the traces & vias that will impact signal integrity.

This is my bet too, 12-16MHz is getting fastish where signal integrity can be a problem and timing can be an issue. Lee was wondering if the memory CAS/RAS and delay circuitry is causing it as there is still a lot of corrosion there, sounds plausible to me as it does reference the DMA signals (last page of GC101 DS schematicS)...

At this point I think DMA is working just fine.

@leejsmith another thing I forgot. In addition to those two captures of failure case it would be nice to see the irq6 interrupt handler code. Im sure this can be done with DOS DEBUG. I dont know what Im doing beyond this point, guys please correct me:
x86 interrupt table is at 0000:0000h to 0000:03FFh. IRQ 6 = INT 0E = 0xE x 4 = 0000:0038h thats where address of floppy interrupt handler should be
DEBUG
-d 0000:0038 // then read 4 bytes. Lets call them AA BB CC DD
-r CS
CS: DDCC // set CS to the contents of last two bytes in reverse order
-u BBAA //decompile floppy interrupt handler

Thank you all for the suggestions, Yes i may have interpreted a few things wrong I am way out of my comfort zone with this one.

When I get around to this again I will work through all the suggestions and data log everything I can. Someone has commented in the video that they have the very same motherboard and I asked for pictures, if they are in the uk I will see if I can work with them in some way.

After removing the first 8bit ISA slot I had three damaged traces. Two from the first slot on the data lines 4 and 6 going to the pull up resistor and one on an address line when the pad lifted and pulled up a trace. I am sure I caused this damage on all three, but the data line 6 was always intermittent causing me to think the graphics card was not working.

I was also thinking I could setup my micro 8088 and capture the same data as it would be closer to the signal spec over the pentium ?

One other thing that crossed my mind is wrong bios, but its hard for me to imagine situation leading to this particular behavior (acknowledging some interrupts just fine, but hard freezing in some specific cases). Still might be worth it to ask for bios dump. None of those boards have any public dumps:
https://www.ultimateretro.net/en/motherboards/5241
https://www.ultimateretro.net/en/motherboards/9810
https://www.ultimateretro.net/en/motherboards/10689
and curiously one of them uses AMI while another a quadtel bios? Also plese upload your own bios (sorry if you did and I missed it).

My current running theory is interrupt handler querying -interrupt/floppy/timer controller- and getting a glitched response making it go into infinite loop.
There is one problem with this theory, keyboard is working, and that also requires flawless irq handling.

I would imagine micro 8088 being closer to ISA specification due to its simplicity.

i have had in the back of my mind that i saw someone on video talk about a small/large file problem and i think ive found right one.
Adrian's Digital Basement talks about it and demonstrates here in the video the two file size problem: https://youtu.be/QFpJ3uWIqVQ?t=3090
Here he has the issue on harddrives but maybe it extends to floppy drives. He also says a Quadtel bios fixes it.
So it probably worth trying another 286 bios like the one Adrian mentions.

Pickle wrote on 2022-08-23, 00:10:

i have had in the back of my mind that i saw someone on video talk about a small/large file problem and i think ive found right […]
Show full quote

i have had in the back of my mind that i saw someone on video talk about a small/large file problem and i think ive found right one.
Adrian's Digital Basement talks about it and demonstrates here in the video the two file size problem: https://youtu.be/QFpJ3uWIqVQ?t=3090
Here he has the issue on harddrives but maybe it extends to floppy drives. He also says a Quadtel bios fixes it.
So it probably worth trying another 286 bios like the one Adrian mentions.

The board comes with the Quadtel bios Adrian used to fix his board. I have no problems with any file size on a hard drive, only floppy drive.

rasz_pl wrote on 2022-08-22, 14:53:

One other thing that crossed my mind is wrong bios, but its hard for me to imagine situation leading to this particular behavior […]
Show full quote

One other thing that crossed my mind is wrong bios, but its hard for me to imagine situation leading to this particular behavior (acknowledging some interrupts just fine, but hard freezing in some specific cases). Still might be worth it to ask for bios dump. None of those boards have any public dumps:
https://www.ultimateretro.net/en/motherboards/5241
https://www.ultimateretro.net/en/motherboards/9810
https://www.ultimateretro.net/en/motherboards/10689
and curiously one of them uses AMI while another a quadtel bios? Also plese upload your own bios (sorry if you did and I missed it).

My current running theory is interrupt handler querying -interrupt/floppy/timer controller- and getting a glitched response making it go into infinite loop.
There is one problem with this theory, keyboard is working, and that also requires flawless irq handling.

I would imagine micro 8088 being closer to ISA specification due to its simplicity.

I did dump the bios that came with the board and also burnt a new set so I could try that, but I think it could be the same quadtel version.

leejsmith wrote on 2022-08-23, 20:19:

rasz_pl wrote on 2022-08-22, 14:53:

One other thing that crossed my mind is wrong bios, but its hard for me to imagine situation leading to this particular behavior […]
Show full quote

One other thing that crossed my mind is wrong bios, but its hard for me to imagine situation leading to this particular behavior (acknowledging some interrupts just fine, but hard freezing in some specific cases). Still might be worth it to ask for bios dump. None of those boards have any public dumps:
https://www.ultimateretro.net/en/motherboards/5241
https://www.ultimateretro.net/en/motherboards/9810
https://www.ultimateretro.net/en/motherboards/10689
and curiously one of them uses AMI while another a quadtel bios? Also plese upload your own bios (sorry if you did and I missed it).

My current running theory is interrupt handler querying -interrupt/floppy/timer controller- and getting a glitched response making it go into infinite loop.
There is one problem with this theory, keyboard is working, and that also requires flawless irq handling.

I would imagine micro 8088 being closer to ISA specification due to its simplicity.

I did dump the bios that came with the board and also burnt a new set so I could try that, but I think it could be the same quadtel version.

Might try and dissasemble the IRQ 6 ISR if I get a moment, but I've quickly merged the hi & lo to give a complete ROM file using the excellent romwak, see attached.

INT 0Eh - IRQ 6 ISR looks pretty standard - only thing different from the IBM 5170 BIOS Is that it does re-enable Interrupts, but that's also true of the Serge's 8088 BIOS I use in my XTjr 8088 PC:

1                       INT 0Eh I believe - IRQ 6 ISR 
2       f000:c6ed 50              PUSH       AX
3       f000:c6ee 1e              PUSH       DS
4       f000:c6ef b0 20           MOV        AL,0x20
5       f000:c6f1 e6 20           OUT        0x20,AL
6       f000:c6f3 2e 8e 1e        MOV        DS,word ptr CS:[BIOS_DS_SEGMENT]                 = 0040h
7                 04 9c
8       f000:c6f8 80 0e 3e        OR         byte ptr [offset DAT_0000_043e],0x80
9                 00 80
10       f000:c6fd 1f              POP        DS
11       f000:c6fe b8 01 91        MOV        AX,0x9101
12       f000:c701 cd 15           INT        0x15
13       f000:c703 58              POP        AX
14       f000:c704 cf              IRET

I don't think it is the BIOS, or at least I'm not sure we'll find the problem by looking at the Quadtel code, but still be good to try a chipset compatible BIOS instead of the Quadtel one just to see if there is any change... Does the Ultimate Retro DB have other generic boards using a similar G2/Headland reference design that might work?

mogwaay wrote on 2022-08-25, 15:34:

5170int0e.png

I don't think it is the BIOS, or at least I'm not sure we'll find the problem by looking at the Quadtel code

This is a straight up empty stub just clearing interrupt from interrupt and floppy controllers. I was expecting something like
https://bochs.sourceforge.io/cgi-bin/lxr/sour … ombios.c#L11318
this has a nice section that would be a perfect candidate for hanging indefinitely while retrying to query some IO
https://www.isdaman.com/alsos/hardware/fdc/floppy.htm search for mrqloop:
"This code will keep looping until the controller says that it is ready to receive data."

Sadly I have very little knowledge of DOS internals, ... but if I was writing DOS 😀 I would either replace bios handler with my own, or put my code in int #0x15 0x9101 function.

Mystery will be solved if/when leejsmith gets around to grabbing those logic analyzer captures.

rasz_pl wrote on 2022-08-25, 17:34:

This is a straight up empty stub just clearing interrupt from interrupt and floppy controllers. I was expecting something like […]
Show full quote

mogwaay wrote on 2022-08-25, 15:34:

5170int0e.png

I don't think it is the BIOS, or at least I'm not sure we'll find the problem by looking at the Quadtel code

This is a straight up empty stub just clearing interrupt from interrupt and floppy controllers. I was expecting something like
https://bochs.sourceforge.io/cgi-bin/lxr/sour … ombios.c#L11318
this has a nice section that would be a perfect candidate for hanging indefinitely while retrying to query some IO
https://www.isdaman.com/alsos/hardware/fdc/floppy.htm search for mrqloop:
"This code will keep looping until the controller says that it is ready to receive data."

Sadly I have very little knowledge of DOS internals, ... but if I was writing DOS 😀 I would either replace bios handler with my own, or put my code in int #0x15 0x9101 function.

Mystery will be solved if/when leejsmith gets around to grabbing those logic analyzer captures.

As in my XT machines, the ISR also sets a flag really which is usually picked up in waiting loops. I think DOS re-vectors IRQ6 which gets called first and then it calls the BIOS routine after doing some stuff, but there might be int 15 stuff too. We could look into the other code that waits for the flag to be set, but would be a lot more work to disassemble and not sure it would find much - think it would be easier to try another compatible BIOS, must be some.

Ghidra is a lot of fun if anyone wants to go digging more 😁

mogwaay wrote on 2022-08-25, 18:17:

As in my XT machines, the ISR also sets a flag really which is usually picked up in waiting loops.
... We could look into the other code that waits for the flag to be set

you mean that OR byte ptr [offset DAT_0000_043e],0x80 / seek_status,int_flag ? CPU gets stuck way earlier inside the interrupt handler before coming around to telling Floppy controller to release IRQ6 line (probably inside int 15 0x9101?). DOS has no opportunity to ever check that flag its not a dos flag, BIOS is the owner and most likely consumer.
https://stanislavs.org/helppc/int_15-91.html
http://www2.ift.ulaval.ca/~marchand/ift17583/dosints.pdf
AL = type code, see AH=90h above
AL = type code
00h: disk
01h: diskette
so int 15 0x9101 is a dedicated 'floppy Interrupt complete' routine. If I was DOS and wanted to run code as fast as possible on Floppy command completion this is the place I would hook into.
Edit:
now I looked at github freedos repository and couldnt find any low level floppy controller routines
I even grepped DOS 5-6 source code and coudlnt find a single "3f4", but I learned dos uses routines from IBMBIO/IO.SYS block driver, and those call int 0x13, and int 13h handler is provided by bios. No wonder I couldnt find anything in DOS sourcecode, its all hardware agnostic.
jakethompson1 was right on the money here Re: Headland based 286 with corrosion - locks up when reading from floppy disc
so the hanging code is provided by bios, and DOS doesnt hook it nor touches hardware directly.

If I pieced it right we have BIOS int 0x13 read command spinning waiting for 'seek_status,int_flag' flag, and BIOS int 15 0x9101 somehow failing to clear floppy controller interrupt flag. Why would that happen when all it does is read 3f4h IO port to get status, same operation that works fine for first 3 read sectors as evidenced by https://github.com/midicdj1000/headland-286-files captures. If there were flaky lower address or data bits on ISA slot leejsmith would see graphic corruption on the screen.

rasz_pl wrote on 2022-08-25, 20:14:

you mean that OR byte ptr [offset DAT_0000_043e],0x80 / seek_status,int_flag ? CPU gets stuck way earlier inside the interrupt h […]
Show full quote

mogwaay wrote on 2022-08-25, 18:17:

As in my XT machines, the ISR also sets a flag really which is usually picked up in waiting loops.
... We could look into the other code that waits for the flag to be set

you mean that OR byte ptr [offset DAT_0000_043e],0x80 / seek_status,int_flag ? CPU gets stuck way earlier inside the interrupt handler before coming around to telling Floppy controller to release IRQ6 line (probably inside int 15 0x9101?). DOS has no opportunity to ever check that flag
https://stanislavs.org/helppc/int_15-91.html
http://www2.ift.ulaval.ca/~marchand/ift17583/dosints.pdf
AL = type code, see AH=90h above
AL = type code
00h: disk
01h: diskette
so int 15 0x9101 is a dedicated 'floppy Interrupt complete' routine. If I was DOS and wanted to run code as fast as possible on Floppy command completion this is the place I would hook into.
Edit: Doh, its even called "OS HOOK" 😀
now I looked at github freedos repository and couldnt find any low level floppy controller routines 🙁
I even grepped DOS 5-6 source code and coudlnt find a single "3f4", but I learned dos uses routines from IBMBIO block driver. .. and ibmbio uses int 0x13. Im lost 😀
jakethompson1 was right on the money here Re: Headland based 286 with corrosion - locks up when reading from floppy disc

Yeah that's the one, 0040:003E, Bit 7 - it's used by the BIOS Floppy driver to check to see if an INT6 was called. On my XTjr 8088 machine, I've written my own DMA-less Floppy Code and DOS uses that quite happily to read, and *almost* write, disks with, so I'm pretty sure it just leans on the BIOS to drive the floppy controller. DOS does get called first on INT 13, but then it seems to hand-over to the BIOS for the heavy lifting...

I did a little more dissassembly on the Quadtel BIOS and think I found the Wait for IRQ 6 routine, and looks pretty standard, will loop 3x 65k times waiting for flag to be set before carrying on...

jakethompson1's code is bang on the money tho, it's the best low-level replication of Lee's bug. It seems to be a multi-sector problem, but I don't see why... FDC should just carry on reading from the next sector, requsting DMA to empty the FIFO buffer (if it has one configured) until DMA sends a TC when it's read all that it needs. Is the CPU fighting the DMA after the 1st sector? But why would that be? Brain fried for now, but I do like a good PC detective mystery.... 😀

in both good and bad read cases DMA seems to be configured for only 512 byte reads and finishes correctly (TC -> interrupt) !?!?

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?

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?

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 have tried booting from just a floppy with the goldstar controller and the fdd controller from my Micro 8088 with and without the XT-IDE. If I boot from a dos boot disc is just sits at starting ms dos. If I boot from the XT-IDE I can only read files smaller than 512b from the fdd.