14

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.

Improve this question
15
  • 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 ♦
    Commented 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
    Commented Feb 9, 2017 at 17:36
  • 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
    Commented 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
    Commented Feb 10, 2017 at 16:15
  • 1
    I can't give out the exact location, but the search terms that you need are "prince of persia" "san inc crack". I can share how it was done, though: pferrie.host22.com/misc/lowlevel14.htm, and a variant was published in PoC||GTFO zine: pferrie.host22.com/papers/apple2_pop.pdf
    – peter ferrie
    Commented Feb 13, 2017 at 18:53

2 Answers 2

Reset to default
12

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
Improve this answer
13
  • 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
    Commented Feb 10, 2017 at 16:51
  • 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
    Commented Feb 10, 2017 at 19:58
  • 2
    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.
    – Nick Westgate
    Commented Feb 10, 2017 at 20:23
  • Would 6+2 say anything about how the second byte of data should be encoded [e.g. I think a fast approach using one 128-byte table would build groups of three bytes from groups of four raw chunks (8 bits each before decoding or six after) by having twelve bits mapped directly but having the other twelve stored as the xor of 2-3 bits from the original data; would that still be called 6+2, or something else?]
    – supercat
    Commented Feb 10, 2017 at 22:40
  • 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
    Commented Feb 11, 2017 at 8:32
19

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.

Improve this answer
10
  • 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 ♦
    Commented 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
    Commented Jun 20, 2017 at 5:33
  • Don't worry; you'll have more reputation soon. Perhaps you could answer some unanswered questions.
    – wizzwizz4 ♦
    Commented 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
    Commented 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
    Commented Jul 6, 2018 at 20:02

You must log in to answer this question.

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