1541-II, nibtools and parallel cable has stopped working
148 views
Skip to first unread message
John Watson
Feb 1, 2016, 4:18:43 PM2/1/16
to ZoomFloppy Users
I have been using my 1541-II for a few weeks with a parallel cable. Just a day or two ago it stopped working altogether. I thought there was a problem with the cable (1m IDC type cable). I've been working on it for about a week now and I'm banging my head against a wall. This is the kind of thing I'm seeing:
Also this sometimes:
I've replaced the 6522 socket and chip.
I've buzzed out each of the 10 individual connections from the user port connector at one end, to the legs of the 6522 at the other.
Tried different USB and IEC cables.
Tried USB2 and USB3 sockets.
I've tried 2 different computers.
I'm using an Arch Linux PC and Arch Linux laptop and both were working just fine. What I am thinking is that maybe some recent software update has caused this? Just a guess, as it is happening on both computers. Either that, or the cable is somehow buzzing-out ok but failing during a transfer?? I have also checked continuity from each 6522 socket pin to the various points on the board, going by the circuit diagram.
I'm not certain that the problem is the software / cable but I'm just trying to eliminate it before checking the hardware.
nibread - Commodore 1541/1571 disk image nibbler
(C) Peter Rittwage and the rest of the C64 Preservation Project team
http://c64preservation.com
Revision 2014 - Built Aug 4 2015 23:15:58
Drive Version: 73,CBM DOS V2.6 1541,00,00
Drive type: 1541
Bumping...
Initializing
Sending 1541 parallel support code...
Uploading floppy-side code ($03a7 bytes, $300-$6a7)...done.
Starting custom drive code...Started!
Testing communication...done.
Passed initial communication test.
Testing code upload...done.
Passed code verification test.
Passed all basic port checks.
18.0: (3!=2 KILLER NOSYNC!)
Cosmetic Disk ID: '��'
Format Disk ID: '��'
USB error in xum1541_wait_status: Broken pipe
USB error in xum1541_ioctl cmd: Broken pipe
Also this sometimes:
[snip]
diff: 930
diff: 932
diff: 933
diff: 934
done.
Failed code verification test. Check cabling.
Floppy drive initialization failed
Resetting drive...
Cleaning up...I've replaced the 6522 socket and chip.
I've buzzed out each of the 10 individual connections from the user port connector at one end, to the legs of the 6522 at the other.
Tried different USB and IEC cables.
Tried USB2 and USB3 sockets.
I've tried 2 different computers.
I'm using an Arch Linux PC and Arch Linux laptop and both were working just fine. What I am thinking is that maybe some recent software update has caused this? Just a guess, as it is happening on both computers. Either that, or the cable is somehow buzzing-out ok but failing during a transfer?? I have also checked continuity from each 6522 socket pin to the various points on the board, going by the circuit diagram.
I'm not certain that the problem is the software / cable but I'm just trying to eliminate it before checking the hardware.
John Watson
Feb 1, 2016, 5:04:55 PM2/1/16
to ZoomFloppy Users
I forgot to add that:
works just fine.
I know there is a big difference is using d64copy and nibread / nibwrite, but this must mean that the physical cable / parallel interface is working (?)
d64copy -t p 8 test.d64works just fine.
I know there is a big difference is using d64copy and nibread / nibwrite, but this must mean that the physical cable / parallel interface is working (?)
Peter Rittwage
Feb 5, 2016, 5:05:55 PM2/5/16
to zoomflop...@googlegroups.com
Sorry nobody has responded to you, John. However as to why it was working and then just quit is a bit puzzling. No idea there.
--
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.
For more options, visit https://groups.google.com/d/optout.
John Watson
Feb 5, 2016, 5:14:02 PM2/5/16
to ZoomFloppy Users, pe...@rittwage.com
Thanks Pete. I'm sure someone will get back eventually :)
In the meantime I removed the parallel cable from my 1541-II and will use my 1571 instead.
In the meantime I removed the parallel cable from my 1541-II and will use my 1571 instead.
Peter Rittwage
Feb 5, 2016, 10:13:48 PM2/5/16
to zoomflop...@googlegroups.com
It sounds like you've tried all the right things, so not sure where you will find it.
I fought with a 3D printer I bought recently. It was detected fine on USB, but you couldn't send jobs, then it would lock up. That one turned out to be dodgy USB cable.
Some people have found longer or shorter parallel cables help, some find VIA's go bad. However, yours was working, so it's a bit harder. ZF/nibtools is very susceptible to interference.
On Fri, Feb 5, 2016 at 5:14 PM, John Watson <super...@gmail.com> wrote:
Thanks Pete. I'm sure someone will get back eventually :)
In the meantime I removed the parallel cable from my 1541-II and will use my 1571 instead.
--
Spiro Trikaliotis
Feb 11, 2016, 3:55:14 PM2/11/16
to ZoomFloppy Users, John Watson
Hello John,
* On Fri, Feb 05, 2016 at 02:14:01PM -0800 John Watson wrote:
> Thanks Pete. I'm sure someone will get back eventually :)
Let's try it. ;)
First question: Are you running OpenCBM on Windows, Linux, or MacOS?
I assume you are using Linux or MacOS and you have compiled OpenCBM on
your own. In this case, you have a completely undocumented program in
opencbm/sample/libtrans/ called samplelibtransf. If you are on Windows,
you have got the program in your installation directory.
This program uses the transfer routines of d64copy (serial1, serial2,
parallel) in order to transfer the contents of the floppy ROM from the
floppy to the PC. Before, I had only tested it with an XA1541 cable, but
I just tested it today, it also works with a ZoomFloppy, at least for
serial2 and serial1.
At first, we need to get the image of your ROM. We need a 32 KB image,
without a C64-like "start address" at the beginning. That is, the image
must be exactly 32768 byte long.
Perhaps, you know the exact type of ROM that is in your floppy? Then put
it into a file called "rom.image". If not, you can get the ROM from the
floppy directly, using standard IEC routines:
$ cbmctrl download 8 0x8000 0x8000 rom.image
will read from device #8 starting from address 0x8000 exactly 0x8000
byte of data.
After this command has succeeded (at will take some minutes!), you can
start samplelibtransf:
$ samplelibtransf -tpp -D8 -C -w 32768
will transfer from drive 8 (-D8), COMPARE what it read with rom.image
(-C), and write all files that it transfered (-w). It will start from
0x8000 (build-in into the program) and will read 0x8000 (32768) byte.
You should see an output like:
using length of 0x64
read: -1, error = 0:
compare success
write: -1, error = 0:
read: -2, error = 0:
compare success
[...]
and so on.
If you get a line like
***** ERROR COMPARING DATA! *****
then the transfer failed.
Just let it run for a while in order to find out if the parallel
transfer is reliable with this drive.
Note: Although the tool first reads from the drive, and then,
afterwards, it writes the data back to the drive, the write is not
verified. That is, you are only testing the transfer from the floppy
drive to the PC.
If you want to check the other direction, too, you have to get the
newest version of OpenCBM from git. I just checked in a patch that
allows you to set the start address of the transfer.
If you got the newest version and compiled it, just issue the
following command:
$ samplelibtransf -a1024 -tpp -D8 -C -w 1024
This will transfer the first 0x400 (= 1024) byte from rom.image to the
floppy RAM at 0x400 (= 1024), that is, to 0x400 - 0x7FF.
That is, more precisely, it will first read the contents, and the write
them back. Then again it will read, and the write them back.
This way, you will test if the transfer works in both directions: If you
get an error "ERROR COMPARING DATA", something wrong happened. Note,
however, that the first read MUST fail, as the rom.image will not match
the contents of the floppy. That is, you will get:
using start address of 0x400
using length of 0x100
read: -1, error = 0:
.
***** ERROR COMPARING DATA! *****
write: -1, error = 1:
You can also try with "-ts2" for serial2, or "-ts1" for serial1
transfer, if you want to test the serial connection, too.
Do you get any errors with this?
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
* On Fri, Feb 05, 2016 at 02:14:01PM -0800 John Watson wrote:
> Thanks Pete. I'm sure someone will get back eventually :)
First question: Are you running OpenCBM on Windows, Linux, or MacOS?
I assume you are using Linux or MacOS and you have compiled OpenCBM on
your own. In this case, you have a completely undocumented program in
opencbm/sample/libtrans/ called samplelibtransf. If you are on Windows,
you have got the program in your installation directory.
This program uses the transfer routines of d64copy (serial1, serial2,
parallel) in order to transfer the contents of the floppy ROM from the
floppy to the PC. Before, I had only tested it with an XA1541 cable, but
I just tested it today, it also works with a ZoomFloppy, at least for
serial2 and serial1.
At first, we need to get the image of your ROM. We need a 32 KB image,
without a C64-like "start address" at the beginning. That is, the image
must be exactly 32768 byte long.
Perhaps, you know the exact type of ROM that is in your floppy? Then put
it into a file called "rom.image". If not, you can get the ROM from the
floppy directly, using standard IEC routines:
$ cbmctrl download 8 0x8000 0x8000 rom.image
will read from device #8 starting from address 0x8000 exactly 0x8000
byte of data.
After this command has succeeded (at will take some minutes!), you can
start samplelibtransf:
$ samplelibtransf -tpp -D8 -C -w 32768
will transfer from drive 8 (-D8), COMPARE what it read with rom.image
(-C), and write all files that it transfered (-w). It will start from
0x8000 (build-in into the program) and will read 0x8000 (32768) byte.
You should see an output like:
using length of 0x64
read: -1, error = 0:
compare success
write: -1, error = 0:
read: -2, error = 0:
compare success
[...]
and so on.
If you get a line like
***** ERROR COMPARING DATA! *****
then the transfer failed.
Just let it run for a while in order to find out if the parallel
transfer is reliable with this drive.
Note: Although the tool first reads from the drive, and then,
afterwards, it writes the data back to the drive, the write is not
verified. That is, you are only testing the transfer from the floppy
drive to the PC.
If you want to check the other direction, too, you have to get the
newest version of OpenCBM from git. I just checked in a patch that
allows you to set the start address of the transfer.
If you got the newest version and compiled it, just issue the
following command:
$ samplelibtransf -a1024 -tpp -D8 -C -w 1024
This will transfer the first 0x400 (= 1024) byte from rom.image to the
floppy RAM at 0x400 (= 1024), that is, to 0x400 - 0x7FF.
That is, more precisely, it will first read the contents, and the write
them back. Then again it will read, and the write them back.
This way, you will test if the transfer works in both directions: If you
get an error "ERROR COMPARING DATA", something wrong happened. Note,
however, that the first read MUST fail, as the rom.image will not match
the contents of the floppy. That is, you will get:
using start address of 0x400
using length of 0x100
read: -1, error = 0:
.
***** ERROR COMPARING DATA! *****
write: -1, error = 1:
You can also try with "-ts2" for serial2, or "-ts1" for serial1
transfer, if you want to test the serial connection, too.
Do you get any errors with this?
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
John Watson
Feb 11, 2016, 4:35:53 PM2/11/16
to ZoomFloppy Users, John Watson
Spiro,
Many thanks for the very detailed reply. As I mentioned earlier, I removed the parallel cable and in the meantime I've been using my 1571. However I will install it again tomorrow evening after work and try your suggestions.John Watson
Feb 11, 2016, 5:19:29 PM2/11/16
to ZoomFloppy Users, super...@gmail.com
Well I couldn't wait till tomorrow to try this so I set it up again just now. I had to re-solder a wire that had come off the socket but no big deal.
The results were not too good:
[john@jupiter64 c64]$ samplelibtransf -tpp -D8 -C -w 32768
libtransfer sample: Jan 1 2016 22:43:20
using length of 0x8000
The results were not too good:
[john@jupiter64 c64]$ samplelibtransf -tpp -D8 -C -w 32768
libtransfer sample: Jan 1 2016 22:43:20
using length of 0x8000
read: -1, error = 0:
.................
***** ERROR COMPARING DATA! *****
write: -1, error = 1:
.................
read: -2, error = 1:
.................
read: -2, error = 1:
.................
***** ERROR COMPARING DATA! *****
write: -2, error = 2:
.................
read: -3, error = 2:
.................
.................
read: -3, error = 2:
.................
***** ERROR COMPARING DATA! *****
write: -3, error = 3:
.................
read: -4, error = 3:
.................
.................
read: -4, error = 3:
.................
***** ERROR COMPARING DATA! *****
write: -4, error = 4:
.................
read: -5, error = 4:
.................
.................
read: -5, error = 4:
.................
***** ERROR COMPARING DATA! *****
write: -5, error = 5:
.................
read: -6, error = 5:
.................
.................
read: -6, error = 5:
.................
***** ERROR COMPARING DATA! *****
write: -6, error = 6:
.:^C
SIGINT caught, resetting IEC bus...
file: pp.c
version: 0.4.99.97, built: Jan 1 2016 22:43:15
line=44, blocks=3, bytes=116, bits=-1
So is this pointing to a cable issue or something else? The cable / socket setup is not great - I have a socket soldered into the main board for the 6522 and the parallel cable itself if soldered to the legs of another socket, which sits on top the first. The 6522 sits in top of both sockets.
I tested this with the mechanism detached from the drive housing to allow access to the 6522 etc but with all 3 main board connectors attached (hope that makes sense).
.:^C
SIGINT caught, resetting IEC bus...
file: pp.c
version: 0.4.99.97, built: Jan 1 2016 22:43:15
line=44, blocks=3, bytes=116, bits=-1
So is this pointing to a cable issue or something else? The cable / socket setup is not great - I have a socket soldered into the main board for the 6522 and the parallel cable itself if soldered to the legs of another socket, which sits on top the first. The 6522 sits in top of both sockets.
I tested this with the mechanism detached from the drive housing to allow access to the 6522 etc but with all 3 main board connectors attached (hope that makes sense).
Spiro Trikaliotis
Feb 12, 2016, 1:39:04 AM2/12/16
to ZoomFloppy Users
Hello John,
> The results were not too good:
>
> [john@jupiter64 c64]$ samplelibtransf -tpp -D8 -C -w 32768
[...]
> So is this pointing to a cable issue or something else?
If everything is set up correctly (see my points below), then this
points to a cable issue, or to the 6522, or to the Atmel on the ZF (I
would say, in this order).
Just to make sure there is no other source for problems, could you
please check the following:
1. Are you sure you have the right rom.image in place? You said that you
have two drives, a 1571 and a 1541-II; perhaps, you are trying with
the rom.image from the 1571 instead of the 1541-II?
2. Please try with "-ts2" instead of "-tpp", so that we can be sure that
the tools generally works for you. This will also make sure that the
rom.image is the correct one, if there is no error.
3. If test #2 worked, then I would be interested in the output of the
program. Please, delete all image.err.* files from your directory.
(These are generated from samplelibtransf).
Then, start samplelibtransf again, with the command line you used
below. Let it run for let's say 10 rounds. Then, stop it (Ctrl+C).
Then send me via mail (directly, not via ML) a ZIP containing all the
files: rom.image and image.err.*
Perhaps, I can see a pattern (for example, always the same bit is
wrong, or so).
> The results were not too good:
>
> [john@jupiter64 c64]$ samplelibtransf -tpp -D8 -C -w 32768
> ***** ERROR COMPARING DATA! *****
[...]
> So is this pointing to a cable issue or something else?
points to a cable issue, or to the 6522, or to the Atmel on the ZF (I
would say, in this order).
Just to make sure there is no other source for problems, could you
please check the following:
1. Are you sure you have the right rom.image in place? You said that you
have two drives, a 1571 and a 1541-II; perhaps, you are trying with
the rom.image from the 1571 instead of the 1541-II?
2. Please try with "-ts2" instead of "-tpp", so that we can be sure that
the tools generally works for you. This will also make sure that the
rom.image is the correct one, if there is no error.
3. If test #2 worked, then I would be interested in the output of the
program. Please, delete all image.err.* files from your directory.
(These are generated from samplelibtransf).
Then, start samplelibtransf again, with the command line you used
below. Let it run for let's say 10 rounds. Then, stop it (Ctrl+C).
Then send me via mail (directly, not via ML) a ZIP containing all the
files: rom.image and image.err.*
Perhaps, I can see a pattern (for example, always the same bit is
wrong, or so).
John Watson
Feb 13, 2016, 10:32:47 AM2/13/16
to ZoomFloppy Users
Spiro, I have some more information for you.
I went into my attic a got another 1541-II drive. I made another parallel cable with new cable and new sockets (both ends) and tried 3 different 6522s - also a different IEC cable. Every test I run in this new setup fails:libtransfer sample: Jan 1 2016 22:43:20
using length of 0x8000
read: -1, error = 0:
.................
***** ERROR COMPARING DATA! *****
write: -1, error = 1:
.................
read: -2, error = 1:
.................
.................
read: -2, error = 1:
.................
***** ERROR COMPARING DATA! *****
write: -2, error = 2:
...........*^C
SIGINT caught, resetting IEC bus...
file: pp.c
version: 0.4.99.97, built: Jan 1 2016 22:43:15
line=33, blocks=86, bytes=106, bits=-1
I think this is good enough to eliminate my drive,6522, IEC cable and parallel cable from this problem, yes?samplelibtransf -ts2 -D8 -C -w 32768
If this is not likely, then it only really leaves the Zoomfloppy unit??
--
You received this message because you are subscribed to a topic in the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/zoomfloppy-users/yy7UZV4Xm1Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to zoomfloppy-use...@googlegroups.com.
John Watson
Feb 13, 2016, 10:55:15 AM2/13/16
to ZoomFloppy Users
Just some more terminal output in case it helps.
BTW I forgot to mention that the 1541-II is the only drive connected - the 1571 is not in the chain at all.[john@jupiter64 c64]$ rm -f rom.image
[john@jupiter64 c64]$ rm -f image.err.*
[john@jupiter64 c64]$ cbmctrl download 8 0x8000 0x8000 rom.image
................o[johnsamplelibtransf -ts2 -D8 -C -w 32768
libtransfer sample: Jan 1 2016 22:43:20
using length of 0x8000
read: -1, error = 0:
.................
compare success
write: -1, error = 0:
.................
write: -1, error = 0:
.................
read: -2, error = 0:
.................
compare success
write: -2, error = 0:
.;^C
compare success
write: -2, error = 0:
.;^C
SIGINT caught, resetting IEC bus...
file: s2.c
version: 0.4.99.97, built: Jan 1 2016 22:43:15
line=71, blocks=2, bytes=174, bits=8
[john@jupiter64 c64]$ cbmctrl status 8
73,cbm dos v2.6 1541,00,00
[john@jupiter64 c64]$ cbmctrl status 8
73,cbm dos v2.6 1541,00,00
[john@jupiter64 c64]$ samplelibtransf -tpp -D8 -C -w 32768
libtransfer sample: Jan 1 2016 22:43:20
using length of 0x8000
read: -1, error = 0:
.................
***** ERROR COMPARING DATA! *****
write: -1, error = 1:
.................
read: -2, error = 1:
.................
***** ERROR COMPARING DATA! *****
write: -2, error = 2:
using length of 0x8000
read: -1, error = 0:
.................
***** ERROR COMPARING DATA! *****
write: -1, error = 1:
.................
read: -2, error = 1:
.................
***** ERROR COMPARING DATA! *****
write: -2, error = 2:
...O^C
SIGINT caught, resetting IEC bus...
file: pp.c
version: 0.4.99.97, built: Jan 1 2016 22:43:15
line=46, blocks=23, bytes=162, bits=-1
[john@jupiter64 c64]$
[john@jupiter64 c64]$
Nate Lawson
Feb 13, 2016, 1:32:48 PM2/13/16
to ZoomFloppy Users
On Feb 13, 2016, at 7:32 AM, John Watson <super...@gmail.com> wrote:
>
> I went into my attic a got another 1541-II drive. I made another parallel cable with new cable and new sockets (both ends) and tried 3 different 6522s - also a different IEC cable. Every test I run in this new setup fails
Sorry if you already answered this, but did you do the pin 1 fix?
>
> I went into my attic a got another 1541-II drive. I made another parallel cable with new cable and new sockets (both ends) and tried 3 different 6522s - also a different IEC cable. Every test I run in this new setup fails
http://www.d81.de/R.I.P/Para1541II.shtml
-Nate
John Watson
Feb 13, 2016, 1:38:15 PM2/13/16
to ZoomFloppy Users
Yes Nate, I did - just forgot to mention it.
Some further testing... nibbling seems to be working now on the new cable and 1541-II. I'm no longer getting the USB errors. However I am still getting ***** ERROR COMPARING DATA! ***** when testing as above.Spiro Trikaliotis
Feb 13, 2016, 2:41:04 PM2/13/16
to ZoomFloppy Users
Hello John,
* On Sat, Feb 13, 2016 at 03:54:35PM +0000 John Watson wrote:
> [john@jupiter64 c64]$ rm -f rom.image
> [john@jupiter64 c64]$ rm -f image.err.*
> [john@jupiter64 c64]$ cbmctrl download 8 0x8000 0x8000 rom.image
> ................o[johnsamplelibtransf -ts2 -D8 -C -w 32768
> libtransfer sample: Jan 1 2016 22:43:20
> using length of 0x8000
> read: -1, error = 0:
> .................
> compare success
> write: -1, error = 0:
> .................
> read: -2, error = 0:
> .................
> compare success
> write: -2, error = 0:
> .;^C
> SIGINT caught, resetting IEC bus...
[...]
Why don't you pack up the image.err.* files and rom.image and send them
to me, so I can have a deeper look?
* On Sat, Feb 13, 2016 at 03:54:35PM +0000 John Watson wrote:
> [john@jupiter64 c64]$ rm -f rom.image
> [john@jupiter64 c64]$ rm -f image.err.*
> [john@jupiter64 c64]$ cbmctrl download 8 0x8000 0x8000 rom.image
> ................o[johnsamplelibtransf -ts2 -D8 -C -w 32768
> libtransfer sample: Jan 1 2016 22:43:20
> using length of 0x8000
> read: -1, error = 0:
> .................
> compare success
> write: -1, error = 0:
> .................
> read: -2, error = 0:
> .................
> compare success
> write: -2, error = 0:
> .;^C
> SIGINT caught, resetting IEC bus...
Why don't you pack up the image.err.* files and rom.image and send them
to me, so I can have a deeper look?
John Watson
Feb 13, 2016, 2:42:22 PM2/13/16
to ZoomFloppy Users
I'll do that this evening Spiro. Thank you.
John Watson
Feb 13, 2016, 4:36:14 PM2/13/16
to ZoomFloppy Users
I've emailed 2 sets of results Spiro.
Spiro Trikaliotis
Feb 13, 2016, 4:41:57 PM2/13/16
to ZoomFloppy Users
Hello John,
* On Sat, Feb 13, 2016 at 08:41:01PM +0100 I wrote:
> Why don't you pack up the image.err.* files and rom.image and send them
> to me, so I can have a deeper look?
I just got your ZIP. There are two interesting points:
1. ALL image.err.* are identical to each other!
2. The image.err.* differ always in the first byte of a 256 byte block.
That is, the offsets 0x0000, 0x0100, 0x0200, 0x0300, ..., 0x7f00 are
different (image.err.* always contain a zero there).
To me, it looks more like a systematical error, an error in the transfer
routines themselves rather than a problem with your setup.
To test it a little bit further, please copy the image.err.1 file to
rom.image, and restart the test again. I am sure you will not get any
errors anymore, right?
To me, it seems I have to test all of this again with the ZF. To be
honest, samplelibtransf was written for the XA1541 only. I only tested
it with the ZF the day I posted it here. Unfortunately, my parallel
cable does not fit to the ZF, so I could not test the parallel transfer,
only the serial transfers.
Is here anyone with a parallel connection to the ZF, who can redo the
test in order to find out if it is a problem of the samplelibtransf
transfer routine for parallel?
* On Sat, Feb 13, 2016 at 08:41:01PM +0100 I wrote:
> Why don't you pack up the image.err.* files and rom.image and send them
> to me, so I can have a deeper look?
1. ALL image.err.* are identical to each other!
2. The image.err.* differ always in the first byte of a 256 byte block.
That is, the offsets 0x0000, 0x0100, 0x0200, 0x0300, ..., 0x7f00 are
different (image.err.* always contain a zero there).
To me, it looks more like a systematical error, an error in the transfer
routines themselves rather than a problem with your setup.
To test it a little bit further, please copy the image.err.1 file to
rom.image, and restart the test again. I am sure you will not get any
errors anymore, right?
To me, it seems I have to test all of this again with the ZF. To be
honest, samplelibtransf was written for the XA1541 only. I only tested
it with the ZF the day I posted it here. Unfortunately, my parallel
cable does not fit to the ZF, so I could not test the parallel transfer,
only the serial transfers.
Is here anyone with a parallel connection to the ZF, who can redo the
test in order to find out if it is a problem of the samplelibtransf
transfer routine for parallel?
John Watson
Feb 13, 2016, 4:48:30 PM2/13/16
to ZoomFloppy Users, an-zoomfl...@spiro.trikaliotis.net
Hello Spiro,
You are correct! I renamed image.err.1 to rom.image, ran the test and this:
[john@jupiter64 Spiro]$ samplelibtransf -tpp -D8 -C -w 32768
You are correct! I renamed image.err.1 to rom.image, ran the test and this:
[john@jupiter64 Spiro]$ samplelibtransf -tpp -D8 -C -w 32768
libtransfer sample: Jan 1 2016 22:43:20
using length of 0x8000
read: -1, error = 0:
.................
compare success
write: -1, error = 0:
.................
read: -2, error = 0:
.................
compare success
write: -2, error = 0:
.................
read: -3, error = 0:
.................
compare success
write: -3, error = 0:
.O^C
read: -3, error = 0:
.................
compare success
write: -3, error = 0:
.O^C
SIGINT caught, resetting IEC bus...
file: pp.c
version: 0.4.99.97, built: Jan 1 2016 22:43:15
line=37, blocks=7, bytes=-12801, bits=-1
On Saturday, 13 February 2016 21:41:57 UTC, Spiro Trikaliotis wrote:
version: 0.4.99.97, built: Jan 1 2016 22:43:15
line=37, blocks=7, bytes=-12801, bits=-1
On Saturday, 13 February 2016 21:41:57 UTC, Spiro Trikaliotis wrote:
Hello John,
Spiro Trikaliotis
Feb 13, 2016, 4:52:32 PM2/13/16
to ZoomFloppy Users
Hello again,
* On Sat, Feb 13, 2016 at 10:41:54PM +0100 I wrote:
> Is here anyone with a parallel connection to the ZF, who can redo the
> test in order to find out if it is a problem of the samplelibtransf
> transfer routine for parallel?
Forget it. I just checked, the parallel transfer of d64copy and the one
of libtransfer differ! I fixed the routines in libtransfer in order to
fix a race condition. For this, the order of the handshake signal and
when the data changes had been changed.
Unfortunately, this means that the parallel transfer cannot work with
the ZF at the moment, as the ZF does not know about this transfer!
I am very sorry for this, I totally forgot about this difference.
Thus, looking at your transfers, it seems to me that the parallel
transfers work very reliable. The differences reported by
samplelibtransf are to be expected.
* On Sat, Feb 13, 2016 at 10:41:54PM +0100 I wrote:
> Is here anyone with a parallel connection to the ZF, who can redo the
> test in order to find out if it is a problem of the samplelibtransf
> transfer routine for parallel?
of libtransfer differ! I fixed the routines in libtransfer in order to
fix a race condition. For this, the order of the handshake signal and
when the data changes had been changed.
Unfortunately, this means that the parallel transfer cannot work with
the ZF at the moment, as the ZF does not know about this transfer!
I am very sorry for this, I totally forgot about this difference.
Thus, looking at your transfers, it seems to me that the parallel
transfers work very reliable. The differences reported by
samplelibtransf are to be expected.
John Watson
Feb 13, 2016, 5:14:04 PM2/13/16
to ZoomFloppy Users, an-zoomfl...@spiro.trikaliotis.net
Spiro, so just to clarify this - the test (-tpp) will not work with ZF but the actual nibread / nibwrite transfers should be OK?
John Watson
Feb 13, 2016, 5:24:58 PM2/13/16
to ZoomFloppy Users, an-zoomfl...@spiro.trikaliotis.net
Just going back to my original issue before I fetched my spare 1541-II from the attic...
I still have one "faulty" drive and one working drive. Both have new parallel cables fitted. When I try nibread on the "faulty" drive I get varying errors but mostly like this:
I still have one "faulty" drive and one working drive. Both have new parallel cables fitted. When I try nibread on the "faulty" drive I get varying errors but mostly like this:
USB error in xum1541_ioctl cmd: Broken pipe
I put a disk into the good drive and it nibbled fine but in the suspect drive, with the same disk, I see this:
===================================================
USB error in read data(0x7ffdae380400, 8192): Broken pipe
18.0: (3!=2 KILLER NOSYNC!)
[Cannot find directory sector!]
[Cannot find directory sector!]
===================================================
USB error in read data(0x7ffdae380400, 8192): Broken pipe
18.0: (3!=2 KILLER NOSYNC!)
[Cannot find directory sector!]
[Cannot find directory sector!]
Cosmetic Disk ID: Format Disk ID:
USB error in xum1541_ioctl cmd: Broken pipe
USB error in xum1541_ioctl cmd: Broken pipe
===================================================
or this:
===================================================
18.0: (2 NOSYNC!)
[Cannot find directory sector!]
[Cannot find directory sector!]
or this:
===================================================
18.0: (2 NOSYNC!)
[Cannot find directory sector!]
[Cannot find directory sector!]
Cosmetic Disk ID: Format Disk ID:
USB error in xum1541_wait_status: Broken pipe
USB error in xum1541_ioctl cmd: Broken pipe
===================================================
Cleaned drive heads....
===================================================
18.0: (2)
Cleaned drive heads....
===================================================
18.0: (2)
Cosmetic Disk ID: ' '
Format Disk ID: ' '
Format Disk ID: ' '
USB error in read data(0x7ffee46becc0, 8192): Broken pipe
1.0: (3) 0 [Unformatted Track]
1.0: (3) 0 [Unformatted Track]
USB error in xum1541_ioctl cmd: Broken pipe
USB error in xum1541_ioctl cmd: Broken pipe
USB error in xum1541_ioctl cmd: Broken pipe
===================================================
What I would like to know is: what exactly does this error mean and what might be causing it?
Could it be dirt on read/write head? Faulty internal wiring? Head alignment?Something else? It must be something to do with this particular drive as I have an identical one beside it working on the same ZF, IEC cable, disk etc.
What I would like to know is: what exactly does this error mean and what might be causing it?
Could it be dirt on read/write head? Faulty internal wiring? Head alignment?Something else? It must be something to do with this particular drive as I have an identical one beside it working on the same ZF, IEC cable, disk etc.
Nate Lawson
Feb 13, 2016, 5:49:57 PM2/13/16
to ZoomFloppy Users, an-zoomfl...@spiro.trikaliotis.net
On Feb 13, 2016, at 2:24 PM, John Watson <super...@gmail.com> wrote:
>
> 18.0: (2)
> Cosmetic Disk ID: ' '
> Format Disk ID: ' '
>
>
> USB error in read data(0x7ffee46becc0, 8192): Broken pipe
> 1.0: (3) 0 [Unformatted Track]
> USB error in xum1541_ioctl cmd: Broken pipe
> USB error in xum1541_ioctl cmd: Broken pipe
> ===================================================
>
>
> What I would like to know is: what exactly does this error mean and what might be causing it?
>
> Could it be dirt on read/write head? Faulty internal wiring? Head alignment?Something else? It must be something to do with this particular drive as I have an identical one beside it working on the same ZF, IEC cable, disk etc.
The error message is not useful since all it means is the ZF stopped responding (never returned data). This can happen for all the reasons above (except IEC cable — that would fail earlier), so you have to troubleshoot each one to find the root cause. It could be bad VIA, bad parallel cable or socket, dirty disk head, etc.
>
> 18.0: (2)
> Cosmetic Disk ID: ' '
> Format Disk ID: ' '
>
>
> USB error in read data(0x7ffee46becc0, 8192): Broken pipe
> 1.0: (3) 0 [Unformatted Track]
> USB error in xum1541_ioctl cmd: Broken pipe
> USB error in xum1541_ioctl cmd: Broken pipe
> ===================================================
>
>
> What I would like to know is: what exactly does this error mean and what might be causing it?
>
> Could it be dirt on read/write head? Faulty internal wiring? Head alignment?Something else? It must be something to do with this particular drive as I have an identical one beside it working on the same ZF, IEC cable, disk etc.
There’s no way to tell from the ZF side or nibtools the root cause of the error once it has succeeded in uploading and executing the drive code and testing the parallel cable. At that point, all failures afterwards are indistinguishable from software.
-Nate
John Watson
Feb 13, 2016, 6:56:53 PM2/13/16
to ZoomFloppy Users, an-zoomfl...@spiro.trikaliotis.net
Thanks Nate. I'll have to keep at it and try everything :)
John Watson
Feb 13, 2016, 9:56:37 PM2/13/16
to ZoomFloppy Users
After several hours of testing, I am now convinced that the problem is the 6522 chip(s) itself. I have three 6522 chips and 2 drives and after swapping them around in various combinations, it would appear that only one 6522 chip actually works in parallel mode. This is very surprising as the 2 "faulty" ones actually did work up until a few days ago. It's almost like running them in "parallel mode" with the ZF had a bad effect on them?! I suppose I'll know for sure if my working 6522 goes the same way.
Looking at the schematic for the 1581-II, I see that PA0-PA7 of U8 (6522) are connected to U10 (Gate Array). I might swap U8 and U6(suspect) to see if there is any effect - good, bad or none.Nate Lawson
Feb 13, 2016, 11:20:37 PM2/13/16
to ZoomFloppy Users
You can probably swap the VIAs in the drive to see if it’s really bad.
Are there any shorts in the parallel cable? VIAs can be zapped by static electricity, but I don’t know of the ZF causing any problems with them.
I assume you’re not unplugging or plugging in any cables while the ZF is plugged into USB or the drive is on, right? You should always do all cable changes while both sides are completely off.
> --
> 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.
Are there any shorts in the parallel cable? VIAs can be zapped by static electricity, but I don’t know of the ZF causing any problems with them.
I assume you’re not unplugging or plugging in any cables while the ZF is plugged into USB or the drive is on, right? You should always do all cable changes while both sides are completely off.
> 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.
John Watson
Feb 14, 2016, 3:18:43 PM2/14/16
to ZoomFloppy Users
On 14 February 2016 at 04:20, Nate Lawson <na...@root.org> wrote:
I assume you’re not unplugging or plugging in any cables while the ZF is plugged into USB or the drive is on, right? You should always do all cable changes while both sides are completely off.
I'm probably guilty of this Nate. Quite often I find myself (un)plugging cables without realising the power isn't off. However I'd expect the chip to be dead i.e. not functioning at all, if it got zapped. IIRC both these "faulty" chips still work in the "normal way" - serial only. I'll re-check this later though.
I was going to try to order some of these 6522s from China as they#re very cheap but I'd like to be sure they are the real thing!
Has anyone had any experience of these Chinese chips?
Nate Lawson
Feb 14, 2016, 3:33:58 PM2/14/16
to ZoomFloppy Users
> On Feb 14, 2016, at 12:17 PM, John Watson <super...@gmail.com> wrote:
>
> On 14 February 2016 at 04:20, Nate Lawson <na...@root.org> wrote:
>
> I assume you’re not unplugging or plugging in any cables while the ZF is plugged into USB or the drive is on, right? You should always do all cable changes while both sides are completely off.
>
>
> I'm probably guilty of this Nate. Quite often I find myself (un)plugging cables without realising the power isn't off. However I'd expect the chip to be dead i.e. not functioning at all, if it got zapped. IIRC both these "faulty" chips still work in the "normal way" - serial only. I'll re-check this later though.
http://root.org/~nate/c64/xum1541/index.html
http://root.org/~nate/c64/ZoomFloppy-Manual-2.0.pdf
-Nate
Alexander Oberhuber
Feb 14, 2016, 7:25:38 PM2/14/16
to zoomflop...@googlegroups.com
John Watson schrieb am 21:17 14.02.2016 :
>I was going to try to order some of these 6522s from China as
>they#re very cheap but I'd like to be sure they are the real thing!
Out of curiosity, at which chinese internet shop can I get these 6522
>I was going to try to order some of these 6522s from China as
>they#re very cheap but I'd like to be sure they are the real thing!
replacements?
Yours
Alex
Spiro Trikaliotis
Feb 15, 2016, 1:20:17 PM2/15/16
to ZoomFloppy Users
Hello John,
* On Sat, Feb 13, 2016 at 02:14:04PM -0800 John Watson wrote:
> Spiro, so just to clarify this - the test (-tpp) will not work with ZF but the
> actual nibread / nibwrite transfers should be OK?
Yes. The -tpp works as good as it can. I just got my 1541 with parallel
cable from the attic, it works exactly like your one. Thus, from my
point of view, the connection itself works and is reliable.
Of course, the nibread/nibwrite routines use the 6522 in different ways
and timings, there might be other issues I am not aware off. But, in
general, you parallel connection is good.
* On Sat, Feb 13, 2016 at 02:14:04PM -0800 John Watson wrote:
> Spiro, so just to clarify this - the test (-tpp) will not work with ZF but the
> actual nibread / nibwrite transfers should be OK?
cable from the attic, it works exactly like your one. Thus, from my
point of view, the connection itself works and is reliable.
Of course, the nibread/nibwrite routines use the 6522 in different ways
and timings, there might be other issues I am not aware off. But, in
general, you parallel connection is good.
Reply all
Reply to author
Forward
0 new messages