CREATING THE 6-SIDE 16-SECTOR VERSION OF TOY SHOP ON THE APPLE II. (October 2014)

INTRODUCTION

They said that it couldn't be done. It only took 28 years to achieve (not least because no-one tried(*)). Finally, we have the first ever 16-sector version, and without requiring more disks!

This one was interesting in a completely different way to Prince of Persia. It seemed trivial at first, based on master side A, but became more difficult with master side B, and seemed impossible for the four sides of the two data disks.

It came to my attention in November of 2013, and I started work on it in January of 2014. Work on the master disk took about two months to complete, and a complete rewrite of the read routines. No 0-days here. After a couple of months break, another month was spent on the data disks.

THE EASY PART

We start with Master Side A. It is loaded into memory this way:

000102030405060708090A0B0C0D0E0F1011
T000868696A6B6C
T01202122232425262728292A2B2C2D2E2F3031
T0232333435363738393A3B3C3D3E3F
T03404142434445464748494A4B4C4D4E4F5051
T0452535455565758595A5B5C5D5E5F
...
T1C08090A0B0C0D0E0F10111213141516171819
T1D1A1B1C1D1E1F9A9B9C9D9E9FA0A1A2A3A4
T1EA5A6A7A8A9AAABACADAEAFB0B1B2B3B4B5B6
T1FB7B8B9BABBBCBDBEBFD0
T20E0E1E2E3E4E5E6E7E8E9EAEBECEDEEEFF0F1
T21F2F3F4F5F6F7F8F9FA
T21.5F2F3F4F5F6F7F8F9FA
T22F2F3F4F5F6F7F8F9FAFBFCFDFEFF

Track 00 is the 18-sector loader. Tracks 01-04 are the title page.

The code that is loaded to page $D0 is the Master side A copy protection. It reads track 21, track 21.5, and track 22. Any failure to read will result in a hang.

To make it all fit, I had to move some sectors. There are multiple possibilities, but I did it this way:

000102030405060708090A0B0C0D0E0F
T000868696A6B6C
T01202122232425262728292A2B2C2D2E2F
T02303132333435363738393A3B3C3D3E3F
T03404142434445464748494A4B4C4D4E4F
T04505152535455565758595A5B5C5D5E5F
...
T1C08090A0B0C0D0E0F1011121314151617
T1D18191A1B1C1D1E1F9A9B9C9D9E9FA0
T1EA1A2A3A4A5A6A7A8A9AAABACADAEAFB0
T1FB1B2B3B4B5B6B7B8B9BABBBCBDBEBFD0
T20E0E1E2E3E4E5E6E7E8E9EAEBECEDEEEF
T21F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF

That allowed me to keep the 18-sector interface code, and only the read addresses had to be changed ($32 -> $30, $52 -> $50, etc). Nothing was added. Even the copy protection at page $D0 is loaded and run, but altered to not engage the phases, leaving track $22 unused.

The 18-sector tracks on master side A were probably used just for faster loading. As you can see, there was plenty of room to convert them to 16-sector tracks.

THE HARD PART

Now we move to Master Side B. It is the interesting one.

The first two tracks are the fonts. There are four fonts, in different styles. This is the layout:

000102030405060708090A0B0C0D0E0F1011
T00F0F0F0F0F0F0F0F1F1F1F1F1F1F1F1F1F2F2
T01F2F2F2F2F2F3F3F3F3F3F3F3

That became

000102030405060708090A0B0C0D0E0F
T00F0F0F0F0F0F0F0F1F1F1F1F1F1F1F1F1
T01F2F2F2F2F2F2F2F3F3F3F3F3F3F3

Toy Shop contains both a regular DOS 3.3 with RWTS, VTOC, and the 18-sector tracks. The VTOC contains a fake catalog which lists the credits, and a hidden catalog with real files that are used.

One of the files is named TEDIT. TEDIT is the Text EDITor, and is the one that makes use of the fonts. This is the code that constructs the read from 18-sector tracks. The code supports reading fonts that span tracks.

