Re: And the trace begins... Pick-A-Dilly Pair

[BLuRry <brendan.robert@gmail.com>]

On Wednesday, October 24, 2012 11:00:55 PM UTC-5, Steve Nickolas wrote:
> On Wed, 24 Oct 2012, Hot Rod wrote:
> 
> 
> 
> > See page 6-4 of Beneath Apple DOS.  These are just straight calls to 
> 
> > RWTS directly, after setting up an input/output control block (IOB) via 
> 
> > the DOS-supplied subroutines.
> 
> >
> 
> > So while there are files on the disk (and a VTOC), the program maintains 
> 
> > its own track/sector lists apparently, and makes these calls via RWTS to 
> 
> > load them.  Hard to know if that's due to the crack, or if that's how 
> 
> > the original disk was.
> 
> >
> 
> > Since this is using regular DOS 3.3 RWTS, it matches the info in Beneath 
> 
> > Apple DOS.  Any calls to $3D9 are going to lead to disk access; seems 
> 
> > unlikely they'd deviate or bypass that.
> 
> 
> 
> The API is baroque as hell.  It doesn't seem to be as simple as "put a 
> 
> disk location here, put a target address here, then do this" like the PC, 
> 
> but you would really think that's all there is to it. o.o;
> 
> 
> 
> The DOS is pretty bogstock, as far as DOS goes.  That might be Reset 
> 
> Vector's doing, I have no way of knowing.
> 
> 
> 
> -uso.

I would love to be able to track down where each byte of memory came from on a disk and if the data went through some sort of processing/decrypt/depack or if it was loaded and stored directly.  As I discussed before, this would involve a significant refactoring of the CPU in Jace but it's not impossible.  I would probably make the "data forensic" version of the CPU its own class that can be enabled optionally.  It would be expensive to leave it on all the time, I imagine.