When I started to examine the program I thought I had some utilities to read and write full tracks. It turns out that they were sector oriented and only KDSK3 could read a track. None of them could write a track. I then decieded to try and write my own assembly program that could read and write tracks. I have a photo copy of the specs for the disk controller that I got from Mr. Goodman, so I knew the commands. I examined an old program in Rainbow (Oct 83) that wrote a RSDOS track 36, and I examined the MSDOS format program that Mr. Goodman wrote in Rainbow (June 86). I finally got it working, and I still couldn't copy track 0. The next day I decided to disassemble NINJA.ASM. I used DISTRAC (a disassembler that I wrote in Pascal. It's fairly good at seperating code from data, but it's batch mode (non-interactive)), but it needed and exec address and ninja.asm auto-starts. I then tried SOURCE3 for the CC3 to disassemble it to disk. It didn't work extremely well, but it worked. I then spent some time correcting it and adding a few obvious comments. I also noted that there were only a few places that game commands to the disk. I statred analyzing and commenting it at the execution point. Naturally there was a lot of it I didn't understand (and still don't), but I was just trying to figure out what certain blocks did, not necassarily each instruction. I had a great deal more luck with the disk I/O sections. There were fairly obvious. Most of it was fairly straight forward and read sectors. There was, however, one section that read a full track. By the time I noticed that, I had already completly commented the other I/O sections. The read track section was fairly straight forward. No tricks were played, it simply read a full track. I then went back over the listing to see if I had missed anything, and I had. There was one small section that seemed to prepare the drive for something, but it didn't really seem to do anything except move the head to track 0 (that's how I missed it). I then spent quite a bit of time examining it, trying to figure out what it did. By this time I had put in several "long nighters" and I wasn't in the mood to do it again that night. So I quit for the night. While trying to relax, unwind and get my mind off K.G., I was wishing there was a better way. If I knew what the data was supposed to be then maybe there was some way I could find it on the disk. Then IT hit me. The program knew how to get it, all I had to do was find some way to get a copy of it! The next day I started looking at the asm listing again, except this time I was looking for a way to patch the program. I didn't know for certain which areas of memory was used, so I couldn't just put it anywhere. There was only one place that I knew was safe, the print data section. If it was safe for the author to put the copyright notice, his name, and prompts, it was safe for me. Now, how do I get a copy of the data out of the computer? I couldn't use any ROM routines, NINJA wants all the memory and complete control of the computer. The data (track 0) was being put at $8000, so I couldn't switch the ROMs in when I needed, because I would loose the data, besides the ROM routines depend on values in lower ram that was no longer correct. I was going to have to do this all myself. I had a very limited amount of memory to work with (<100 bytes), so it had to be simple. My printer (Star NX-1000) has a hex dump mode, that if you sent it any character, it would print the hex value for it. This was just what I was needing. I then examined the 'print character to printer' routine in ROM and wrote my own, setting it for 2400 baud. I then simply ORG'ed it for right place, put in a small patch to call my print routine. I then patched NINJA.BIN so that it wouldn't autostart. Then I loaded ninja, loaded my patch over it, and then EXEC 20480. Ninja then ran, loaded all the data, printed out the part I wanted, and then went right on playing. My routine didn't interfere with it at all. Looking over the data, something just didn't seem quite right. I couldn't prove it, but I was fairly sure it was wrong. I remembered that when I was testing the print routine in EDTASM+, it was hard to get the baud rate exactly right and the printer would print garbage. I took a closer look at the Ninja assembly and saw that I was running in DOUBLE speed, while my print routine was expecting normal (slow) speed. I changed it to slow down, print, and the speed up. This time the data 'looked' right. I still couldn't be certain though, so I went back to the drawing board. It occured to me that Ninja didn't actually HAVE to keep running after I got hold of the data. So I wrote another patch. This one copied all the data it was getting into bank 112 (the lower 8K of mem, on the second bank of 64K). This seemed to be a fairly safe place, as BASIC doesn't use it during boot up. After it copied the data into that bank, it then turned off the drive and hung up, so that I would now it was done. I then pressed -reset, then reset again. This starts BASIC cold. To get at the data, I then PCLEAR 1:CLEAR 200,16383:POKE &HFFA2,112. The poke puts block 112 into the section of normal memory from 16384 to 24575. I peeked at it, and sure enough it was the data I had printed out! I then SAVEM"DATA",16384,24575,0. TA DA! I now had the data on disk so I could use it. (NOTE: I'm making it sound like I simply wrote correct ASM routines each time and in just a few minutes. I didn't. There were 3 disks full of trial and error and at least a full days time.) By this I HAD to take a break, so I took the next day off (coincidentally it was Sunday!). Sunday night, while watching TV, I got to thinking. Did I really HAVE to put the data back onto track 0? It would still be hard to copy, you would have to use a special program to put the copy protected track 0 onto each and every disk. You wouldn't be able to use BACKUP0. It then occured to me that MAYBE there was some blank space on the disk and I could put all of this data into normal sectors. A full track of information would be 6K, so it would take 19 sectors (a track and a half) to hold it all. Was there that much space on disk? I checked using KDSK3, and there was A LOT of sectors that appeared to be empty. I looked at the listing, and it didn't seem to use them. Finally, I had a plan. This was Monday, and I had recieved K.G. on Tuesday the previous week, I figured you probably were wanting the disk back (with shipping it would have been 2 weeks). I already had the data from track 0 on disk as a file, so I didn't NEED to keep it. So Monday night I got it ready to mail back to you tuesday morning. Tuesday, I forgot to mail it. It was very fortunate, because I DID need the disk again, I'll get to that in a minute. Tuesday, I wrote a patch to replace the read track 0 section. There was already a routine in the I/O section that read a sequence of sectors off the disk. All I had to do was put the necassary commands to call the read range of sectors routine instead of reading track 0. I wasn't sure of exactly what variables the read track 0 section modified, did later sections depend on some variable that was innocently changed? I had to try and make the same variable changes in my patch. I then put the data that was on disk onto a copy of the K.G. disk. (I think it was track 25, sectors 1-18, track 26, sectors 1-9). Finally, I was ready to try it. I loaded NINJA, loaded my patch over it, and EXEC 20480 'ed it. And... it didn't work. I stared at it for a while, and then gave up. I had worked on it for a week and I was a little depressed that it didn't work. I decided to play you copy of K.G. While it was loading, I noticed something rather strange. It seemed to be going to track 0 several times! What that meant was that it usually didn't get the right info on the first try, but on later tries. My copy routine (the one I used to put the info on disk), just got it on the first try and then hung up, it never allowed the program to read it again to get the REAL data. I had been working with the WRONG data!!! When I looked at it, parts of it looked famililar. It was the same data that I had printed out with my print routine. It had printed out the data from ALL tries, not just the first one. I then changed the copy routine so that it would only be called when the NINJA program had the right data, not simply after it had ANY data, like it had been doing. I then put that on disk, copied that data onto the right sectors, and tried it again, and held my breath. This time it worked!!! (Actually, At first I thought that it read it twice and then compared the two to see if they were different. Some times during a read track, some of the control bytes will be read differently, until it can synchronise with the real data. Thats what this was doing. It was only after I tried to patch it so that it could read diffent infos on consecutive tries that I realized that I simply wasn't working with the right data to begin with.) NOTES: I didn't write any of the asm programs for sharing, so they are not commented. I also am not entirely sure these were the final versions that I used, after all I've 3 1/2 disks full of versions of asm programs I used. NINJA.ASM: The disassembly of Ninja.bin. It's not fully done, there are probably major errors in it. But it should be of some help in understanding the following asm patches. NINJA.BIN: This is just a copy of the one of the orriginal game disk, except it doesn't auto-start. I did this by changing a couple of bytes at the end. Byte 2089 changed from 80 to 198, and byte 2090 changed from 0 to 228. Bytes 2089 and 2090 are loaded into a ROM hook at 387 (jump before keyboard input) READTK.ASM: This reads track 0 into memory. This reads a full track, including control bytes, crc (correct or not), etc. It puts the data in $4000 to $5FFF. WRITETK.ASM: This writes a track 0 onto disk. (NOTE: certain control values cannot be written during a write track command. They will be translated as special control bytes onto the disk. It expects data to be in $4000 to 5FFF. PRINT1.ASM: This is the orriginal print routine. It adds $2A to all of the data printed because NINJA.BIN subtracts $2A during loading. This was used when I was still trying to find the data on disk. It also prints a few header bytes of variables that I was checking at the time. PRINT2.ASM: Same as above excepth it doesn't add $2A. PRINT3.ASM: Same as print2.asm, except it is hooked into a different place. This one prints the REAL data. It also doesn't print any of the variables the other ones do. COPY1.ASM: This copies the data read into bank 112, turns off the drive and hangs up, allowing me to reset the computer. It also puts several header bytes of variables I was interested in. COPY2.ASM: This copies the REAL data into bank 112. It doesn't copy any variables. It is hooked into a different place than COPY2. PATCHED.ASM: The patch that is placed over the read track 0 section. This tells it to read the sectors where I put the data at. PUT.BAS: This is the BASIC program to put the information onto track 25, sectors 1-18, and track 26, sectors 1-9. You must have already loaded the data that was saved to disk. MERGE.BAS: This adds the PATCHED.BIN that was assembled onto the end of the NINJA.BIN on the game disk. DIRECTIONS FOR MAKING NINJA.BIN NON-AUTO-STARTING. 1. Copy NINJA.BIN from the original game disk onto a fresh blank disk. 2. Leave the new disk with NINJA.BIN in. 3. Type OPEN "D",#1,"NINJA.BIN",1 4. Type FIELD #1,1 AS A$ 5. Type PRINT #1,CHR$(198); (This patches it so that it loads into 387) 6. Type PUT #1,2089 (what is already there. I.E. it doesn't) 7. Type PRINT #1,CHR$(228); (change it, so it wont auto-start.) 8. Type PUT #1,2090 9. Type CLOSE DIRECTIONS FOR PATCHING KYUM-GAI YOURSELF: 1. Load NINJA.BIN (the non-auto-starting one) 2. Load COPY2.BIN (this will do the copying) 3. Put the orriginal game disk in (the copy protected one) 4. EXEC 20480 (this runs it) 5. After a while the disk will shut off and nothing else will happen. This takes less than a minute. 6. Remove the orriginal game disk. 7. Hold , and and press reset. 8. You should see a picture of 3 Microware guys. 9. Press reset (don't hole ) 10. You should see the normal BASIC startup message. 11. Type PCLEAR1 12. Type CLEAR 200,16383 13. Type POKE &HFFA2,112 (this brings in bank 112 into memory locations 16384-24575.) 14. Put in a formated disk 15. Type SAVEM"DATA.BIN",16384,24575,0 16. Turn the computer off, then back on. 17. Load PUT.BAS 18. Put the disk from step 15 in. 19. Type RUN 20. Put in a non-write protected back up copy of K.G. 21. Press enter 22. When done, turn your computer off, then back on. 23. Load MERGE.BAS 24. Put the disk that has PATCHED.BIN in the drive. 25. Type RUN 26. Put the K.G. disk from step 20 in the drive. 27. Press enter. 28. When done, put a write protect on the K.G. disk. 29. Turn the computer off, then on. 30. Type LOADM"NINJA" 31. Kyum-Gai should load and run.