Not ready error writing drive B - Amstrad PPC640/PPC512

[Leeev]

Hi,
I've got a small issue with FlashFloppy on my Amstrad PPC640 luggable.
I've installed it as Drive B: as the machine only had a single 720K DSDD floppy.
Using only jumper S1 and the current 2.14 firmware, the Gotek drive appears to work fine. I can copy disk images to the USB stick and they appear as B:. I can format them, copy/edit/delete files, the machine will even boot DOS off the Gotek. All good.

However, when I try to copy a file from A: to B: I get a
"Not ready error writing drive B"
I've tried swapping the drives to make the Gotek A: and the positions on the cable, but the result is the same. Also tried, M0 instead of S0 (general failure error). I've added "motor-delay=200" (no difference).
The only odd thing I've noticed is that the motor on the floppy drive spins up when I access files on the Gotek, which doesn't seem right.

Anyone else had this on a PPC? Any ideas on how to fix it? From the FAQ the Amstrad is supposed to be a 'standard Shugart' drive?

[keirf]

motor-delay=200 won't do anything unless you do the motor line hardware mod. This may or may not be your issue. I'm not sure PPC is explicitly discussed in the wiki.

You expect both drives to turn their motor on at the same time as they share a motor enable signal.

[Leeev]

Ah, right, so the motor spinning and delay is a red herring. Excellent.

The PPC640 is mentioned here in the wiki
https://github.com/keirf/FlashFloppy/wiki/Host-Platforms#ibm-pc

Testing some more, it seems coping files off the Gotek is OK, it's copying file to the Gotek is the issue. And even then, small files are copied OK, anything over about 6K fails with the Not Ready error.

Seems like it's timing out maybe?

I also have a parallel port SD adapter (that pretends to be a slow hard drive). This also has the same issues so it's not the physical floppy causing the problems, it seems like it's the Gotek.

[keirf]

Large writes may be taking time to write to usb and then the host is timing out waiting for the gotek to respond again. What stick are you using? Can you try another?

[bradwh]

What happens if you copy a large file from the Gotek back to the Amstrad's floppy?

[Leeev]

The original USB stick was a 3 year old 256MB stick I got free at an event, using it on a PC works fine, as does fully formatting it, and H2Test. I get that this may be junk though. So I gathered 8 other USB sticks I have on hand, from 1GB to 16GB in capacity, and makes like Kingston/Intenso/Toshiba. Formatted them all and copied over the images. They all exhibit the same issues, though the 'best' 16GB Kingston did manage to copy one 12K file over before it errored.

I wonder if this is a weird oddity that affects the Amstrad PPC's ?

[keirf]

Another thing to try, then, is index-suppression = no in FF.CFG

[Leeev]

Another thing to try, then, is index-suppression = no in FF.CFG

Ah! Now that seems to to have (almost) fixed the problem! I can now copy lots of files to/from the Gotek without the Not Ready error. Result!

However, I've noticed that occasionally it now throws up a Sector Not Found error reading from the Gotek. Pressing R for Retry reads the sector correctly (I compare the copied file to the original).

The error is completely repeatable, that file will Sector Not Found every time, with a single retry correcting the issue. Copying the same set of files off the floppy to another image on the Gotek, then copying them back to the floppy resulted in a different file have a repeatable SNF error.

Now it was late, but I think cycling the power caused that initial SNF file to copy OK, but another one then had the SNF error. I'll try this again tonight and also with another of the USB sticks.

[keirf]

Here's another recipe for you to try:

index-suppression = yes
track-change = realtime

I'm not sure this will work but worth a try. Otherwise I could try making index-suppression=no a bit less aggressive, perhaps targeting writes only.

EDIT: To be honest I'm not sure it's index related at all. The schematic for PPC640 doesn't have anything fancy happening with the index signal. Perhaps it is to do with where track read restarts after a write is completed. We could investigate that with some test firmware builds.

[Leeev]

index-suppression = yes
track-change = realtime

That worked too, but still have the same SNF error that worked after a retry.
I don't know about the inner workings, but I'm up for testing some new firmware!

[keirf]

Well, I'm kind of surprised that fixed the write errors :) I will work on a test firmware for you to try, that just tweaks the index-suppression=yes, track-change=realtime behaviour.

Meanwhile can you just double check no typos in your FF.CFG for the previous test: I'm that surprised it worked so well for you, I'm a little bit suspicious.

EDIT: Another way to test your previous configuration, would be to modify the track-change line to track-change = instant and observe that your original behaviour (Not Ready on writes) comes back. If so, switch it back again to track-change = realtime, observe the SNF error comes back, and then run the test firmware that I post here shortly.

[keirf]

Okay, here is a firmware to try. You should use it with the index-suppression = yes and track-change = realtime config options.

ff_320_1.zip

[Leeev]

