Can you log interrupt status too? to see when the emulator turns off irq signal? Ill have a look in the sourcecode of 86box.

edit: found it https://github.com/86Box/86Box/blob/7405d777e … oppy/fdc.c#L735
inside fdc_sis. fdc_sis(fdc) is called on execution of case 0x08: /*Sense interrupt status*/ command. All other cases of FDC rising interrupt level seem to automatically lower it back down?

rasz_pl wrote on 2022-09-14, 03:34:

Can you log interrupt status too? to see when the emulator turns off irq signal? Ill have a look in the sourcecode of 86box.

Sorry I couldn't see how to do this in MAME...

rasz_pl wrote on 2022-09-14, 03:34:

edit: found it https://github.com/86Box/86Box/blob/7405d777e … oppy/fdc.c#L735
inside fdc_sis. fdc_sis(fdc) is called on execution of case 0x08: /*Sense interrupt status*/ command. All other cases of FDC rising interrupt level seem to automatically lower it back down?

Quick scan at the source didn't really help me, I'm not familair enough with it, but that sounds like the same thing I'm thinking - IRQ will lower once results phase has completed and the result bytes have been read.

Soooo Lee's machine probably isn't reading the result bytes from the FDC on completion of a 2 sector read and we're back to: why?

mogwaay wrote on 2022-09-14, 09:21:

Quick scan at the source didn't really help me, I'm not familair enough with it, but that sounds like the same thing I'm thinking - IRQ will lower once results phase has completed and the result bytes have been read.

I mean all the other "fdc->fintr = 0" (setting interrupt signal back to 0) instances are immediately following code sending interrupt request "fdc_int(fdc, 1)". IBM PC ISA interrupts are Edge triggered, you dont need to keep the interrupt line active. Looking at that code above *Sense interrupt status* command is the only direct way of forcing FDC to explicitly turn Interrupt signal off. The way I see it all other commands generating Interrupt will send quick impulse and do not require manual intervention. That of course assumes 86Box is a good FDC implementation. Ill look at mame code next to confirm.
Edit: found it https://github.com/mamedev/mame/blob/ef8ac6ee … pd765.cpp#L1512
looks very similar, same logic, Sense command will clear interrupt.
Btw this file shows some debug options like LOG_COMMAND LOG_TCIRQ but no idea how or where to invoke this

Now I dont know if DMA transfer should end with Interrupt being held high until manually cleared in the first place.

my guess as to the OP motherboard is one of:
-interrupt line sticking/being held high for some reason. This might prevent bios from recognizing end of consecutive command as afaik they all generate interrupt and bios waits for said interrupt to continue.
-IO command 8 *Sense interrupt status* is unsuccessfully send due to some IO corruption
-I dont know what to think about those 62ns short signals, ISA bus might be running too fast/glitching. Taking a capture at much faster rate (>50MHz) of at least iordy and DMAAEN with the fault manifesting would show if thats the case.

rasz_pl wrote on 2022-09-14, 10:29:

I mean all the other "fdc->fintr = 0" (setting interrupt signal back to 0) instances are immediately following code sending inte […]
Show full quote

mogwaay wrote on 2022-09-14, 09:21:

Quick scan at the source didn't really help me, I'm not familair enough with it, but that sounds like the same thing I'm thinking - IRQ will lower once results phase has completed and the result bytes have been read.

I mean all the other "fdc->fintr = 0" (setting interrupt signal back to 0) instances are immediately following code sending interrupt request "fdc_int(fdc, 1)". IBM PC ISA interrupts are Edge triggered, you dont need to keep the interrupt line active. Looking at that code above *Sense interrupt status* command is the only direct way of forcing FDC to explicitly turn Interrupt signal off. The way I see it all other commands generating Interrupt will send quick impulse and do not require manual intervention. That of course assumes 86Box is a good FDC implementation. Ill look at mame code next to confirm.
Edit: found it https://github.com/mamedev/mame/blob/ef8ac6ee … pd765.cpp#L1512
looks very similar, same logic, Sense command will clear interrupt.
Btw this file shows some debug options like LOG_COMMAND LOG_TCIRQ but no idea how or where to invoke this

Now I dont know if DMA transfer should end with Interrupt being held high until manually cleared in the first place.

my guess as to the OP motherboard is one of:
-interrupt line sticking/being held high for some reason. This might prevent bios from recognizing end of consecutive command as afaik they all generate interrupt and bios waits for said interrupt to continue.
-IO command 8 *Sense interrupt status* is unsuccessfully send due to some IO corruption
-I dont know what to think about those 62ns short signals, ISA bus might be running too fast/glitching. Taking a capture at much faster rate (>50MHz) of at least iordy and DMAAEN with the fault manifesting would show if thats the case.

