57 replies to this topic

[acadiel]

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?

[mizapf]

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.

[acadiel]

 

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.

[mizapf]

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.

[FALCOR4]

 

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.

Attached Files

•  DBLDLIST.rtf   64.19KB   10 downloads

Edited by FALCOR4, Thu Apr 26, 2018 8:02 PM.

[FALCOR4]

DELETE FILE DBLDLIST.RTF if you downloaded it.  I had part of the listing turned off which contained some important data.  The attached file has the entire listing.

 

 

 dbldlist_c1.rtf   112.65KB   17 downloads

[FALCOR4]

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   36.39KB   6 downloads

[FALCOR4]

Here's LDR1 or, "DISKASSEM" as it is named on the DiskAssembler disk.  This is the loader that's launches LDR2 which in turn pulls the program images off and puts them into memory.

 

 DskDLDR1.rtf   65.73KB   8 downloads