---------Little Computer People-------- A 4am crack 2014-06-16 --------------------------------------- "Little Computer People" (a.k.a. "House on a Disk") is a 1986 simulation game distributed by Activision, Inc. It uses both sides of a double-sided disk. Only side A is bootable. COPYA copies both sides, but the copy does not work. The side A copy loads sequential tracks (slowly), then halts. EDD 4 bit copy fares no better. The boot process does not sound like DOS 3.3, ProDOS, or Pascal. There *is* a disk catalog on track $11, but it holds nothing but two deleted files while claiming that the disk has zero free sectors. Time for boot tracing with 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 Well, that went swimmingly. Despite its custom loading process (and fake disk catalog), this disk appears to use a standard boot0 and DOS 3.3-derived RWTS routine. Let's find out where it all goes wrong. ]BLOAD BOOT1,A$2600 ]CALL -151 ; disconnect DOS *FE89G FE93G *B600<2600.2FFFM *B700L ; standard initialization of the RWTS ; parameter table (starts at $B7E8) B700- 8E E9 B7 STX $B7E9 B703- 8E F7 B7 STX $B7F7 B706- A9 01 LDA #$01 B708- 8D F8 B7 STA $B7F8 B70B- 8D EA B7 STA $B7EA ; $B7E0 is $03 (sectors to read) B70E- AD E0 B7 LDA $B7E0 B711- 8D E1 B7 STA $B7E1 ; hmm, reading T00,S0C is unusual (DOS ; usually starts at T02,S04) B714- A9 00 LDA #$00 B716- 8D EC B7 STA $B7EC B719- A9 0C LDA #$0C B71B- 8D ED B7 STA $B7ED ; $B7E7 is $0F (1 + high byte address ; of last sector to read) B71E- AC E7 B7 LDY $B7E7 B721- 88 DEY B722- 8C F1 B7 STY $B7F1 B725- A9 01 LDA #$01 B727- 8D F4 B7 STA $B7F4 B72A- 8A TXA B72B- 4A LSR B72C- 4A LSR B72D- 4A LSR B72E- 4A LSR B72F- AA TAX B730- A9 00 LDA #$00 B732- 9D F8 04 STA $04F8,X B735- 9D 78 04 STA $0478,X B738- 8D EB B7 STA $B7EB ; read 'em B73B- 20 93 B7 JSR $B793 B73E- A2 FF LDX #$FF B740- 9A TXS ; normal, jumps back to $B744 B741- 4C C8 BF JMP $BFC8 B744- 20 89 FE JSR $FE89 ; execution continues here B747- 4C 00 0C JMP $0C00 OK, so it's loading 3 sectors from T00,S0A-0C into $C00..$EFF, then jumping to $C00. I'll interrupt the boot there and see what it looks like. *9600 *D12 0D12- 55 Now it should be safe to remove the call to $0C60 (which just reads a pointless sector to position the drive head for the following nibble check) and the call to $0C70 (the nibble check that calculates the correct value of $0D12), and manually set $0D12 on disk to the correct value. T00,S0A,$49 change "20" to "2C" T00,S0A,$54 change "20" to "2C" T00,S0B,$12 change "00" to "55" Success! The game boots and loads with no complaint. There doesn't appear to be any further protection on side A or side B. Quod erat liberandum. ~ POSTSCRIPT: RESETTING THE GAME This game saves its state on side B. I have reset the state on this copy. When you run it for the first time, it will ask for your name and the date, then you will see the moving-in sequence. (The game suffers from a Y2K bug, in that you can only enter 2-digit years.) The next time you boot, the game will remember your name and just ask for the date, then increment the session number and continue where you left off. The moving-in sequence is quite long, and while it's running, no interaction is possible. The doorbell will ring several times, then the little guy will come in and look around, then he will leave. Then he will come back with his dog and look around some more. After that, the game will access the disk drive, and soon you will be able to type commands. If you want to reset the game to this pristine state later but can't re- download it for some reason, use a sector editor to read T0E,S0F on side A, change the last byte in the sector from "01" to "02", then write that sector to T0E,S0F on side B. --------------------------------------- A 4am crack No. 78 ------------------EOF------------------