Thanks for the help so far

Thanks for the help so far

Post by Christian » Tue, 10 Feb 2009 18:49:53



All of you, thanks so far. I won't be working on my little problem for the
next couple of days but I'll get back asap.

I have a suspicion that one of the transistors on the adaptor has a bad
soldering - it's not quite in place. But more about that later...
 
 
 

Thanks for the help so far

Post by Wolfgang M » Tue, 10 Feb 2009 20:46:54

Hi Christian,

Christian R. Larsen schrieb:



many thanks, I always appreciate feedback much
being it positive or negative.


You may want to have a talk with NKC electronics
first. You may lose warranty, if you try to
repair it on your own (assuming that the adaptor
really is defective).


Womo

 
 
 

Thanks for the help so far

Post by Joe Forste » Wed, 11 Feb 2009 04:29:42

Womo, this should be a lesson for us. We need to advertize XCDetect
and XCTest more agressively, with stress on when to use which (first
XCDetect, then XCTest), along with a guide about _interpreting_
unexpected results (XCDetect doesn't find the drive or XCTest tests
fail). Let's talk about it in E-mail.
 
 
 

Thanks for the help so far

Post by Christian » Wed, 11 Feb 2009 20:26:57


I agree. XCDetect needs documentation about what is unexpected results.

It took me quite a few read-throughs to understand the point of chapter 3 in
the XCtest doc.
 
 
 

Thanks for the help so far

Post by Joe Forste » Thu, 12 Feb 2009 04:53:29

> It took me quite a few read-throughs to understand the point of chapter 3 in

Good. Then you can help us. ;-)
 
 
 

Thanks for the help so far

Post by Wolfgang M » Fri, 13 Feb 2009 05:59:37

Hi Christian and Joe,

Christian R. Larsen schrieb:


hmmm, I don't think so, because Christian was the
very first person being able to mostly work on his
own without stressing our support too much.

Don't you remember to some other users that
weren't able (or willing) to carefully read the
documentation of XCTest or constantly failed to
report facts (what happened actually) instead of
their own interpretations.


Well, XCDetect was not thought as a cable failure
debugging tool. I wrote it to help people to
identify the type of the cable(s), so that they
became able to configure The Star Commander
correctly.

Do you remember that I once proposed it to be
integrated into the Star Commander, so that SC
would become able to autoconfigure the cable type,
and parallel port settings? That was my initial
intention for XCDetect.

Well, nevertheless it works very well as a
checker, _that_ the cable is ok, when it is ok.


Yes please, maybe we find some potential for
improvements nevertheless ;-)


Hmmm, as I explained above, we might document,
what would be expected results. So what is the
expected printout, if the cable is working fine.

Any thing else then would be unexpected behavior.
Please understand that XCDetect is not able to
give hints on what's wrong, when such unexpected
behavior happens. This would require massive
extensions and detection heuristics.


Which point?


Womo
 
 
 

Thanks for the help so far

Post by Joe Forste » Fri, 13 Feb 2009 07:41:57

> > I agree. XCDetect needs documentation about what is unexpected results.

Errr, I might have mixed up this one, too: _XCTest_ may benefit from
such an expanded documentation.
 
 
 

Thanks for the help so far

Post by Christian » Fri, 13 Feb 2009 20:40:21


Basically, I had a hard time understanding the point of the first two test
groups and I'm in fact still not sure I tested everything in the way I was
supposed to, though your answers suggest I got it right to a large degree.

Besides, it's pretty hard to read from the document how to interpret the
test results the tests described under group 1 and 2 produce.

Group 3 makes more sense since it states that if any of the first four tests
fail, then something's wrong.

A nice feature in the software or documentation would be moving it besides
the point of stating that "something" is wrong and into a more trouble
solving oriented mode. In my case, certain conclucions are more likely than
others.

By the way - The helpful people at NKC electronics promised to send me a new
adaptor free of charge so I hoping to get things working soon.
 
 
 

Thanks for the help so far

Post by Wolfgang M » Sat, 14 Feb 2009 05:04:00

i Christian,

Christian R. Larsen schrieb:

I fear this is intentional. The tool XCTest should
mainly help us, Joe, Nicolas, me and some other cable
experienced people to give support advice to users
like you.

It is incredibly important does not get biased either
by the tool itself or its documentation. At least it
is my intention that the documentation does not tell
too much about how to inteprete the results.

As a supporter I need to know about unbiased facts:
if the cable configuration is set to a), the output
configuration is set to b) and then signal c) is set
to level d), what does which input line do then?

Otherwise many people would tend to tell me
something about "the test with 'toggling the lines'
does not show the expected behavior". I then would
have to ask: "which test exactly, there are several
one that toggle a line", "what is the exact behavior
shown" and so on.


Often you need a deep understanding of the concrete
construction of each of the X cables, a very deep
understanding of the input and output circuitry of
the 1541 disk drive and its exact behavior on
certain signal state changes and a fairly deep
understanding about general TTL/CMOS driver
technologies, namely Open-Collector/Open-Drain vs.
Totem-Pole output circuitry to get a feeling about
potential compatibility issues between certain LPT
port hardware implementations and the X cable used.

While with one cable type some shown misbehavior
may be problematic, with another cable type it may
not (as long as this assumption is supported by
some of the other test groups).


Yeah, but especially the tests of group 3 wouldn't
have helped Joe or me to identity that your cable
has got a problem with the CLOCK line. This
assumption could only be made by combining the
results from test group 3 (and knowing about the
inner workings of the 1541) with the ones from
groups 1 and 2.

Take note also, that the results from group 2
_may_ be different on certain LPT hardware
implementations. At least I can think of
constellations, where the input values do not
follow their output settings. If this is the
same for all lines then it might be no problem,
if other test results support this assumption.


Of course I understand your point. You would
like to see a machine that is able to tell
you what to do to fix your problem. I'm very
sorry that I don't feel able to program such
a "master tool". I won't say that it would
be impossible, but for sure it would be a
lot of work.

And then take into account that I never
experienced any two support tasks that ended
with the same bug resolution. With one
exception: In the last 3 years many people
suffered from incompatibilities of their
LPT port hardware with the XM1541 and XE1541
cable and had to replace it with the XA1541.

To get an impression about _how_ different
our support task may end, have a look here:

http://wiki.trikaliotis.net/bin/view/OpenCBM/OpenCbmAcknowledgedCableIncompatibilities

There I document acknowledged
incompatibilities between mainboard types
and cable types. Mainly it was intended for
XA1541 incompatibilities, but I'm using it
now for all cables that are supported by
OpenCBM.



Please don't forget to report here, when
you got some positive result from the
replacement. You will be added to the
documentation page above ;-)


Womo