Jump to content

Photo

ATR-Format Reference


49 replies to this topic

#1 cas OFFLINE  

cas

    Dragonstomper

  • 524 posts

Posted Fri Mar 21, 2008 7:51 AM

Hi,

is there a Reference somewhere how an ATR Image should look like for the various Density formats, and what violations of the original Format exists, caused by which programs?

I have the feeling the ATR Format is a real mess, because it has never been documented clearly in a way that programmers can find and use the reference.

I there is no such reference in existence, I would like to collect such a reference.

Can you point me to the Programs using/creating the ATR Format and send me example ATR Files for inspection.

Carsten

#2 Sub(Function(:)) OFFLINE  

Sub(Function(:))

    Moonsweeper

  • 430 posts
  • Location:Athens, Greece

Posted Fri Mar 21, 2008 8:32 AM

Hello Carsten,

is there a Reference somewhere how an ATR Image should look like for the various Density formats, and what violations of the original Format exists, caused by which programs?

The only documentation I found on ATR's when I looked a while ago were:
http://www.atarimax....rg/afmtatr.html
http://www.atarimax....s/DiskImageFAQ/

I have the feeling the ATR Format is a real mess, because it has never been documented clearly in a way that programmers can find and use the reference.

Agreed

I there is no such reference in existence, I would like to collect such a reference.

I can only thank you, and offer whatever help I can.

Can you point me to the Programs using/creating the ATR Format and send me example ATR Files for inspection.

Looking in my atari devtools "bin" directory these are the ones I found:

Programs By Jindroush
Acvt v1.07 (PC)
Adir v0.67 (PC)
AExt v1.02 (PC)

Ken Siders
AtrUtil Version 1.13
ATRDCM Dos Utils

MacFalkner
DASSI (Readonly?)

Burkhard Rau's
ATARI-Filelister new name ATARI-FileManagement???

Eric Bacher's
DIS6502 (Read only?)

Steve Tucker's
APE and its applications

Misc.
There is also a TotalCommander Plugin for ATR file management

Most of these applications seem to have been written for the PC but I have also seen Linux and Amiga ports, particularly where the source code has been made available.

I guess the software above will have generated most of the ATR's in existence. But now we also have all of the new hardware devices out there that now use ATR's SIO2SD, SIO2IDE SIO2USB..... I have not been keeping up with a lot of these, but I am sure other will be able to list them

Good luck on your search. ;)

MfG.

#3 Sub(Function(:)) OFFLINE  

Sub(Function(:))

    Moonsweeper

  • 430 posts
  • Location:Athens, Greece

Posted Fri Mar 21, 2008 8:40 AM

:ponder:

Sorry, I forgot the obvious:

"Atari800WinPlus" can create ATR's as well. So I guess all in this group (Atari800, etc) may also have the ability.

#4 a8isa1 OFFLINE  

a8isa1

    Stargunner

  • 1,486 posts

Posted Fri Mar 21, 2008 9:31 AM

Hi,

is there a Reference somewhere how an ATR Image should look like for the various Density formats, and what violations of the original Format exists, caused by which programs?

I have the feeling the ATR Format is a real mess, because it has never been documented clearly in a way that programmers can find and use the reference.

I there is no such reference in existence, I would like to collect such a reference.

Can you point me to the Programs using/creating the ATR Format and send me example ATR Files for inspection.

Carsten

Nick Kennedy's page. There you'll find all his SIO2PC information. The layout information for Nick's ATR format is in the Readme.Txt file.

- Steve Sheppard

#5 cyco130 OFFLINE  

cyco130

    Chopper Commander

  • 111 posts

Posted Sat Mar 22, 2008 5:40 AM

Here's my own compilation about ATR file format(s). Sorry for the long post, but currently I don't have any web space to upload this info.

Please note that SIO2PC revision 4.05 version of the format (with copy protection info) is rarely used. Actually I never saw such an image. Nevertheless you can read it as a fairy tale :)