No typos, all cut & pasted from your messages.
Above settings and errors as predicted.

New firmware flashed from the .upd file (two buttons pressed at power up), it said "Upd" on the display?

So my setting are currently -

nav-mode = indexed
interface = shugart
index-suppression = yes
track-change = realtime

But sadly it still gives Sector Not Found on copying stuff off the Gotek to the floppy drive.

Another thing I tried was tried was to used DISKCOPY to create a physical boot disk (for DOS 5) from an image on the Gotek, this gave "Unrecoverable read errors" on three "tracks" in the image, which was repeatable.

[keirf]

If you switch back to track-change=instant do the read and diskcopy (gotek to real drive) errors all disappear?

EDIT: Also what image type are you using? IMG files?

EDIT: And yes, Upd on display means you are in update mode. Then you should automatically return to normal operation after the update is completed.

[Leeev]

OK, switched back to track-change=instant and the read errors and sector not found errors disappear (I can complete the diskcopy ok now!). However the "Drive Not Ready" errors when writing files TO the Gotek have reappeared. Seems the firmware change wasn't effective? :(

Yes, I'm using 720K .img files (the floppy drive and controller are on Double Density) that I've found the net. The images seem OK in that I can open then up on my Linux PC, pull the files out of the them and the contents of the files seem OK.

[keirf]

This is just super weird. I don't suppose you have two real drives you can test, as a control case for copying between two drives on the PPC?

EDIT: Also, update to the latest v3.12a firmware for any further Gotek tests. That's the benchmark for debugging stuff, and we should drop the changes that I introduced in the ff_320_1 firmware above.

[Leeev]

I have another 3.5" floppy drive, but as it's a 1.44MB version I suspect it won't work with the PPC's 720K controller, but I'll give it go anyway this evening when I get home. Along with reverting to 3,12a.

[keirf]

1.44M should work fine, the interface is the same, and the 1.44M switches automatically between DD and HD operation. I suppose one possoble problem is Shugart vs PC interface (affects pin 34 primarily, which I think PPC doesn't use, but also the drive might respond as S1 rather than S0 drive select: Usually that is changeable via a jumper or soldered resistor on the drive PCB).

[Leeev]

Urgh! What an evening. I found two 3.5" drives. The first just gives errors when the PPC boots (drive or interface error in the POST before DOS boots. The second drive, a Sony, which I found the jumper settings for, gets past the boot but the head stepper motor appears to have failed. There is a slight spin of the gear rod then it errors. If I push the drive head to the outside, then it can read the directory track but obviously goes no further and errors. I've messaged a local friend who may have another drive, but not heard back yet.

[Leeev]

Right then, my friend found a pair of old drives, the first of which works like charm! I can copy files to/from the drive and do DISKCOPY's just fine. I even wrote a batch file to copy a set of files from one to the other and back again, over and over, while logging the results. Hundreds of copies later, not a single error!

So I guess that rules out errors with the Amstrad side of the hardware?

[keirf]

Yes, clearly the Amstrad and cabling is all fine.

So, I believe you have tried A: v3.12a with default config (track-change=instant and index-suppression=yes). And this gives file copy errors TO Gotek? The behaviour here is that whenever the Gotek changes track or a write finishes, the virtual disk stops spinning: Reads then restart at the exact rotational position that read ended (on previous track) or write ended (if we just ended a write).

This above behaviour caused Not Ready errors on BBC B which uses regular index pulses to detect a disk is inserted: If you stall the disk (and hence produce no pulses) the BBC throws errors. Hence config B: index-suppression=no which leaves the disk spinning during track changes, and rotates the disk to just before the index mark after a write ends (so an index pulse occurs asap after reads restart). It even inserts fake index pulses: On every head-step command, and immediately that a write is ended.

So that above configuration caused Read Errors for you. It is quite an aggressive configuration setting, tailored to BBC B, hence C: Trying revert to index-suppression=yes and instead try track-change=realtime. This setting affects only track changes, and causes the disk to keep spinning through the change. It does not affect write behaviour (compared with default config) at all. Hence surprising that this config behaved identically for you as B did.

But I'm struggling to see the pattern or what the underlying expectation is of the Amstrad. Or whether there's a bug or something in FlashFloppy non-default config.

One thing we could try is just turning on the write-related index trickery. But then you have seen the write problem disappear in C above which doesn't (directly) affect write behaviour.

Or we could try and knock a few edge bugs off of C, which I tried to do in the alt firmware posted earlier in this ticket, but I may have mucked up a bit. The bug in release firmware is: I may occasionally allow an index pulse when the read stream hasn't yet restarted: This is bad because the host usually times out a read after seeing two index pulses with no sector match (the idea being you've then seen at least one full revolution of the disk). It's a bit of a narrow window of a bug, and I'm not sure I would expect it to make the mess of reads that you are seeing....

