[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hardware musings

Michael J. Mahon wrote:

--but I detected a tone of disagreement!  ;-)
Not much of a discussion without some differing views. :) Besides, I was actually trying to challenge you (or anyone lurking) to punch holes in my suggested format. I really would like to make a format that could handle any 5.25 disk, regardless. If that means making a new 5.25 controller or designing a new piece of hardware to make it possible, so be it. I'd make it open source for the good of the community. 



I'd be worried about discarding information from the image file that
later (maybe *much* later) turned out to be needed.  (Say, after you
reach the treasure chest and drop the bronze key...  ;-)
True, look at Silent Service or was it PHS Pegasus... Whatever. I have a supposedly cracked copy that works on a IIc, but on an enhanced IIe, it turns all enemies into destroyers part way through. (So I'm told.) 


The problem is that no amount of testing can be proven sufficient

> Until a program has been driven into every nook an cranny of its
> states, you cannot be sure that it isn't going to do some protection
> check, unless you have a priori knowledge of that protection scheme.
>
> There have been several cases lately in which a "deprotected" game
> has failed well into its scenario--because the deprotector overlooked
> some state.
>
Actually if you can play the game all the way through to the finally several times, then the game is most likely OK.
You have to remember that most game that were produced were not designed with protection in mind and it had to be added via disk format modification or adding a subroutine to check a disk signature or track synch. Only the truly devious went back and modified their code to inhibit a game. 


Because of this, I have been saying "why take a chance--just keep all
the data."


Agreed, if the bitstream image works then great!  (Seen next responce.)


"Pruned" images are a space optimization that can seldom be *proven* to
completely replace the un-pruned image.
But a pruned image would be more likely to succeed in recreating a real floppy because the head on an A2 drive is wider than a normal (half) track. That is why the A2 used every other track to store data. Double density disks are 96 TPI, the apple II uses half that due to physical propertied of the head. 



I'm a pragmatist.  ;-)


Me too!
But I have read of a protection scheme that moves the arm back an forth across this multi track wide data stream and is not allowed to be out of synch for one byte in the entire track. I therefore content that the 'wide track' could not be replicated by a normal drive. That sort of bit for bit alignment for a real apple II drive is not probable precisely because the rotational speed (often) varies from one rotation to another. 

Yes, and that's true of virtually *all* disk drives, which is why
it could only be written with a wide head.  It's pretty astonishing
that such a device would be made, since it would either considerably
reduce the capacity of the disk, or require duplication in two passes.


People are clever!




True.

It would be very interesting to see a "breakdown" of the frequency of
various types of protection, and their combinations--and then plot
the data versus the date the disk shipped, since the whole process
was evolutionary.


All things considered, it sounds to me like we're in "violent
agreement".  ;-)
What's not to agree on? You asked for a way to store copy protected disks, I provided one based on my experience with NIB format and what is lacking. 

Well, we seemed to be in disagreement about "pruning" early or late
and it took me a while to see what your "track length" field was.
I think we're on the same page now.




I guess I'd like to see any such format have an extensible part that
could contain additional information about the protection scheme and
perhaps some interpretive code to guide a disk "writer".
Sounds like you'd want something like the Copy II+ parameter file in the disk capture/ write utility. Maybe an accompanying text file if there is known formatting.
I finally found one disk I was never able to back up or crack, "Clue: Master Detective". This bitstream format would be ideal to test this game with as it fails quite early by not allowing a necessary part of the game. 

>> I can copy every bit of every track from a protected disk and it
>> won't boot because the track to track alignment is off.  The only way
>> to circumvent this is to make certain that the tracks are
>> synchronized. ... The
>> current Nib format could potentially handle synch as long as the data
>> was presynchronized and the emulator (or device) took into accountthe
>> timing necessary to move the arm and to rotate the disk.  As long as
>> it is a funciton of the program or hardware, the Apple II could runat
>> any speed and the data could come back at any rate...
Anyone want to make a utility to read the track in a few times? Maybe someone with a IIgs, it has enough RAM to do a bitstream image in memory all at once. OF course a II could if you had a slinky with a meg on it. The IIgs could also potentially make a better timing program as it is 2.6 times faster than a standard IIe, but that may take special hardware to bypass the cluch mechanisms in the IIgs that ensure 'normal' speed for Diskette access.
Anyone want to make a hack to the disk II to put an index hole reader circuit in to alleviate the track synch capture issue? Maybe add it to the EDD board and modify the program a bit? Again, on a IIgs this has potential to becomes a wee bit more powerful. 

Thankx,
Ed