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.

Thanks

  • 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 '17 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 '17 at 17:36
  • @dirkt not for me considering I still use my many "vintage" computers quite often. :-) – cbmeeks Feb 9 '17 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 '17 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 '17 at 16:15
up vote 8 down vote accepted

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 '17 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. – Nick Westgate Feb 10 '17 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 '17 at 19:58
  • 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 Feb 10 '17 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 '17 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 '17 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 '17 at 5:33
  • Don't worry; you'll have more reputation soon. Perhaps you could answer some unanswered questions. – wizzwizz4 Jun 20 '17 at 7:07
  • @rolandgust Good point,and nice to see you here. I'll upvote you for now so you can comment, but I think my answer is still pretty good because I quoted you! ; - ) Cheers! – Nick Westgate Jun 20 '17 at 22:52
  • I would expect that 4+4 would have allowed faster read speeds under various RAM constraints, and likewise write speeds. Store D as ((D>>1) and $55)+$95 and (D and $55)+95 and it can be decoded as ((B1 and $55)<<1) +(B2 and $55) without needing any other lookup table. It may be possible to process 6+2 in real-time if one has enough lookup tables, but only if one doesn't need that RAM for other things. – supercat Jun 21 '17 at 16:25

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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