Combined VGA / Tube interface board for Atom

[dreamerxb]

Hello Dave, the AtoMMC is also broken when using *LOAD/LINK in the previous post.

It least it's consistent...

What errors do you then get if you do:
- *HELP
- *CAT
- *LOAD TEST

Does ejecting / re-inserting the SD Card fix it?

Dave

No errors and AtoMMC is the stil working. Re-inserting SD card dos not fix the problem.
It's a very weird problem, the atom has always worked with the RAMROM loader till now.

Erik

[hoglet]

No errors and AtoMMC is the stil working. Re-inserting SD card dos not fix the problem.
It's a very weird problem, the atom has always worked with the RAMROM loader till now.

Sorry, we are talking at cross purposes.

Can you get it into the broken state:

Code: Select all

<Press BREAK>
*CWD SYS
*LOAD TEST
LINK #2800

Then try some more commands, for example:

Code: Select all

*HELP
*CAT
*LOAD TEST

I want to see what errors are generated in the broke state.

It's a very weird problem, the atom has always worked with the RAMROM loader till now.

OK, so what's changed then?

Dave

[dreamerxb]

No errors and AtoMMC is the stil working. Re-inserting SD card dos not fix the problem.
It's a very weird problem, the atom has always worked with the RAMROM loader till now.

Sorry, we are talking at cross purposes.

Can you get it into the broken state:

Code: Select all

<Press BREAK>
*CWD SYS
*LOAD TEST
LINK #2800

Then try some more commands, for example:

Code: Select all

*HELP
*CAT
*LOAD TEST

I want to see what errors are generated in the broke state.

It's a very weird problem, the atom has always worked with the RAMROM loader till now.

OK, so what's changed then?

Dave

Here are the results:
The only thing what's changed was the Combined VGA/Tube interface board which was not working due to incorrect soldering on my part. But now it works and the atom has a small problem. I can imagine that maybe a component on the atom is not function proberly because I may damaged something.

[hoglet]

Here are the results:

All * commands are falling with ERROR 224 which is a nice clue.

Errors on the Atom are generated by BRK instructions, and error number is the 2 + the LSB of the address of the BRK. So ERROR 224 means a BRK instruction has been hit at address xxDE.

Now, the default OSCLI vector (for executing star commands) when AtoMMC is running is #E0DE.

So it looks like for some reason the AtoMMC ROM at #E000 has be switched out.

Could you run the following test:

Code: Select all

<Press BREAK>
PRINT &!#E0DE, &?#BFFE'
*CWD SYS
*LOAD TEST
PRINT &!#E0DE, &?#BFFE'
LINK #2800
PRINT &!#E0DE, &?#BFFE'
*HELP
PRINT &!#E0DE, &?#BFFE'

(Sorry for so much typing, but we are getting closer)

Post a screen shot of the result.

I want to see if the AtoMMC ROM at #E000 literally vanishes and is replaced by zeros, and whether this change corresponds to a change in BFFE.

Dave

[dreamerxb]

Here are the results:

All * commands are falling with ERROR 224 which is a nice clue.

Errors on the Atom are generated by BRK instructions, and error number is the 2 + the LSB of the address of the BRK. So ERROR 224 means a BRK instruction has been hit at address xxDE.

Now, the default OSCLI vector (for executing star commands) when AtoMMC is running is #E0DE.

So it looks like for some reason the AtoMMC ROM at #E000 has be switched out.

Could you run the following test:

Code: Select all

<Press BREAK>
PRINT &!#E0DE, &?#BFFE'
*CWD SYS
*LOAD TEST
PRINT &!#E0DE, &?#BFFE'
LINK #2800
PRINT &!#E0DE, &?#BFFE'
*HELP
PRINT &!#E0DE, &?#BFFE'

(Sorry for so much typing, but we are getting closer)

Post a screen shot of the result.

I want to see if the AtoMMC ROM at #E000 literally vanishes and is replaced by zeros, and whether this change corresponds to a change in BFFE.

Dave

Don't be sorry Dave I am learning a lot, here is the result of all that typing

[hoglet]

Don't be sorry Dave I am learning a lot, here is the result of all that typing

Great, that shows the #E000 ROM is changing, yet BFFE is stays at 02. Which is impossible normally!

I think the default value for BFFE on power up should be 06 not 02. Bit 2 of this value controls the OS ROM set. If it's one, the OS ROM set includes AtoMMC. If it's zero, then the OS ROM set includes DOS. The 88013600 value comes from the DOS ROM, and happens to have a zero (BRK) at E0DE, hence the error 224.

So I have a hypothesys....

I think there may be a problem with the D2 line (again) but this time on YARRB. The most likely problem is a poor joint on pin 9 of the CPLD. Or a maybe broken track between pin 9 of the CPLD and pin 31 of the 6502. Least likely (but possible) is the CPLD is damaged.

You could investigate with a multimeter, checking continuity between these two pins.

Alternatively, try running this code after power up:

Code: Select all

DO PRINT &?#BFFE;UNTIL 0

