Interesting C64/6526 case

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Interesting C64/6526 case

silverdr@wfmh.org.pl
Now, we know those cases when the characters are garbled (not like garbage character but the character definitions are wrong). If not the CHAROM and not the CIA then the next goto chip is the U2 CIA. Checking the bits on its Port A is often enough to find that the lines read wrong combination, effectively preventing VIC from accessing the CHAROM. Now to the interesting case. I've got a CIA that passes all the diagnostic tests, including both ports. Moreover works all well everywhere (C64 U1, 1571) as long as it is not the U2 position in C64. There it causes the garbled characters symptom. Anyone willing to take a stab at possible explanation?

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Interesting C64/6526 case

silverdr@wfmh.org.pl

> On 2018-10-26, at 15:48, [hidden email] wrote:
>
> Now, we know those cases when the characters are garbled (not like garbage character but the character definitions are wrong). If not the CHAROM and not the CIA

s/CIA/PLA/

I meant PLA, of course...

> then the next goto chip is the U2 CIA. Checking the bits on its Port A is often enough to find that the lines read wrong combination, effectively preventing VIC from accessing the CHAROM. Now to the interesting case. I've got a CIA that passes all the diagnostic tests, including both ports. Moreover works all well everywhere (C64 U1, 1571) as long as it is not the U2 position in C64. There it causes the garbled characters symptom. Anyone willing to take a stab at possible explanation?

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Interesting C64/6526 case

Francesco Messineo
In reply to this post by silverdr@wfmh.org.pl
On Fri, Oct 26, 2018 at 3:49 PM <[hidden email]> wrote:
>
> Now, we know those cases when the characters are garbled (not like garbage character but the character definitions are wrong). If not the CHAROM and not the CIA then the next goto chip is the U2 CIA. Checking the bits on its Port A is often enough to find that the lines read wrong combination, effectively preventing VIC from accessing the CHAROM. Now to the interesting case. I've got a CIA that passes all the diagnostic tests, including both ports. Moreover works all well everywhere (C64 U1, 1571) as long as it is not the U2 position in C64. There it causes the garbled characters symptom. Anyone willing to take a stab at possible explanation?

did you try to look at the actual signals with a scope?
I've found often that a failure mode of MOS Technology/CSG chips is a
very weak pullup output capability on some output drivers. It may work
up to a reasonable logic level (2.5 - 3V) when driving few inputs or
no inputs at all, and fall down to 2V or less when driving more stiff
inputs or more inputs together.
These outputs will usually (but not always) completely fail in a few
days/weeks of use.

Frank

Reply | Threaded
Open this post in threaded view
|

Re: Interesting C64/6526 case

Groepaz
In reply to this post by silverdr@wfmh.org.pl
Am Freitag, 26. Oktober 2018, 15:52:51 CEST schrieb [hidden email]:

> > On 2018-10-26, at 15:48, [hidden email] wrote:
> >
> > Now, we know those cases when the characters are garbled (not like garbage
> > character but the character definitions are wrong). If not the CHAROM and
> > not the CIA
> s/CIA/PLA/
>
> I meant PLA, of course...
>
> > then the next goto chip is the U2 CIA. Checking the bits on its Port A is
> > often enough to find that the lines read wrong combination, effectively
> > preventing VIC from accessing the CHAROM. Now to the interesting case.
> > I've got a CIA that passes all the diagnostic tests, including both
> > ports. Moreover works all well everywhere (C64 U1, 1571) as long as it is
> > not the U2 position in C64. There it causes the garbled characters
> > symptom. Anyone willing to take a stab at possible explanation?

i'd measure if it actually manages to pull down the bank select lines

--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

On the issue of evolution, the verdict is still out on how God created the
Earth.
<George W. Bush>





Reply | Threaded
Open this post in threaded view
|

Re: Interesting C64/6526 case

silverdr@wfmh.org.pl
In reply to this post by Francesco Messineo

> On 2018-10-26, at 15:55, Francesco Messineo <[hidden email]> wrote:
>
> On Fri, Oct 26, 2018 at 3:49 PM <[hidden email]> wrote:
>>
>> Now, we know those cases when the characters are garbled (not like garbage character but the character definitions are wrong). If not the CHAROM and not the CIA then the next goto chip is the U2 CIA. Checking the bits on its Port A is often enough to find that the lines read wrong combination, effectively preventing VIC from accessing the CHAROM. Now to the interesting case. I've got a CIA that passes all the diagnostic tests, including both ports. Moreover works all well everywhere (C64 U1, 1571) as long as it is not the U2 position in C64. There it causes the garbled characters symptom. Anyone willing to take a stab at possible explanation?
>
> did you try to look at the actual signals with a scope?

Not yet. Just quickly exchanged chips around and checked how this behaves plus ran the diagnostics. I'll probably put up a scope on it over the weekend.

> I've found often that a failure mode of MOS Technology/CSG chips is a
> very weak pullup output capability on some output drivers.

The default is "Bank 0" so I guess it might rather be driving down problem, which in fact is what AFAIR NMOS drivers are not best at.

> It may work
> up to a reasonable logic level (2.5 - 3V) when driving few inputs or
> no inputs at all, and fall down to 2V or less when driving more stiff
> inputs or more inputs together.

Those lines have to drive 1 and 2 inputs only so that would mean that those inputs are more "stiff" in some way.

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Interesting C64/6526 case

silverdr@wfmh.org.pl
In reply to this post by Groepaz

> On 2018-10-26, at 15:58, [hidden email] wrote:
>
> i'd measure if it actually manages to pull down the bank select lines

Yeah. Shall do. Just surprised because there isn't much (like many inputs) to drive on the other end(s).
--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Interesting C64/6526 case

