Killed my ZoomFloppy...

[Benjamin Hase]

Hi,

I killed my ZoomFloppy :-( It can be accessed from USB, also controller update is possible and 'xum1541cfg devinfo' gives correct results.

But as soon as I try to access the bus, everything freezes and nothing works; the floppy I used before also works on a C64 without problems.

The root cause was an incorrect power sequence, I switched everything off for re-wiring, then I powered on the floppy but did not connect USB. When I recognized my mistake, I switched off the floppy, put in the USB cable and powered the floppy again - since then I cannot access the bus any more :-(

The 74LS06 is already removed to see if I get some results on the 40-pin header but it looks like the issue is in the main controller...

Best regards

Benjamin

[Benjamin Hase]

As I mentioned, I have removed the 7406, this was possibly over-hasty as it is not clear where the issue really is. Anyway it is gone now and my question is how can I check if the main controller is working correctly on the parallel and IEC side before soldering a new 7406?

Best regards

Benjamin

[RETRO Innovations]

--
You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zoomfloppy-users/48ec64ed-c76a-44ad-9e1d-433c010e91d5n%40googlegroups.com.

You should be able to watch the inputs of the '06 (with it removed) and see ATN going high (which would bring the !ATN output low, etc.

But, if you know the 7406 is good, it might make sense to replace it and then write a quick AVR test program that just exercises all of the output and inputs of the IEC bus, with an LA on the IEC bus pins. 

If you just want to put a new uC on it and call it a day, I think I have one lying around.

Jim

-- 
RETRO Innovations, Contemporary Gear for Classic Systems
www.go4retro.com
store.go4retro.com

[Spiro Trikaliotis]

Hello,

* On Mon, Nov 21, 2022 at 10:05:01AM -0600 RETRO Innovations wrote:

> You should be able to watch the inputs of the '06 (with it removed) and see ATN
> going high (which would bring the !ATN output low, etc.
>
> But, if you know the 7406 is good, it might make sense to replace it and then
> write a quick AVR test program that just exercises all of the output and inputs
> of the IEC bus, with an LA on the IEC bus pins. 

The tool cbmlinetester comes in handy as a test program.

You can use it with the optoin --interactive ("cbmlinetester --interactive").
With this option, it will start and wait for some keypressed.

a - set ATN (pull it low on the IEC bus)
A - unset ATN (high state on the IEC bus if there is a pull-up)
d - set DATA (pull it low on the IEC bus)
D - unset DATA (high state on the IEC bus if there is a pull-up)
c - set CLOCK (pull it low on the IEC bus)
C - unset CLOCK (high state on the IEC bus if there is a pull-up)
r - set RESET (pull it low on the IEC bus)
R - unset RESET (high state on the IEC bus if there is a pull-up)

s - set SRQ (pull it low on the IEC bus)
S - unset SRQ (high state on the IEC bus if there is a pull-up)

Note that with "SRQ", it might not work with older firmware versions of
the ZF because there was a bug in the logic behind it.

You can quit it with the key "x".

The tool shows the state of the output lines (that is, the wanted
state), as well as the state of the input lines; thus, you can also test
if the inputs work as expected.

You can also use the tool non-interactively; look at the output of
"cbmlinetester --help" for instructions.

Regards,
Spiro

--
Spiro R. Trikaliotis
https://spiro.trikaliotis.net/

[Benjamin Hase]

Hello Spiro,

Am 21.11.22 um 20:55 schrieb Spiro Trikaliotis:

> * On Mon, Nov 21, 2022 at 10:05:01AM -0600 RETRO Innovations wrote:
>
>> You should be able to watch the inputs of the '06 (with it removed) and see ATN
>> going high (which would bring the !ATN output low, etc.
>>
>> But, if you know the 7406 is good, it might make sense to replace it and then
>> write a quick AVR test program that just exercises all of the output and inputs
>> of the IEC bus, with an LA on the IEC bus pins.
> The tool cbmlinetester comes in handy as a test program

> [...]

> You can also use the tool non-interactively; look at the output of
> "cbmlinetester --help" for instructions.
>

Thanks for the hint and sorry for the late answer, I did not find some time until now.

I tried the cbmlinetester tool and got some suspicious behaviour; 'xum1541cfg devinfo' works as well as updating the firmware.

But when I try to access the device, it hangs:

% XUM1541_DEBUG=99 cbmlinetester -r
[XUM1541] scanning usb ...
[XUM1541] device 1d6b:0003
[XUM1541] device 138a:0017
[XUM1541] device 04ca:7058
[XUM1541] device 8087:0a2b
[XUM1541] device 058f:9540
[XUM1541] device 12d1:15c1
[XUM1541] device 16d0:0504
[XUM1541] found xu/xum1541 version 0208 on bus 1, device 20
[XUM1541] xum1541 name: xum1541 floppy adapter (ZOOMFLOPPY)
[XUM1541] xum1541 serial number: 0
[XUM1541] firmware version 8, library version 8
[XUM1541] device capabilities 1b status 02
[XUM1541] [xum1541_init] Tape supported, disk mode entered.
[XUM1541] firmware git revision is 0ca9fb9f
[XUM1541] compiled with avr-gcc version 11.2.0
[XUM1541] and using avr-libc version 2.0.0
[XUM1541] ioctl 29 for device 8, sub 0
[XUM1541] xum1541_wait_status checking for status


There it stays infinite, until cancelled or USB disconnect.
As far as I understand the code, the bulk transfer of USB IN does not return (line 806 resp. 811 in opencbm/lib/plugin/xum1541/xum1541.c).
For every possible return there should be some output.

I am still not 100% convinced but this looks like a damage to the microcontroller?

Best regards
Benjamin

[Benjamin Hase]

Hello Jim,

Am 21.11.22 um 17:05 schrieb RETRO Innovations:

On 11/21/2022 9:21 AM, Benjamin Hase wrote:

As I mentioned, I have removed the 7406, this was possibly over-hasty as it is not clear where the issue really is. Anyway it is gone now and my question is how can I check if the main controller is working correctly on the parallel and IEC side before soldering a new 7406?

Best regards

Benjamin

Benjamin Hase schrieb am Montag, 21. November 2022 um 13:34:37 UTC+1:

Hi,

I killed my ZoomFloppy :-( It can be accessed from USB, also controller update is possible and 'xum1541cfg devinfo' gives correct results.

But as soon as I try to access the bus, everything freezes and nothing works; the floppy I used before also works on a C64 without problems.

The root cause was an incorrect power sequence, I switched everything off for re-wiring, then I powered on the floppy but did not connect USB. When I recognized my mistake, I switched off the floppy, put in the USB cable and powered the floppy again - since then I cannot access the bus any more :-(

The 74LS06 is already removed to see if I get some results on the 40-pin header but it looks like the issue is in the main controller...

You should be able to watch the inputs of the '06 (with it removed) and see ATN going high (which would bring the !ATN output low, etc.

But, if you know the 7406 is good, it might make sense to replace it and then write a quick AVR test program that just exercises all of the output and inputs of the IEC bus, with an LA on the IEC bus pins. 

If you just want to put a new uC on it and call it a day, I think I have one lying around.

Jim

Things are really weird here... I replaced the controller and put in a new 74LS06, but that did not change the behavior. When I find a few minutes, I will look at in- and outputs of the 7406; does the firmware check the status if the lines are set correctly? Is it possible that some passive component (resistor) has been damaged due to unintended current flow - remember, my error was to power on the floppy (with parallel cable) without having the ZoomFloppy connected to USB :-(

As a side note, why has been chosen such a small package for resistors/capacitors? Space constraints are not the reason I would assume :-)

Best regards

Benjamin

[RETRO Innovations]

On 11/27/2022 3:26 AM, Benjamin Hase wrote:
>
>
> Things are really weird here... I replaced the controller and put in a
> new 74LS06, but that did not change the behavior. When I find a few
> minutes, I will look at in- and outputs of the 7406; does the firmware
> check the status if the lines are set correctly?
>

No, it does not (it simply assumes they are working).

>
> Is it possible that some passive component (resistor) has been damaged
> due to unintended current flow - remember, my error was to power on
> the floppy (with parallel cable) without having the ZoomFloppy
> connected to USB :-(
>

While both ports carry some current, the IEC port current is limited by
the nature of the port (open collectors with pullups), and the parallel
port is not needed for normal IEC operations.  Thus, I doubt this would
have caused the issue.  (Lots of folks do what you've done.  Not saying
it's good for the unit, but if the uC was that sensitive, I should see
more issues, and I've probably seen 5 uC failures in all the time the
item has been sold.

>
> As a side note, why has been chosen such a small package for
> resistors/capacitors? Space constraints are not the reason I would
> assume :-)
>

Part variation rationalization.  The same firm that makes sense makes
the uIEC/SD, where size is more important, and that unit came out first,
so the smaller sizes were already in stock.

Jim

[mthi...@gmail.com]

I tried the cbmlinetester tool and got some suspicious behaviour; 'xum1541cfg devinfo' works as well as updating the firmware.

But when I try to access the device, it hangs:

% XUM1541_DEBUG=99 cbmlinetester -r

[...] 

[XUM1541] xum1541_wait_status checking for status


There it stays infinite, until cancelled or USB disconnect.

Looks more like a problem on the host side. Are you really sure it worked before the incident you suspect to have "killed" the ZF?

[Benjamin Hase]

Am 29.11.22 um 19:39 schrieb mthi...@gmail.com:

This is a possibility, too - an indicator for this is that the changed microcontroller behaves similar.

I had the setup working, 'cbmctrl detect' found my floppy and directory could be read; also the cable detection reported correctly a cable issue in the parallel cable (one pin was loose). But, I run frequently updates on my box, so possibly an update was done inbetween, I cannot retrace that now. A clean rebuild and re-installation of opencbm did not fix this. Any hints?

Benjamin

[mthi...@gmail.com]

I had the setup working, 'cbmctrl detect' found my floppy and directory could be read; also the cable detection reported correctly a cable issue in the parallel cable (one pin was loose). But, I run frequently updates on my box, so possibly an update was done inbetween, I cannot retrace that now. A clean rebuild and re-installation of opencbm did not fix this. Any hints?

What kind of system is this? Linux? If so: Which kernel and libusb versions? There have been (unresolved) reports of similar problems on linux (thread "ZoomFloppy on Linux" here and https://www.forum64.de/index.php?thread/122335-zoomfloppy-unter-linux-mit-opencbm-version-0-4-99-103/). 

When you say you did a "clean rebuild" of opencbm, does that mean you compiled it yourself?

[Martin Thierer]

> libusb is installed 0.1 and 1.0, the xum1541 seems to use 1.0:

The interesting part would be the point release number. 1.0.24 apparently had some issues on linux. But your kernel version suggests that your system is pretty up to date, so it's probably at least 1.0.25.

> When you say you did a "clean rebuild" of opencbm, does that mean you compiled it yourself?
>

> Yes, git clone of https://git.code.sf.net/p/opencbm/code, 'git describe' gives zoomfloppy_v2_0-424-g0ca9fb9f

Ok, so you could try

1. Spiro's "usb-quirks" feature. I never used it myself, but from what I understand it should work by adding "usb-quirks=1" as a line in the "[xum1541]" section of /etc/opencbm.conf (or maybe the file ended up in /usr/local/etc/, as you seem to have installed to /usr/local/).
2. a different USB port and/or a different machine, if you happen to have access to another one running linux

3. the version from https://github.com/thierer/OpenCBM/tree/set_configuration_fix which removes the change which proved problematic at least in the forum64 case (but this should basically have the same effect as the "usb-quirks" setting).

[Benjamin Hase]

Martin Thierer <mthi...@gmail.com> schrieb am Di., 29. Nov. 2022, 22:40:

> libusb is installed 0.1 and 1.0, the xum1541 seems to use 1.0:

The interesting part would be the point release number. 1.0.24 apparently had some issues on linux. But your kernel version suggests that your system is pretty up to date, so it's probably at least 1.0.25.

Yes, 1.0.25 

Ok, so you could try

1. Spiro's "usb-quirks" feature. I never used it myself, but from what I understand it should work by adding "usb-quirks=1" as a line in the "[xum1541]" section of /etc/opencbm.conf (or maybe the file ended up in /usr/local/etc/, as you seem to have installed to /usr/local/).

With usb-quirks=1 I can access the IO with the line tester tool :-) Looks like I replaced a working controller ...

Solution 2 and 3 I did not try so far, I have some machine I could try #2.

Many thanks to you all!

Best regards

Benjamin 

[Martin Thierer]

with usb-quirks=1 I can access the IO with the line tester tool :-) Looks like I replaced a working controller ...

Solution 2 and 3 I did not try so far, I have some machine I could try #2.

If "usb-quirks" helped, there is no point in trying the version from 3.