7

Although the 1571 is capable of reading and writing both sides of a disk, accesses to the second side using the second head will be performed with the drive spinning in opposite direction from how it would be read if inserted upside-down and accessed with the first head (only head on the 1541). Conceptually, however, it would seem like it should be possible to write a disk which could be read in either direction, either by:

  1. If one only needed to use about half the capacity of the second side, one could format the disk side with a mixture of forward-written and reverse-written sector headers. Track 18, for examine, which would normally contain 17 sectors, could have eight reverse-written headers for sectors 0-7, followed by eight forward-written headers for sectors 0-7. If the BAM for the "read as flippy" direction marked as "used" all of the sectors that didn't exist in that direction, inserting the disk as a flippy would simply make it appear as a normal disk that appeared full despite having less than 85K of stuff on it. Presumably, to make the other side compatible with 1541 drives, it would be formatted as a normal 170K disk, so any data on the reverse would have to be accessed using track/sector accesses.

  2. If one needed to use more of the capacity, one could write much of the data using a custom format that would precede each sector with a forward-written header and immediately follow it with a reverse-written one. Reading a reverse-written sector would require different decoding logic from reading a forward-written one, but I don't think the drive electronics should care about whether the data is being read forward or backward.

Would such a thing have been possible? Has anyone ever done it, either back in the day or in the "retro-computing era"?

Improve this question
13
  • The biggest problem I see is that even the 1571 only has 2K RAM, and you need to store the code that deals with all the clever modifications somewhere.
    – dirkt
    Sep 20, 2020 at 21:00
  • @dirkt: Reading or writing the forward and backward formats wouldn't really be terribly different from handling other custom formats such as those used by the Vorpal Disk Utility. BTW, I was really bummed back in the day at the 1571's failure to include 8K of RAM, since 8Kx8 RAM chips were commonplace and even 32Kx8 chips were available, and since being able to buffer a track would have made it possible to improve performance enormously. If code asks for track 4 sector 2, and after moving the head to track 4 the drive sees a header for track 4 sector 5, reading that sector...
    – supercat
    Sep 23, 2020 at 18:50
  • ...would cost nothing if buffer space is available. Pre-emptively reading an entire track any time code asks for a sector would slightly increase the time required for the operation, but if code ends up wanting two or more sectors from the track, it would be a net performance win.
    – supercat
    Sep 23, 2020 at 18:55
  • Again: You'll have to write code that cannot re-use much of the ROM. GCR tables backward will be different. Writing an address header backward will be different. 2K is not a lot, and you still need some of that for buffers. Maybe it can be done in 2K, but it will be pretty tricky. Only way to find out is to actually sit down and actually write it ...
    – dirkt
    Sep 23, 2020 at 19:54
  • @dirkt: In Commodore's encoding, every quintuple is either symmetrical or else has a mirror-image counterpart. Thus, from what I can tell, reading data backward and decoding it using the normal tables would yield a bit pattern from which the forward data could be determined by reversing the order of nybbles and then applying a lookup table; such things could be done on the C64/C128 if need be to avoid the need to have the drive do them.
    – supercat
    Sep 23, 2020 at 20:42

1 Answer 1

Reset to default
3

It's not just the drive spinning in the opposite direction; tracks are also offset by about 8 track widths between front and back to prevent both mechanical (squeezing the disk too hard) and electrical (interference) problems.

Foone recently talked about that on Twitter: https://twitter.com/foone/status/1267014860589555712

So even if you could solve the "reading backwards" issue by some clever reprogramming of the drive, 8 tracks on the reverse side would remain mechanically inaccessible.

Improve this answer
7
  • Surely that makes things easier with respect to the only-use-half suggestion as you therefore don’t have to craft an eighteenth track that can be read in either direction?
    – Tommy
    Sep 20, 2020 at 20:11
  • It depends on what you're trying to achieve, really -- if you only want to divide the second side into two non-overlapping partitions, then yes, that makes it easier, and gives you some extra capacity. However, I don't see what you would achieve this way...
    – Michael Graf
    Sep 20, 2020 at 21:47
  • Re, "solve the 'reading backwards' issue," Could be somewhat of an engineering problem. I don't remember much about what "formatting" looks like on a disk or how it's used, but I don't imagine that the stock hardware would even recognize that the disk was formatted if it was spinning the wrong way.
    – Solomon Slow
    Sep 21, 2020 at 11:17
  • @SolomonSlow: If the disk only had headers written in one direction, that would be correct, but the drive would be capable of writing headers in either direction.
    – supercat
    Sep 21, 2020 at 12:38
  • @MichaelGraf: My design thought had been, among other things, to make it so that a game which would normally have a "boot side" and a "play side" wouldn't need to be flipped over when using a Commodore 128 and 1571 drive, but would still be playable on a 1541. And for that purpose, having tracks that would be available on the 1541 but not 1571 and vice versa would be fine.
    – supercat
    Sep 21, 2020 at 12:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .