Tor wrote:Hmmm... Not entirely sure I should try, given that I have very little programming experience - and none with drivers, or anything near that old (all of those systems are legend to me).
If one never tries, then one will never know for sure whether it was possible or not. Recall that this is technology that's been dead for well over a decade, and the last time (other than this past April) I got hands on any of it was 30+ years ago.
What does cross my mind (yours too?) is the possibility that someone could have been trying to get it working the right way, but added that as a kluge after getting frustrated with debugging - and then got distracted before fixing it. Seems I've done that kind of thing before, improper and ugly though it may be.
I'm not willing to put it down to that. The culture when this code was written (1977) was
very different than it is now where
everything is geared to "get it out the door NOW!" The culture in computing in the late '70s was cutthroat, but in a more genteel way than it is today. Folks were expected to produce quality results that would scale and would still fit within the memory-footprint of the machines of the era.
Yes, I've been forced to produce some really cr@p code on occasion, mainly by incompetent and pernicious managers -- and I've positively hated doing it because some poor SOB is going to have to maintain it when I'm gone. The old adage of "pay it forward" holds in this regard.
In any event, my immediate quandary was solved by looking at pieces of code from later operating systems that included disks with different geometries. One got it "right" (and validated what I wanted to do), and the other was a kludge that hard-coded the value as part of a skip-chain.
I'm not going to rubbish the original author's code, both out of respect for his standing in the community, and out of respect for the dead, but the version that I'll do will be fully-generalized to handle arbitrary disk geometries, and take up, perhaps, a half-dozen more words of core.
Internally, the OS looks at a disk drive as one large contiguous collection of blocks and doesn't worry about the geometry (number of cylinders, heads, and sectors (C/H/S)) -- that gets done at the controller-interface layer where all the drives required the C/H/S addressing notion because that was how things were done at the time. What we're seeing here is the way that the technology advances -- we're seeing it through the lens of the "archaeologist's eye" because we "know how it should be done" (until the next jump happens). This is why it's important to study the past: it helps us to not repeat the mistakes made by our forebears.
I know that this has precisely nothing whatsoever to do with skirts, and that's why it's in the "Off Topic" section. But,
does it have anything to do with skirts? It certainly points up that if you never try, you'll never know, and if you don't push your own boundaries you're stuck in a box. I am not an Operating System Programmer, and never have been. I haven't even played one on television. Yet, here I am deep in the bowels of one, adding capabilities and smoothing out decisions that whilst may have made sense when the code was written were invalidated later on.
That's pushing one's own boundaries.
If one doesn't push past the expectation of trousers, then one will be confined in them for one's lifetime. Get brave. Push!
