Page 1 of 1

Atari 8-bit image issue

Posted: Sun Jan 30, 2011 10:47 pm
by Farb
Hi all,

I just got my shiny new Kryoflux board and am trying to use it to image by Atari 8-bit disk collection. I figured I'd start with some simple non-protected images.

My drive is a Toshiba ND-0401GR (360K 5.25") and I had to use the slow firmware to get DTC to recognize it. I'm running DTC on Mac OS X 10.6.6 and the "dtc -c2" command tells me the drive has maxtrack=41.

I'm running the command "dtc -ftest.img -i3a -l15 > log.txt" to image a single-sided single-density disk. However, the resulting image file appears incomplete (data at the end of the disk appears to be missing). I'm attaching a file with the .img file that DTC generated, the log output as well as a .atr file of the same disk created using Atarmax's ProSystem using a real Atari drive for comparison.

Is there something that I'm doing wrong? I've tried two different "new" Toshiba drives (never before used).

Thanks in advance for any help!


Re: Atari 8-bit image issue

Posted: Mon Jan 31, 2011 8:06 am
by IFW
According to the log, you are using a 48 tpi drive.
The default is always using 96 tpi ones.
Reading these types of images on a 96 tpi drive requires stepping over "half-tracks", which is set by your specific image type.
This however results on a 48 tpi drive in skipping every second data track...

02.0 : FM: OK*, trk: 001[002], sec: 18, *T
Here you are reading physical track 2 and expecting it to have the track number of 1 (as it would with 96 tpi). Instead you get track 2 (and a warning about incorrect track number), which should mean it is a 48 tpi drive.

You can override this behaviour by specifying -k1, say dtc -ftest.img -k1 -i3a

Re: Atari 8-bit image issue

Posted: Mon Jan 31, 2011 3:31 pm
by Farb
Thanks for the response, IFW.

I tried adding the -k1 setting and the logs look better. However, the drive now tries to read past track 40 when I use "dtc -ftest.img -k1 -i3a". So, I tried adding the -e40 parameter to force it to read only the first 40 tracks. What's strange is I now get a 184k disk image where I'd only expect to see 92k. Is there something else I should be doing?

I'm attaching log files both with and without the -e40.


Re: Atari 8-bit image issue

Posted: Mon Jan 31, 2011 6:35 pm
by IFW
It could be that:
1, a minimum number of tracks are enforced
2, 2 sides are enforced (side 1 empty)

I think it's the first case by looking at the logs, but could be either. If it's the first case, it's planned that there will be a way to enforce the number of tracks in an image, disregarding the minimum number of numbers set per image type (ie create images with 1 track or 40 track or an arbitray number of track etc...)
If the second case, I'll have to look into what causes it.

Since we don't really have a 48 TPI drive like the one you are using here and DTC primarily supports 96 TPI dumping as it is required for preservation (apart from 3'' as users couldn't be expected to have a 96 TPI drive on that platform), the best would be to submit the stream file for investigating exactly what happens.

Please submit a support ticket at:

or PM MrVince for details on how to submit a dump.

As for preservation you may need to get hold of a 96 TPI drive anyway... but I'll look into this issue regardless.

Re: Atari 8-bit image issue

Posted: Mon Jan 31, 2011 7:36 pm
by Farb
While I do plan to get a 96 TPI drive, it would be nice to be able to use my 48 TPI drives (I have 3 of them) to image the non-protected disks that don't require "preservation level" images. I plan to use a 96 TPI drive (when I get my hands on one) for my original copy-protected disks.

I'll open a support ticket for this issue.

Thanks for the help!