I was reading about Prince of Persia over at POP Code Review. In that article, the writer printed an interview with Roland Gustafsson, the inventor of RWTS18 copy protection for the Apple II series.

Roland says:

It would have been better for them to have created a copy-system that created exactly the same format, RW18 and just make exact copies!! The experience was MUCH better, faster, etc.

As a kid, when I played these games (including C64 games) I seriously thought all of these "cracktros", "trainers", etc. were actually a part of the game! It wasn't until much later I realized that they were pirated games.

Anyway, my copy of Prince of Persia came on three disks. Turns out, that's because it was cracked to fit on the standard RWTS16 format from Apple which only supported 140K disks instead of the 157K (two disk) version of the original POP.

So, my question is, how would it have been much better? Other than a little less disk swapping. Even with the three disk version, I don't remember it being terrible with constant swapping.

The only real negative I remember is that is crashed frequently. I suppose this is because of the cracked version? I never had the original to compare.


  • 1
    The game was designed and optimised for this file format. It's a little like saying "How can memory optimisation make a game faster / better?", but for a disk instead of RAM.
    – wizzwizz4
    Feb 9, 2017 at 16:23
  • 1
    "Better" in the sense of "loads faster, less disk swapping". Not "better gameplay". It's easy to forget today how slow loading from a disk was.
    – dirkt
    Feb 9, 2017 at 17:36
  • @dirkt not for me considering I still use my many "vintage" computers quite often. :-)
    – cbmeeks
    Feb 9, 2017 at 18:17
  • 2
    C64 disk I/O was slow due to the CPU doing all the bitwise work (due to chip/manufacturing issues preventing the CIA chips from being able to do the work), so that's not a great comparison point. :) The first computer/drive combo to work as originally intended over the serial cable was the 128/1571
    – Joe
    Feb 9, 2017 at 19:14
  • 1
    @SF. do you remember when magazines would have a BASIC program that did CRC checking on hex dumps of their code? Then we would sit with a ruler and type on pages and pages of hex values to play some cheesy game? Those were the days. :-)
    – cbmeeks
    Feb 10, 2017 at 16:15

2 Answers 2


Less disk swapping, but also faster loading. Much of the performance improvement in Apple II fast DOS implementations (including ProDOS) was due to less latency between reading sectors - and this happens naturally (in a game) when there are more sectors per track and you read them all. By the time you've read a sector and finished processing it, you arrange for the next sector you need to be right under the drive head ready to be read next.

Roland in another interview: (with some similar answers - he must use a FAQ!)

The true speed-up came with sector-latency reading... where the read routines would just start reading whatever was under the head, I used this with the 18 sector routines so the maximum latency was 1/6 revolution of the disk.

At the same link there's actually mention of pirates writing dedicated copiers ("Gogsmith") to reproduce specific 18-sector titles - exactly as Roland suggests in cbmeeks' question's quote.

But as wizzwizz4 implies, although the performance and storage increase were impressive, it's unlikely it would have been suitable for a general-purpose Disk Operating System, since the requirements are quite different. For instance after reading or writing a sector there would be no guarantee that the next sector needed would be under the drive head.

Of course Roland also wrote RDOS for SSI - 13 and 16-sector versions, but not an 18-sector one.

Here's a comparison of nibble encodings and their storage capacities:

Nibbles  Sectors/Track  Total Disk Space in: Bytes   kB
4+4      10                                  89600   87.5
5+3      13                                  116480  113.75
6+2      16                                  143360  140
6+2      18                                  161280  157.5
  • What do 4+4, 5+3, etc. mean? I would guess the fastest format uses two bytes of raw disk data per byte of useful data storage, but what do the other numbers mean?
    – supercat
    Feb 10, 2017 at 16:51
  • Yes, exactly. That's worth a whole question itself, but basically 4+4 is like MFM, and 5+3 and 6+2 are GCR - all done in software on the Apple II so 4+4 is faster because it's simpler. A few books e.g. Beneath Apple DOS have more details. Feb 10, 2017 at 19:41
  • I'm familiar with the principles of GCR, but I'm not sure about the numbering. Since each 8-bit chunk of storage on the disk needs to hold one of 81 distinct values, is the chart simply saying that each 8-bit chunk is used to hold 4, 5, or 6 bits of useful data? Does the number after the + mean anything?
    – supercat
    Feb 10, 2017 at 19:58
  • 1
    Yes, but from a different perspective. The encoding name refers to the way source data is split into disk nibbles. 6+2 means 6 bits get translated into one nibble, two into another (with 4 other bits to make up to six total). Each encoding scheme uses a different number of possible nibble values, not always 81. Feb 10, 2017 at 20:23
  • 1
    And with the reduced gaps there would also be problems writing sectors randomly, instead of writing the whole track at once as it's probably done to create the disks.
    – dirkt
    Feb 11, 2017 at 8:32

The assertion that 4x4 is faster is false, it's easier, yes, but not faster. RWTS18 could read the entire track in one revolution so it is the fastest. I know that 4x4 and 6x2 were also capable of reading in one revolution but not sure about 13 sector... don't think anyone ever tried. :-)

So RWTS18 gave the game developer faster speed, more space with the requirement that they had to manage disk space manually. The fact that it made it harder to crack was a side benefit but not the main goal, believe it or not! That crack that required 3 disks was chuckle-worthy to me and only when the true 2 disk version was recently created was I impressed with the results. (That crack used RWTS16 with data compression, something that was not widely used back in the day.)

RDOS was similar in that the space allocated for a file remained constant. This was to allow for as small an OS as possible.

  • Welcome to Retrocomputing Stack Exchange. Thanks for the answer. I didn't know that RDOS used a custom filesystem. Have you read the tour?
    – wizzwizz4
    Jun 19, 2017 at 4:36
  • Sorry, no, I tried to reply but didn't have the necessary points! :-) A bit frustrating when I know the exact answer because it's discussing something that I created! :-) I'm happy to contribute in those areas where I was involved back in the day. :-)
    – rolandgust
    Jun 20, 2017 at 5:33
  • Don't worry; you'll have more reputation soon. Perhaps you could answer some unanswered questions.
    – wizzwizz4
    Jun 20, 2017 at 7:07
  • 1
    @rolandgust: Data comes off the disk at a rate of roughly 32 cycles per "nybble" [octet], but unless it is written more slowly than usual, code should be prepared for it to arrive somewhat faster (e.g. once every 28 cycles). If code uses six cycles for a "LDY/BPL" sequence to wait for each byte, that would leave 22 cycles for other processing. Processing data that's stored using anything other than 4+4 encoding would require either using lookup tables, or reading sectors without translating the data and cleaning it up afterward.
    – supercat
    Jul 5, 2018 at 15:50
  • 2
    The bottom line constraint for speed was how much data could you load in a single revolution of the disk, assuming you could decode it as you loaded it. RW18 stored 0x1200 bytes, RWTS16 stored 0x1000, 4+4 stores about 0x0C00 and all can be decoded in single revolution. RW18 wins. :-)
    – rolandgust
    Jul 6, 2018 at 20:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.