Francesco Messineo
In reply to this post by silverdr@wfmh.org.pl
On Fri, Oct 26, 2018 at 4:13 PM <[hidden email]> wrote:
>
>
> > On 2018-10-26, at 15:55, Francesco Messineo <[hidden email]> wrote:
> >
> > On Fri, Oct 26, 2018 at 3:49 PM <[hidden email]> wrote:
> >>

>
> Those lines have to drive 1 and 2 inputs only so that would mean that those inputs are more "stiff" in some way.

well, on U1 position, usually you drive one input whenever a key is
pressed, so it works with no loads most of the time.
On the 1571, portA and portB of the 6526 are disconnected. Only the
serial port is used (2 pins).

Frank

Reply | Threaded
Open this post in threaded view
|

Re: Interesting C64/6526 case

MiaM
In reply to this post by silverdr@wfmh.org.pl
Den Fri, 26 Oct 2018 15:48:24 +0200 skrev [hidden email]:
> Now to the interesting case. I've got a CIA that passes all the
> diagnostic tests,

My impression is that in general the tests aren't that throughout and
can miss stuff.

--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

Re: Interesting C64/6526 case

Francesco Messineo
On Fri, Oct 26, 2018 at 4:23 PM Mia Magnusson <[hidden email]> wrote:
>
> Den Fri, 26 Oct 2018 15:48:24 +0200 skrev [hidden email]:
> > Now to the interesting case. I've got a CIA that passes all the
> > diagnostic tests,
>
> My impression is that in general the tests aren't that throughout and
> can miss stuff.

This is surely the case. It's a complex task to very well test a
Complex Interface Adapter ;)
I have a 6526 with probably a subtle fault in the timer part. It
passes all tests and appear to work on both U1 and U2 on the C64, but
makes the C64 solid hang when launching the LFT's "lunatico" demo from
it's Note program (works fine when launching the demo with a normal
LOAD"*",8 : RUN).
The Note program included in that demo makes use of a CIA's timer.

Frank

Reply | Threaded
Open this post in threaded view
|

Re: Interesting C64/6526 case

silverdr@wfmh.org.pl

> On 2018-10-26, at 16:33, Francesco Messineo <[hidden email]> wrote:
>
>>> Now to the interesting case. I've got a CIA that passes all the
>>> diagnostic tests,
>>
>> My impression is that in general the tests aren't that throughout and
>> can miss stuff.
>
> This is surely the case. It's a complex task to very well test a
> Complex Interface Adapter ;)

True. Just here those are simply port bits. I'd need to check if there is a way to test those both directions. Maybe it's tested only one direction. And maybe there is no easy way to test it both directions. But if there is, and it's not tested that way then this is another point to add to my list of things to improve in the test cart's software I use.

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Interesting C64/6526 case

Francesco Messineo
On Fri, Oct 26, 2018 at 4:48 PM <[hidden email]> wrote:

>
>
> > On 2018-10-26, at 16:33, Francesco Messineo <[hidden email]> wrote:
> >
> >>> Now to the interesting case. I've got a CIA that passes all the
> >>> diagnostic tests,
> >>
> >> My impression is that in general the tests aren't that throughout and
> >> can miss stuff.
> >
> > This is surely the case. It's a complex task to very well test a
> > Complex Interface Adapter ;)
>
> True. Just here those are simply port bits. I'd need to check if there is a way to test those both directions. Maybe it's tested only one direction. And maybe there is no easy way to test it both directions. But if there is, and it's not tested that way then this is another point to add to my list of things to improve in the test cart's software I use.

if you have a way to at least loopback I/O pins to other I/O pins
(like on the user port with an external adapter for example, or
substituting a loopback connector in place of the keyboard connector)
then you can test the pins on both input and output functions,
however, it would require much more effort to test output current
capability and input logic thresholds, I'm sure you know what I mean.
Looping back I/O pins to other I/O pins on the same device can give
you an idea of what's surely broken and what might be working, but can
not give final results of all possible failure modes.
Frank

Reply | Threaded
Open this post in threaded view
|

Re: Interesting C64/6526 case

MiaM
In reply to this post by silverdr@wfmh.org.pl
Den Fri, 26 Oct 2018 16:47:15 +0200 skrev [hidden email]:

>
> > On 2018-10-26, at 16:33, Francesco Messineo
> > <[hidden email]> wrote:
> >
> >>> Now to the interesting case. I've got a CIA that passes all the
> >>> diagnostic tests,
> >>
> >> My impression is that in general the tests aren't that throughout
> >> and can miss stuff.
> >
> > This is surely the case. It's a complex task to very well test a
> > Complex Interface Adapter ;)
>
> True. Just here those are simply port bits. I'd need to check if
> there is a way to test those both directions. Maybe it's tested only
> one direction. And maybe there is no easy way to test it both
> directions. But if there is, and it's not tested that way then this
> is another point to add to my list of things to improve in the test
> cart's software I use.

For the CIA pins that select VIC 16k bank, you could use the VIC sprite
collision hardware to by software detect which 16k bank VIC is reading
data from.

You might be able to with some kind of super exact timing set up VIC to
use the sprite collision detection hardware to read certain parts of
memory (I.E. set it so the collision data would indicate if VIC did
read from 16k bank 0,1,2 or 3) and then time it so that the CPU flips
the CIA VIC bank pins exactly the moment before VIC actually does the
read. This might or might not be able to detect problems related to
incorrect logic levels as the transition might be a bit slower or a bit
faster. It will probably not make much difference though.

An oscilloscope on these signals would probably tell if it's worth the
effort trying to code something like this.

Btw afaik reading back an output port will actually read the pin
status, so if there is a short circuit you can afaik detect that even
with the pins in output mode.

--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.