5B75A0 00LDY#0
5B77loc_5B77:
5B77B9 00 DELDA$DE00,Y
5B7A99 9D 5BSTAbyte_5B9D,Y
5B7DC8INY
5B7EC0 12CPY#$12
5B8090 F5BCCloc_5B77
5B82loc_5B82:
5B82B9 00 DELDA$DE00,Y
5B8599 A3 5BSTAbyte_5BA3,Y
5B88C8INY
5B89C0 24CPY#$24
5B8B90 F5BCCloc_5B82

Since our tracks are only 16 sectors large, we only need to support 32 slots, instead of 36.

5B75A0 00LDY#0
5B77loc_5B77:
5B77B9 00 DELDA$DE00,Y
5B7A99 9D 5BSTAbyte_5B9D,Y
5B7DC8INY
5B7EC0 12CPY#$10
5B8090 F5BCCloc_5B77
5B82loc_5B82:
5B82B9 00 DELDA$DE00,Y
5B8599 A3 5BSTAbyte_5BA5,Y
5B88C8INY
5B89C0 24CPY#$20
5B8B90 F5BCCloc_5B82

Then we just add our sector read routine in place of the 18-sector read routine, and the calling convention remains the same. That was the easy one. In fact, since there's a DOS 3.3 RWTS, I just called it directly.

Tracks $16+ are models and decals. They are stored in an overlapped format, such that the start of a model or decal might be inside a block that holds another model or decal. Since the sizes of the models and decals are not constant, it was too hard to separate them and move only some data to other tracks. Further hampering the effort to understand what was going on is the fact that the program is a mix of interpreted code and native code. Instead, I had to move the entire data to lower tracks.

The objects are loaded via a table of track/sector pairs:

5E65.BYTE$1F,8
.BYTE$1F,$B
.BYTE$1F,$E
.BYTE$20,0
.BYTE$20,8
.BYTE$20,$10
.BYTE$21,5
.BYTE$21,8
.BYTE$21,$C
5E77.BYTE$19,$10
.BYTE$19,$11
.BYTE$1A,1
5E7D.BYTE$16,9
.BYTE$16,$D
.BYTE$16,$10
5E83.BYTE$1C,$A
.BYTE$1D,0
.BYTE$1D,8
.BYTE$1D,$E
.BYTE$1E,2
.BYTE$1E,9
5E8F.BYTE0
5E90.BYTE0
5E91.BYTE$19,8
.BYTE$19,$B
.BYTE$19,$E
5E97.BYTE$18,$A
.BYTE$18,$D
.BYTE$18,$11
.BYTE$19,3
.BYTE$19,4
.BYTE$19,6
5EA3.BYTE$16,0
.BYTE$16,3
.BYTE$16,6
5EA9.BYTE$17,5
.BYTE$17,9
.BYTE$17,1
5EAF.BYTE$1A,2
.BYTE$1A,3
.BYTE$1A,4
.BYTE$1A,5
.BYTE$1A,6
.BYTE$1A,7
5EBB.BYTE0
5EBC.BYTE$1A,$E
.BYTE$1B,0
.BYTE$1B,4
5EC2.BYTE$1B,$C
.BYTE$1B,$A
.BYTE$1B,8
5EC8.BYTE$1B,$E
.BYTE$1B,$11
.BYTE$1C,2
5ECE.BYTE$1C,3
.BYTE$1C,6
.BYTE$1C,8
5ED4.BYTE$1A,9
.BYTE$1A,$B
.BYTE$1A,$D
5EDA.BYTE$1E,$11
.BYTE$1F,2
.BYTE$1F,5
5EE0.BYTE$17,$D
.BYTE$18,0
.BYTE$18,5
5EE6.BYTE$21,$10
.BYTE$22,1
.BYTE$22,4

