scarybeast

@tptacek -- you're so awesome. I keep meaning to reply on some of these security threads but then I see you've made the relevant points of sanity in a well reasoned manner.

For what it's worth, when I was setting up the culture and values of Google's first bug bounty programs, I hammered "be magnanimous" into the reward committees. i.e. look for reasons to reward more, not less. Find the value in the information provided, even if the person is being a jerk. etc. I don't think this culture has changed. There are teams of people rooting for incoming reports to succeed, and they get excitement and joy from issuing large bounties (because this means Google security is getting stronger).

The floppy disc controller doesn't have a way of knowing if the write worked or not. There are some corner cases here, like the drive can signal a fault line if it's on fire, but if there's simply a dodgy patch of disc surface, nothing will be apparent during the write.

So, the operating system could verify the write by reading it back, but I don't think the BBC Micro disc ROMs typically did that for file writes -- only for formats.

Do you have any recommendations for any particular techniques or software? I'd gladly try them.

Great that you're working on something similar! How are you finding those tools for handling degraded tape waveforms? I keep bouncing back and forth between hacking up my own vs. wanting to find some existing tool that has some clever math formula.

I'd personally phrase things a bit differently: an _individual_ was able to pull this off while surrounded by screaming children. A large government, with all its resources and hundreds+ of people, would pull this off regularly and without breaking a sweat.

We definitely wanted fun! I guess there are two ways to slice and dice it: 1) fun because the application is exotic / iconic, or 2) fun because the chip is exotic. This is definitely a case of the latter: an exotic chip with interesting history.

I think this is a bad decision. The "in-the-wild" part is the interesting part because it is not the norm at all and it implies an interesting story.

That's an interesting story of the 6522 VIA for sure :) I don't think it is what I was hitting though, for a few reasons:

1) "The 6522 has a bug in mode 011, shifting synchronous serial data in under control of external CB1 clock" -- this is not the mode I tried.

2) The bug appears to be intermittent data loss. What I had trouble with seemed deterministic, the chip is just too slow to respond.

3) I wonder if this hardware bug was ever fixed? The BBC Micro doesn't use the MOS 6522 VIA. It tends to use Synertek or Rockwell. It's unclear if those companies were just using the buggy MOS mask under licence, or something else.