XA1541 trouble
Christian R. Larsen
I bougt a XA1541 - the adaptor version which can be seen here:
http://www.nkcelectronics.com/commodore-xa1541-ada1541.html
I'm using a 1541 II-drive which is in perfect condition as I tried it with
my C64 a few days ago.
I started out trying to make it work under Windows XP but decided to move to
DOS in order to remove the OS-issues from the equation. However, I still
haven't made it work with either of my desktop PC's.
The first PC I tried it woth is a Dell XPS4. The parallel port supports
different modes:
AT
PS/2
EPP
ECP.
Furthermore, you can set the LPT1-port to various adresses for each mode,
typically 0x278-0x27f and 0x378-0x37f (default). I tried all these settings
without any luck
Secondly, I tried it on an older machine equipped with an ASUS a7a-266E
mainboard. This allows the following LPT-port modes:
Normal
ECP
EPP
ECP+EPP
Besides, you can set the DMA channel if you choose ECP or ECP+EPP-mode and
you can choose between two addresses 278H/IRQ5 and 378H/IRQ7.
I was hoping to make it running Star Commander under DOS but it never got in
touch with the disk drive. It shifted between shoing time out and drive not
found. The drive is reacting on Star Commander as you can hear the engine
running once in a while when appropriate.
Then I decided to test things with XCDETECT 0.18.
It does find the XA1541 adaptor as connected to the LPT port.
It does calculate a delayoffset (5 on the Dell and 12 on the older Asus-pc)
When it gets to searching for IEC floppy drives, it comes out with the
following statement on both machines:
Searching for IEC floppy devices ...
Floppy devices connected to port 0x378: 8<NC:0x80> 9<NC:0x83> 10<NC:0x80>
11<NC:0x83>
It does seem like it detects something on 8 and 10 since the error codes
differs.
Any ideas on how to move forward on this issue?
Joe Forster/STA
Christian R. Larsen
news:47fd3277-419a-45a8...@a12g2000pro.googlegroups.com...
Do I need any additional hardware in order to test the adaptor?
Wolfgang Moser
I am very sorry to hear that the XA type is not
working for you. Let me make some general
recommendations before doing some deeper analysis.
Christian R. Larsen schrieb:
> I bougt a XA1541 - the adaptor version which can be seen here:
> http://www.nkcelectronics.com/commodore-xa1541-ada1541.html
This _should_ be fine, in the past years there
were numerous people that bought stuff from NKC.
Some had difficulties with XE or XM cables, but
got a XA replacement from NKC and things were
fine.
> I'm using a 1541 II-drive which is in perfect condition as I tried it
> with my C64 a few days ago.
Please verify this more thoroughly, do some
longer load, maybe with using a software speed
loader.
Please tell me, which ID is your floppy drive
configured to?
> The first PC I tried it woth is a Dell XPS4. The parallel port
> supports different modes: AT PS/2 EPP ECP.
>
> Furthermore, you can set the LPT1-port to various adresses for each
> mode, typically 0x278-0x27f and 0x378-0x37f (default). I tried all
> these settings without any luck
>
> Secondly, I tried it on an older machine equipped with an ASUS
> a7a-266E mainboard. This allows the following LPT-port modes: Normal
> ECP EPP ECP+EPP
>
> Besides, you can set the DMA channel if you choose ECP or
> ECP+EPP-mode and you can choose between two addresses 278H/IRQ5 and
> 378H/IRQ7.
For any of the modern cable types, namely the
XE1541, XM1541 and XA1541 I recommend the
following BIOS parallel port type setting:
type: ECP+EPP
port: 0x0378
IRQ: 7
DMA: 3
> Then I decided to test things with XCDETECT 0.18.
Of course, XCDetect running under plain old DOS
is the best choice to debug any cable/drive
related issues. Well done.
> It does find the XA1541 adaptor as connected to the LPT port.
>
> It does calculate a delayoffset (5 on the Dell and 12 on the older
> Asus-pc)
>
> When it gets to searching for IEC floppy drives, it comes out with
> the following statement on both machines:
>
> Searching for IEC floppy devices ... Floppy devices connected to port
> 0x378: 8<NC:0x80> 9<NC:0x83> 10<NC:0x80> 11<NC:0x83>
>
> It does seem like it detects something on 8 and 10 since the error
> codes differs.
Hmmmmm, that doesn't tell me anything. When an
IEC device is detected for a certain device ID,
then the Status should be 0x00. The ones above
are both wrong.
Code 0x80 means that there is no device present.
Code 0x03 means some sort of input timeout, but
I'm not sure, if this is the case above.
> Any ideas on how to move forward on this issue?
a) Please enable debugging mode for XCDetect
and put a verbatim copy of all of its output
over here. You might want to use output
redirection to create such a report:
xcdetect -d > xa_detect.log
b) Get Joe's manual cable debugging utility
XCTest from:
http://sta.c64.org/scextprg.html
Carefully read the manual and the described
test scenarios. Configure the utility upon
the description in section 2 then move on
and systematically work yourself through
chapter 3.
This way we may be able to identify one
single line of the cable or the adapter that
may not work with your setup.
You may want to verify your cable with the tests
described above (a) and b)) with both your
mainboards. Currently it is somewhat unclear to
me, which mainboard you used for the XCDetect
test.
Womo
Wolfgang Moser
Christian R. Larsen schrieb:
the more basic tests described in section 3 don't
need additional equipment beside your PC running
under plain old DOS, the XA adapter, an IEC bus
cable and an IEC device.
The test description will tell you, if the adaptor,
the cable and/or the drive should be connected to
the PC's parallel port, switched on or off.
The more advanced tests of section 4 additionally
require a multimeter, so that you can measure out
voltage levels for the different parallel port
lines.
Womo
Wolfgang Moser
did you make some progress with the
recommendations from Joe and me?
Womo
Christian R. Larsen
OK - thanks. I moved on with XCtest and here's what I got.
The situation: I'm on the newer Dell PC (newer dual core machine).
I actually tried different settings with the LPT-port but finally
ended up recognizing that XCtest detects it as ECP no matter what I
set it to.
When using LPTdetect, the port is detected as ECP but the ECP-mode is
detected as follows in LPT-detect:
AT-mode in BIOS detected as byte-mode
ECP-mode in BIOS detected as ECP-mode
EPP-mode in BIOS detected as EPP-mode
Back to XCtest:
I ran through the various tests specified in the XCtest manual chapter
3. These were all run in ECP-mode and EPP-mode with the same result.
Test 1:
The adaptor is removed, nothing connected to the parallel port.
When altering the four outputs, the inputs still remain the same.
I tried letting it detect port modes - for some reason, it detects a
X1541 cable and sets this option. Then, when running the same tests as
before, all input lines change as they should.
Test 2:
Only the adaptor in place - no cable connected.
All four outputs set to low one at a time - all other outputs are kept
at high. Atn, Data and Reset inputs all change mode following their
corresponding outputs. Clock doesn't - Clock's always high.
Test 3:
The adaptor in place, the cable connected, the drive switched on.
Drive-Loop test:
All four outputs set to low one at a time - all other outputs are kept
at high.
Failed. Atn and Data change mode following their corresponding
outputs. Clock input doesn't change and when altering the Reset
output, both Clock, Data and Reset inputs shifts state.
Drive-Reset test:
Passed.
Drive-Detect:
Failed. Set clock to low, alter Atn - data and Atn should both change
state following Atn output. However, only Atn output changes state.
Data input remains high.
Drive-detect-inv:
Failed. Only Atn changes state, Data remains high.
Drive-Detect-Combo:
Failed due to the same lack of ability to make Data react as described
above.
Drive-Detect-Jitter:
Seems to work though Data doesn't react every time it should.
Then I tried XCDETECT 0.18:
LPT1 at 0x378, ECP
Preinitialised port 0x378 for XA1541 (signal inversion detected for
ATN)
let bus devices calm down after possible bus resets
Searching for cables (DelayOffeset: 5)...
(can only be found, if IEC devices are connected and switched on)
Testing for cable: XA1541
XA1541 connected to port address 0x378
Searching for IEC floppy devices:
Floppy devices connected to port 0x378: 8<NC:0x83> 9<NC:0x83> 10<NC:
0x83> 11<NC:0x83>
Christian R. Larsen
> Hello Christian,
>
> I am very sorry to hear that the XA type is not
> working for you. Let me make some general
> recommendations before doing some deeper analysis.
>
> Christian R. Larsen schrieb:
>
> > I bougt a XA1541 - the adaptor version which can be seen here:
> >http://www.nkcelectronics.com/commodore-xa1541-ada1541.html
>
> This _should_ be fine, in the past years there
> were numerous people that bought stuff from NKC.
> Some had difficulties with XE or XM cables, but
> got a XA replacement from NKC and things were
> fine.
>
> > I'm using a 1541 II-drive which is in perfect condition as I tried it
> > with my C64 a few days ago.
>
> Please verify this more thoroughly, do some
> longer load, maybe with using a software speed
> loader.
It behaves as it did when I used it back then. It loads anything I
tell it to. I used it extensively for the previous two weeks. I don't
know if this is sufficient.
> Please tell me, which ID is your floppy drive
> configured to?
As far as I know 8. I never changed it. Does this seem likely?
There are two dipswitches on the back. Both are in the high position
if this tells you anything.
> For any of the modern cable types, namely the
> XE1541, XM1541 and XA1541 I recommend the
> following BIOS parallel port type setting:
>
> type: ECP+EPP
> port: 0x0378
> IRQ: 7
> DMA: 3
I'm not able to set DMA-channel when using selecting those modes.
> Code 0x80 means that there is no device present.
> Code 0x03 means some sort of input timeout, but
> I'm not sure, if this is the case above.
Ok interesting.
> You may want to verify your cable with the tests
> described above (a) and b)) with both your
> mainboards. Currently it is somewhat unclear to
> me, which mainboard you used for the XCDetect
> test.
Both.
Joe Forster/STA
> ended up recognizing that XCtest detects it as ECP no matter what I
> set it to.
>
> When using LPTdetect, the port is detected as ECP but the ECP-mode is
> detected as follows in LPT-detect:
> AT-mode in BIOS detected as byte-mode
> ECP-mode in BIOS detected as ECP-mode
> EPP-mode in BIOS detected as EPP-mode
This might be caused by LPTDetect using (the C port of) an older _and_
modified version of Star Commander's parallel port access routines
while XCTest is using the latest one without modifications. I think
Womo spent his time with expanding them with a query of the current
submode of the ECP port while I never bothered. ;-)
> I tried letting it detect port modes - for some reason, it detects a
> X1541 cable and sets this option.
XCTest doesn't detect the cable type, you need to set it manually.
(That's the point of the software, complete control: you select what
you want and see if the reaction of the setup - PC, cable and drive -
is correct.)
The results of tests 2 and 3 seem obvious to me: the Clock line is not
working correctly. Continue with the multimeter testing and see where
the Clock line is cut or short-circuited.
Wolfgang Moser
Joe Forster/STA schrieb:
>> I actually tried different settings with the LPT-port but finally
>> ended up recognizing that XCtest detects it as ECP no matter what I
>> set it to.
>>
>> When using LPTdetect, the port is detected as ECP but the ECP-mode is
>> detected as follows in LPT-detect:
>> AT-mode in BIOS detected as byte-mode
>> ECP-mode in BIOS detected as ECP-mode
>> EPP-mode in BIOS detected as EPP-mode
>
> This might be caused by LPTDetect using (the C port of) an older _and_
> modified version of Star Commander's parallel port access routines
> while XCTest is using the latest one without modifications. I think
> Womo spent his time with expanding them with a query of the current
> submode of the ECP port while I never bothered. ;-)
well, LPTDetect was always developed on its own.
But for XCDetect I'm in fact relying on some
older Star Commander detection routines.
The detection result above tells us, that the
BIOS does not configure different LPT ports
hardware wise (e.g. LPT or Super-I/O chipsets
from Winbond do support this), but it just
preinitializes the ECP mode. Therefore the
selected LPT hardware implementation is always
ECP, but the ECP submode is configured to
different types.
>> I tried letting it detect port modes - for some reason, it detects a
>> X1541 cable and sets this option.
>
> XCTest doesn't detect the cable type, you need to set it manually.
> (That's the point of the software, complete control: you select what
> you want and see if the reaction of the setup - PC, cable and drive -
> is correct.)
And, additionally, cable types can only be
detected automatically, when an IEC bus device
is connected and switched to on. At least the
reliability of the detection is improved a lot.
> The results of tests 2 and 3 seem obvious to me: the Clock line is not
> working correctly. Continue with the multimeter testing and see where
> the Clock line is cut or short-circuited.
I would say that the output trace of the CLOCK
line is not working correctly. This includes
pin 14 of the DB-25 connector, the resistor
and the transistor following this track.
Either your LPT port is not able to drive pin
14 as expected or there is some sort of cold
soldering point for the resistor or transistor.
Have a look here (take note: This is my version
of a XA1541 schematic, not NKC ones):
http://d81.de/R.I.P/png/XAP1541V2-sch.png
I was talking about the line O_CLOCK above.
Womo
Wolfgang Moser
beside the comments given to Joe's post I
would like to give some detailed side info
to your nice analysis report.
Christian R. Larsen schrieb:
> The situation: I'm on the newer Dell PC (newer dual core machine).
Ok.
> I ran through the various tests specified in the XCtest manual chapter
> 3. These were all run in ECP-mode and EPP-mode with the same result.
>
> Test 1:
> The adaptor is removed, nothing connected to the parallel port.
> When altering the four outputs, the inputs still remain the same.
Ok, this is because no drive is connected
and switched to on. Are the lines detected
as constant high or as constant low?
> I tried letting it detect port modes - for some reason, it detects a
> X1541 cable and sets this option. Then, when running the same tests as
> before, all input lines change as they should.
Cable autodetection does only work reliably,
when a) a cable or adaptor is plugged into
the LPT port b) the cable is not defective
and c) when a drive is connected and
switched to on.
The behavior of the test is correct, when a
X1541 is configured as the documentation
tells.
> Test 2:
> Only the adaptor in place - no cable connected.
> All four outputs set to low one at a time - all other outputs are kept
> at high. Atn, Data and Reset inputs all change mode following their
> corresponding outputs. Clock doesn't - Clock's always high.
Hmmmm, you did configure the cable type to
XA1541 before, right?
Currently I see two possibilities. Either
the input line is not working or not
connected correctly. Or the output part of
the XA1541 cable has got a malfunction.
> Test 3:
> The adaptor in place, the cable connected, the drive switched on.
>
> Drive-Loop test:
> All four outputs set to low one at a time - all other outputs are kept
> at high.
> Failed. Atn and Data change mode following their corresponding
> outputs. Clock input doesn't change
Ok, this reflects the result from Test 2,
either the input line doesn't work, or it is
the output line not beign able to create a
low level at all.
> and when altering the Reset
> output, both Clock, Data and Reset inputs shifts state.
This reporting belongs to the next test!
> Drive-Reset test:
> Passed.
This is, what you said above. When the drive
is put into reset by setting the RESET line
to low, then the drive pulls CLOCK and DATA
line to low on its own.
The fact that we can see the CLOCK line
going low tells us that the input part of
the XA1541's CLOCK line is working fine. So
it must be the output part of the CLOCK line
that we should look further.
> Drive-Detect:
> Failed. Set clock to low, alter Atn - data and Atn should both change
> state following Atn output. However, only Atn output changes state.
> Data input remains high.
This is another indication for the CLOCK
output line not working as expected. The
drive doesn't "see" the CLOCK toggling and
therefore the EXOR gate is not triggered and
therefore the DATA line toggling is not
done.
> Drive-detect-inv:
> Failed. Only Atn changes state, Data remains high.
Same as above.
> Drive-Detect-Combo:
> Failed due to the same lack of ability to make Data react as described
> above.
Yep, same as above.
> Drive-Detect-Jitter:
> Seems to work though Data doesn't react every time it should.
That's right and the reason, why the keyboard
repeat rate should be set to maximum.
> Then I tried XCDETECT 0.18:
I'm omitting this report, because the results
above clearly tell that either your LPT port
or the XA1541 adaptor itself does not behave
as it should.
If you own a multimeter (a simple logic
tester _could_ work also), then please make
some checks for the CLOCK output trace, see
my XA1541 schematic [1]:
1. Connect the black cable of the
multimeter with GND, e.g. pin 18 of
the LPT port.
2. Test (using the red cable) pin 14 of
your LPT port with the XA1541 not
connected. Toggle the CLOCK line with
the XCTest utility and check that you
can see both voltage levels, a high
(2.8V...5V) as well as a low
(0V...0.8V).
3. Connect the XA1541 cable and do the
same test at pin 14, but "behind" the
XA1541's DB-25 connector.
4. Follow the trace of the CLOCK output
line beginning at pin 14 up to the
small SMD resistor. You should see the
line toggling at both side, before and
after the resistor.
5. Follow the trace from the resistor to
the small transistor. You should end
up at the left lead. Again check that
you can see both logic levels here,
when you toggle the CLOCK output line
with the help of XCTest.
6. Check the transistors output line which
is the middle lead at its opposite. Here
the logic levels should be inverted. It
may be that you need to connect an IEC
device first and switch it to on, so
that you can see a full high level.
7. Finally follow the trace from the
transistors output up to the IEC
connector and check that the line
toggling correctly ends up on the IEC
bus.
Womo
Joe Forster/STA
> But for XCDetect I'm in fact relying on some
> older Star Commander detection routines.
Whoops, sorry then, I mixed up the two. <:-)
Christian R. Larsen
news:498bed64$0$90267$1472...@news.sunsite.dk...
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...
Wolfgang Moser
Christian R. Larsen schrieb:
> "Christian R. Larsen" <crla...@hotmail.com> wrote in message
> news:498bed64$0$90267$1472...@news.sunsite.dk...
>
> 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.
many thanks, I always appreciate feedback much
being it positive or negative.
> 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...
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
Joe Forster/STA
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.
Christian R. Larsen
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.
Joe Forster/STA
> the XCtest doc.
Good. Then you can help us. ;-)
Wolfgang Moser
Christian R. Larsen schrieb:
> "Joe Forster/STA" <s...@c64.org> wrote:
>
>> 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),
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.
>> along with a guide about _interpreting_
>> unexpected results (XCDetect doesn't find the drive or XCTest tests
>> fail).
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.
>> Let's talk about it in E-mail.
Yes please, maybe we find some potential for
improvements nevertheless ;-)
> I agree. XCDetect needs documentation about what is unexpected results.
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.
> It took me quite a few read-throughs to understand the point of chapter 3 in
> the XCtest doc.
Which point?
Womo
Joe Forster/STA
Errr, I might have mixed up this one, too: _XCTest_ may benefit from
such an expanded documentation.
Christian R. Larsen
news:gmve7p$m4a$1...@vs5413.trikaliotis.net...
>> It took me quite a few read-throughs to understand the point of chapter 3
>> in the XCtest doc.
>
> Which point?
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øm hoping to get things working soon.
Wolfgang Moser
Christian R. Larsen schrieb:
> "Wolfgang Moser" wrote:
>
>>> It took me quite a few read-throughs to understand the point of chapter 3
>>> in the XCtest doc.
>> Which point?
>
> 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.
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).
> Group 3 makes more sense since it states that if any of the first four tests
> fail, then something's wrong.
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.
> 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.
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.
> By the way - The helpful people at NKC electronics promised to send me a new
> adaptor free of charge so Iøm hoping to get things working soon.
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
Christian R. Larsen
I haven't got my new adapter yet but yesterday I got impatient and decided
to use a little 'violence' on the misplaced transistor that has caused my
XA1541 not to work. I simply moved it slightly so that it's now on place.
That did the trick.
Wolfgang Moser
Christian R. Larsen schrieb:
thank you very much for your feedback. So
I can complete my support database's entry.
So what may have happened to your cable?
Either the manufacturer's testing procedures
are leaky or your adaptor was damaged on
shipping, a so named "dead on arrival".
Womo
Christian R. Larsen
My best guess is that it wasn't tested thoroughly enough. The transistor is
positioned un a place where it dosn't seem vulnerable to that sort of
damage.