Icky - Progress

[exxos]

Keeping CS high disables the 1772.. so doesn't seem to be a bus conflict in this case, so I don't think a Ajax will help.

The only thing to try is the capacitors like on gigafile mod I did.

[Icky]

Keeping CS high disables the 1772.. so doesn't seem to be a bus conflict in this case, so I don't think a Ajax will help.

Makes sense

The only thing to try is the capacitors like on gigafile mod I did.

I did start looking at this last night could only find two 68pF capacitors. Tried them but made no difference.

[exxos]

I did start looking at this last night could only find two 68pF capacitors. Tried them but made no difference.

I think it has to be around 390pF to make any odds..

Might be better to look into the video noise issues for the time being..


EDIT:

Looked at the 1772 timings...

1772.JPG (49.74 KiB) Viewed 3614 times

So basically 150ns data is valid after CS goes high, aka 1 clock cycle. So assuming this is why the STE had the clocked buffers to stop bus conflicts on the DMA bus..

So I will most likely add those buffers on the next board just to be on the safe side. Looks like Atari kept to that convention in a lot of later machines.

Doesn't help with Icky's issue, but obviously there is a issue with these, even though it doesn't seem to be very apparent.

[exxos]

BTW - Did you try lifting DMA pin 24, and connect the socket end to 5V (this will disable CS to the hard drive)... In theory with no drive selected it should allow the floppy drive to still work then as can't be any bus conflicts as the HDD is prevented from being enabled...

Thinking about possible bus conflicts again.. Why didn't Atari just clock out HDCS in the first place

[Icky]

BTW - Did you try lifting DMA pin 24, and connect the socket end to 5V (this will disable CS to the hard drive)... In theory with no drive selected it should allow the floppy drive to still work then as can't be any bus conflicts as the HDD is prevented from being enabled...

Thinking about possible bus conflicts again.. Why didn't Atari just clock out HDCS in the first place

Didn’t get that far last night. Will take a look tonight.

Re video noise it seems to relate to the PSU being used. Trying different ones creates differing types of noise.

[exxos]

Re video noise it seems to relate to the PSU being used. Trying different ones creates differing types of noise.

Probably stray RF being picked up on the RGB drivers.. so not surprising.

[Icky]

BTW - Did you try lifting DMA pin 24, and connect the socket end to 5V (this will disable CS to the hard drive)... In theory with no drive selected it should allow the floppy drive to still work then as can't be any bus conflicts as the HDD is prevented from being enabled...

Thinking about possible bus conflicts again.. Why didn't Atari just clock out HDCS in the first place

Didn’t get that far last night. Will take a look tonight.

Re video noise it seems to relate to the PSU being used. Trying different ones creates differing types of noise.

Lifted pin 24 on DMA and tied to 5V.

With HDD connected the Floppy was seen.

[exxos]

Lifted pin 24 on DMA and tied to 5V.

With HDD connected the Floppy was seen.

That is interesting as doing the reverse by disabling the floppy didn't make the hard drive work..

Can you put the pin back, and see if you can see pin 24 & 22 both go low at the same time at any point ? Might be tricky to capture both, probably a trigger on pin 24 might be best.. TOS may only pulse the signal once after power up... or capture a second if your scope has enough memory, then you can see exactly if either signal goes low, and zoom in to see if both going low at the same time...


EDIT:
You could also try lifting the 1772 data pins out of the socket.. see if the HDD boots then...


EDIT2:
I still think its a bus conflict.. looking at the FDCS line is driving the flipflop, so its isolating the DMA bus for a CLK8 cycle after 1772 access....
I think isolating the 1772 from the DMA based on FDCS would do the same job (and use 2 less chips)..

But of course need to know more about what is going on first.. but clearly disabling the HDD via CS is preventing the issue, and there isn't much else common other than the databus..

[Icky]

Lifted pin 24 on DMA and tied to 5V.

With HDD connected the Floppy was seen.

That is interesting as doing the reverse by disabling the floppy didn't make the hard drive work..

Can you put the pin back, and see if you can see pin 24 & 22 both go low at the same time at any point ? Might be tricky to capture both, probably a trigger on pin 24 might be best.. TOS may only pulse the signal once after power up... or capture a second if your scope has enough memory, then you can see exactly if either signal goes low, and zoom in to see if both going low at the same time...

Yes its tricky am not currently seeing them go low at the same point - I could be missing it though.

EDIT:
You could also try lifting the 1772 data pins out of the socket.. see if the HDD boots then...

My WD1772 pins are starting to get a bit weak so am going to break something if I continue messing with it. Currently don't have a spare to hand. Might have to go on a raid.

EDIT2:
I still think its a bus conflict.. looking at the FDCS line is driving the flipflop, so its isolating the DMA bus for a CLK8 cycle after 1772 access....
I think isolating the 1772 from the DMA based on FDCS would do the same job (and use 2 less chips)..

But of course need to know more about what is going on first.. but clearly disabling the HDD via CS is preventing the issue, and there isn't much else common other than the databus..

This is perplexing - just to make sure I am not going mad have tested again the megafile with an original and it sees both floppy and hdd.

[exxos]

My WD1772 pins are starting to get a bit weak so am going to break something if I continue messing with it. Currently don't have a spare to hand. Might have to go on a raid.

If you have a spare socket, you can cut the socket pins to do the same job.. I think lifting the datapins is going to be a huge clue...

If not, break the 1772 if needs be.. I will send you a replacement one... The test needs to be done...

This is perplexing - just to make sure I am not going mad have tested again the megafile with an original and it sees both floppy and hdd.

Good idea..

Though its clear there is a conflict as Atari added the DMA bus delay based on the 1772 CS line on the STE..

As Rodolphe suggested, AJAX might not suffer, BUT, the 1772 datasheet says 150ns max.. so possible some have a lower hold time and work fine on the STFM... So some of these long term DMA issues (only on STF/M that is) could be linked to what batch of 1772 is used...

Break the pins