One problem with the specification is that it is not clear how to interpret an image with a size field unequal to the actual file size. When the size stored in the header is bigger then the actual size, I think it's best to interpret the file as a "sparse" image, i.e. read all zeros for the "off" sectors and make the the image file grow when written to. When the size in the header is smaller then the actual size size, it's probably an error condition.

Also note that, Ken Sider's MAKEATR boot loader produces images with wrong size info (x2 if I remember correctly). And there are plenty of game ATR's on the internet made with that utility.

ATR image file format:

----------------------------------------------------------------------------------------------

ATR file format is invented by Nick Kennedy for his SIO2PC program. It is
also used by other emulators. It consists of a 16-byte header followed by the
raw dump of disk sectors. Despite being a de facto standard as the Atari
disk image file format, some parts of the header are redefined in an
incompatible way by different emulators. The first definition of the header
by Nick Kennedy was as follows:

WORD Magic;
WORD Size;
WORD SectorSize;
BYTE Unused[10];

Note: In this file, BYTE means an 8-bit data, WORD means a 16-bit data and
LONG means a 32-bit data. WORD and LONG are in the LSB-first format.

The explanation of individual fields are as follows:

Magic: This is a special code to identify an ATR file. Its value should be
be equal to the byte of the sum of ASCII values of the characters of
the string "NICKATARI", which is 0x0296 (662). If a different value is
encountered in the first two bytes of a file, then this is not an ATR
image file.

Size: Size of the image, excluding this header, in paragraphes, that is, in
16-byte blocks. Note that this allows a maximum size of 0xFFFF0 bytes,
which is not enough to create larger sizes. See SIO2PC rev. 3.0
extensions for the solution of this problem. When

SectorSize: This is the size, in bytes, of one sector of the image. It should
be either 128 (for single density and enhanced density disks) or
256 (for double density disks). Note that regardless the value of
this field, the first three sectors of all images are always
128-byte long. However there are some broken images where these
sectors are 256-byte long for double density disks.

Unused: These bytes are not used by the first definition of the format and
should be zero.

----------------------------------------------------------------------------------------------

In revision 3.0 of the SIO2PC program, Nick Kennedy has extended the format
as follows:

WORD Magic;
WORD Size;
WORD SectorSize;
WORD SizeHi;
BYTE Unused[8];

The newly added SizeHi field holds the high word of the image size in
paragraphes. This allows 0xFFFFFFFF0 bytes as the maximum size. But the
maximum size of a real atari disk can't exceed 0xFFFD80 (65535 sectors,
double density). So only the first byte of this field should be used.

----------------------------------------------------------------------------------------------

In revision 4.05 of SIO2PC, Nick Kennedy has further extended his format to
cover some disk protection schemes. But please note that these extensions are
rarely used. The header's structure has became as follows:

WORD Magic;
WORD Size;
WORD SectorSize;
WORD SizeHi;
BYTE Flags;
WORD ProtectionInfo;
BYTE Unused[5];

The newly added fields are defined as follows:

Flags: This byte holds two flags. If bit 4 is set, the image has bad sector
information. If bit 5 is set, the image is write protected. If the
image have bad sector information, the sectors starting with
0x1E3D1CC2 will be treated as bad sectors. See below.

ProtectionInfo: If the bit 4 of the Flags byte is set, this field holds the
bad sector with copy protection information in it. This
sector contains, in addition to bad sector information, some
information about the good sectors and I/O timing, in order to
emulate some copy protection schemes. See below:

A bad sector has the following information, instead of sector data:

LONG Magic;
BYTE BadSectorStatus[4];
BYTE AckResponse;
BYTE CptResponse;
BYTE ChecksumStatus;

The rest of the sector is unused.

Magic: This is a special code to identify sectors with bad sector information
instead of sector data. It should be 0x1E3D1CC2.

