Falcon doesn't initialize blank screen

[Badwolf]

BW,

ROM inserted.

CH1 probe on pin 4 "Address Strobe" of the 50-pin connector.

AS is an active low. You should see (at least) four pulses low on AS after reset. These are what you should set up your scope to capture. MAke sure these are on the screen. You are showing a flat line for AS: this is useless.

Remember, you are interested in the state of the data line(s) *whilst AS is low*.

Pressing the reset button AS pulse goes high but, no pulse activity on D1,D2,D3,D4,D5,D6,D7,D8,D9,D10,D11,D12,D13,D14,D15 low state.

This makes little sense as the data lines are pulled high when not in use.

I don't think you're capturing at the right time: the first four pulses of AS.

There is no 'correct' steady state here. You must capture the data at the right time. The first four pulses after reset goes high.

With reset held in, AS will be high. Set your trigger to capture on the falling edge of AS and then release reset. You should adjust your timebase so you can see at least four pulses. The pulses should be around 500ns each and the four pulse train should take around 3 to 5 microseconds.

BW

[SteveBagley]

The pictures in the first post are interesting since they appear to show the Falcon in two different screen modes (one has borders, the other doesn't, and also show very regular patterns. Were those two images taken with the display connected in the same fashion or did you connect the falcon differently to test? You mentioned something about connecting via RF, is one image via RF and the other VGA?

Do you always get the same pattern and image when you turn the machine on or is it random (I'm assuming its static too)? If it's always the same image (for the same connection method) with regular patterns like that, I'd be suspecting a software over a hardware problem (although I'd also expect the background to be white…)

Can you get your monitor to give info on the refresh rate of the video signal being generated for each image? The reason I ask is my Falcon would never escape NTSC (60Hz/15kHd) modes when I managed to cause the boot process to fail early on, so if it does get to a VGA resolution then some code must be running I'd have thought…

Steve

[sdisla]

BW,

ROM inserted.

CH1 probe on pin 4 "Address Strobe" of the 50-pin connector.

AS is an active low. You should see (at least) four pulses low on AS after reset. These are what you should set up your scope to capture. MAke sure these are on the screen. You are showing a flat line for AS: this is useless.

Remember, you are interested in the state of the data line(s) *whilst AS is low*.

Pressing the reset button AS pulse goes high but, no pulse activity on D1,D2,D3,D4,D5,D6,D7,D8,D9,D10,D11,D12,D13,D14,D15 low state.

This makes little sense as the data lines are pulled high when not in use.

I don't think you're capturing at the right time: the first four pulses of AS.

There is no 'correct' steady state here. You must capture the data at the right time. The first four pulses after reset goes high.

With reset held in, AS will be high. Set your trigger to capture on the falling edge of AS and then release reset. You should adjust your timebase so you can see at least four pulses. The pulses should be around 500ns each and the four pulse train should take around 3 to 5 microseconds.

BW

BW,

ROM inserted:

CH1 AS
CH2 D1 D5

These are my interpretation of the readings for D5 and D1 while AS goes down.

AS D5 1111
AS D1 1110

Let me know if now the readings are ok to continue with the rest of the data lines.

Thank you,

[Badwolf]

BW,

ROM inserted:

CH1 AS
CH2 D1 D5

These are my interpretation of the readings for D5 and D1 while AS goes down.

AS D5 1111
AS D1 1110

Let me know if now the readings are ok to continue with the rest of the data lines.

Thank you,

Firstly, thank you for including the pictures of the probing, that does confirm you're on the correct pins.

I concur with your interpretation of the scope output for D5: 1111

However, to me the D1 pin reads: 1010.

These are supposed to be 1011 and 1000 respectively.

Even allowing for a different TOS version (perhaps you have 4.02), this would only change the D1 pin to 1100.

Now, I may be barking up the wrong tree, but to me that suggests that the CPU is getting the right data from the ROM. That could explain why the cartridge port is not being activated (and it should be activated only around 17 AS cycles into the boot process).

But the good news is we can see the D1 line is toggling up and down so it's unlikely to be tied high or low. You said you checked for shorts between data lines, so it's probably not that. We haven't see D5 toggle at all, but that could just be co-incidence.

Now it's possible the ROM has failed, but that seems unlikely unless it had a major overvoltage or something, so perhaps there is an addressing issue.

That would probably be the next big thing to check -- you can perform the same style of test -- sampling AS after reset and probing the address lines. This time I would probe around the ROM socket (you'll have to do this with the RAM out again, but that's fine for now).

If you go around measuring the first four accesses of each address pin from A1 to A19 you can build up the actual address that's being requested.

It should be:

Code: Select all

A19-A1
0000 0000 0000 000
0000 0000 0000 001
0000 0000 0000 010
0000 0000 0000 011

You can also do the same for the data lines, as you've just done, but build up the full 16 bit pattern on each access. It does not look like it's going to be what we documented before, however:

Code: Select all

D15----D0
0110 0000 0010 1110
0000 0100 0000 0100
0000 0000 1110 0000
0000 0000 0011 0000

In the meantime, though, I would suggest you try something really simple to rule out an easy thing (bus conflict): simply leave the probes as you have them now and repeat the experiment for D1 and D5, but with the ROM removed. Without the ROM those first four accesses should all be HIGH as the databus defaults to high when there is nothing driving it (you can see the voltage ramp up in your pictures when AS is deactivated).

It seems you've found the first actual fault. Well done. You now need to track down where it's coming from.

Good luck.

BW

[sdisla]

BW,

ROM inserted:

CH1 AS
CH2 D1 D5

These are my interpretation of the readings for D5 and D1 while AS goes down.

AS D5 1111
AS D1 1110

Let me know if now the readings are ok to continue with the rest of the data lines.

Thank you,

Firstly, thank you for including the pictures of the probing, that does confirm you're on the correct pins.

I concur with your interpretation of the scope output for D5: 1111

However, to me the D1 pin reads: 1010.

These are supposed to be 1011 and 1000 respectively.

Even allowing for a different TOS version (perhaps you have 4.02), this would only change the D1 pin to 1100.

Now, I may be barking up the wrong tree, but to me that suggests that the CPU is getting the right data from the ROM. That could explain why the cartridge port is not being activated (and it should be activated only around 17 AS cycles into the boot process).

But the good news is we can see the D1 line is toggling up and down so it's unlikely to be tied high or low. You said you checked for shorts between data lines, so it's probably not that. We haven't see D5 toggle at all, but that could just be co-incidence.

Now it's possible the ROM has failed, but that seems unlikely unless it had a major overvoltage or something, so perhaps there is an addressing issue.

That would probably be the next big thing to check -- you can perform the same style of test -- sampling AS after reset and probing the address lines. This time I would probe around the ROM socket (you'll have to do this with the RAM out again, but that's fine for now).

If you go around measuring the first four accesses of each address pin from A1 to A19 you can build up the actual address that's being requested.

It should be:

Code: Select all

A19-A1
0000 0000 0000 000
0000 0000 0000 001
0000 0000 0000 010
0000 0000 0000 011

You can also do the same for the data lines, as you've just done, but build up the full 16 bit pattern on each access. It does not look like it's going to be what we documented before, however:

Code: Select all

D15----D0
0110 0000 0010 1110
0000 0100 0000 0100
0000 0000 1110 0000
0000 0000 0011 0000

In the meantime, though, I would suggest you try something really simple to rule out an easy thing (bus conflict): simply leave the probes as you have them now and repeat the experiment for D1 and D5, but with the ROM removed. Without the ROM those first four accesses should all be HIGH as the databus defaults to high when there is nothing driving it (you can see the voltage ramp up in your pictures when AS is deactivated).

It seems you've found the first actual fault. Well done. You now need to track down where it's coming from.

Good luck.

BW

BW,

ROM removed:

AS D1 0000

AS D5 1111

You were right!

So D1 bus somehow is shorted?

I check for continuity and the multimeter is showing some resistance but not 0 ohms.

Anything else on the data lines that I need to check with respect to ground?

Thank you for your time.

[Badwolf]

BW,

ROM removed:

AS D1 0000

AS D5 1111

You were right!

So D1 bus somehow is shorted?

Hmm. I don't know. Double-check your measurements there as in the last measurements we see it toggling high/low with a typical pull-up ramp when nothing is asserting.

...or something else is on the address lines.

See the previous message about going around the address pins in turn and working out what's on them at each of those first four AS strobes.

BW

[sdisla]

BW,

ROM removed:

AS D1 0000

AS D5 1111

You were right!

So D1 bus somehow is shorted?

Hmm. I don't know. Double-check your measurements there as in the last measurements we see it toggling high/low with a typical pull-up ramp when nothing is asserting.

...or something else is on the address lines.

See the previous message about going around the address pins in turn and working out what's on them at each of those first four AS strobes.

BW

BW,

Will do.

[sdisla]

BW,

ROM removed:

AS D1 0000

AS D5 1111

You were right!

So D1 bus somehow is shorted?

Hmm. I don't know. Double-check your measurements there as in the last measurements we see it toggling high/low with a typical pull-up ramp when nothing is asserting.

...or something else is on the address lines.

See the previous message about going around the address pins in turn and working out what's on them at each of those first four AS strobes.

BW

BW,

You are correct, I overlook the setup now D1 is always high without the ROM when the reset is press.

I will procced as you instructed previously after this sanity check.

Thank you

[sdisla]

As per your comments below:

"Now, I may be barking up the wrong tree, but to me that suggests that the CPU is getting the right data from the ROM. That could explain why the cartridge port is not being activated (and it should be activated only around 17 AS cycles into the boot process)."

"But the good news is we can see the D1 line is toggling up and down so it's unlikely to be tied high or low. You said you checked for shorts between data lines, so it's probably not that. We haven't see D5 toggle at all, but that could just be co-incidence."

"Now it's possible the ROM has failed, but that seems unlikely unless it had a major overvoltage or something, so perhaps there is an addressing issue."

"That would probably be the next big thing to check -- you can perform the same style of test -- sampling AS after reset and probing the address lines. This time I would probe around the ROM socket (you'll have to do this with the RAM out again, but that's fine for now)."

"If you go around measuring the first four accesses of each address pin from A1 to A19 you can build up the actual address that's being requested.
It seems you've found the first actual fault. Well done. You now need to track down where it's coming from."

It should be:

Code: Select all

A19-A1
0000 0000 0000 000
0000 0000 0000 001
0000 0000 0000 010
0000 0000 0000 011

BW,

I did the measurements from A0 to A18 on the PROM socket.

These are the reading as per my interpretation.

A1 0101

A0 0000
A2 0000
A3 0000
A4 0000
A5 0000
A6 0000
A7 0000
A8 0000
A9 0000
A10 0000
A11 0000
A12 0000
A13 0000
A14 0000
A15 0000
A16 0000
A17 0000
A18 0000

Thank you

[sdisla]

BW,

As per your comments below:

"Now it's possible the ROM has failed, but that seems unlikely unless it had a major overvoltage or something, so perhaps there is an addressing issue."

"That would probably be the next big thing to check -- you can perform the same style of test -- sampling AS after reset and probing the address lines. This time I would probe around the ROM socket (you'll have to do this with the RAM out again, but that's fine for now)."

You can also do the same for the data lines, as you've just done, but build up the full 16 bit pattern on each access.

It does not look like it's going to be what we documented before, however:

Code: Select all

D15----D0
0110 0000 0010 1110
0000 0100 0000 0100
0000 0000 1110 0000
0000 0000 0011 0000

As per your request:

D1 1101
D2 1100
D3 1101
D4 1000
D5 0000
D6 1010
D7 1010
D8 1000
D9 1000
D10 1000
D11 1000
D12 1000
D13 1101
D14 1101
D15 1101