Heya, Not sure if anyone else out there has any/many MECC disks, but a while ago I won an auction that had HUNDREDS of MECC titles. I haven't sorted through them all yet, and I know there are definitely duplicates, but I've been wanting to back them up to my PC using ADT and MECCOPY. I did this for a couple disks already, like Oregon Trail. But MECCOPY requires the use of TWO 5.25" drives and it seems that my second drive doesn't work very well.. Most of the time it won't even INIT a disk without an error. Anyhow, I'm getting back into 6502 programming and decided that I would take a stab at reverse-engineering the MECCOPY program. Once I've disected it, I'll probably enter the source code into Merlin-8. BTW, I won an eBay auction for Merlin 8/16 that came with the manual and the Merlin-8 disks (one for DOS 3.3 and one for ProDOS). The Merlin-16 disks weren't part of it, so I don't have that.. But I don't have a GS yet either.. for another day.. anyhow, I transfered the Merlin-8 to DSK images with ADT and uploaded them to Asimov this morning. Hopefully they'll show up in the "unsorted" directory in a little while. So MECCOPY isn't very large, just 15 blocks on a DOS 3.3 disk. I have it on a DSK image and used CiderPress to "dump" the raw hex so I could put that into TextPad (the text editor I use on Windows.) Next, I set up a "Generic / Text Only" printer under windows that lets me capture printer output to a file; then I fired up the Apple Oasis II emulator and did a BLOAD MECCOPY, PR#1, CALL -151, 800L to list the disassembly.. Then I started going through the disassembly in TextPad. First, I extracted all the JMP addresses to see what routines were called and where.. Came up with 17 routines and 1 routine at $FAA6, which reboots DOS. (The MECCOPY program has option #5, "Quit And Reboot"..) Then I went through all the JSR calls and came up with 17 of those too. All internal to the program, except for a call to $03D9, which is a call to RWTS (Read/Write Track/Sector). Anyone interested in helping disect? :) Maybe someone will be entertained for a little while with it, as I am now.. I've had to break out a few books (apple //e tech ref, and beneath apple dos) to understand some of the calls.. There's a couple routines I've found in MECCOPY that I don't understand yet.. I know what they DO but what the effects really are I'm not sure. It seems to be patching an area of DOS that's Beneath Apple DOS says is the end of the READ routine. Seems to be the section at the end where it branches to a SEC/RTS to signal an error. So the patch is maybe trying to get DOS 3.3 to ignore read errors? Not sure about that yet. Here's the routines as i have them: (Sorry for the line wrap with the comments I've been writing..) ; ; (?) PATCH DOS 3.3 READ Routine To ignore errors ; SUB15: 0DE2- A9 EA LDA #$EA ;OP-CODE for NOP 0DE4- 8D 36 B9 STA $B936 ;Overwrite DOS's READ routine "BNE $B942" 0DE7- 8D 37 B9 STA $B937 ; which goes to a SEC/RTS (signalling an error) 0DEA- A9 4C LDA #$4C ; Write opcodes for "JMP $B99E" to addresses $B93E-$B940 0DEC- 8D 3E B9 STA $B93E 0DEF- A9 9E LDA #$9E 0DF1- 8D 3F B9 STA $B93F 0DF4- A9 B9 LDA #$B9 0DF6- 8D 40 B9 STA $B940 ; (done writing "JMP $B99E") 0DF9- AD A7 0E LDA $0EA7 ; Next, copy PATCH1 data to DOS READ routine area 0DFC- 8D 55 B9 STA $B955 0DFF- AD A8 0E LDA $0EA8 0E02- 8D 5F B9 STA $B95F 0E05- AD A9 0E LDA $0EA9 0E08- 8D 6A B9 STA $B96A 0E0B- AD AA 0E LDA $0EAA 0E0E- 8D E7 B8 STA $B8E7 0E11- AD AB 0E LDA $0EAB 0E14- 8D F1 B8 STA $B8F1 0E17- AD AC 0E LDA $0EAC 0E1A- 8D FC B8 STA $B8FC 0E1D- 60 RTS ; ; Restore DOS 3.3 READ routine back to original ; SUB16: 0E1E- A9 D0 LDA #$D0 0E20- 8D 36 B9 STA $B936 0E23- A9 0A LDA #$0A 0E25- 8D 37 B9 STA $B937 0E28- A9 C9 LDA #$C9 0E2A- 8D 3E B9 STA $B93E 0E2D- A9 AA LDA #$AA 0E2F- 8D 3F B9 STA $B93F 0E32- A9 F0 LDA #$F0 0E34- 8D 40 B9 STA $B940 0E37- AD AD 0E LDA $0EAD 0E3A- 8D 55 B9 STA $B955 0E3D- AD AE 0E LDA $0EAE 0E40- 8D 5F B9 STA $B95F 0E43- AD AF 0E LDA $0EAF 0E46- 8D 6A B9 STA $B96A 0E49- AD B0 0E LDA $0EB0 0E4C- 8D E7 B8 STA $B8E7 0E4F- AD B1 0E LDA $0EB1 0E52- 8D F1 B8 STA $B8F1 0E55- AD B2 0E LDA $0EB2 0E58- 8D FC B8 STA $B8FC 0E5B- 60 RTS ; ; Copy PATCH2 onto PATCH1 ; SUB17: 0E5C- AD AD 0E LDA $0EAD 0E5F- 8D A7 0E STA $0EA7 0E62- AD AE 0E LDA $0EAE 0E65- 8D A8 0E STA $0EA8 0E68- AD AF 0E LDA $0EAF 0E6B- 8D A9 0E STA $0EA9 0E6E- AD B0 0E LDA $0EB0 0E71- 8D AA 0E STA $0EAA 0E74- AD B1 0E LDA $0EB1 0E77- 8D AB 0E STA $0EAB 0E7A- AD B2 0E LDA $0EB2 0E7D- 8D AC 0E STA $0EAC 0E80- 60 RTS DATA: PATCH1 0EA7- D5 AA 96 D5 AA AD PATCH2 0EAD- D5 AA 96 D5 AA AD ROM Routines Used: $FAA6 = REBOOT (RE-BOOTS DISK SYSTEM) $FC22 = VTAB (PERFORM a VERTICAL TAB to ROW in ACCUMULATOR) $FC58 = HOME (HOME & CLEAR SCREEN (Destroys ACCUMULATOR & Y-REG)) $FD0C = CIN (GET KEY from KEYBOARD (Destroys A & Y-REG) WAIT for KEY PRESS) $FDED = COUT (A Register Printed As ASCII) JSR ROUTINES: $03D9 = Call to RWTS Routine $0A56 = SUB1 $0A89 = SUB2 $0AD4 = SUB3 $0B61 = SUB4 $0B76 = SUB5 $0BAF = SUB6 $0D2F = SUB7 $0D61 = SUB8 = Clear Text Screen, lines 4 through 20 $0D75 = SUB9 = Redraw Track Status Area on line 23 $0D81 = SUB10 = Display string " Formatting ... " in track status area $0D8B = SUB11 = Display String starting on line number specified in X register, string location in Y/A registers $0D9A = SUB12 = Display String (Y = High-Byte of String Address, A = Low-Byte of String Address) $0DB2 = SUB13 = Set Cursor Position to X=VERT POS, Y=HORIZ POS, then fall into SUB14: $0DB9 = SUB14 $0DE2 = SUB15 = (?) PATCH DOS 3.3 READ Routine To ignore errors $0E1E = SUB16 = Restore DOS 3.3 READ routine back to original $0E5C = SUB17 = Copy PATCH2 to PATCH1 $FC22 = PERFORM a VERTICAL TAB to ROW in ACCUMULATOR $FC58 = HOME (HOME & CLEAR SCREEN (Destroys ACCUMULATOR & Y-REG)) $FD0C = CIN (GET KEY from KEYBOARD (Destroys A & Y-REG) WAIT for KEY PRESS) $FDED = COUT (A Register Printed As ASCII) JMP ROUTINES: $0819 = L1 = Main Menu Display $085F = L2 = Option 1: Copy Disk, One Side $08BE = L3 = $08D0 = L4 = Option 2: Copy Disk, Two Sides $0956 = L5 $09A1 = L6 = Option 3: Copy a data disk $09F7 = L7 = Option 5: Quit And Reboot $0A0E = L8 = Option 4: About MECCOPY v3.1 $0A44 = L9 $0AAF = L10 $0B31 = L11 $0BC8 = L12 $0BCE = L13 $0C1F = L14 $0C38 = L15 $0C95 = L16 $0CDE = L17 $FAA6 = RE-BOOTS DISK SYSTEM I can post the whole thing on my web page if anyone is interested.. I've got about maybe 40% of it figured out... // CHRIS On 13 Feb 2004 08:46:11 GMT, mjmahon@aol.com (Michael J. Mahon) wrote: >Given what you have already done, I predict complete understanding >within a few more hours. ;-) > >-michael > >Check out amazing quality sound for 8-bit Apples on my >Home page: http://members.aol.com/MJMahon/ Thanks.. yeah, I'm not done yet but I've gotten a bit further.. I checked out the "DOS 3.3 Anatomy" files at textfiles.com and can see what parts of the RWTS read routine are being modified.. Also I think I got most of the "local variables" nailed down in the program.. most are from two copies of IOB (input/output block) tables (one for Drive 1 and one for Drive 2) and the DCT (Device characteristics table) used by RWTS. Still needs more work to be fully understood, but once I've got it all figured out I'll write up the source code in Merlin-8 and post it to the comp.sys.apple2.binaries group for anyone interested.. I think it would be interesting to mix the MECCOPY program with ADT, so that MECCOPY reads and "deprotects" the MECC disks and transmits them to your PC instead of writing the data to another disk.. This way you can knock them out quickly without having to do a couple, ADT transfer them, do a couple, ADT transfer them.. By the way, the program uses a monitor function called "VTAB" to set the cursor position on the screen.. My //e tech ref manual only describes the "VTABZ" function.. I can't find any reference in the manual for just the "VTAB" function. VTAB is at $FC22 VTABZ is at $FC24 Looking at the monitor listing.. ]CALL -151 *FC22L FC22- A5 25 LDA $25 FC24- 85 28 STA $28 FC26- 98 TYA FC27- A0 04 LDY #$04 FC29- D0 89 BNE $FBB4 FC2B- 00 BRK (etc) So calling $FC22 and $FC24 is pretty much the same.. With $FC22, you store your vertical position in the $25 zero page address; with $FC24 you call it with the position in the accumulator.. Last night I wrote a quick program in the monitor mini-asm, and verified that the VTAB lets you set the X and Y cursor position.. But this isn't documented anywhere that I've seen.. Anyone know what's up with that? // CHRIS "Chris Morse" wrote in message news:j65r20tlko1ds07405ldpfhqjv27p7o6tu@4ax.com... : [ snip ] : : By the way, the program uses a monitor function called "VTAB" to set : the cursor position on the screen.. My //e tech ref manual only : describes the "VTABZ" function.. I can't find any reference in the : manual for just the "VTAB" function. : : VTAB is at $FC22 : VTABZ is at $FC24 : : Looking at the monitor listing.. : : ]CALL -151 : : *FC22L Here's the listing as in Apple II Reference and Apple IIc Reference - 1st Edition Volume 2. : FC22- A5 25 LDA $25 "Old Monitor ROM: LDA CV ;Get Cursor V-index" "Autostart ROM" : LDA CV ;same as above" "Original IIc is: BRA NEWVTAB ;guess this jumps to the routine that does the above function." : FC24- 85 28 STA $28 "Old Monitor ROM: JSR BASCALC ;Generate Base address" "Autostart ROM : JSR BASCALC" " " " "Original IIc is: JSR BASCALC" " " " : FC26- 98 TYA : FC27- A0 04 LDY #$04 : FC29- D0 89 BNE $FBB4 : FC2B- 00 BRK : (etc) : : So calling $FC22 and $FC24 is pretty much the same.. With $FC22, you : store your vertical position in the $25 zero page address; with $FC24 : you call it with the position in the accumulator.. : : Last night I wrote a quick program in the monitor mini-asm, and : verified that the VTAB lets you set the X and Y cursor position.. But : this isn't documented anywhere that I've seen.. : : Anyone know what's up with that? Could we see your routine? Bill @ GarberStreet Enterprizez };-) Web Site - http://garberstreet.netfirms.com Email - willy4SPAM6pa@comXcast.net Remove - SPAM and X to contact me --- This email ain't infected, dude! Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.576 / Virus Database: 365 - Release Date: 1/31/04 Jplcsch wrote: >"Michael J. Mahon" wrote in message >news:20040214015031.17086.00001972@mb-m03.aol.com... >> Chris Morse wrote: >> >> >> >> >I think it would be interesting to mix the MECCOPY program with ADT, >> >so that MECCOPY reads and "deprotects" the MECC disks and transmits >> >them to your PC instead of writing the data to another disk.. This way >> >you can knock them out quickly without having to do a couple, ADT >> >transfer them, do a couple, ADT transfer them.. >> >> You would be very interested in the Super IOB program described in >> and distributed by Hardcore Computist. It is an Applesoft program >> with a couple of M/L subroutines that call RWTS passing an IOB >> in low memory that the Applesoft program POKEs and PEEKs. >> >> With the appropriate "scripts" EXECed into the program, it can >> de-protect almost any copy protected program. And there are >> "controller" scripts for hundreds of programs and types of >> protection, like MECC. >> >> It is a generalized solution to de-protecting disks, not just >> copying them in protected form, so it would be a perfect match >> to ADT, allowing protected disks to be "normalized" and >> transferred to a disk image file at the same time. > >You are absolutely right Michael, >but as you know often you have two or three other protect system like >nibble count or synchronisation when the editor use an easy modification of >the format. But it's a great step to transfert the protected disk into a >.dsk format and after you just have to remove the other protections on the >.dsk file. I prefer front door method on a real Apple but it's because I >like this technique and I'm not ready to change...I'm a gorilla I know. Super IOB is quite capable of handling heavily protected disks. One technique which is quite common with Super IOB is to capture the modified RWTS of the protected disk and install it in memory together with a normal RWTS. The two RWTSs are then used alternately to read the protected disk and write the de-protected disk--commonly called a "swap controller". Nibble counts and track synchronization checks are usually handled by sector edits to remove them. Using Super IOB requires complete manual analysis of the protection scheme, but the program then applies it automatically to de-protect other identically protected disks. This allows the de-protection work done by one person to be easily applied by another, and sometimes whole families of similarly protected disks can be handled by a single controller (like most MECC disks). The key to making a program usable as a .dsk image it de-protection, and .nib images are a poor substitute for de-protection (since they actually handle only very weak protection schemes). Of course, a de-protected disk is strictly only one with a normal sector format, able to be copied by a standard disk copier. Maximum utility for any program is achieved when the disk is not only de-protected, but also "normalized", so that it uses a standard file system. -michael Check out amazing quality sound for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/ On Fri, 13 Feb 2004 00:16:12 -0500, Chris Morse wrote: >Anyhow, I'm getting back into 6502 programming and decided that I >would take a stab at reverse-engineering the MECCOPY program. Once >I've disected it, I'll probably enter the source code into Merlin-8. I've updated the dis-assembly: http://www.cosmicwolf.com/AppleII/MECCOPY.DISASSEM.TXT I've got it all figured out now.. The patches being made are to the DOS read routine where it checks for the data epilogue bytes. The DOS routine at $B92F will read the first two bytes (only) of the data epilogue ("DE AA"). The patch essentially makes it so that any two bytes will be accepted without error. As it copies the MECC disk tracks, it scans the data and patches it back to normal DOS 3.3. // CHRIS Chris Morse wrote: >I've got it all figured out now.. The patches being made are to the >DOS read routine where it checks for the data epilogue bytes. The DOS >routine at $B92F will read the first two bytes (only) of the data >epilogue ("DE AA"). The patch essentially makes it so that any two >bytes will be accepted without error. As it copies the MECC disk >tracks, it scans the data and patches it back to normal DOS 3.3. You may be interested to know that, even there are theoretically three epilog bytes, only two are ever checked, because when it is writing, RWTS turns off the write before the final epilog byte is completely written. The third byte is therefore corrupt and therefore not useful. -michael Check out amazing quality sound for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/ On 16 Feb 2004 23:37:46 GMT, mjmahon@aol.com (Michael J. Mahon) wrote: >Chris Morse wrote: > >>I've got it all figured out now.. The patches being made are to the >>DOS read routine where it checks for the data epilogue bytes. The DOS >>routine at $B92F will read the first two bytes (only) of the data >>epilogue ("DE AA"). The patch essentially makes it so that any two >>bytes will be accepted without error. As it copies the MECC disk >>tracks, it scans the data and patches it back to normal DOS 3.3. > >You may be interested to know that, even there are theoretically >three epilog bytes, only two are ever checked, because when it >is writing, RWTS turns off the write before the final epilog byte >is completely written. The third byte is therefore corrupt and >therefore not useful. > >-michael > >Check out amazing quality sound for 8-bit Apples on my >Home page: http://members.aol.com/MJMahon/ Yeah, Thanks -- I was wondering about that.. I was looking at the DOS 3.3 disassembly and noticed that it was never checking for the last byte (#$96 for address fields, and #$AD for data fields.) Now I know why! // CHRIS