Jump to content
IGNORED

ATR-Format Reference


cas

Recommended Posts

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

Link to comment
Share on other sites

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.com/jindroush.atari.org/afmtatr.html

http://www.atarimax.com/ape/docs/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.

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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" :)

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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'.

Link to comment
Share on other sites

  • 1 year later...

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...

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

  • 5 years later...

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.

ATR Image File Header Format comparison chart.pdf

  • Like 1
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

post-10165-0-37097400-1424188613_thumb.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..

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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
  • Like 1
Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...