I removed the 8 bit ISA and the only problems I found could have come from the removing of the isa slot. I found one of the data lines had a damaged trace to a pull up resistor array and then one trace that I 100% damaged because the pad was left on the old ISA socket. Then when I came to test the clock was running super fast and I am guessing my hot air has damaged the crystal for the RTC because it was running at over 100mhz instead of 32. A new crystal has been ordered and also the cd74hc14 for the same crystal because that was sometimes showing bad. None of this has changed how the floppy is working. I will be looking at this again over the weekend, but I think it will be just to make part two and I doubt I will fix the problem.
All of the lines across the ISA connections are buzzed and tested.
I could compare the signals out of the gc101sx chip to the isa connectors.
Need to find if the /io ch chk line is pulled up, this is showing activity with other signals and I am still wondering if this is the problem causing cpu pauses that only cause problems with DMA tansfers.

/io ch chk and /iow are almost the same.

Oof sorry the removal of the slot was so painful, but I think with all the corrosion visible on the slot it needed to be done.

My take is that the floppy errors are too weird to get an easy answer for, however I think the IOCHCHK line is fairly simple and should be silent, so activity there might indicate some problems elsewhere. It's a lower hanging fruit to fix IMHO. Looking at older ref schematics from G2 IOCHCHK should just go from the bus, have a pull up resister to 5v and input to GC101. I don't think the FDC/IDE/SERIAL card should use IOCHCHK and if nothing else on the bus, should be silent. I think the other Headland chip checks parity so doesn't use the IOCHCHK line (calls NMI itself).

mogwaay wrote on 2022-08-11, 15:24:

Oof sorry the removal of the slot was so painful, but I think with all the corrosion visible on the slot it needed to be done.

My take is that the floppy errors are too weird to get an easy answer for, however I think the IOCHCHK line is fairly simple and should be silent, so activity there might indicate some problems elsewhere. It's a lower hanging fruit to fix IMHO. Looking at older ref schematics from G2 IOCHCHK should just go from the bus, have a pull up resister to 5v and input to GC101. I don't think the FDC/IDE/SERIAL card should use IOCHCHK and if nothing else on the bus, should be silent. I think the other Headland chip checks parity so doesn't use the IOCHCHK line (calls NMI itself).

On my list is to track down the pull up resistor and see if it's a single or a network, perhaps it has a problem. The 8bit floppy controller I have for my micro 8088 does the same thing on this 286 as my 16 bit ide - fdd and it does not use iochck so I am sure it's not the cause of the problem. I should also check to see if iordy ever changes.

leejsmith wrote on 2022-08-11, 14:41:

Need to find if the /io ch chk line is pulled up
/io ch chk and /iow are almost the same.

what even generates io chk here????
ISA System Architecture Third Ed.pdf:
'CHCHK# Channel or liD check. This signal is asserted by an ISA expansion
board to signal an error condition to the microprocessor. An NMI
interrupt is issued to the microprocessor if NMI interrupts have
been enabled (bit 7 of port 70h is a 0) and if recognition of channel
check has been enabled (bit 3 of port 61h is a 0). '

'Figure 16-6. The Channel Check Logic' shows it will generate nmi if (bit 3 of port 61h is a 0)
Would NMI every time there is a IOW have a potential of interfering with DMA? CPU is already frozen during DMA cycle so the read/write will finish correctly, it could slow things down when CPU is trying to program another transfer I guess?

try tracing source of /io ch chk on the board, GC101 has an input for it so its not the source. You could maybe temporarily lift/cut this signal and see if anything changes.
My naive guess for the source would be Floppy controller noticing missing MEMW? you can tape over A1 ISA pin to check.

leejsmith wrote on 2022-08-11, 14:41:

I am still wondering if this is the problem causing cpu pauses that only cause problems with DMA tansfers.

you could probe gc101/cpu HOLD/hold acknowledge pins to see when it is being stopped, but my hunch is GC101 is only doing what its being told to do.
maybe check other dma request/ack lines for another dma running other than dma2?

286 platform is almost as straight forward as C64 or 8 bit ataris. All the vital things are still in the open instead of being hidden in highly integrated chipsets. You should be able to fix it by monitoring all the signals and staring at them long enough. Its a question of how much time you want to sink into it. Another board using same chipset would greatly help.

I'm surprised that the Goldstar FDC/IDE/SERIAL card uses IOCHCHK as all images I can find of similar cards on internet don't seem to have that pin connected - they sometimes have the contact plated on the edge but no traces come off it. However of you're seeing the same activity on the u8088 FDC card then something is defo amis. Good luck finding the source of the signal!

Good luck, you will save this board - it shall enjoy Floppy distributed Shareware Wolf3D!!

this is the thing I tried my fdd controller from my micro 8088 and it does not have a iochchk pin and I have the same problem.

I traced the iochchk line from the chip to the point on the ISA connector and then across to the others ISA. It had a 1k pullup resistor to 5v as expected, but then it was also connected to the end of a 100k that is connected to the battery circuit. I was not able to find the point it connected to this resistor, but it made no change if I removed the 100k or replaced with a new one.
Todays work was to fix my mistake on the RTC so that is now running at the correct speed and it made no change to the FDD reading and then it just stopped booting and the pc would not see the graphics card. I tried many times and it worked once more and then stopped. Not sure why this has happened, I just hope it will work again tomorrow.

>I was not able to find the point it connected to this resistor, but it made no change if I removed the 100k or replaced with a new one

