cas Posted March 21, 2008 Share Posted March 21, 2008 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 Quote Link to comment Share on other sites More sharing options...
Sub(Function(:)) Posted March 21, 2008 Share Posted March 21, 2008 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. Quote Link to comment Share on other sites More sharing options...
Sub(Function(:)) Posted March 21, 2008 Share Posted March 21, 2008 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. Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted March 21, 2008 Share Posted March 21, 2008 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 1 Quote Link to comment Share on other sites More sharing options...
cyco130 Posted March 22, 2008 Share Posted March 22, 2008 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. 1 Quote Link to comment Share on other sites More sharing options...
cyco130 Posted March 22, 2008 Share Posted March 22, 2008 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" 1 Quote Link to comment Share on other sites More sharing options...
cas Posted March 22, 2008 Author Share Posted March 22, 2008 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 Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted March 22, 2008 Share Posted March 22, 2008 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. Quote Link to comment Share on other sites More sharing options...
jdh Posted March 23, 2008 Share Posted March 23, 2008 (edited) 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 March 23, 2008 by jdh Quote Link to comment Share on other sites More sharing options...
Urchlay Posted March 23, 2008 Share Posted March 23, 2008 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. Quote Link to comment Share on other sites More sharing options...
+Larry Posted March 23, 2008 Share Posted March 23, 2008 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 Quote Link to comment Share on other sites More sharing options...
jdh Posted March 24, 2008 Share Posted March 24, 2008 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'. Quote Link to comment Share on other sites More sharing options...
cyco130 Posted December 15, 2009 Share Posted December 15, 2009 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... Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted December 15, 2009 Share Posted December 15, 2009 (edited) 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 December 15, 2009 by sup8pdct Quote Link to comment Share on other sites More sharing options...
+bf2k+ Posted December 16, 2009 Share Posted December 16, 2009 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. Quote Link to comment Share on other sites More sharing options...
sup8pdct Posted December 16, 2009 Share Posted December 16, 2009 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 Quote Link to comment Share on other sites More sharing options...
+bf2k+ Posted December 16, 2009 Share Posted December 16, 2009 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). Quote Link to comment Share on other sites More sharing options...
fujidude Posted February 17, 2015 Share Posted February 17, 2015 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 1 Quote Link to comment Share on other sites More sharing options...
atari8warez Posted February 17, 2015 Share Posted February 17, 2015 (edited) 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 February 17, 2015 by atari8warez Quote Link to comment Share on other sites More sharing options...
fujidude Posted February 17, 2015 Share Posted February 17, 2015 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. 3 Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted February 17, 2015 Share Posted February 17, 2015 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.. Quote Link to comment Share on other sites More sharing options...
fujidude Posted February 17, 2015 Share Posted February 17, 2015 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.. 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. Quote Link to comment Share on other sites More sharing options...
atari8warez Posted February 17, 2015 Share Posted February 17, 2015 (edited) 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 February 17, 2015 by atari8warez 1 Quote Link to comment Share on other sites More sharing options...
atari8warez Posted February 17, 2015 Share Posted February 17, 2015 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. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 18, 2015 Share Posted February 18, 2015 (edited) 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 February 18, 2015 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.