BadSectorStatus: This is the 4-byte data, in reverse order, to be returned to
Atari in response to a get status (0x53, 'S') SIO command
after an attempt to read this bad sector.

AckResponse: This is the acknowledgement code to be returned to Atati, instead
of ACK [0x41('A')] byte, when an attempt is made to read this
bad sector. It can be 'A' for ACK, 'N' for NAK or 'T' for
timeout. If it is 'T', the acknowledgement code will not be
sent.

CptResponse: This is the operation complete code to be returned to Atari,
instead of CPT [0x43('C')] byte, when an attempt is made to read
this bad sector. It can be 'C' for CPT, 'E' for ERR, 'T' for
timeout or '_' for not available. If it is 'T', the complete
code will not be sent. If the AckResponse is 'N' or 'T', this
field should be '_'.

ChecksumStatus: This byte, although not used by SIO2PC, is 'G' for good
checksum and 'B' for bad checksum.

The protection info sector, which is the bad sector pointed by the
ProtectionInfo field of the header, has the following information in addition
to the ordinary bad sector information:

BYTE GoodSectorTiming;
BYTE BadSectorTiming;
BYTE GoodSectorStatus[4];

GoodSectorTiming: This is the amount of delay, in jiffies (1/18.2 seconds),
after responding to a good sector read/write command. This
information is not used by SIO2PC.

BadSectorTiming: This is the amount of delay in jiffies, after responding to
a bad sector read/write command. This information is not
used by SIO2PC.

GoodSectorStatus: This is the 4-byte data, in reverse order, to be returned
to Atari in response to a get status (0x53, 'S') SIO
command, after a good sector read/write. Note that all
good sectors of an image returns the same code.

----------------------------------------------------------------------------------------------

Unfortunately, Steven Tucker, the author of APE, has extended the ATR header
structure in an incompatible way with SIO2PC rev. 4.05. These extension are
as follows:

WORD Magic;
WORD Size;
WORD SectorSize;
WORD SizeHi;
LONG CRC32;
BYTE Unused[3];
BYTE Status;

CRC32: This is the CRC32 of the image. It is calculated as if the second
8-byte part of the header contains all zeroes.

Status: This byte holds some information about disk status. If bit 0 is set,
then the image should be threated as write protected. If bit 1 is
set, then the image is sealed and the CRC32 code is valid.



#6 cyco130 OFFLINE  

cyco130

    Chopper Commander

  • 111 posts

Posted Sat Mar 22, 2008 6:22 AM

As an add on, these are some standard image sizes:

Atari 810, Atari Dos 2.0s compatible: (almost universal)
Single Sided, Single Density, 40 tracks per side, 18 sectors per track, 128 bytes per sector. 720 sectors, 92160 bytes total.

Atari 1050, Atari Dos 2.5 compatible:
Single Sided, Enhanced* Density, 40 tracks per side, 26 sectors per track, 128 bytes per sector. 1040 sectors, 133120 bytes total.

* Atari calls it "dual" density. Prone to confusion with real "double" density.

Indus GT, compatible with some newer DOSes:
Single Sided, Double Density, 40 tracks per side, 18 sectors per track, 256 bytes per sector (except first 3 sectors that are 128 bytes). 720 sectors, 183936 bytes total.

Atari XF551, compatible with some newer DOSes:
Double Sided, Double Density, 40 tracks per side, 18 sectors per track, 256 bytes per sector (except first 3 sectors that are 128 bytes). 1440 sectors, 368256 bytes total.

Percom single sided, compatible with some newer DOSes:
Single Sided, Double Density, 80 tracks per side, 18 sectors per track, 256 bytes per sector (except first 3 sectors that are 128 bytes). 1440 sectors, 368256 bytes total.

Percom double sided, compatible with some newer DOSes:
Double Sided, Double Density, 80 tracks per side, 18 sectors per track, 256 bytes per sector (except first 3 sectors that are 128 bytes). 2880 sectors, 736896 bytes total.

