search

keirf / greaseweazle

Tools for accessing a floppy drive at the raw flux level
The Unlicense
998 stars 100 forks source link

Flux Underflow writing SCP #170

Closed drdpj closed 2 years ago

drdpj commented 2 years ago

Bit of an unusual SCP, mind - for a victor 9000. We know this works on a supercard pro. I'm trying to write it with an F7v1, using a TEAC FD55-GFR at 360rpm, high density, it underflows at track 62, but using an FD55-FV (the standard density model) at 300rpm it underflows at track 5... Offending SCP file is here: https://t.co/zzOUsxN99Z

drdpj commented 2 years ago

Should also say this is firmware 1.0 and tools 0.38.

keirf commented 2 years ago

I'll take a look at the SCP but on first blush flux underflow is usually a usb bandwidth issue so check gw bandwidth

drdpj commented 2 years ago

That's alarming! - This is plugged into a USB2 port. Min. / Mean / Max. Write Bandwidth: 4.211 / 4.220 / 4.228 Mbps Read Bandwidth: 7.556 / 7.556 / 7.568 Mbps

Estimated Consistent Min. Bandwidth: 3.790 Mbps -> WARNING BELOW REQUIRED MIN.: 4.627 Mbps

What's confusing me is why it's barfing earlier at 300rpm which, in theory, should be less bandwidth required?

drdpj commented 2 years ago

I've tried a bunch more ports and found one that seems to give a sensible set of values: Min. / Mean / Max. Write Bandwidth: 8.302 / 8.339 / 8.399 Mbps Read Bandwidth: 9.205 / 9.206 / 9.221 Mbps

Estimated Consistent Min. Bandwidth: 7.472 Mbps -> Max. Flux Rate: 0.841 Msamples/sec -> Min. Ave. Flux: 1.190 us

I had no idea these things were so touchy. I believe I've got success now - I've actually managed to write out a ridiculous victor 9k disk which appears to read back in OK and verify with the fluxengine software. Needs testing on a real victor! I think this can be closed now.

On Tue, 22 Feb 2022 at 20:14, Keir Fraser @.***> wrote:

I'll take a look at the SCP but on first blush flux underflow is usually a usb bandwidth issue so check gw bandwidth

— Reply to this email directly, view it on GitHub https://github.com/keirf/greaseweazle/issues/170#issuecomment-1048173936, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATU2PCOGBYTJB6UQF42QDLU4PVC5ANCNFSM5PCHEMXA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

keirf commented 2 years ago

The F7 OTG stack could be optimised/pipelined some more but since no F7 boards are being produced now, there's not a lot of motivation. Furthermore this could even simply be a limitation of some ports with full speed devices (which would typically require negligible bandwidth, hence bandwidth bugs like this would not be noticed).

In short: yes, unless you have a burning desire to dig into this some more with further usb tests with a range of Greaseweazle types, we are done here ☺️

keirf commented 2 years ago

Re 300rpm vs 360rpm, there's an increase in bytes per flux at around 3.5us above which flux values are represented by two bytes rather than one. Hence 360rpm can be more efficient in bandwidth if the smaller flux values are more likely to each be represented by a single byte. Of course as you move to higher tracks the flux times get longer, you move above the 3.5us threshold, and you hit the usb bottleneck.

drdpj commented 2 years ago

That makes sense. As an aside - this is really quite exciting. The victors are terrible to get software onto - you need another victor to write the disc, and then you need to transfer software over by serial. This looks like the solution to the bootstrapping problem. I should probably get a v4 to test on. Will drop a message on FB :)