NIBRead Woes
Rob O'Hara
parallel port socket into a 1541 last night. Before we get into my
problems, I want to thank Nate and Peter and Jim and everyone else
involved in making the ZoomFloppy a reality. It's perfect!
Well, almost perfect.
I am having problems with the nibtools. I will give you all the
information I can think of, but please feel free to ask for more. I've
worked in IT and tech support for fifteen years now, and if there's
one thing I can't stand it's an uncooperative caller!
The problem I am having is similar to the one Gene Buckle described in
his post "nibread loses its mind ...". Whenever I try to nibble a disk
using nibread, the program starts dumping the image and then the
ZoomFloppy resets (I can hear the Windows sound of unplugging and
replugging a USB device). I am running Windows 7 64-Bit. I downloaded
and installed the drivers from Nate's site. I am using driver version
1.2.20 (libusb-win32 devices). I am running version 493 of NIBRead.
I have successfully made .D64 images using D64Copy. I have also forced
parallel mode using D64 copy, so I am assuming the parallel port and
cable are both installed and working correctly.
The command line I am using is: nibread image.nib
For a moment, everything appears to run normally. I get back the
correct Drive Version and Drive Type. I also get "Uploading floppy-
side code...", "Starting custom drive code...", and "Passed basic
parallel port checks." I also get "18.0: (2)", and the Disk ID. After
that, the disk begins copying.
I have tried half a dozen disks so far (both sides) and not one has
completed. Sometimes it bombs out as early as track 2, other times it
makes it into the 30s. Either way, at some point I hear the Windows
sound the the ZoomFloppy disconnecting/reconnecting and then I get
probably 500 lines of: "USB error in xum1541_ioctl cmd: libusb0-
dll:err [submit_async] submitting request failed, win error: The
device does not recognize the command."
After about 500 lines (give or take) of that error, Windows 7 asks to
close the application. NIBRead does not leave a .NIB file behind, and
the corresponding log file is empty (0 bytes).
I ran NIBRead with -t (advanced Parallel test) and it says it passed.
Although I was unable to get a log file, here are some screen shots.
Note that in this example, all the tracks came back as bad. This was
not the case on all the disks, just this particular one.
http://www.robohara.com/pix/junk/nibread_1.jpg
http://www.robohara.com/pix/junk/nibread_2.jpg
http://www.robohara.com/pix/junk/nibread_3.jpg
http://www.robohara.com/pix/junk/nibread_4.jpg
I am open to any suggestions or tests you guys can think of!
Nate Lawson
> I got my ZoomFloppy yesterday, and installed Peter Scheper�s pre-wired
> parallel port socket into a 1541 last night. Before we get into my
> problems, I want to thank Nate and Peter and Jim and everyone else
> involved in making the ZoomFloppy a reality. It's perfect!
Thanks!
> The problem I am having is similar to the one Gene Buckle described in
> his post "nibread loses its mind ...". Whenever I try to nibble a disk
> using nibread, the program starts dumping the image and then the
> ZoomFloppy resets (I can hear the Windows sound of unplugging and
> replugging a USB device). I am running Windows 7 64-Bit. I downloaded
> and installed the drivers from Nate's site. I am using driver version
> 1.2.20 (libusb-win32 devices). I am running version 493 of NIBRead.
>
> I have successfully made .D64 images using D64Copy. I have also forced
> parallel mode using D64 copy, so I am assuming the parallel port and
> cable are both installed and working correctly.
>
> The command line I am using is: nibread image.nib
nibread has really lousy command line parsing and will *not* report
errors even in many cases of bad command lines. (I am egging Peter on to
use a real getopt() implementation, so hopefully this improves soon).
Your screenshots show you actually typed "nibread 8 image.nib". This is
incorrect. To specify an alternate drive number, do "nibread -D9
image.nib". Note: due to lousy parsing, you can't put a space in there
("-D 9").
Since 8 is the default, really type just:
nibread image.nib
I don't know if that's part of the problem but that is not quite correct
usage. I think it's trying to create a file called "8.nib"
> For a moment, everything appears to run normally. I get back the
> correct Drive Version and Drive Type. I also get "Uploading floppy-
> side code...", "Starting custom drive code...", and "Passed basic
> parallel port checks." I also get "18.0: (2)", and the Disk ID. After
> that, the disk begins copying.
>
> I have tried half a dozen disks so far (both sides) and not one has
> completed. Sometimes it bombs out as early as track 2, other times it
> makes it into the 30s. Either way, at some point I hear the Windows
> sound the the ZoomFloppy disconnecting/reconnecting and then I get
> probably 500 lines of: "USB error in xum1541_ioctl cmd: libusb0-
> dll:err [submit_async] submitting request failed, win error: The
> device does not recognize the command."
> I ran NIBRead with -t (advanced Parallel test) and it says it passed.
This is good.
> Although I was unable to get a log file, here are some screen shots.
> Note that in this example, all the tracks came back as bad. This was
> not the case on all the disks, just this particular one.
>
> http://www.robohara.com/pix/junk/nibread_1.jpg
> http://www.robohara.com/pix/junk/nibread_2.jpg
> http://www.robohara.com/pix/junk/nibread_3.jpg
> http://www.robohara.com/pix/junk/nibread_4.jpg
>
> I am open to any suggestions or tests you guys can think of!
The behavior you describe is the watchdog timer in the ZoomFloppy going
off. This means the drive is taking too long to respond to it. I don't
think your command line is the problem.
Perhaps this is a dirty drive head? You can clean it with a soft cloth
or Q-tip and rubbing alcohol. If the drive can't find the sync bits or
something, perhaps it is not answering in time. Since this happens at
different times, either drive alignment, drive speed, or dirty drive
head may be the culprit.
Does d64copy work? (for unprotected disks only, of course):
d64copy -tp 8 image.d64
That will transfer your data using the parallel port.
--
Nate
robohara
> nibread image.nib
I've been using.
> The behavior you describe is the watchdog timer in the ZoomFloppy going
> off. This means the drive is taking too long to respond to it. I don't
> think your command line is the problem.
>
> Perhaps this is a dirty drive head? You can clean it with a soft cloth
> or Q-tip and rubbing alcohol. If the drive can't find the sync bits or
> something, perhaps it is not answering in time. Since this happens at
> different times, either drive alignment, drive speed, or dirty drive
> head may be the culprit.
start hacking around with my best 1541, so I used one of, shall we
say, "unknown pedigree". I'll have to Google for a good cleaning/
alignment regimen.
> Does d64copy work? (for unprotected disks only, of course):
> d64copy -tp 8 image.d64
Sounds like I'm off to clean the wizard ...
Nate Lawson
> Nate wrote:
>> The behavior you describe is the watchdog timer in the ZoomFloppy going
>> off. This means the drive is taking too long to respond to it. I don't
>> think your command line is the problem.
>>
>> Perhaps this is a dirty drive head? You can clean it with a soft cloth
>> or Q-tip and rubbing alcohol. If the drive can't find the sync bits or
>> something, perhaps it is not answering in time. Since this happens at
>> different times, either drive alignment, drive speed, or dirty drive
>> head may be the culprit.
>
> If those things can cause this problem, it's likely. I didn't want to
> start hacking around with my best 1541, so I used one of, shall we
> say, "unknown pedigree". I'll have to Google for a good cleaning/
> alignment regimen.
>
>> Does d64copy work? (for unprotected disks only, of course):
>> d64copy -tp 8 image.d64
>
> Yeah, works perfectly. I tried both "-tp" and "-t parallel".
>
> Sounds like I'm off to clean the wizard ...
All signs indicate the parallel port is fine and the drive is executing
the nibread code just fine. So the only other thing is the drive reading
the media, so clean first.
After that, trying checking speed by running "cbmrpm41 8" with a blank
formatted disk. You can format the disk with "cbmformat 8 test,aa".
This should give you 297-300 rpm with low variability or it's a bad belt
or drive speed needs adjustment.
--
Nate
Pete Rittwage
Also make sure that this 1541 is the only device on the IEC chain- the nibtools protocols won't work properly if any other drive is connected (and especially if they are connected, but turned off).
-Pete
Gene Buckle
> I got my ZoomFloppy yesterday, and installed Peter Scheper�s pre-wired
> parallel port socket into a 1541 last night. Before we get into my
> problems, I want to thank Nate and Peter and Jim and everyone else
> involved in making the ZoomFloppy a reality. It's perfect!
>
Rob, do you have a 1571 you could try this with by chance?
Since I quit using the stupid command line args I stopped getting those
errors - but the difference may be 1571 vs 1541 since you're not using any
command line args either.
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
Political correctness is a doctrine, fostered by a delusional, illogical
minority, and rabidly promoted by an unscrupulous mainstream media, which
holds forth the proposition that it is entirely possible to pick up a turd
by the clean end.
Jim Brain
> On 3/31/2011 5:55 PM, robohara wrote:
>> Nate wrote:
>>> The behavior you describe is the watchdog timer in the ZoomFloppy going
>>> off. This means the drive is taking too long to respond to it. I don't
>>> think your command line is the problem.
behavior. Is there some reason why we can't poll of otherwise kick the
watchdog while we wait for the IEC response, and reset our code if we
don't get a response in a timely manner? The USB spec was not designed
to have devices disappear and then re-appear in such a manner.
Jim
robohara
> formatted disk. You can format the disk with "cbmformat 8 test,aa".
>
> This should give you 297-300 rpm with low variability or it's a bad belt
> or drive speed needs adjustment.
new floppy. The slowest speed I got was 300.653, and the fastest was
300.843.
robohara
> nibtools protocols won't work properly if any other drive is connected (and
> especially if they are connected, but turned off).
original post. I only have a single 1541 connected to the ZoomFloppy.
robohara
>
> Since I quit using the stupid command line args I stopped getting those
> errors - but the difference may be 1571 vs 1541 since you're not using any
> command line args either.
suspect have the older ROM versions that Peter warns about on his
page:
http://ist.uwaterloo.ca/~schepers/1571port.html
Everything is pointing to alignment/cleaning issues at this point, so
I'm going to go that route first.
Nate Lawson
Seems pretty steady. I'd lower it to 297 RPM if you want to start
writing VMAX floppies. But walk first before you run. :)
--
Nate
Pete Rittwage
-Pete
Gene Buckle
Ok. All the ones I have had JiffyDOS on 'em when I got them. I've
actually had to burn a couple of original 1571 ROMs to recover the ability
to read MFM disks in CP/M with them.
Pete Rittwage
Gene Buckle
> Having JiffyDOS roms makes no difference to nibtools.
>
I didn't think it did. :)
Nate Lawson
Hey Jim, this is pretty far off what's really going on. I actually spent
a lot of time on this exact issue to make sure it works the best
possible. In fact, the entire rewrite from USB control msgs to bulk msgs
in fall 2009 was for a similar reason.
The README.txt in the firmware describes the USB protocol. Instead of
using synchronous control messages like xu1541, we use bulk messages and
split command/status phases by polling for the status. This was done to
support infinite listener hold-off while still allowing the user to
abort and restart commands. No other interface (even XAP1541) supports
this fully.
USB control messages require a hard timeout of a little less than 2
seconds. If a device takes longer than that to complete a message, the
host can abort the command unconditionally.
Bulk messages are all independent so we can write a command to the
outbound pipe, and poll indefinitely for a response from the status
pipe. This allows us to do commands like "cbmctrl change" where we have
to wait forever for the user to change disks.
Actually, the code waits the max timeout limit of libusb, which is 2
billion milliseconds or about 24 days. :) You can't let the command
timeout because the host controller is then in an indeterminate state
and you need to do a USB bus reset.
But how do we handle aborts (user pressing ^C because they're tired of
waiting)? There's a flag that gets set by the first message of a
"transaction", the INIT message (cmdSeqInProgress). This in-progress
flag is cleared by the SHUTDOWN message. OpenCBM sends INIT when opening
the device and SHUTDOWN when closing it.
If another INIT message is received but in-progress is set, the last
command must have died and we need to reset the IEC bus to get control
of the drive again. In this case, we set another flag (doDeviceReset)
indicating we need to interrupt any command being run by the firmware
and reset the IEC bus.
INIT is a control message, handled in an irq by the firmware so it can
override any bulk message that was being processed previously. Bulk
processing exits early if we're going to do a reset.
The routine that checks this flag, does maintenance tasks, and resets
the watchdog is TimerWorker(). If you look throughout all the loops, it
is called from many places. This way we keep the watchdog running but
keep polling a flag that allows the user to regain control of the device
without unplugging it from USB and back again. This is what you're
looking for.
This all works fine. All the protocols (IEC original, s1, s2, pp) call
TimerWorker(). You can test aborting them repeatedly and re-running
commands and they pick up as expected. I spent a long time trying to get
that to work well and it does mostly.
I have seen once or twice that I had to repeat a reset command if I was
jamming on ^C and restarting commands dozens of times. It's a minor nit
but one I'm interested in fixing. But this isn't the problem.
The only loop that does not call TimerWorker() is the nibbler routines.
If you look in nib.c, there are bare loops that don't call
TimerWorker(). I added in calls to it back in Jan 3, 2011 but reverted
it on Jan 10 before the first ZF firmware release.
The nibbler routines are extremely timing-sensitive compared to the
others. We have 25 microseconds per byte (200 clocks at 8 Mhz, 400 at 16
Mhz). This includes reading the full byte and any USB buffer management
overhead. Since the hardware accelerates the latter, we can meet the
deadlines but there is no room for extra operations.
When I added calls to TimerWorker(), it broke the 8 Mhz USBKEY devices
(but worked on the ZF). Now there are only a few of those devices, but
it's still worth supporting. The overhead of the function call and only
a few other instructions was enough to fail.
It may be possible that I can inline TimerWorker() and add a separate
function for status indicators. This may make it possible to meet the
timing deadlines on USBKEY devices. I can't just add an indiscriminate
WDR instruction because then when drives go away or the user aborts
nibread, they'll have to unplug/replug their USB device to make it work
again. Might as well disable the watchdog in this case.
Just so we're clear, the drive is never coming back from the state it
was in, even if we waited longer. For Gene using the -d flag with
nibread on a protected disk, that flag waits for sync that would never
appear. For Rob, my guess is either alignment or a dirty head means it
occasionally never raises the sync signal.
So they would have to ^C nibread at some point. The options until I can
optimize the TimerWorker() then are:
1. Replug the USB cable (if we disable watchdog completely)
2. Wait 1 second for the bus to reset (current)
I chose #2 as more palatable for users for now.
This is the only loop I know of that does not poll the abort flag and
tickle the watchdog. And it only does so because the timing was so
sensitive. The IEC routines (and s1, s2, pp) are all fine. They can be
interrupted cleanly. I plan to look into instruction counting and seeing
if we can optimize things to fit the WDR/poll for abort into the nib loops.
As for this being bad USB behavior, it's definitely allowed by the spec.
The device just gets re-enumerated. The many error messages are the
fault of OpenCBM and/or nibread, which don't stop sending new commands
even if old ones encountered an error while the device is in reset.
Hope this explains things fully,
--
Nate
robohara
the test I performed and the results I got:
01. Downloaded random .G64 disk image from the Internet (image1.g64)
02. Wrote G64 image to physical floppy using NIBWrite
03. Floppy booted and ran on real C64 with no errors.
04. Read physical disk into NBZ format using NIBRead (image2.nbz)
05. Converted NBZ into G64 using NIBconv (image2.g64)
06. Loaded and ran image2.g64 in WinVice.
When reading the disk in with NIBRead I still got "bad/weak" on most
tracks, and when converting the NBZ to G64 I got "badgcr" for most
tracks. All signs point to dirty drive, so I'm off to get some rubbing
alcohol (for the drive) and some drinking alcohol (for me).
Pete Rittwage
Bad/weak is normal as long as it's a few bytes- all disks have some on the write splice. So in this case with this disk, no crazy read errors occurred during the read back of the newly written disk? That's strange, if they are still happening on your other disks. Perhaps they are just bad...
What drive speed is being reported when you write disks with nibtools?
-Pete
robohara
> Bad/weak is normal as long as it's a few bytes- all disks have some on the
> write splice. So in this case with this disk, no crazy read errors
> occurred during the read back of the newly written disk? That's strange, if
> they are still happening on your other disks. Perhaps they are just bad...
>
> What drive speed is being reported when you write disks with nibtools?
still get errors -- enough that the ZoomFloppy disconnects/reconnects.
I tried upping the retries in NIBRead with the -e# switch but it
doesn't seem to matter. Once I hit a bad track, I get the ol' Windows
"Beep Boop, Boop Beep!" and the ZoomFloppy disconnects.
I was able to read in Disk 1, Side 1 of my old original GEOS Disk,
convert it to G64 and get it to load, so hardware-wise I think
everything's a go at this point.
Nate Lawson
> On Apr 4, 8:53 am, Pete Rittwage <rittw...@gmail.com> wrote:
>> Bad/weak is normal as long as it's a few bytes- all disks have some on the
>> write splice. So in this case with this disk, no crazy read errors
>> occurred during the read back of the newly written disk? That's strange, if
>> they are still happening on your other disks. Perhaps they are just bad...
>>
>> What drive speed is being reported when you write disks with nibtools?
>
> After cleaning the head on my 1541 I'm getting better results, but I
> still get errors -- enough that the ZoomFloppy disconnects/reconnects.
Sorry to hear that. It might be alignment or some other drive problem.
Is there any way you can try using a different drive? If you used the
solderless parallel cable, it should be easy to move it to another 1541.
This would isolate whether it's the ZF or drive.
> I tried upping the retries in NIBRead with the -e# switch but it
> doesn't seem to matter. Once I hit a bad track, I get the ol' Windows
> "Beep Boop, Boop Beep!" and the ZoomFloppy disconnects.
>
> I was able to read in Disk 1, Side 1 of my old original GEOS Disk,
> convert it to G64 and get it to load, so hardware-wise I think
> everything's a go at this point.
I assume you were able to read this disk without the ZF resetting,
right? Does this disk always read ok or does it also cause a ZF reset
occasionally?
--
Nate
Psycho
I now stumbled over a disk that causes the same USB error here.
I was dumping the game 'Netherworld' and everything looked real fine, until nibread came to track 36.
That's where zoomfloppy hungs up with the following message:
USB error in Xum1541_control_msg:libusb0-dll:err [control_msg] sending control message failed, win error: Das Gerät erkennt den Befehl nicht
The last german sentence means something like 'device does not recognize command'
I tried it several times now and it's always the same. I successfully dumped other games with the GMA/Securispeed protection, like IO or Samurai Warrior, if that matters.
It's only this disk so far that causes this problem. I tried to skip the endtrack via nibread -E35, but that's no help as the image won't work in Vice. It's looking for data on Track 38, I think.
Thanks.
Nate Lawson
> I now stumbled over a disk that causes the same USB error here.
>
> I was dumping the game 'Netherworld' and everything looked real fine, until nibread came to track 36.
> That's where zoomfloppy hungs up with the following message:
>
> USB error in Xum1541_control_msg:libusb0-dll:err [control_msg] sending control message failed, win error: Das Gerät erkennt den Befehl nicht
>
> The last german sentence means something like 'device does not recognize command'
>
> I tried it several times now and it's always the same. I successfully dumped other games with the GMA/Securispeed protection, like IO or Samurai Warrior, if that matters.
> It's only this disk so far that causes this problem. I tried to skip the endtrack via nibread -E35, but that's no help as the image won't work in Vice. It's looking for data on Track 38, I think.
The question is "why is the drive code not responding?" I don't know what's on track 36 of that title, but perhaps Pete Rittwage could give more info.
-Nate
Peter Rittwage
me...@gmx-topmail.de
If this does not work do you have a 1571 drive or can you get one to test out a different nibread disk imaging routine?
Can you please tell us which drive type you are using, which ZoomFloppy firmware, which opencbm and nibtools versions, and which nibread commandline?
Regards
Arnd
-------- Original-Nachricht --------
> Datum: Wed, 1 Aug 2012 09:27:36 -0700 (PDT)
> Von: Psycho <psycho...@gmx.de>
> An: zoomflop...@googlegroups.com
> CC: robo...@gmail.com
> Betreff: Re: NIBRead Woes
Klotz
But it didn't work either. Same result on track 36.
My drive is a 1541 with Speeddos+, firmware is the latest released I
guess (date is September 2011).
Don't know how to check opencbm version though. But the cbm files
(cbmctrl etc) are also dated September 2011. They were probably updated
with the firmware? Nibtools built is 2012-07-20
I'll try to find my 1571 and hook it up.
Thanks,
Chris
Klotz
nibread says '2 Killer' on track 36,37,39 and 40. Track 38 shows [NDOS]
Now, should I keep my 1571 hooked up with my zoomfloppy? Why does it
fail on my 1541?
Cheers,
Peter Rittwage
Ha, I got it working with my 1571.
nibread says '2 Killer' on track 36,37,39 and 40. Track 38 shows [NDOS]
Now, should I keep my 1571 hooked up with my zoomfloppy? Why does it fail on my 1541?
Cheers,
@Psycho: Can you please try again with "nibread -n image.nib" and report back?
If this does not work do you have a 1571 drive or can you get one to test out a different nibread disk imaging routine?
Can you please tell us which drive type you are using, which ZoomFloppy firmware, which opencbm and nibtools versions, and which nibread commandline?
Regards
Arnd
-------- Original-Nachricht --------
Datum: Wed, 1 Aug 2012 09:27:36 -0700 (PDT)
Von: Psycho <psycho...@gmx.de>
Klotz
Well, killer is an all sync track, which it appears your 1541 is not detecting. �
That's odd, because usually the problems go the other way- works on 1541, not 1571 due to how it reads weak areas.
My images of that game don't have killer tracks, so yours must be different somehow.
On Thu, Aug 2, 2012 at 7:11 AM, Klotz <psycho...@gmx.de> wrote:
Ha, I got it working with my 1571.
nibread says '2 Killer' on track 36,37,39 and 40. Track 38 shows [NDOS]
Now, should I keep my 1571 hooked up with my zoomfloppy? Why does it fail on my 1541?
Cheers,
@Psycho: Can you please try again with "nibread -n image.nib" and report back?
If this does not work do you have a 1571 drive or can you get one to test out a different nibread disk imaging routine?
Can you please tell us which drive type you are using, which ZoomFloppy firmware, which opencbm and nibtools versions, and which nibread commandline?
Regards
Arnd
-------- Original-Nachricht --------
Datum: Wed, 1 Aug 2012 09:27:36 -0700 (PDT)
Von: Psycho <psycho...@gmx.de>
CC: robo...@gmail.com
Betreff: Re: NIBRead Woes
Hi.
I now stumbled over a disk that causes the same USB error here.
I was dumping the game 'Netherworld' and everything looked real fine,
until
nibread came to track 36.
That's where zoomfloppy hungs up with the following message:
USB error in Xum1541_control_msg:libusb0-dll:err [control_msg] sending
control message failed, win error: Das Ger�t erkennt den Befehl nicht
The last german �sentence means something like 'device does not recognize
command'
I tried it several times now and it's always the same. I successfully
dumped other games with the GMA/Securispeed protection, like IO or Samurai
Warrior, if that matters.
It's only this disk so far that causes this problem. I tried to skip the
endtrack via nibread -E35, but that's no help as the image won't work in
Vice. It's looking for data on Track 38, I think.
Thanks.
Am Freitag, 1. April 2011 01:57:18 UTC+2 schrieb Rob O'Hara:
I got my ZoomFloppy yesterday, and installed Peter Scheper�s pre-wired
me...@gmx-topmail.de
Can you please post the complete nibread console text output or the generated logfile? It might help us.
Regards
Arnd
-------- Original-Nachricht --------
> Von: Klotz <psycho...@gmx.de>
> An: zoomflop...@googlegroups.com
> Betreff: Re: NIBRead Woes
me...@gmx-topmail.de
Your 1571 isn't equipped with a parallel port like your 1541, is it?
Klotz
Nate Lawson
Thanks,
Nate
On Aug 2, 2012, at 5:04 AM, Peter Rittwage wrote:
> Well, killer is an all sync track, which it appears your 1541 is not detecting.
>
> That's odd, because usually the problems go the other way- works on 1541, not 1571 due to how it reads weak areas.
>
> My images of that game don't have killer tracks, so yours must be different somehow.
>
>
> On Thu, Aug 2, 2012 at 7:11 AM, Klotz <psycho...@gmx.de> wrote:
>> Ha, I got it working with my 1571.
>> nibread says '2 Killer' on track 36,37,39 and 40. Track 38 shows [NDOS]
>>
>> Now, should I keep my 1571 hooked up with my zoomfloppy? Why does it fail on my 1541?
>>
>> Cheers,
>>
>> Chris
>>
>>>
>>> Datum: Wed, 1 Aug 2012 09:27:36 -0700 (PDT)
>>> Von: Psycho <psycho...@gmx.de>
Nate Lawson
>> On Wed, Aug 1, 2012 at 2:33 PM, Nate Lawson <na...@root.org> wrote:
>> All the USB message means is that the drive code that nibread installs in RAM did not respond in time, so the watchdog timer ran and reset the transfer.
>>
>> The question is "why is the drive code not responding?" I don't know what's on track 36 of that title, but perhaps Pete Rittwage could give more info.
>
>
> I don't have a good solution for these types of tracks at this time other than Nate increasing the timeouts a bit in Zoom firmware. Index hole routines do not work either for the same reason- it times out waiting for the signal (up to 200ms) and resets ZF.
>
> The other option is for someone with more free time than me (at the moment) to rewrite the nibtools routines to constantly send a stream of data that is interpreted at the host, instead of waiting for events to happen in the drive and send just data bytes.
Note that this is after the seek, so that isn't counted here. It's just the time between sending "read track" and the first GCR starting to stream back.
I can possibly extend this if there is some reasonable interval, say 4 seconds or less.
-Nate
Peter Rittwage
I think its the same code but I can check.
Peter Rittwage
That should be more than enough. This has always been broken in SRQ version and I thought we talked about it before. I recall Arnd rewrote something but we waited and released the old version. I'll have to go back through email to remember...