have you looked at LA capture to see if disconnecting got rid of iochchk?

>then it just stopped booting and the pc would not see the graphics card.

imo this is good news, with any luck whatever was causing dma corruption failed completely now, makes it easier to find the cause

rasz_pl wrote on 2022-08-14, 00:46:

>I was not able to find the point it connected to this resistor, but it made no change if I removed the 100k or replaced with a […]
Show full quote

>I was not able to find the point it connected to this resistor, but it made no change if I removed the 100k or replaced with a new one

have you looked at LA capture to see if disconnecting got rid of iochchk?

>then it just stopped booting and the pc would not see the graphics card.

imo this is good news, with any luck whatever was causing dma corruption failed completely now, makes it easier to find the cause

I didn't have chance to test with the LA, but I did read the large files and it failed. The pc is booting this morning so not sure what is going in with the gfx card. The good news is the RTC is running again and the checkit test passed so dos time and rtc time matched. This morning I am going to look at the video footage while I let the pc just sit for a few hours so I can check the time and let the new 4.8v battery charge up.

in the gc101 pdf I do not see any connection to the iochchk line so I think this needs more investigation

When the battery is charged it stops the pc from booting, just dead no post codes at all, if I removed a jumper for the battery is will then post ok. I checked the circuit above and it is different because it has a 3rd transistor, but everything looks to work ok. I can see a low voltage on the RTC when powered off and when I switch it on it jumps up to 5v. Still no luck finding the short or link from the iochchk line to the battery circuit and I wonder if this is messing with the boot sequence.

Could this be a multi layer problem ? perhaps some corrosion on that first ISA connector. I might have to cut some traces to bypass a few things.
The time is good and after half an hour it had not lost any time when checking the dos time and the rtc

I have split the iochck line from the 1st isa connector after the pull down resistor. Then I have the LA on the side connected to the gc101 chip and the other side of the ISA. With no ISA cards installed I have activity on the iochchk line on the side that I thought was not connected to the gc101 and the gc101 side has no activity.
Not sure if this is related but it wiil not find the graphics card no matter what slot I put it in.

this picture is just booting and saying no graphics card

leejsmith wrote on 2022-08-14, 12:47:

I have split the iochck line from the 1st isa connector after the pull down resistor. Then I have the LA on the side connected to the gc101 chip and the other side of the ISA. With no ISA cards installed I have activity on the iochchk line on the side that I thought was not connected to the gc101 and the gc101 side has no activity.
Not sure if this is related but it wiil not find the graphics card no matter what slot I put it in.

this picture is just booting and saying no graphics card

I checked the iochchk line on the side with activity and it does not connect back to any pin of any chip that I can find.

i am a total idiot, the iochchk and iordy lines was mislabled in the LA software, all this time and I was looking at the wrong signals. So the iochchk has no activity as it should be.

so much time wasted over a stupid simple thing.

I found an intermittent trace on data line 6 that was the cause of the graphics card not working.

So we can eliminate the time difference between the RTC and the dos time.
iochchk was always ok and I am a dumb ass
I used my scope to test the address and data lines with one probe on the first and one on the last and everything matches, I think I need to do this for the 16 bit section too.
the graphics card is working again

The system will not post when the battery has charge
and dma is not working.

did i mention I am a dumb ass ?

leejsmith wrote on 2022-08-14, 13:01:

the iochchk and iordy lines was mislabled in the LA software, all this time and I was looking at the wrong signals. So the iochchk has no activity as it should be.

😀
good, one less thing to worry about

>I used my scope to test the address and data lines with one probe on the first and one on the last and everything matches, I think I need to do this for the 16 bit section too.

floppy controller is 8 bit

>The system will not post when the battery has charge

draw the vbatt circuit of your board on paper, q1 q2 d1-4 etc You didnt post clean high res photo of your board, but on the similar https://www.ultimateretro.net/en/motherboards/9810 there is an LM393 comparator close by. This suggests to me some kind of powergood situation going on, a blown diode/transistor could interfere with that

>and dma is not working.

still no ideas other than _why the hell is this board missing memw on ior_

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

:-) good, one less thing to worry about […]
Show full quote

leejsmith wrote on 2022-08-14, 13:01:

the iochchk and iordy lines was mislabled in the LA software, all this time and I was looking at the wrong signals. So the iochchk has no activity as it should be.

😀
good, one less thing to worry about

>I used my scope to test the address and data lines with one probe on the first and one on the last and everything matches, I think I need to do this for the 16 bit section too.

floppy controller is 8 bit

>The system will not post when the battery has charge

draw the vbatt circuit of your board on paper, q1 q2 d1-4 etc You didnt post clean high res photo of your board, but on the similar https://www.ultimateretro.net/en/motherboards/9810 there is an LM393 comparator close by. This suggests to me some kind of powergood situation going on, a blown diode/transistor could interfere with that

>and dma is not working.

still no ideas other than _why the hell is this board missing memw on ior_

This is how far I am with the battery circuit compared to the gc101 pdf and I was not looking at the lm393 at all so I will extend my testing to that chip. I have already made bad trace fixes on this area that ran to the other side of the board so I bet I have missed something.

i won't have any time to look at this until the weekend.

I think the lm393 is not part of the not switching on problem, it always reads the same on the output boot or no boot. It sometimes does not boot with or without the battery connected nothing on the post card and no data activity.

I have uploaded the latest LA captures to my github
https://github.com/midicdj1000/headland-286-files
and the next video will be released in a few days.

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.