53 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.