Hey Womo, did you ever figure out, what speed dos, JD stole to use in
the SC+ rom ??
most likely he patched a speed dos to use.
no, I did not find any bigger similarities between
SpeedDOS and the SC+ ROM. For JiffyDOS I cannot tell
since I didn't investigate that in depth.
There are of course greater similarities between
some routines from the Professional-DOS speeder
system (RapidDOS Pro in the US, DemonDOS in the UK)
and SC+, some routines that make absolutely no sense
for SC+ since it misses the GCR decoding tables as
well as the nybble shifting hardware.
Maybe this was bad coincidence or just made to
obfuscate any code reverse engineers, I don't know.
Even SC+ is not able to make an identical copy of a
certain disk. As Jim Drew explained somewhere, the true
halftrack protection from Bounty Bob Strikes Back!
cannot be reproduced with the native copier for the SC+.
Instead Jim wrote a custom copier after he analyzed the
By analyzing a protection and then creating a mastering
routine that will recreate that protection does mean
that this is not a _copy_, but a re-master.
And further true copier machines (Trace duplicator) are
able to create patterns that can be detected with a 1541
disk drive, but cannot be written with 'em, even if you
do adjust the motor speed. E.g. true Fat Tracks that are
recorded over two adjacent halftracks. If you try to
replicate that, then you would always overwrite one of
the both halftracks due to mechanical issues. The 1541's
R/W head is a so named tunnel erasing head. It write a
wider track and after that the left and right side of
that wide track are erased again after. This sharpens
the track and it can be better reread after. In fact I
never saw such a true Fat Track protection, mostly these
were only precisely aligned adjacent full-tracks.
Reframing btw. is no magic issue. And because Jim Drew
does not explicitly tell about all the nifty tricks that
he used to make the copiers work does not mean that he
did not use something similar to reframing for SC+.
Since no 1541 drive runs at the very same RPM as the
drive the original disk was recorded for, you always
have to do SYNC and GAP length reducing/increasing,
maybe RPM adjustments and some sort of reframing or
frame detection (perhaps tail GAP detection too) on
|Nodes:||4 (0 / 4)|