Hard disks should report their sizes as single sided single track. They can be double or single density.

Here are some definitions:

Number of sides:
1 -> ss (single sided)
2 -> ds (double sided)
Tracks per side:
1 -> Hard disks
35 -> Rare
40 -> Most common format
77 -> Rare
80 -> Sometimes called "quad" density.
Sectors per track:
18 -> sd/dd (single density or double density)
26 -> ed (enhanced density, also called dual density)
Bytes per sector
128 -> single or enhanced density, all sectors are 128 bytes long
256- -> double density, first 3 sectors are 128 bytes long, rest is 256 bytes long.

So, basically, you read bytes per sector info from an ATR file and you decide if it's a sd/ed or dd disk. Then you check the size and calculate the number of sectors. You look up a table to determine other disk geometry parameters, e.g. to use in an emulator to supply get geometry and set geometry functions. (SIO commands 0x4E and 0x4F).

However some geometries cannot be determined with table lookup. Percom SS and Atari XF551 have the exact same size and sectors per track. It seems that another extension to ATR format is necessary :)

The full list:
ss, sd, 35: 1*35*80= 630 * 128 = 80640
ss, sd, 40: 1*18*40= 720 * 128 = 92160 (810)
ss, ed, 35: 1*26*35= 910 * 128 = 116480
ss, ed, 40: 1*26*40=1040 * 128 = 133120 (1050)
ss, dd, 35: 1*18*35= 630 . 256 = 160896
ds, sd, 35: 2*18*35=1260 * 128 = 161280
ss, sd, 77: 1*18*77=1386 * 128 = 177408
ss, dd, 40: 1*18*40= 720 . 256 = 183936 (indus)
ss, sd, 80: 1*18*80=1440 * 128 = 184320 -|
ds, sd, 40: 2*18*40=1440 * 128 = 184320 -|
ds, ed, 35: 2*26*35=1820 * 128 = 232960
ss, ed, 35: 1*26*80=2080 * 128 = 266240 -|
ds, ed, 35: 2*26*40=2080 * 128 = 266240 -|
ds, dd, 35: 2*18*35=1260 . 256 = 322176
ss, dd, 77: 1*18*77=1386 . 256 = 354432
ds, sd, 77: 2*18*77=2772 * 128 = 354816
ss, dd, 80: 1*18*80=1440 . 256 = 368256 -| (percom single sided)
ds, dd, 40: 2*18*40=1440 . 256 = 368256 -| (xf551)
ds, sd, 80: 2*18*80=2880 * 128 = 368640
ds, ed, 35: 2*26*80=4160 * 128 = 532480
ds, dd, 77: 2*18*77=2772 . 256 = 709248
ds, dd, 80: 2*18*80=2880 . 256 = 736896 (percom double sided)

Well, there are also broken double density image files which store 256 bytes for the first 3 sectors instead of 128:

ss, bd, 35: 1*18*35= 630 * 256 = 161280
ss, bd, 40: 1*18*40= 720 * 256 = 184320 (broken indus)
ds, bd, 35: 2*18*35=1260 * 256 = 322560
ss, bd, 77: 1*18*77=1386 * 256 = 354816
ss, bd, 80: 1*18*80=1440 * 256 = 368640 -| (broken percom single sided)
ds, bd, 40: 2*18*40=1440 * 256 = 368640 -| (broken xf551)
ds, bd, 77: 2*18*77=2772 * 256 = 709632 (broken)
ds, bd, 80: 2*18*80=2880 * 256 = 737280 (broken percom double sided)

bd means "broken density" :)

#7 cas OFFLINE  

cas

    Dragonstomper

  • Topic Starter
  • 524 posts

Posted Sat Mar 22, 2008 6:43 AM

Hello,

thanks for the information so far, very valuable.

I will compile all this information into a webpage and will continue to collect information about the topic so that hopefully, some software can be fixed and new software and hardware will play well with ATR files.