[Leeev]

It occurred to me that I may have been using the 2.14 version of the firmware in some of the testing above, so I've reflashed to 3.12a and run all the permutations above again, and subject to also having "nav-mode = indexed" & "interface = shugart" above them, the results are -

a) "track-change=instant" and "index-suppression=yes"
Reads FROM the Gotek - all OK.
Writes TO the Gotek - small writes work, larger writes give "Drive not ready" errors*
Diskcopy TO the Gotek to floppy - the format works fine**, but then "Not ready error - make sure the disk in in the drive and the door is closed"
Diskcopy FROM the Gotek to floppy- Works great. Very confusing - see (b)

b) "index-suppression=no"
Reads FROM the Gotek - all OK.
Writes TO the Gotek - small/large files all OK.
Diskcopy TO the Gotek from floppy - all OK.
Diskcopy FROM Gotek to floppy - errors with "Unrecoverable read error". This is ALWAYS on side1/track8 and side1/track73 (sometimes plus side1/track57). ***

c) "track-change=realtime" and "index-suppression=yes"
Writes TO the Gotek - "Not ready error" no retries offered.
Reads FROM the Gotek - all OK.
Diskcopy TO the Gotek from floppy - the format works fine**, but the then "Not ready error - make sure the disk in in the drive and the door is closed"
Diskcopy FROM Gotek to floppy - errors with "Unrecoverable read error". This is ALWAYS on side1/track8 and side1/track73 (sometimes plus side1/track57).

*I was thinking that this may be a track change issue where the file spills over a single track?
** I think a previous error has wreaked the boot/partition sectors so it thinks the disk is unformatted.
***I've tried six different floppies, ten different images, from 4/5 different sources, always the same spots. I've stuck the USB stick back in the PC and extracted all the files from those images just fine.
Looking at the Gotek display, it reads the previous tracks showing the track number on the first two digits and the lower two segments of the third digit alternate and then it moves to the next track, but counts up through the tracks to that next track. When it errors it just counts up to that errored track, repeating three/four times then errors. Even when it doesn't actually error it may have a couple of attempts at reading track 57 before succeeding.

So, option (b) is almost there. Just some of the magic from (a) to cure its Diskcopy issues! :)

[keirf]

Okay, I may need to unpack the hacks I did for BBC B a bit, and add some configurability there. I will think about a new test firmware for you.

[keirf]

Ok here is one to try with default config, which is your (a) above: "track-change=instant" and "index-suppression=yes". It avoids stopping spinning the disk while draining a write to USB.

ff_320_2.zip

I think it is better to try fixing writes based on the default config, than massively perturb things as in (b) and fix up the fallout that affects reads. Let's see how it goes! This may or may not be enough.

[Leeev]

:( Still exactly the same I'm afraid.
Firmware 320_2 / 3.12b, track-change=instant / index-suppression=yes.

Reads FROM the Gotek - all OK.
Writes TO the Gotek - small writes work, larger writes give "Drive not ready" error
Diskcopy TO the Gotek to floppy - "Not ready error"
Diskcopy FROM the Gotek to floppy- all OKt.

[keirf]

Ok here's one with identical post-write behaviour to the BBC B hacks when index-suppression is disabled. Again, leave your config at the (a) defaults.

ff_320_3.zip

If this doesn't help, we'll have to try a different tack.

[Leeev]

And we have a WINNER!!
V3.12c works in all four of the test cases!

It could probably use some more testing, so I'll continue playing with the Gotek drive over the next week or so to give it a thorough workout.

[keirf]

We're almost there, but now to see which bit of the BBC B post-write behaviour is needed. There are two parts: 1. fake index mark immediately the write ends, and 2. restart read at end of track after write is drained to USB stick. I'm guessing (2) is the bit we need.

So here is another firmware to try, same (a) default config:

ff_320_4.zip

If this works, then I will make it configurable via FF.CFG, have you test that, and then we're done (it will be in next 3.x release)!

[Leeev]

You're the boss.

V3.12d works in all four of the test cases too!
Many files copied, many diskcopies to/from the Gotek. All perfect.

[keirf]

That's great, I will now sort out a firmware in which this behaviour is non-default but configurable. I will post it here soon.

[keirf]

Here it is. You should find that, as is, your writes fail. But this should then be fixed when you add write-drain=eot to your FF.CFG.

ff_320_5.zip

[Leeev]

So just to confirm my understanding -
"track-change=instant" and "index-suppression=yes" are the default settings?

I removed these params from FF.CFG and ran the tests again with v3.12d, all tests were successful.

I updated to v3.12e (still without any extra params), the usual errors returned.

I added the "write-drain=eot" param to FF.CFG and ran the tests again, all tests were successful !!

Nice :)

[keirf]

Excellent I will make sure this is in the next 3.x release!