Jump to content
IGNORED

MG Program copyright protection


acadiel

Recommended Posts

Awesome! Great job!

 

Hey, we not only have accurate preserved backups of these programs now, we have also improved the floppy emulation! I call that a win.

 

So... now that we know the HFE Format contains enough of the data to get these programs to run, can we actually transform these into PC99 .DSK (track) format and keep the protection intact?

Link to comment
Share on other sites

So... now that we know the HFE Format contains enough of the data to get these programs to run, can we actually transform these into PC99 .DSK (track) format and keep the protection intact?

 

I'm inclined to say yes (on even minutes) and no (on odd minutes); at least this is what I just experienced. I have to think about that a bit longer.

 

The problem is that PC99 is less powerful than the HFE format. In particular, although the address marks (AM) are contained in PC99, they do not "smell" like AMs. The problem is that the specific nature of AMs are the clock bits, and these are not preserved in PC99. An IDAM looks like "FE" when read as data, but some clock bits are missing. This allows the controller to find the marks on the track and to tell them apart from FE values that are ordinary data. The DAM (Data AM) looks like "FB", but again with special clock bits, and it is immediately followed by sector contents. Suppose that the first byte of the sector is also FB; in that case we cannot decide which one to take as DAM.

 

Therefore, the PC99 format makes assumptions where these AMs are located in the track. When you add a single byte at the beginning, the whole track will become unreadable, because the AMs have moved.

 

It is not so much an issue of the 1K sectors (this would be detected when reading, because the size is recorded in the header) but of the special tracks. You saw that is it essential that the AM are found on these special tracks as well.

 

I guess it would be easier to patch the loader instead.

Link to comment
Share on other sites

 

I'm inclined to say yes (on even minutes) and no (on odd minutes); at least this is what I just experienced. I have to think about that a bit longer.

 

The problem is that PC99 is less powerful than the HFE format. In particular, although the address marks (AM) are contained in PC99, they do not "smell" like AMs. The problem is that the specific nature of AMs are the clock bits, and these are not preserved in PC99. An IDAM looks like "FE" when read as data, but some clock bits are missing. This allows the controller to find the marks on the track and to tell them apart from FE values that are ordinary data. The DAM (Data AM) looks like "FB", but again with special clock bits, and it is immediately followed by sector contents. Suppose that the first byte of the sector is also FB; in that case we cannot decide which one to take as DAM.

 

Therefore, the PC99 format makes assumptions where these AMs are located in the track. When you add a single byte at the beginning, the whole track will become unreadable, because the AMs have moved.

 

It is not so much an issue of the 1K sectors (this would be detected when reading, because the size is recorded in the header) but of the special tracks. You saw that is it essential that the AM are found on these special tracks as well.

 

I guess it would be easier to patch the loader instead.

 

Loader = Easy. We have the source for DiskAssembler and Explorer. Falcor is removing some of the copyright protection checks and going to re-assemble it all into EA/5 files that we can put into a cartridge image. He will also probably put the title screen back into the unprotected binaries, as that was a loader function.

 

Advanced Diagnostics, we do *not* have the source code for. It also needs to read some preference files off a diskette (which, I supposed, you can hard code somehow). That one will be more difficult to re-assemble without the source code, unless Falcor and I can find the original author, and he still has the source code. We have proven that the 'memory image' of Advanced Diagnostics does not work on every system because of the setup that was performed in the protected loader (i.e. it writes to scratch pad and has AORG's in strange places and sets up the scratch pad data up according to a QI or non QI system and the type of disk controller). So, we can get it, but you will have to find all the booby traps. At least with a working HFE you can closely examine it with the debugger and see what it's doing.

Link to comment
Share on other sites

Try to disassemble with TIMT, using symbolic disassembly. This will take some time and needs a lot of adjustment around DATA and TEXT, but you will ultimately get a useful source code. If we cannot access the object code, we can still log the transfer in MAME.

Link to comment
Share on other sites

 

Loader = Easy. We have the source for DiskAssembler and Explorer. Falcor is removing some of the copyright protection checks and going to re-assemble it all into EA/5 files that we can put into a cartridge image. He will also probably put the title screen back into the unprotected binaries, as that was a loader function.

 

Advanced Diagnostics, we do *not* have the source code for. It also needs to read some preference files off a diskette (which, I supposed, you can hard code somehow). That one will be more difficult to re-assemble without the source code, unless Falcor and I can find the original author, and he still has the source code. We have proven that the 'memory image' of Advanced Diagnostics does not work on every system because of the setup that was performed in the protected loader (i.e. it writes to scratch pad and has AORG's in strange places and sets up the scratch pad data up according to a QI or non QI system and the type of disk controller). So, we can get it, but you will have to find all the booby traps. At least with a working HFE you can closely examine it with the debugger and see what it's doing.

 

I attached a list file for the DiskAssembler production program. I hope it helps and doesn't cause more confusion. I have the loaders that I can attach here pretty soon. I'm trying to recreate the full method we used to make the disks back then for historical documentation. You'll see the the production program uses several memory images when it constructs the disk. I'm trying to find exactly what i used to pull them out of memory to make the files. It may have actually been an old TI program from 1981? Still looking. BTW, this program only ran on the CorComp card.

 

Let me know if this sheds any light on the subject.

DBLDLIST.rtf

Edited by FALCOR4
Link to comment
Share on other sites

Attached is the LDR2 listing. You will find this loader in HEX early in the DBLDLIST_c1.rtf file, with the label LDR2. The DiskAssembler production program incorporated it and put it out to disk along with the DD2, DD3, DD4 and DD5 program images. I believe that I also have the first loader as well, the one that loads this one when you launch DiskAssembler. I'll post that one next if it is indeed the correct one. That will complete everything you would need to produce an original DiskAssembler disk (if that's your thing :-). Have fun with it, I hope some of this history is interesting.

 

DLDR2LST.rtf

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...