Falcon doesn't initialize blank screen

[sdisla]

Are you sure you getting the right pins when scoping? Some of the photos appear to be off by one (e.g. the photo you've labelled STERM above, looks like you might have the probe on DSACK1 -- unless I can't count ).

Steve

Look again... 123...

[Badwolf]

Check STERM pin on the CPU 5K ohms to GND and 4.8K ohms to 5V.

That seems strange at first glance as it would mean the voltage floating around 2.5V, but I assume the route to GND is via the CPU and that's some internal path that isn't there during operation. It measures OK.

Alright, would you mind re-doing the DSACKx tests with the new setup (ie. both AS and DSACKx on the scope)?

SOMETHING must be going low!

BW

[sdisla]

That seems strange at first glance as it would mean the voltage floating around 2.5V, but I assume the route to GND is via the CPU and that's some internal path that isn't there during operation. It measures OK.

Alright, would you mind re-doing the DSACKx tests with the new setup (ie. both AS and DSACKx on the scope)?

SOMETHING must be going low!

BW

@Badwolf

DSACK0
DSACK1

[Badwolf]

DSACK1

Well, that's better -- previously you reported DSACK1 was always low.

But I'm not enamoured with that trace. Unfortunately I don't have my Falcon on the desk else I'd be interested to see if my DSACK1 asserts for such a little time before pulling high too.

Anyway, we've established you've not got a problem with STERM or DSACK0 asserting when they oughtn't, so I think we're back to address lines and data lines.

Basically: A1 isn't counting up when it should be and A2 is counting like A1. There's also problem on the top data line, but that feels a bit secondary at the moment.

I'm not sure what more to recommend to you. You could try removing all the GALs in sockets from the front of the board (and the one up by the DSP) and probing AS/A1 again just in case one of those is pulling down the bus (but label them properly -- they need to go back in the right place!)

That's a bit of a 'well why not?' attempt, though. Just as they're socketed. I think we need to find a smoking gun on the address lines.

I know what I'd do next, but then I've got a lot of bits of half-built boards, logic analysers and bits and pieces lying around that make it easy: I'd run a wire from BGK and BR on the expansion header to ground, power on and check to see if CPUBGO is held low (one of the pins under the jumper on the expansion header) and if it were, assume the bus is quiescent and start injecting 0V onto each line and measuring the others.

BUT I don't want you to blow up your machine, so I'd just suggest you continue looking for cross-contamination between all address lines. Perhaps paying attention to the pull-up resistor packs, but that's just a guess.

Sorry, I think we may have gone beyond the ability to remotely debug now unless you stumble across a definitive short on the board.

BW

[sdisla]

Well, that's better -- previously you reported DSACK1 was always low.

But I'm not enamoured with that trace. Unfortunately I don't have my Falcon on the desk else I'd be interested to see if my DSACK1 asserts for such a little time before pulling high too.

Anyway, we've established you've not got a problem with STERM or DSACK0 asserting when they oughtn't, so I think we're back to address lines and data lines.

Basically: A1 isn't counting up when it should be and A2 is counting like A1. There's also problem on the top data line, but that feels a bit secondary at the moment.

I'm not sure what more to recommend to you. You could try removing all the GALs in sockets from the front of the board (and the one up by the DSP) and probing AS/A1 again just in case one of those is pulling down the bus (but label them properly -- they need to go back in the right place!)

That's a bit of a 'well why not?' attempt, though. Just as they're socketed. I think we need to find a smoking gun on the address lines.

I know what I'd do next, but then I've got a lot of bits of half-built boards, logic analysers and bits and pieces lying around that make it easy: I'd run a wire from BGK and BR on the expansion header to ground, power on and check to see if CPUBGO is held low (one of the pins under the jumper on the expansion header) and if it were, assume the bus is quiescent and start injecting 0V onto each line and measuring the others.

BUT I don't want you to blow up your machine, so I'd just suggest you continue looking for cross-contamination between all address lines. Perhaps paying attention to the pull-up resistor packs, but that's just a guess.

Sorry, I think we may have gone beyond the ability to remotely debug now unless you stumble across a definitive short on the board.

BW

@Badwolf

Followed your advice removing the GALs one by one.
Removing U62 the last one be removed ironically A1 is counting up.

A1 got a pulse now - 1010
A2 got a pulse too - 0110

[Badwolf]

Followed your advice removing the GALs one by one.
Removing U62 the last one be removed ironically A1 is counting up.

A1 got a pulse now - 1010
A2 got a pulse too - 0110

Oh wow! That would be incredibly lucky if it were that.

Do you get the ROM4 pulse now on the cartridge port?

BW

PS, I read that as 0101 on A1 and 0011 on A2, which would be correct.

[sdisla]

Oh wow! That would be incredibly lucky if it were that.

Do you get the ROM4 pulse now on the cartridge port?

BW

PS, I read that as 0101 on A1 and 0011 on A2, which would be correct.

@Badwolf

Probe AS with both ROM3 and ROM4 no pulse down after reset, both stay high.

Do you think the DIAGNOSTIC CARTRIDGE should work even without one of them? These are like a 4 in 1 FPGA I presume.

[Badwolf]

Probe AS with both ROM3 and ROM4 no pulse down after reset, both stay high.
Do you think the DIAGNOSTIC CARTRIDGE should work even without one of them? These are like a 4 in 1 FPGA I presume.

The pulses would only be brief about 17 cycles in. You'd need to trigger on ROM4 rather than on AS.

If ROM4 pulses there's a chance you could get the cartridge to start working, but not without it. BUT it may also need UDS & LDS, which I believe are generated by that GAL.

BW

[sdisla]

Probe AS with both ROM3 and ROM4 no pulse down after reset, both stay high.
Do you think the DIAGNOSTIC CARTRIDGE should work even without one of them? These are like a 4 in 1 FPGA I presume.

The pulses would only be brief about 17 cycles in. You'd need to trigger on ROM4 rather than on AS.

If ROM4 pulses there's a chance you could get the cartridge to start working, but not without it. BUT it may also need UDS & LDS, which I believe are generated by that GAL.

BW

@Badwolf

Besides your suggestion above do you think at this point is worth to replace them?

See below pictures, this is what I can get with my scope.
CH1 ROM4
CH2 ROM3

Also, I noticed the screen characters looks improved even is just garbage hence U62 is not plug.
Lastly, I can hear a crack noise on the speaker once the reset button is press.
Observations are all new after U62 is not in the picture.

Thank you for your assistance.

[Badwolf]

Besides your suggestion above do you think at this point is worth to replace them?

See below pictures, this is what I can get with my scope.
CH1 ROM4
CH2 ROM3

Also, I noticed the screen characters looks improved even is just garbage hence U62 is not plug.
Lastly, I can hear a crack noise on the speaker once the reset button is press.
Observations are all new after U62 is not in the picture.

Thank you for your assistance.[/b]

Well that's good (despite the terrible sample rate on your scope! I assume you sampled at long baseline then zoomed in?).

Perhaps you can get something out of the diagnositc cartridge now.

If you have a source for a replacement GAL I would say it's probably worth trying it now. You've shown code is being executed if you're able to get the ROM4 line to activate. Very good.

My only slight hesitation in blaming that GAL immediately for everything is that it's not directly connected to any address lines that I can see and I'm struggling to work out how it may be causing the problems you've seen -- perhaps it's dragging one of the SIZE lines down to zero?

Anyway, I believe the GAL equations are on dev-docs.org and it should be possbile to make a new one.

BW