Thanks. I'm still fairly sure that for a normal read/write/verify/format command, the FDC will set the IRQ line at the end of the execution phase (once DMAC has done it's thing) and clear it once the results have been read - sense interrupt is only used to get the results from a Recalibrate or Seek (https://wiki.osdev.org/Floppy_Disk_Controller … Sense_Interrupt), no idea why that is, but FDCs are a bit of an 'evolved' not designed IC!

rasz_pl wrote on 2022-09-14, 10:29:

"-interrupt line sticking/being held high for some reason" -

Yeah this would be a problem but I think it would error out, not lock the machine, as the loops waiting for the Floppy Int flag to go high are not infinate, but should timeout

rasz_pl wrote on 2022-09-14, 10:29:

"-IO command 8 *Sense interrupt status* is unsuccessfully send due to some IO corruption"

Possible, but there isn't a seek/recalibrate at the end of a read/write/format/verify int 13 call, however I think Lee did the traces using DOS, so it might be reading the directory or something. I also can't see why this would only happen for a 2+ sector read from the floppy, but be perfectly stable on a 1 sector read...

rasz_pl wrote on 2022-09-14, 10:29:

-I dont know what to think about those 62ns short signals, ISA bus might be running too fast/glitching.

Hmm, this is interesting, does seem a bit spicy. Could it be the GC113 that is generating those IOCHRDY signals (input only on the GC101)? Looking at it's datasheet it's timing does suggest it would go low for 2 PROCCLK cylces, PROCCLK running at 32MHz for a 16Mhz CPU, so 62ns would be right. It would be for the benifit of the GC101 for lengthing the CPU cycle and not the ISA bus devices which tend to only use IOCHRDY as an output to request more time. The GC113 datasheet states that it only uses IOCHRDY to handle a page miss (not sure what that means to be honest). But maybe something else is dropping IOCHRDY? I don't think it's the FDC, a lot of the Goldstar ones don't even have it connected and it's not used on Sergey's 8-bit ISA FDC card for example (I think would need external circuitry to activate it anyway as not output by the integrated 82077 chip).

I wonder if when Lee has the energy, he could try using the very simple Debug-read-2-sectors-test, so less DOS in the way - and trace as much as he can using his LA, we could perhaps help him to identify what would be really good signals to look at? I'd be very interested in some of the following:

- CPUHRQ (GC101)
- CPUHLDA (GC101)
- DRQ2
- TC
- IOR
- IRQ6
- INTR (to CPU)
- INTA (from CPU)
- WE line to the Memory
- others I can't think of right now... 😉

mogwaay wrote on 2022-09-15, 09:35:

Thanks. I'm still fairly sure that for a normal read/write/verify/format command, the FDC will set the IRQ line at the end of th […]
Show full quote

rasz_pl wrote on 2022-09-14, 10:29:

I mean all the other "fdc->fintr = 0" (setting interrupt signal back to 0) instances are immediately following code sending inte […]
Show full quote

mogwaay wrote on 2022-09-14, 09:21:

Quick scan at the source didn't really help me, I'm not familair enough with it, but that sounds like the same thing I'm thinking - IRQ will lower once results phase has completed and the result bytes have been read.

I mean all the other "fdc->fintr = 0" (setting interrupt signal back to 0) instances are immediately following code sending interrupt request "fdc_int(fdc, 1)". IBM PC ISA interrupts are Edge triggered, you dont need to keep the interrupt line active. Looking at that code above *Sense interrupt status* command is the only direct way of forcing FDC to explicitly turn Interrupt signal off. The way I see it all other commands generating Interrupt will send quick impulse and do not require manual intervention. That of course assumes 86Box is a good FDC implementation. Ill look at mame code next to confirm.
Edit: found it https://github.com/mamedev/mame/blob/ef8ac6ee … pd765.cpp#L1512
looks very similar, same logic, Sense command will clear interrupt.
Btw this file shows some debug options like LOG_COMMAND LOG_TCIRQ but no idea how or where to invoke this

Now I dont know if DMA transfer should end with Interrupt being held high until manually cleared in the first place.

my guess as to the OP motherboard is one of:
-interrupt line sticking/being held high for some reason. This might prevent bios from recognizing end of consecutive command as afaik they all generate interrupt and bios waits for said interrupt to continue.
-IO command 8 *Sense interrupt status* is unsuccessfully send due to some IO corruption
-I dont know what to think about those 62ns short signals, ISA bus might be running too fast/glitching. Taking a capture at much faster rate (>50MHz) of at least iordy and DMAAEN with the fault manifesting would show if thats the case.

Thanks. I'm still fairly sure that for a normal read/write/verify/format command, the FDC will set the IRQ line at the end of the execution phase (once DMAC has done it's thing) and clear it once the results have been read - sense interrupt is only used to get the results from a Recalibrate or Seek (https://wiki.osdev.org/Floppy_Disk_Controller … Sense_Interrupt), no idea why that is, but FDCs are a bit of an 'evolved' not designed IC!

rasz_pl wrote on 2022-09-14, 10:29:

"-interrupt line sticking/being held high for some reason" -

Yeah this would be a problem but I think it would error out, not lock the machine, as the loops waiting for the Floppy Int flag to go high are not infinate, but should timeout

rasz_pl wrote on 2022-09-14, 10:29:

"-IO command 8 *Sense interrupt status* is unsuccessfully send due to some IO corruption"

Possible, but there isn't a seek/recalibrate at the end of a read/write/format/verify int 13 call, however I think Lee did the traces using DOS, so it might be reading the directory or something. I also can't see why this would only happen for a 2+ sector read from the floppy, but be perfectly stable on a 1 sector read...

rasz_pl wrote on 2022-09-14, 10:29:

-I dont know what to think about those 62ns short signals, ISA bus might be running too fast/glitching.

Hmm, this is interesting, does seem a bit spicy. Could it be the GC113 that is generating those IOCHRDY signals (input only on the GC101)? Looking at it's datasheet it's timing does suggest it would go low for 2 PROCCLK cylces, PROCCLK running at 32MHz for a 16Mhz CPU, so 62ns would be right. It would be for the benifit of the GC101 for lengthing the CPU cycle and not the ISA bus devices which tend to only use IOCHRDY as an output to request more time. The GC113 datasheet states that it only uses IOCHRDY to handle a page miss (not sure what that means to be honest). But maybe something else is dropping IOCHRDY? I don't think it's the FDC, a lot of the Goldstar ones don't even have it connected and it's not used on Sergey's 8-bit ISA FDC card for example (I think would need external circuitry to activate it anyway as not output by the integrated 82077 chip).

I wonder if when Lee has the energy, he could try using the very simple Debug-read-2-sectors-test, so less DOS in the way - and trace as much as he can using his LA, we could perhaps help him to identify what would be really good signals to look at? I'd be very interested in some of the following:

- CPUHRQ (GC101)
- CPUHLDA (GC101)
- DRQ2
- TC
- IOR
- IRQ6
- INTR (to CPU)
- INTA (from CPU)
- WE line to the Memory
- others I can't think of right now... 😉

I had a very busy month with work and working on a few projects with PCBWAY at the moment, once these are finished I will run what ever tests I can.

I did find this board and was thinking I could move the chips over from my board
https://www.ebay.co.uk/itm/225097880067?hash= … GoAAOSwnKhiOdkZ

perhaps I could use this to test the cpu or just make a good one out of the two.

leejsmith wrote on 2022-09-16, 09:30:

https://www.ebay.co.uk/itm/225097880067?hash= … GoAAOSwnKhiOdkZ

insane price for scrap :0

leejsmith wrote on 2022-09-16, 09:30:

I had a very busy month with work and working on a few projects with PCBWAY at the moment, once these are finished I will run wh […]
Show full quote

I had a very busy month with work and working on a few projects with PCBWAY at the moment, once these are finished I will run what ever tests I can.

I did find this board and was thinking I could move the chips over from my board
https://www.ebay.co.uk/itm/225097880067?hash= … GoAAOSwnKhiOdkZ

perhaps I could use this to test the cpu or just make a good one out of the two.

Hi Lee! Sorry rasz_pl and I have carryed on pondering this - it's a right brain teaser and I love it 😉

That's a nice looking board - based on the original G2 chips before Headland took them over GC101/2/3. Slightly different from your GC101SX[386SX compatible?]/HT102/GC113 set but might be swappable? Also, kinda the going rate for 286 motherboards in the UK at the moment... Defo could be one of the Headland chips that is bad, perhaps the GC101 in it's DMA/PIC logic so swapping that could be interesting....

Please don't worry tho, take your time, you left it in a good place and hope you don't mind us continuing to ponder this issue as it's a right weird one - 1 sector vs. 2 sector reading of floppies, not much difference so weird it would behave like this... It's also giving me a great opportunity to level-up on AT architecture as I've been very XT up till now 😀

Cheers!

Hi All 😀

I have some time this weekend to look at the 286 and I also have an acer FDD-HDD controller to try just in case it's the goldstar chipset, but It will not boot. The post code is 1A memory refresh test and so far it will not pass. Nothing has changed since I put it on the shelf so I wonder what has happened, perhaps the cmos is corrupted.
Just testing the ram as I have a retro chip tester pro so I can make sure it's ok.

It's not the CMOS I removed the chip and it didn't complain and just gave the same post code.

yay new defects 😀
was it stored in the cold? maybe thermal cycling broke marginal track/solder joint

it was in my workshop in an office building so normal temperatures. Had a quick look and all my bodge wires are still connected and it was doing this before, but not all the time just now and then.

so its an intermittent connection you havent found yet

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

so its an intermittent connection you havent found yet

before it was when I had the battery connected and it had a full charge and when I removed the battery it would post.

I think I am going to reflow all the chipset and cpu and remove and test all logic chips.

Hey Lee glad your taking another stab at it! I think reflowing the chips sounds like a very good idea and testing more of the chips around the damaged areas, good luck!