[Video] Broken Falcon030 Motherboard

[JezC]

Was that a Naked Gun reference creeping in there @Badwolf ?

[viking272]

Was that a Naked Gun reference creeping in there @Badwolf ?

I think it started in Airplane!
Whats our vector Victor. We have clearance Clarence, roger Roger

[JezC]

Was that a Naked Gun reference creeping in there @Badwolf ?

I think it started in Airplane!
Whats our vector Victor. We have clearance Clarence, roger Roger

Ah yes, of course! Both classics...

[mikro]

Sorry if I missed something in the video but why are you obsessed with that IDE thing? I remember seeing those random characters when IDE is not connected as far as with my first Falcon 25 years ago. Never suspected it to be something not working properly.

[Badwolf]

Sorry if I missed something in the video but why are you obsessed with that IDE thing? I remember seeing those random characters when IDE is not connected as far as with my first Falcon 25 years ago. Never suspected it to be something not working properly.

Aha! That's a data point. Thanks.

I've never seen it before but I normally have an IDE device connected and, until recently, haven't had a SCSI device so have never really needed to run a hard disc driver in that state.

So it may be a simple sample selection artefact and totally normal. Which is what I basically conclude in part 4 as I decide I can't fix it.

With all other other problems on the board I did had assumed it was a symptom rather than background noise.

BW

[Cyprian]

Could this have anything to do with the fact that the IDE port in Falcon is unbuffered?

[Badwolf]

Could this have anything to do with the fact that the IDE port in Falcon is unbuffered?

I don't think so. But I'd like to know how HDDriver decides there's a drive there or not. It's just occurred to me that when there's a master installed we don't see errant slave detections. So what gives?

I'm still leaning towards this not actually being a board fault and a bit of a red herring (per Mikro), though.

BW

[GadgetUK164]

My guess is the detection is looking a specfic bit (or more than 1 bit) on the databus, where pullups mean its fake detecting a drive perhaps? Then when queried specifically obviously the data returned is going to be high (pull ups) or random - due to the fact there is no proper response on the databus at that point because there is no drive!

EDIT: For example, on the Amiga 4000 you can trick the long wait for IDE by pulling a couple of databits high or low with resistors, when it detects those 2 bits of cerrtain logic state, THEN it does the next stage of detection whereby it queries the drive in someway, and because it doesnt get the expected response to that 2nd stage "query" it then gives up and assumes no drive.

My guess is the HDD driver is not doing that 2 stage detection and just accepting the first challenge response and then going to straight to the "get the drive name" stage, regardless of the fact there's no drive there...

In theory, you could fake fix that by working out which bits its detecting and in what state, and perhaps pull those bits in the relevant direction when the drive is being asserted... (Pull up / pull down bodge, connected to drive interface CS or something? - I am not sure without hitting schematics, what signal controls the drive).