Falcon doesn't initialize blank screen

[sdisla]

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

Steve,

Top picture via monitor connector D19 to SCART then HDMI converter. TV on HDMI.

Botton picture is over the RF box. TV CH3.

Also, I tried original monitor connector D19 adapter VGA to VGA.

Any combination produces the same results.

Thank you.

[Badwolf]

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

Now that is interesting. You should have *two* lines toggling, not just one.

BTW, In case you hadn't realised, the A numbers are out by one on the ROM from the CPU. A0 on the ROM == A1 on the CPU bus.

So according to this the actual addresses your ROM is being asked for are:-

Code: Select all

0x00000
0x00004 (because ROM A1 = CPU A2)
0x00000
0x00004

Whereas it should be 0,2,4,6.

Let's try to translate the data lines, then (you've missed D0, so I'm going to assume it's 0 for now). Unfortunately I don't agree with your readings, but you've attached the scope images, so I can read them myself (I think you're reading at the beginning of the AS assertion -- it's the value at the end that's important -- remember the ROM is responding to the request so it takes a few dozen nanoseconds).

I've assumed you've gone top left, top right, bottom left, bottom right in your picture order. Correct?

Code: Select all

D15-D1 (D0 missing)
1110 0000 0010 111- = 0xE02E (should be 602E!)
0000 0000 1110 000- = 0x00E0 (should be 0404, but with this address it should be 00E0!)
1110 0000 0010 111- = 0xE02E (should be 00E0, but with this address should be 602E)
0000 0000 1110 000- = 0x00E0 (should be 0030, but with this address should be 00E0)

So! Very interesting! It's not counting up properly, but we've *ALMOST* got the data we expect from those addresses -- D15 is wrong on the first and third read, but correct on the second and fourth, so we can't assume it's stuck, but perhaps it's shorted to D14?

Worth double checking.

Now why wouldn't it count? There are two aspects. Firstly it's counting up in fours not twos. This would happen if DSACK0 and DSACK1 on the CPU were asserting together. DSACK0 should not assert on the Falcon except during DSP access.

So I'd scope that line on the CPU if you can. Should always be high.

Basically the two DSACK lines tell the CPU how wide the bus is -- 32, 16 or 8 bits. On the Falcon (apart from the DSP) the bus is 16 bits so during the first read, DSACK1 goes low and DSACK0 stays high. This says 'you've got 16 bits', so the CPU knows to ask for address 0x2 after 0x0. If both were low, then the CPU would think it had 32 bits and ask for 0x4 next. This is close to what we're seeing.

Secondly why is it going back to 0 for the third read. That could mean the next address line up isn't working properly. A3 on the CPU (A2 on the ROM) is always low, but it should switch to high after the second read if it were following a 32 bit read.

So I think you should concentrate on the address lines. Are there any shorts (or low resistance paths) between A1, A2, A3 and any other address lines?

I would also consider ordering a replacement TOS 4.04 ROM. It's not very expensive and it would rule that out quickly.


BW

[sdisla]

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

Now that is interesting. You should have *two* lines toggling, not just one.

BTW, In case you hadn't realized, the A numbers are out by one on the ROM from the CPU. A0 on the ROM == A1 on the CPU bus.

Noted.

So according to this the actual addresses your ROM is being asked for are:-

Code: Select all

0x00000
0x00004 (because ROM A1 = CPU A2)
0x00000
0x00004

Whereas it should be 0,2,4,6.

Let's try to translate the data lines, then (you've missed D0, so I'm going to assume it's 0 for now). Unfortunately I don't agree with your readings, but you've attached the scope images, so I can read them myself (I think you're reading at the beginning of the AS assertion -- it's the value at the end that's important -- remember the ROM is responding to the request so it takes a few dozen nanoseconds).

I've assumed you've gone top left, top right, bottom left, bottom right in your picture order. Correct?

This is correct, top left, top right, bottom left, bottom right pictures order.

Code: Select all

D15-D1 (D0 missing)
1110 0000 0010 111- = 0xE02E (should be 602E!)
0000 0000 1110 000- = 0x00E0 (should be 0404, but with this address it should be 00E0!)
1110 0000 0010 111- = 0xE02E (should be 00E0, but with this address should be 602E)
0000 0000 1110 000- = 0x00E0 (should be 0030, but with this address should be 00E0)

So! Very interesting! It's not counting up properly, but we've *ALMOST* got the data we expect from those addresses -- D15 is wrong on the first and third read, but correct on the second and fourth, so we can't assume it's stuck, but perhaps it's shorted to D14?

Worth double checking.

I will check for short D14 and double check the rest of them one more time.

30-PIN connector data lines checked - D0 => D15 10K ohms on each pin with respect to ground as well as the CPU PIN all 10K ohms.

50-PIN connector address lines checked - A1 => A23 4.7K ohms on each pin with respect to ground as well as the CPU PIN all 4.7K ohms.

ROM Address lines checked - A0 => A17 4.7K ohms on each pin with respect to ground.

ROM data lines checked - D0 => D15 10K ohms on each pin with respect to ground.

Now why wouldn't it count? There are two aspects. Firstly, it's counting up in fours not twos. This would happen if DSACK0 and DSACK1 on the CPU were asserting together. DSACK0 should not assert on the Falcon except during DSP access.

So, I'd scope that line on the CPU if you can. Should always be high.
DSACK0 - High
DSACK1 - High
By pressing the reset button nothing happens on neither lines.

Probe if that DSACK0 is high, got it.

Basically the two DSACK lines tell the CPU how wide the bus is -- 32, 16 or 8 bits. On the Falcon (apart from the DSP) the bus is 16 bits so during the first read, DSACK1 goes low and DSACK0 stays high. This says 'you've got 16 bits', so the CPU knows to ask for address 0x2 after 0x0. If both were low, then the CPU would think it had 32 bits and ask for 0x4 next. This is close to what we're seeing.

Secondly why is it going back to 0 for the third read. That could mean the next address line up isn't working properly. A3 on the CPU (A2 on the ROM) is always low, but it should switch to high after the second read if it were following a 32 bit read.

So I think you should concentrate on the address lines. Are there any shorts (or low resistance paths) between A1, A2, A3 and any other address lines?

I will check for shorts (or low resistance paths) between A1, A2, A3 and other address lines.

I would also consider ordering a replacement TOS 4.04 ROM. It's not very expensive and it would rule that out quickly.

I already ordered from EXXOS and swap them getting the same results.

BW

Thank you for your time and assistance.

[mikro]

Btw, @Badwolf as I have just recently bought an oscilloscope, your analysis and reasoning are the best guide I could ever ask for! ;-)

