---------Your Universe Volume 2-------- ------------The Planet Earth----------- A 4am crack 2014-07-14 --------------------------------------- "Your Universe Volume 2: The Planet Earth" is a 1985 educational game developed by Larry Cunningham, programmed by Alan Biegelman, edited by Joseph London, and distributed by Focus Media, Inc. [The copy protection is identical to "Who Am I? Birds, Trees, and Flowers," also distributed by Focus Media. This write-up is therefore quite similar to that one, with a few corrections.] The original disk boots, loads DOS, displays a BASIC prompt, then runs a HELLO program of some sort. COPYA fails miserably and immediately with a disk read error. EDD 4 bit copy gives no read errors, but the copy grinds the disk drive on boot and never gets any further. My trusty Copy ][+ sector editor can read track 0, sectors 0-9 without any trouble. Everything beyond that, even the rest of the sectors on track 0, is unreadable. Ignoring epilogue bytes (press "P" to get to the Sector Editor Patcher, then select "DOS 3.3 PATCHED") makes no difference. Switching to the nibble editor, it appears that all the tracks are in a fairly standard 16-sector format, but the data prologue has been changed from "D5 AA AD" to "D5 AA FF". --v-- COPY ][ PLUS BIT COPY PROGRAM 8.4 (C) 1982-9 CENTRAL POINT SOFTWARE, INC. ---------------------------------------- TRACK: 01 START: 1E35 LENGTH: 015F 1E10: FF FF FF FF FF FF FF FF VIEW 1E18: FF FF FF FF FF FF FF FF 1E20: FF FF FF FF FF FF E7 F9 1E28: FE FF FF FF FF FF FF FF 1E30: FF FF FF FF FF D5 AA 96 <-1E35 ^^^^^^^^ standard address prologue 1E38: FF FE AA AB AA AA FF FF 1E40: AB AA CF F3 FC FF FF FF ^^^^^^^^ non-standard address epilogue 1E48: FF FF FF D5 AA FF CF CA ^^^^^^^^ non-standard data prologue 1E50: DF BE BA BA A9 AF BF BD ---------------------------------------- A TO ANALYZE DATA ESC TO QUIT ? FOR HELP SCREEN / CHANGE PARMS Q FOR NEXT TRACK SPACE TO RE-READ --^-- All tracks appears to use the same prologue and epilogue sequences (except for the first 10 sectors on track 0). The sectors I can read on track 0 appear to be a standard(-ish) DOS 3.3 RWTS. Of course, there are some modifications to accommodate the non-standard prologue and epilogue sequences, but a cursory glance shows no other obvious pitfalls. Of course, it's always the non-obvious pitfalls that bite you, so let's forget I mentioned it. Go go gadget AUTOTRACE! [S6,D1=original disk] [S5,D1=my work disk] ]PR#5 ... CAPTURING BOOT0 ...reboots slot 6... ...reboots slot 5... SAVING BOOT0 CAPTURING BOOT1 ...reboots slot 6... ...reboots slot 5... SAVING BOOT1 SAVING RWTS SAVING IOB For those of you just tuning in, my work disk uses a custom program that I affectionately call "AUTOTRACE" to automate the process of boot tracing as far as possible. For some disks, this just captures track 0, sector 0 (saved in a file called "BOOT0") and stops. For other disks that load in the same way that an unprotected DOS 3.3 disk loads, it captures the next stage of the boot process as well (in a file called "BOOT1"). BOOT1 contains sectors 0-9 on track 0, which are loaded into memory at $B600..$BFFF. This generally contains the RWTS routines which the program uses to read the rest of the disk. If the RWTS is fairly normal as well (and my AUTOTRACE program just spot- checks a few memory locations to guess at its "normalcy"), there's a good chance I'll be able to use a tool called Advanced Demuffin (written in 1983 by The Stack) to convert the disk from whatever weird format it uses to store its sector data into a standard disk readable by unprotected DOS 3.3 disks or any other third-party tools. In this case, AUTOTRACE extracts the RWTS routines (generally loaded from track 0, sectors 2-9 into $B800..$BFFF) and saves *that* into a third file called "RWTS". But wait, there's more! The latest feature I added to my AUTOTRACE program is automatic IOB module creation. What the heck is an IOB module? Well, the author of Advanced Demuffin anticipated that he couldn't anticipate everything, so he made the program extensible. Quoting from the Advanced Demuffin softdocs (included on my work disk): --v-- An IOB module is an interface for the source RWTS. Advanced Demuffin uses the IOB module to set up the IOB table and jump to RWTS. The IOB module is stored from $1400-$14FB. When Advanced Demuffin loads in a IOB module, it reads the first sector of the file off the track-sector list and stores it at $13FC-$14FB. When Advanced Demuffin wants to read a sector it JSRs to the IOB module with the phase number, sector number, and the page number stored in the A, Y and X registers respectively. Since the source drive always has to be drive one, Advanced Demuffin can make the IOB module very compact. After it gets the page,track and sector Advanced Demuffin sets up the IOB for RWTS using this infor- mation, and JMPs to RWTS. (It jumps instead of JSRing, because it lets the RWTS do the RTS.) Here is a list of the IOB module that is built in to Advanced Demuffin: ; Convert phase # to track # 1400- 4A LSR ; Store track number 1401- 8D 22 0F STA $0F22 ; Store sector number 1404- 8C 23 0F STY $0F23 ; Store page number ; [note: original docs have incorrect ; hex opcode on this line] 1407- 8E 27 0F STX $0F27 140A- A9 01 LDA #$01 ; Store the drive number 140C- 8D 20 0F STA $0F20 ; Store the read code 140F- 8D 2A 0F STA $0F2A ; With high byte of IOB 1412- A9 0F LDA #$0F ; With low byte of IOB 1414- A0 1E LDY #$1E ; Goto RWTS 1416- 4C 00 BD JMP $BD00 --^-- Basically, Advanced Demuffin only knows how to call a custom RWTS if it 1. is loaded at $B800..$BFFF 2. uses a standard RWTS parameter table 3. has an entry point at $BD00 that takes the address of the parameter tables in A and Y 4. doesn't require initialization As it turns out, that covers a *lot* of copy protected disks, but it doesn't cover this one because the RWTS on disk is loaded at $3800..$3FFF and has its entry point at $3D00. If I told Advanced Demuffin to load this RWTS at $B800 and call it at $BD00, it would crash quite spectacularly. So, I added a check to AUTOTRACE to detect that the RWTS is loaded in a non-standard location (lines 279-300 in the HELLO program on my work disk) and automatically create an IOB file that can tell Advanced Demuffin how to access it. Here's what it looks like: ]BLOAD IOB,A$1400 ]CALL -151 *1400L ; Most of this is identical to the ; standard IOB module that comes with ; Advanced Demuffin (explained above). 1400- 4A LSR 1401- 8D 22 0F STA $0F22 1404- 8C 23 0F STY $0F23 1407- 8E 27 0F STX $0F27 140A- A9 01 LDA #$01 140C- 8D 20 0F STA $0F20 140F- 8D 2A 0F STA $0F2A ; One problem with having an RWTS at ; $3800..$3FFF is that that range is ; normally used to store track data ; during the copy process. If we just ; let Advanced Demuffin run, it will ; overwrite the custom RWTS almost ; immediately and crash. In the ; ADVANCED DEMUFFIN TECH NOTES (also ; included on my work disk), the author ; mentions that you can control how ; many sectors Advanced Demuffin reads ; at a time, and where it puts it in ; memory. Normally $1CF0 is $20 and ; $1CF1 is $90, meaning that it will ; copy 7 tracks worth of data at a time ; into $2000..$8FFF. Changing the end ; parameter to $30 will only copy one ; track at a time, but has the distinct ; advantage of not overwriting the RWTS ; and crashing. 1412- A9 30 LDA #$30 1414- 8D F1 1C STA $1CF1 ; get the address of the RWTS parameter ; table at $0F1E and call the RWTS ; entry point at $3D00 (instead of the ; usual $BD00) 1417- A9 0F LDA #$0F 1419- A0 1E LDY #$1E 141B- 4C 00 3D JMP $3D00 Now I can use Advanced Demuffin to convert the disk to a standard format. It uses the disk's own RWTS to read the original (stored in the RWTS file, accessed via the IOB module), then a standard DOS 3.3-compatible RWTS to write out the data, sector by sector. Advanced Demuffin will only load RWTS and IOB files from a drive in slot 6, which is annoying since mine is in slot 5. Note to self: patch that someday. In the meantime, I'm swapping floppy disks like some kind of 16th century monk. [S6,D1=my work disk] ]PR#6 ]BRUN ADVANCED DEMUFFIN 1.1 --> LOAD NEW RWTS MODULE At $38, load "RWTS" from D1 --> LOAD NEW IOB MODULE load "IOB" from D1 [S6,D1=original disk] [S6,D2=blank disk] --> FORMAT TARGET DISK ...grind grind grind... --> CONVERT DISK --> CHANGE DEFAULT VALUES? N This disk is 16 sectors, and the default options (copy the entire disk, all tracks, all sectors) don't need to be changed unless something goes horribly wrong. --v-- ADVANCED DEMUFFIN 1.1 - COPYRIGHT 1983 WRITTEN BY THE STACK -CORRUPT COMPUTING =======PRESS ANY KEY TO CONTINUE======= TRK:R.................................. +.5: 0123456789ABCDEF0123456789ABCDEF012 SC0:R.................................. SC1:R.................................. SC2:R.................................. SC3:R.................................. SC4:R.................................. SC5:R.................................. SC6:R.................................. SC7:R.................................. SC8:R.................................. SC9:R.................................. SCA:................................... SCB:................................... SCC:................................... SCD:................................... SCE:................................... SCF:................................... ======================================= 16 SC $00,$00 TO $22,$0F BY $01 TO DRV2 --^-- The disk's own RWTS can't read the first 10 sectors of track 0, but that's to be expected -- they were in a different format than the rest of the disk. What I really care about is the rest of the disk, and that part went flawlessly. That's the power and the genius of Advanced Demuffin. Every disk must be able to read itself. So, let it read itself, then capture the data and write it out in a standard format. Of course, my copy won't boot, because it doesn't have any boot code in the first 10 sectors of track 0! But check this out... [S6,D1=my work disk] [S6,D2=demuffin'd copy] ]PR#6 ... ]CATALOG,S6,D2 C1983 DSR^C#254 152 FREE A 003 HELLO B 034 INTRO T 003 HELP1TXT T 003 HELP2TXT T 004 HELP3TXT T 003 HELP4TXT T 003 HELP5TXT T 003 HELP6TXT T 004 HELP7TXT T 003 HELP8TXT T 003 HELP9TXT T 004 HELP10TXT T 004 HELP11TXT T 004 HELP12TXT T 003 HELP13TXT T 003 HELP14TXT A 018 START *B 002 MOVE *B 002 HRU2 T 004 HELP15TXT T 002 HELP16TXT T 003 HELP18TXT B 014 HELP17PK *B 003 RBOOT *B 005 RLOAD *R 012 HRCG *B 002 SKIGUYS.SHP *B 002 SWAP B 013 ESC1PK T 039 QUESTIONS *B 002 SOUND T 057 ANSWERS A 033 GAME T 003 POINTERS A 017 START B 004 SLOPE T 023 QUESTIONSSEQ ]RUN HELLO The game loads and runs without complaint. All further disk access is done through standard DOS functions. (It even runs from drive 2!) There doesn't appear to be any kind of nibble check or other copy protection, beyond the custom DOS. Now to make the disk be able to read itself. Using Copy ][+, I can "copy DOS" from a freshly initialized DOS 3.3 disk onto the demuffin'd copy. This function of Copy ][+ just sector-copies tracks 0-2 from one disk to another, but it's easier than setting that up manually in some other copy program. Copy ][+ --> COPY --> DOS --> from slot 6, drive 2 --> to slot 6, drive 1 [S6,D1=demuffin'd copy] [S6,D2=newly formatted DOS 3.3 disk] ...read read read... ...write write write... Quod erat liberandum. --------------------------------------- A 4am crack No. 85 ------------------EOF------------------