----------The Computer Almanac--------- A 4am crack 2014-09-10 --------------------------------------- "The Computer Almanac" is a general purpose program by David Carman and distributed by Huntington Computing. Neither the disk label nor the manual mention a publication date. The back of the manual reads, in part, "This program is guaranteed against defects for 90 days (including bad media, fingerprints, snow storms, hungry babies, and other such disasters)." COPYA fails miserably and immediately with a disk read error. EDD 4 bit copy gives no errors, and the copy works, which suggests that this disk may not use any secondary protection beyond the non-standard disk structure. (I have seen some weaker nibble checks that can be defeated with a strong bit copier, so you never know until you try.) Turning to my trusty Copy ][+ sector editor, I press "P" to get to the Sector Editor Patcher, and select "DOS 3.3 PATCHED". This option ignores checksum bytes and epilogue sequences. As long as the address and data prologue are standard ("D5 AA 96" and "D5 AA AD", respectively), this will allow me to read each sector. And lo and behold, it works! I can read the data from every sector on every track. Track $11 appears to be a standard DOS 3.3 disk catalog. T01,S09 lists HELLO as the autorun program. Given the (relatively) weak structural protection, I used to turn to the DOS 3.3 master disk, patch the RWTS to ignore checksums and epilogue bytes (changing $B942 from "SEC" to "CLC"), and run COPYA. Then, one fine day, and completely by accident, I came across an original disk with a bad sector. I suppose this shouldn't surprise me. These floppies are decades old by now; it's amazing any of them work at all. The point is, I shouldn't be using tools that ignore potentially serious read errors. There are other tools, like Super Demuffin, that can convert a disk like this (with non-standard epilogue bytes) into a standard format. It requires figuring out what the actual epilogue bytes are, but it has the advantage of surfacing a read error if the original disk actually has a read error. So... no more COPYA+B942:18 patch. From now on, it's Super Demuffin or Advanced Demuffin to convert disks to a standard format. Based on my initial inspection with a sector editor, this disk loads DOS and runs a HELLO program. So it shouldn't be difficult to capture the RWTS and load it into Advanced Demuffin. [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". If anything looks fishy or non- standard, AUTOTRACE just stops, and I have to check the files it saved so far to determine why. But in this case, it ran all the way through, automatically capturing BOOT0, BOOT1, and RWTS files. 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, then a standard DOS 3.3- compatible RWTS to write out the data, sector by sector.) 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. [S6,D1=original disk] [S6,D2=blank disk] [S5,D1=my work disk] ]PR#5 ... ]BRUN ADVANCED DEMUFFIN 1.5 [press "5" to switch to slot 5] [press "R" to load a new RWTS module] --> At $B8, load "RWTS" from drive 1 [press "I" to load a new IOB module] --> load "IOB" from drive 1 [press "6" to switch to slot 6] [press "C" to convert disk] 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.5 (C) 1983, 2014 ORIGINAL BY THE STACK UPDATES BY 4AM =======PRESS ANY KEY TO CONTINUE======= TRK:................................... +.5: 0123456789ABCDEF0123456789ABCDEF012 SC0:................................... SC1:................................... SC2:................................... SC3:................................... SC4:................................... SC5:................................... SC6:................................... SC7:................................... SC8:................................... SC9:................................... SCA:................................... SCB:................................... SCC:................................... SCD:................................... SCE:................................... SCF:................................... ======================================= 16SC $00,$00-$22,$0F BY1.0 S6,D1->S6,D2 --^-- The disk's own RWTS gave no read errors on any track. This is 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. Rebooting my work disk, I can now see the catalog on the demuffin'd copy. ]PR#5 ... ]CATALOG,S6,D2 C1983 DSR^C#254 163 FREE A 002 HELLO T 003 APPLE PROMS T 002 LOCATION T 001 `APPLE`PROMSlLtp A 057 ALMANAC A 026 TRAVEL A 035 BIO A 006 INTRO A 045 HEALTH B 034 ANNV.PIC B 034 CHILL1.PIC A 006 LOCATION CHANGER A 010 LIGHTNING A 002 LOADER B 034 TIT1.PIC B 034 BIR.PIC T 002 SLOT ]RUN HELLO The program 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 RWTS. Now to make the disk be able to read itself (remember, it still has the original RWTS on it)... For future reference (mostly mine), here's a nice chart of the memory locations for all the prologues and epilogues for an RWTS loaded into low memory. The disk loads T00,S02 at $3800, T00,S03 at $3900, and so on. 0x | read | write ---------------+-------+------- D5 | $3955 | $3C7A prologue AA | $395F | $3C7F / 96 | $396A | $3C84 ADDRESS -------+-------+------- \ DE | $3991 | $3CAE epilogue AA | $399B | $3CB3 EB | | $3CB8 ---------------+-------+------- D5 | $38E7 | $3853 prologue AA | $38F1 | $3858 / AD | $38FC | $385D DATA ----------+-------+------- \ DE | $3935 | $389E epilogue AA | $393F | $38A3 EB | | $38A8 ---------------+-------+------- Based on manual inspection with a sector editor (note to self: write an RWTS comparison tool), it appears I need to change the first byte of both the address and data epilogues. T00,S02,$9E change "DA" to "DE" T00,S03,$35 change "DA" to "DE" T00,S03,$91 change "DA" to "DE" Quod erat liberandum. --------------------------------------- A 4am crack No. 130 ------------------EOF------------------