[Badwolf]

Btw, @Badwolf as I have just recently bought an oscilloscope, your analysis and reasoning are the best guide I could ever ask for! ;-)

Thanks Mikro. I hope we can get to the bottom of it!

BW

[Badwolf]

Both DSACKs shouldn't be high.

An AS assertion is only terminate by assertion of one or both of the DSACK lines, the STERM line, the BERR line or some other more serious interruption (like RESET).

Check STERM is properly held high (not floating). It should have < 10k resistance to 5V.

An incorrect assertion of STERM would also cause a +4 byte skip on every access.

You need to remeasure with AS on the other channel.

BW

[sdisla]

Both DSACKs shouldn't be high.

An AS assertion is only terminate by assertion of one or both of the DSACK lines, the STERM line, the BERR line or some other more serious interruption (like RESET).

Check STERM is properly held high (not floating). It should have < 10k resistance to 5V.
Got it - On it.

An incorrect assertion of STERM would also cause a +4 byte skip on every access.

You need to remeasure with AS on the other channels.
@Badwolf
Can you please elaborate a little more here?
AS on other channels, are you referring to which channels?
Thank you.

BW

[Badwolf]

@sdisla:

I mean sample these lines as you did the address and data lines.

Have AS on channel one of your scope and trigger on the first negative edge after reset and then the line under investigation on the second oscilloscope channel.

You need to see the two signals side by side to be sure you're looking at the right thing at all.

BW

[sdisla]

@sdisla:

I mean sample these lines as you did the address and data lines.

Have AS on channel one of your scope and trigger on the first negative edge after reset and then the line under investigation on the second oscilloscope channel.

You need to see the two signals side by side to be sure you're looking at the right thing at all.

BW

@Badwolf

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

AS on channel CH1 & STERM CH2 after reset held high, not sure about floating (minor spikes) please see picture of oscilloscope channel.

AS on channel CH1 & BERR CH2 after reset held high, please see picture of oscilloscope channel.

Thank you.

AS STERM.jpg

STERM.jpg

AS BERR.jpg

BERR.jpg

[SteveBagley]

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