Carsten

#8 CharlieChaplin OFFLINE  

CharlieChaplin

    River Patroller

  • 2,839 posts

Posted Sat Mar 22, 2008 2:00 PM

Afaik,
the SIO2PC software (newest version 4.21 under DOS and many older versions) has a "bug" where it adds 384 bytes at the end of any DD (double-density) ATR image... one may use Jindroush`s ACVT program to correct this (but if you have hundreds of DD ATR images, it would be much nicer to have SIO2PC software without this bug, especially for images that are bigger than 180kbytes and cannot be corrected with ACVT)...

If I remember correctly, version 3.x of the SIO2PC software also had a bug where it produced Enhanced/Dual Density disks with 140 or 143 kbytes instead of 130kbytes... (there are a few dozens of such ATR images on the Pooldisk two; the problem when downloading these images onto the Atari is, that most Atari sector copiers will not accept 140 or 143k as ED, they still treat it as SD which means a loss of approx. 40kbytes of data)...

-Andreas Koch.

#9 jdh OFFLINE  

jdh

    Chopper Commander

  • 249 posts
  • Location:Nottingham, UK

Posted Sat Mar 22, 2008 8:33 PM

Very informative links!
I've had to delve in to this when writing a tool for my Mac to extend the file length and correct the header of certain single density ATRs in order to get them to work
with the SIO2USB device.

If anyone could compile and try it on Linux and FreeBSD, that would be great (there's a short DROPZONE.atr image in the folder to test with)
http://www.puisoft.co.uk/atari/utils/
(please don't laugh at the code, I gave up coding for a day job a few years back ;) )

Jon

Edited by jdh, Sat Mar 22, 2008 8:35 PM.


#10 Urchlay OFFLINE  

Urchlay

    Stargunner

  • 1,133 posts

Posted Sat Mar 22, 2008 10:00 PM

If anyone could compile and try it on Linux and FreeBSD, that would be great (there's a short DROPZONE.atr image in the folder to test with)


Compiles and runs fine on Slackware Linux 10.2 and FreeBSD 6.3.

One minor feature you might add: use "DROPZONE_corrected.atr" as the output filename, and/or take a 2nd argument to set the output filename.

#11 Larry OFFLINE  

Larry

    River Patroller

  • 3,970 posts
  • Location:U.S. -- Midwest

Posted Sun Mar 23, 2008 5:30 AM

As an add on, these are some standard image sizes:

Atari 810, Atari Dos 2.0s compatible: (almost universal)
Single Sided, Single Density, 40 tracks per side, 18 sectors per track, 128 bytes per sector. 720 sectors, 92160 bytes total.

Atari 1050, Atari Dos 2.5 compatible:
Single Sided, Enhanced* Density, 40 tracks per side, 26 sectors per track, 128 bytes per sector. 1040 sectors, 133120 bytes total.

* Atari calls it "dual" density. Prone to confusion with real "double" density.

Indus GT, compatible with some newer DOSes:
Single Sided, Double Density, 40 tracks per side, 18 sectors per track, 256 bytes per sector (except first 3 sectors that are 128 bytes). 720 sectors, 183936 bytes total.

Atari XF551, compatible with some newer DOSes:
Double Sided, Double Density, 40 tracks per side, 18 sectors per track, 256 bytes per sector (except first 3 sectors that are 128 bytes). 1440 sectors, 368256 bytes total.

Percom single sided, compatible with some newer DOSes:
Single Sided, Double Density, 80 tracks per side, 18 sectors per track, 256 bytes per sector (except first 3 sectors that are 128 bytes). 1440 sectors, 368256 bytes total.

Percom double sided, compatible with some newer DOSes:
Double Sided, Double Density, 80 tracks per side, 18 sectors per track, 256 bytes per sector (except first 3 sectors that are 128 bytes). 2880 sectors, 736896 bytes total.

Hard disks should report their sizes as single sided single track. They can be double or single density.

Here are some definitions:

Number of sides:
1 -> ss (single sided)
2 -> ds (double sided)
Tracks per side:
1 -> Hard disks
35 -> Rare
40 -> Most common format
77 -> Rare
80 -> Sometimes called "quad" density.

(snip...)


Nice compilation, but raises a question... IIRC, 77 tracks were from 8" floppy disks, and you can format floppies with that on some Dos versions. What drives used the 35 tracks/side? I remember that some CP/M systems used 35 tracks, but don't recall anything for the Atari. (?)

-Larry

#12 jdh OFFLINE  

jdh

    Chopper Commander

  • 249 posts
  • Location:Nottingham, UK

Posted Sun Mar 23, 2008 6:54 PM

If anyone could compile and try it on Linux and FreeBSD, that would be great (there's a short DROPZONE.atr image in the folder to test with)


Compiles and runs fine on Slackware Linux 10.2 and FreeBSD 6.3.

One minor feature you might add: use "DROPZONE_corrected.atr" as the output filename, and/or take a 2nd argument to set the output filename.


Thanks :)

I've added your suggestion for an output file switch and also a -test switch to give verbose output on the ATR header (regardless of density) but not actually 'correct it'.

#13 cyco130 OFFLINE  

cyco130

    Chopper Commander

  • 111 posts

Posted Tue Dec 15, 2009 1:59 AM

Nice compilation, but raises a question... IIRC, 77 tracks were from 8" floppy disks, and you can format floppies with that on some Dos versions. What drives used the 35 tracks/side? I remember that some CP/M systems used 35 tracks, but don't recall anything for the Atari. (?)


Here's the answer after almost 2 years :)

I don't know but these are the disk geometry options from SpartaDos's format (xinit) command...

#14 sup8pdct OFFLINE  

sup8pdct

    Dragonstomper

  • 882 posts
  • Location:australia

Posted Tue Dec 15, 2009 3:22 AM

Just a little side note conceriong atari800win+.
If an atr is created with said program and you say a custom size, the program will try to create a size close to the specafied size using tracks, sides and sectors.
Ie a 65535 custom size created will return a percom block of $28 tracks, 2 sides and $333 sectors per track. this works out to FFF0 sectors.

Don't know why they didn't go the same as all other programs/devices with tracks set to 1 and total size in sectors....

James

Edited by sup8pdct, Tue Dec 15, 2009 3:26 AM.


#15 bf2k+ OFFLINE  

bf2k+

    Stargunner

  • 1,766 posts
  • Location:Boot Factory BBS 2k+

Posted Tue Dec 15, 2009 7:52 PM

Just a little side note conceriong atari800win+.
If an atr is created with said program and you say a custom size, the program will try to create a size close to the specafied size using tracks, sides and sectors.
Ie a 65535 custom size created will return a percom block of $28 tracks, 2 sides and $333 sectors per track. this works out to FFF0 sectors.

Don't know why they didn't go the same as all other programs/devices with tracks set to 1 and total size in sectors....

James


I don't know either but when you try to initialize one of these a800win created ATR's with SpartaDOS HDFMTDIR, you get the infamous ?Shows Multiple Tracks? error message. The Real DOS version of HDFMTDIR formats these ATR's fine. I don't think I've ever tried the SDX FORMAT program on one of these images.

#16 sup8pdct OFFLINE  

sup8pdct

    Dragonstomper

  • 882 posts
  • Location:australia

Posted Wed Dec 16, 2009 5:27 AM

Just a little side note conceriong atari800win+.
If an atr is created with said program and you say a custom size, the program will try to create a size close to the specafied size using tracks, sides and sectors.
Ie a 65535 custom size created will return a percom block of $28 tracks, 2 sides and $333 sectors per track. this works out to FFF0 sectors.

Don't know why they didn't go the same as all other programs/devices with tracks set to 1 and total size in sectors....

James


I don't know either but when you try to initialize one of these a800win created ATR's with SpartaDOS HDFMTDIR, you get the infamous ?Shows Multiple Tracks? error message. The Real DOS version of HDFMTDIR formats these ATR's fine. I don't think I've ever tried the SDX FORMAT program on one of these images.


The SDX format program is actually quite good. It will work out the number of sectors on the disk from the percom block returned from the device.
I have dissassembled it for use in another project. Tho with atari800win+ returning $28 for number of tracks, it will give the option to format the disk instead of making formating not an option.
heh, maybe I will assemble a version of the sdx format program for disk based sparta versions.....
James

#17 bf2k+ OFFLINE  

bf2k+

    Stargunner

  • 1,766 posts
  • Location:Boot Factory BBS 2k+

Posted Wed Dec 16, 2009 5:36 AM

The SDX format program is actually quite good. It will work out the number of sectors on the disk from the percom block returned from the device.
I have dissassembled it for use in another project. Tho with atari800win+ returning $28 for number of tracks, it will give the option to format the disk instead of making formating not an option.
heh, maybe I will assemble a version of the sdx format program for disk based sparta versions.....
James


That would be VERY nice - I'll test it for you (I don't use anything but SpartaDOS and SDX).

#18 fujidude OFFLINE  

fujidude

    River Patroller

  • 4,972 posts
  • Location:United States of America

Posted Mon Feb 16, 2015 9:03 PM

I have been doing a bit of digging on this topic and have found Nick Kennedy's info, but also Steve Tucker's and Jindroush's.  I put together a comparison chart which I will try to post here.  The green positions are consistent, while the red ones mis-match.

 

The .ATR format is fairly important in today's A8 world, so overcoming the inconsistencies is likewise important.  The way I see it, a coule of basic approaches come to mind to overcome the inconsistencies.  One way is to re-define the format in a way that can be agreed on, and would be kept (hopefullly) as the only one going forward.  It could be updated of course as future needs arise, but it should be a managed updating to ensure it doesn't get forked up so to speak. :)  The other way, would be to see what parts of the divergent specs are the same and different, and simply avoid using features which are handled by inconsistent zones.  We can call that dumbing down the feature set you use to the least common denominator.  Right now, as I understand it, that LCD is to use only the first six bytes (offset 0 - 5).

 

I'm interested in the thoughts of the community on this.  It is kind of a shame Steve Tucker contradicted Nick's spec, especially as Nick had set aside some spare bytes for future expansion.  Steve commandeered some that were already specifically defined, and left untouched 4 out of 5 of the spares.  Don't mis understand me, I am not trying to be too judgemental of Steve.  My research may not be as accurate as I hope.  Also, I don't know the evolution of Steve's version and Nick, and if any collaboration was attempted, or whatever else I may be unaware of that played a part.

Attached Files



#19 atari8warez OFFLINE  

atari8warez

    River Patroller

  • 2,724 posts
  • Location:Canada

Posted Tue Feb 17, 2015 1:24 AM

Holly crap, replying to a 6 years old question at the beginning of the thread, must start sleeping more than I normally do, lol.......


Edited by atari8warez, Tue Feb 17, 2015 1:32 AM.


#20 fujidude OFFLINE  

fujidude

    River Patroller

  • 4,972 posts
  • Location:United States of America

Posted Tue Feb 17, 2015 9:48 AM

Holly crap, replying to a 6 years old question at the beginning of the thread, must start sleeping more than I normally do, lol.......

 

It may an old thread, but there is no problem that I'm aware of  in having new interest in it or more to talk about at a later date.  It seemed better to me to post my information here than to create a new one.



#21 rdea6 OFFLINE  

rdea6

    River Patroller

  • 2,696 posts
  • Location:Arizona USA

Posted Tue Feb 17, 2015 10:02 AM

Atr Headers info.PNG

 

Just so I could visualize the information being talked about,  I think a clearer impact on the reader would be a nice picture of your efforts rather than something you have to open later with Adobe reader.  When all context of what is being offered is not seen at the moment..

 

 



#22 fujidude OFFLINE  

fujidude

    River Patroller

  • 4,972 posts
  • Location:United States of America

Posted Tue Feb 17, 2015 2:09 PM

attachicon.gifAtr Headers info.PNG

 

Just so I could visualize the information being talked about,  I think a clearer impact on the reader would be a nice picture of your efforts rather than something you have to open later with Adobe reader.  When all context of what is being offered is not seen at the moment..

 

 

 

I sincerely thank you for your input, but I don't think it is much of a chore to open PDF document.  There are tons of free PDF viewers out there if you don't care for Adobe.  It is about as close to a universaly accepted standard as you can get besides text.  I wanted to put a picture up, but thought this forum requires that you host the picture somewhere else.  That's a can of worms I did not want to open.  I see you managed to get one on here and it is hosted here.  I'll have to take a closer look at that next time around.



#23 atari8warez OFFLINE  

atari8warez

    River Patroller

  • 2,724 posts
  • Location:Canada

Posted Tue Feb 17, 2015 4:50 PM

 

It may an old thread, but there is no problem that I'm aware of  in having new interest in it or more to talk about at a later date.  It seemed better to me to post my information here than to create a new one.

 

Sorry I think there is a misunderstanding, my comment was actually to myself because I responded to an 6 year old post. There is nothing wrong with yours, it was mine that didn't make sense 8 years later because I said to him: "You forgot AspeQt as one of the software that handles ATRs". Obviously 6 years ago there was no AspeQt and the majority of 8 bit users today already know about it. That's why when I realized that the message was quite old, I deleted my response and said "I need to sleep more"....

 

Hope that clears the issue.    :)


Edited by atari8warez, Tue Feb 17, 2015 4:53 PM.


#24 atari8warez OFFLINE  

atari8warez

    River Patroller

  • 2,724 posts
  • Location:Canada

Posted Tue Feb 17, 2015 5:00 PM

 

I sincerely thank you for your input, but I don't think it is much of a chore to open PDF document.  There are tons of free PDF viewers out there if you don't care for Adobe.  It is about as close to a universaly accepted standard as you can get besides text.  I wanted to put a picture up, but thought this forum requires that you host the picture somewhere else.  That's a can of worms I did not want to open.  I see you managed to get one on here and it is hosted here.  I'll have to take a closer look at that next time around.

 

Pics and video links are OK, we do it all the time.

 

As for the ATR format inconsistencies, I agree with you. As a developer I personally take the original (NIck Kennedy's) version as the standard format. I don't know what Steve's additions used for exactly. I don't even know why it is important to sign and seal an ATR file. It's not like there are tons of hackers trying to inject malware into our ATRs and I fail to see why exactly authentication is required. I believe the space used for signing and sealing and the CRC could be used for something more useful.



#25 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 13,565 posts
  • Location:United Kingdom

Posted Tue Feb 17, 2015 6:33 PM

For the purpose of making an ATR which actually mounts (and the latest discussion seems to have been sparked by the result of attempting to prepare an unARCed copy of the SDX toolkit disk with an ATR tool which couldn't manage to write the header properly), only the first seven bytes of the header are required, and these are common to both variations. Even non-standard DD ATRs without truncated boot sectors are not difficult to decypher by those of us who have written software to read them. It will take more than half a dozen bytes to store any kind of meaningful metadata anyway: the ATR is what it is and I doubt if a third or forth variation on the same format will improve matters. The parameters in the header required to get the image to work are universally agreed upon anyway. Volume locking and such is usually handled by the host software. We've discussed the ATR format and possible alternatives numerous times already. It does not strike me as the burning question of the day towards which we should all steer our attention.

Edited by flashjazzcat, Tue Feb 17, 2015 6:34 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users