then gently pressing down on pin 9 with something plastic and see if the 02 changes to 06.

Here's a package diagram that should let you identify pin 9:
https://www.xilinx.com/support/document ... /tq144.pdf

It may be just touching pin 9 "fixes" the issue.

Dave

[dreamerxb]

So I have a hypothesys....

I think there may be a problem with the D2 line (again) but this time on YARRB. The most likely problem is a poor joint on pin 9 of the CPLD. Or a maybe broken track between pin 9 of the CPLD and pin 31 of the 6502. Least likely (but possible) is the CPLD is damaged.

You could investigate with a multimeter, checking continuity between these two pins.

Alternatively, try running this code after power up:

Code: Select all

DO PRINT &?#BFFE;UNTIL 0

then gently pressing down on pin 9 with something plastic and see if the 02 changes to 06

It may be just touching pin 9 "fixes" the issue.

Dave

I have checked with the multimeter en there is continuetie between pin 31 and pin 9. Also tried the code and pushed on pin 9. The result stays 2.
So may I conclude that the CPLD has a defect ?

Erik

[hoglet]

So may I conclude that the CPLD has a defect ?

Probably, but I don't see how the fault you had with the Combo board would have caused this.

What does the following do:

Code: Select all

PRINT &?#BFFE'
?#BFFE=6
PRINT &?#BFFE'
?#BFFE=7
PRINT &?#BFFE'

Dave

[dreamerxb]

So may I conclude that the CPLD has a defect ?

Probably, but I don't see how the fault you had with the Combo board would have caused this.

What does the following do:

Code: Select all

PRINT &?#BFFE'
?#BFFE=6
PRINT &?#BFFE'
?#BFFE=7
PRINT &?#BFFE'

Dave

[KenLowe]

Sometimes just touching the CPLD pin with a multimeter lead is enough to make the pin connect with the pad, fooling you into thinking there's a good connection there. It would be worth running the soldering iron over the CPLD pins again to make sure you've got both a good connection, and you don't have any bridges - particularly around pin 9. I guess you already know this, but use plenty of flux!

[hoglet]

OK, one last test before I give up on the CPLD:

Code: Select all

PRINT &!#E0DE,&?#BFFE'
?#BFFE=6
PRINT &!#E0DE,&?#BFFE'
?#BFFE=2
PRINT &!#E0DE,&?#BFFE'

(I'm trying to figure out if D2 is broken on reads, writes or both)

Dave

[dreamerxb]

OK, one last test before I give up on the CPLD:

Code: Select all

PRINT &!#E0DE,&?#BFFE'
?#BFFE=6
PRINT &!#E0DE,&?#BFFE'
?#BFFE=2
PRINT &!#E0DE,&?#BFFE'

(I'm trying to figure out if D2 is broken on reads, writes or both)

Dave

[KenLowe]

In the last test, you typed an incorrect number! E9DE instead of E0DE.

[dreamerxb]

In the last test, you typed an incorrect number! E9DE instead of E0DE.

[dreamerxb]

I think that’s it. Conclusion, my stupid fault, CPLD has a defect.

Thank you Dave for all your efforts to solve the problem. Also thanks to Ken. The plus is that the Combined VGA/Tube interface is working.

Erik

[hoglet]

The power-up default for BFFE is 06 (D2=1) which selects the OS ROM Set with AtoMMC (A0D8FFA2).

But it reads back as 02 (D2=0)

Writing 06 (D2=1), shouldn't have any effect, but it does, selecting the OS ROM Set with DOS (88013600)

So regardless of what's on D2, when a write happens BFFE bit 2 in the CPLD is updated to zero.

This could be a damaged CPLD, but I still think it's more likely this is a bad joint on pin 9.

So I would second Ken's suggestion to carefully reflow that pin.

Can you post a close-up / macro photo of those pins?

Dave

[dreamerxb]

The power-up default for BFFE is 06 (D2=1) which selects the OS ROM Set with AtoMMC (A0D8FFA2).

But it reads back as 02 (D2=0)

Writing 06 (D2=1), shouldn't have any effect, but it does, selecting the OS ROM Set with DOS (88013600)

So regardless of what's on D2, when a write happens BFFE bit 2 in the CPLD is updated to zero.

This could be a damaged CPLD, but I still think it's more likely this is a bad joint on pin 9.

So I would second Ken's suggestion to carefully reflow that pin.

Can you post a close-up / macro photo of those pins?

Dave

Pin 9 is de middle pin in the picture. I wil tomorow resolder some pins to rule bad connections out.

[hoglet]

The XC95288XL CPLDs are pretty expensive (£43+VAT from Mouser UK) and not much fun to replace. So fingers crossed it's not that.

If it is the CPLD, you could try running a patch wire from D2 to a currently unused CPLD pin, and then reprogram the CPLD with a new pinout. That might actually be pretty straightforward.

Edit: Or if you are not interested in DOS, then you could tweak the CPLD to just ignore D2 (i.e. BFFE bit 2 would appear to be fixed at '1').

Dave