That's a lot of extra sectors - two entire tracks worth - that are needed in order to map the result to 16 sectors... but where do we find two extra tracks? It turns out that tracks 2-8 are not referenced by anything. Even though they are in 18-sector format, it seems that they were originally intended for the models and decals during early development (at a time when SELECT was on side B, and GEDIT was on side A. We know the original location of these files because the deleted entries remain in the VTOC). After the disk layout was finalized, the tracks were left in 18-sector format. I moved the DOS files down by two tracks, overwriting some of the unused data, to make room for the new content. The resulting track/sector translation for the models and decals looks like this:

1600->1400
1601->1401
1602->1402
1603->1403
...
160D->140D
160E->140E
160F->140F
1610->1500
1611->1501
...
2208->2200
2209->2201
220A->2202
220B->2203
220C->2204
220D->2205
220E->2206
220F->2207
2210->2208
2211->2209

The translation table in both GENTOY (GENerate TOY, the renderer from side A) and GEDIT (Graphics EDITor, from side B) had to be changed. The tables are identical in both files, only their load address in memory is different. So we end up with a table that looks like this:

5E65.BYTE$1E,$A
.BYTE$1E,$D
.BYTE$1F,0
.BYTE$1F,4
.BYTE$1F,$C
.BYTE$20,4
.BYTE$20,$B
.BYTE$20,$E
.BYTE$21,2
5E77.BYTE$18,6
.BYTE$18,7
.BYTE$18,9
5E7D.BYTE$14,9
.BYTE$14,$D
.BYTE$15,0
5E83.BYTE$1B,6
.BYTE$1B,$E
.BYTE$1C,6
.BYTE$1C,$C
.BYTE$1D,2
.BYTE$1D,9
5E8F.BYTE0
5E90.BYTE0
5E91.BYTE$17,$E
.BYTE$18,1
.BYTE$18,4
5E97.BYTE$16,$E
.BYTE$17,1
.BYTE$17,5
.BYTE$17,9
.BYTE$18,$A
.BYTE$17,$C
5EA3.BYTE$14,0
.BYTE$14,3
.BYTE$14,6
5EA9.BYTE$15,7
.BYTE$15,$B
.BYTE$15,3
5EAF.BYTE$18,$A
.BYTE$18,$B
.BYTE$18,$C
.BYTE$18,$D
.BYTE$18,$E
.BYTE$18,$F
5EBB.BYTE0
5EBC.BYTE$19,6
.BYTE$19,$A
.BYTE$19,$E
5EC2.BYTE$1A,6
.BYTE$1A,4
.BYTE$1A,2
5EC8.BYTE$1A,8
.BYTE$1A,$B
.BYTE$1A,$E
5ECE.BYTE$1A,$F
.BYTE$1B,2
.BYTE$1B,4
5ED4.BYTE$19,1
.BYTE$19,3
.BYTE$19,5
5EDA.BYTE$1E,1
.BYTE$1E,4
.BYTE$1E,7
5EE0.BYTE$15,$F
.BYTE$16,4
.BYTE$16,9
5EE6.BYTE$21,6
.BYTE$21,9
.BYTE$21,$C

Then we insert the 16-sector read routines, just like for TEDIT.

THE DATA DISKS

The data disks contain the full-size bitmapped versions of the models, so they are really necessary. They are fully 18 sector format, and completely full. That 157kb of data per side, that need to be crammed into a 140kb format. They needed to be compressed. Fortunately, the bitmaps are read in chunks of 9 sectors at a time. It was simply a matter of compressing the content enough to convert 9x2 sectors to 8x2 sectors, and then decompressing them on demand.

And there you have it.

(*) in the 80s, when disk space was severely limited, and transmission costs were expensive, no-one wanted anything except games on their boards. Certainly, no-one was going to accept a graphics program for printing toys, which would have required more than three entire disks to hold the data, and several hours to download. That meant that most of the educational and graphics software were left untouched, and possibly lost forever. What a sad situation.

Copyright (c) 2014 Peter Ferrie
All rights reserved

This site is hosted by 000webhost.com



Free web hostingWeb hosting