Jump to content

Photo

ATR-Format Reference


49 replies to this topic

#26 fujidude OFFLINE  

fujidude

    River Patroller

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

Posted Tue Feb 17, 2015 7:15 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.

 

It is the 1st 6 bytes that are common.  That's probably what you meant to say.  In Nick's a word is used at offset 6 and 7 for extending the amount of paragraphs .  In Steve's it is a byte at offset 6.  Offset 7 is the first part of a dword for his CRC.  Granted it really would be unlikely that a full extra word would need to be added to the image size information and single byte is fine.  The other areas that are common are Nick's spares at the end (offset 11 - 15), except for the last byte (offset 15) which steve wanted to be for flags, even though Nick had already defined that at offset 8.

 

Since the spares do not yet have an agreed upon funtion, in fact no one has yet defined them, they are not "safe" to use for an image that needs to be compatible.  This leaves only the the 1st 6 bytes as safe and useful right now.


Edited by fujidude, Tue Feb 17, 2015 7:15 PM.


#27 Shawn Jefferson OFFLINE  

Shawn Jefferson

    Stargunner

  • 1,987 posts
  • Location:Victoria, Canada

Posted Tue Feb 17, 2015 9:44 PM

The whole concept of "paragraphs", imo, is just weird.  Why not just sector size and number of sectors? Also, what's with the "first (or typical) bad sector" field?  That couldn't have possibly been of much use for copy protection emulation...

 

Can't really change it now though I suppose, and why would you want to?  Better to build a better format.  A successor disk image format should probably also take into account copy protection information (like ATX), but also be extendable to larger disk sizes too.


Edited by Shawn Jefferson, Tue Feb 17, 2015 9:47 PM.


#28 Shawn Jefferson OFFLINE  

Shawn Jefferson

    Stargunner

  • 1,987 posts
  • Location:Victoria, Canada

Posted Tue Feb 17, 2015 9:46 PM

oops duplicate post


Edited by Shawn Jefferson, Tue Feb 17, 2015 9:47 PM.


#29 fujidude OFFLINE  

fujidude

    River Patroller

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

Posted Tue Feb 17, 2015 11:02 PM

The whole concept of "paragraphs", imo, is just weird.  Why not just sector size and number of sectors? Also, what's with the "first (or typical) bad sector" field?  That couldn't have possibly been of much use for copy protection emulation...

 

Can't really change it now though I suppose, and why would you want to?  Better to build a better format.  A successor disk image format should probably also take into account copy protection information (like ATX), but also be extendable to larger disk sizes too.

 

I think the answer to some things is that it wasn't as well thought out as it could have been.  But it's here, it's in wide use, and we should all take care to use it in a way which is interoperable.  An .ATR file that actually depends upon information past the 1st 6 bytes probably won't work in some software.  That's a bad thing.



#30 fujidude OFFLINE  

fujidude

    River Patroller

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

Posted Wed Feb 18, 2015 8:04 PM

The whole concept of "paragraphs", imo, is just weird.  Why not just sector size and number of sectors?

 

That makes more sense to me as well.  At first I thought perhaps Nick only wanted to use a word for size, and needed to have it represent paragraphs so larger sizes could be handled, but then he added 2 more bytes for that purpose as well, which would negate the need to be paragraphs.  Also, sectors are 128, 256, or 512 bytes: much larger than paragraphs, so storing number of sectors would seem the thing to do as you could easily calculate total size by multiplication.  You could get by with fewer bytes to store size that way, or allow much larger sizes with same number of bytes.


Edited by fujidude, Wed Feb 18, 2015 8:06 PM.


#31 drac030 OFFLINE  

drac030

    Stargunner

  • 1,836 posts
  • Location:Warszawa, Poland

Posted Thu Feb 19, 2015 4:48 AM

It is the 1st 6 bytes that are common.


Seven: offsets 0, 1, 2, 3, 4, 5, 6 make 7 bytes.

#32 fujidude OFFLINE  

fujidude

    River Patroller

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

Posted Thu Feb 19, 2015 10:52 AM

Seven: offsets 0, 1, 2, 3, 4, 5, 6 make 7 bytes.

 

Oops.  Yes indeed.  I got my offset number and counting from one position mixed around.  The 1st 7 bytes.  Thank you for pointing that out.  I must havbe been tired.



#33 HiassofT OFFLINE  

HiassofT

    Stargunner

  • 1,057 posts
  • Location:Salzburg, Austria

Posted Thu Feb 19, 2015 5:29 PM

Has anyone came across one of those ATRs with the CRC32 checksum in the header?

I can't remember seeing one of those so far, and I surely would have noticed them because I check all 4 size bytes in AtariSIO.

I did a quick check with APE trial under wine, and it seems the CRC32 bytes are usually set to 0 (so no compatibility problem here). But it's a pity that APE uses the last byte for the write protect flag - being able to write-protect images independently from OS file attributes is a really nice feature IMO.

so long,

Hias

#34 kenjennings OFFLINE  

kenjennings

    Dragonstomper

  • 788 posts
  • Me + sio2pc-usb + 70 old floppies
  • Location:Florida, USA

Posted Thu Feb 19, 2015 7:55 PM

 

That makes more sense to me as well.  At first I thought perhaps Nick only wanted to use a word for size, and needed to have it represent paragraphs so larger sizes could be handled, but then he added 2 more bytes for that purpose as well, which would negate the need to be paragraphs.  Also, sectors are 128, 256, or 512 bytes: much larger than paragraphs, so storing number of sectors would seem the thing to do as you could easily calculate total size by multiplication.  You could get by with fewer bytes to store size that way, or allow much larger sizes with same number of bytes.

 

How big is a paragraph then?



#35 Shawn Jefferson OFFLINE  

Shawn Jefferson

    Stargunner

  • 1,987 posts
  • Location:Victoria, Canada

Posted Fri Feb 20, 2015 12:20 AM

I believe it's 16 bytes?

0000 0000 96 02 80 16 80 00 00 00  00 00 00 00 00 00 00 01

Yes, definitely 16.  that's the ATR header there, 96 02 is the "magic number", and 80 16 is $1680, which multiplied by $80 (128) gives you the size of a regular 720 sector SD disk.

 

I guess using paragraphs you could have an ATR that total size isn't a multiple of the sector size, but I wonder what the point of that would be?


Edited by Shawn Jefferson, Fri Feb 20, 2015 12:25 AM.


#36 atari8warez OFFLINE  

atari8warez

    River Patroller

  • 2,724 posts
  • Location:Canada

Posted Fri Feb 20, 2015 2:00 AM

and 80 16 is $1680, which multiplied by $80 (128) gives you the size of a regular 720 sector SD disk.

 

 

 You really meant "$1680 (5760), which multiplied by $10 (16) gives you the size of a regular 720 sector SD disk ($16800 / 92160 bytes)"


Edited by atari8warez, Fri Feb 20, 2015 2:01 AM.


#37 fujidude OFFLINE  

fujidude

    River Patroller

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

Posted Fri Feb 20, 2015 1:01 PM

I believe it's 16 bytes?

0000 0000 96 02 80 16 80 00 00 00  00 00 00 00 00 00 00 01

Yes, definitely 16.  that's the ATR header there, 96 02 is the "magic number", and 80 16 is $1680, which multiplied by $80 (128) gives you the size of a regular 720 sector SD disk.

 

I guess using paragraphs you could have an ATR that total size isn't a multiple of the sector size, but I wonder what the point of that would be?

 

Correct, paragraph is 16 bytes.  At least it is in Atari land.  Not sure if the definition ever changes like it can for WORD on different processors.  Also agree on the what's the point question there too.  Seems that storing number of sectors and sector size is the best, easiest, most compact way.



#38 Shawn Jefferson OFFLINE  

Shawn Jefferson

    Stargunner

  • 1,987 posts
  • Location:Victoria, Canada

Posted Fri Feb 20, 2015 9:20 PM

Thanks for catching that typo... multiplied by 16 bytes, not the sector size.



#39 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,510 posts
  • Location:USA

Posted Sat Feb 21, 2015 12:07 AM

Perhaps the ATR format was introduced with a DOS program? 16 byte paragraphs are an artifact from x86 real mode segment:offset addressing.



#40 CharlieChaplin ONLINE  

CharlieChaplin

    River Patroller

  • 2,839 posts

Posted Sat Feb 21, 2015 7:57 AM

Perhaps the ATR format was introduced with a DOS program? 16 byte paragraphs are an artifact from x86 real mode segment:offset addressing.

 

Most likely.

Nick Kennedy not only made the SIO2PC hardware, but also SIO2PC software. And errm, SIO2PC.exe is a DOS program... (I still use the hardware and software under MS-DOS 6.22 on my 2Ghz PC).



#41 eed002 OFFLINE  

eed002

    Space Invader

  • 18 posts

Posted Wed Jul 11, 2018 8:12 PM

All,

 

Its a couple of years, but I am trying to understand the ATR format, for a project I am working on. I have read the posts, and the NICK textfile is great.

 

However, with regards to the ATR format, where is the File allocation table kept? Is there a binary map of empty sectors?

 

An help is appreciated.

 

Thanks,

Ed


Edited by eed002, Wed Jul 11, 2018 8:14 PM.


#42 Kyle22 ONLINE  

Kyle22

    River Patroller

  • 3,377 posts
  • Call my BBS! telnet://broadway1.lorexddns.net
  • Location:McKees Rocks (Pittsburgh), PA

Posted Wed Jul 11, 2018 8:25 PM

It depends. If it is a Sparta format disk, it is usually near the beginning of the disk.  If it's an AtariDOS or MyDOS disk, it's near the middle. ATR is only a 16 byte header tacked on the front of the actual image.

 

Look here: http://fileformats.a...am.org/wiki/ATR

 

Edit: Typo.


Edited by Kyle22, Wed Jul 11, 2018 8:26 PM.


#43 JR> OFFLINE  

JR>

    Moonsweeper

  • 252 posts

Posted Wed Jul 11, 2018 8:43 PM

The ATR file is mostly just a container for sectors.  How those sectors are managed is determined by the DOS being used.



#44 eed002 OFFLINE  

eed002

    Space Invader

  • 18 posts

Posted Wed Jul 11, 2018 8:52 PM

Thanks. I thought I was going nuts. I have seen http://fileformats.a...am.org/wiki/ATR, and the many DOS specifications, posts, etc...and I thought I was missing something. This helps a lot.

 

Thanks,

Ed


Edited by eed002, Wed Jul 11, 2018 8:52 PM.


#45 eed002 OFFLINE  

eed002

    Space Invader

  • 18 posts

Posted Wed Jul 11, 2018 9:25 PM

I am working on a simple ultimate SIO peripheral(P: R: D: C:) , SIO2WIFI with an ESP8266. Where for D: access, I was planing on accessing files at an FTP directory. 

 

I plan on reusing already existing code for .ATR implementations. However, I wanted a way to just have all the files in the ftp directory, directly accessible, and not part of an ATR structure.

 

My idea was that I could have a virtual directory structure. However, if a dos like sparta needs a FAT located somewhere in the middle of the drive I have a problem.

 

I wanted to parse the ftp directory, create a JSON of all the files, and assign sectors to them. The first 3 sectors would be special, but in essence my special JSON file will have the sector structure. So that, if sparta dos X was what was installed in that ftp directory mount, then its FAT would be non file data that is stored on sectors in the JSON. I would also have to hide the JSON from the OS itself.

 

The problem that I am seeing is that any file that is added via any non-sparta transaction(user drops a file into the directory), those files wont be in the FAT, and sparta wont know about it.

 

For this to work, I need to know where the FAT is located(dos dependent), and update the JSON, every time I reconnect to the ftp directory.

 

I think I am stuck only supporting/serving .ATR files, and my idea for a free directory structure is a dead end.

 

Hence, my desire to know the location of all the FATs, and tables for each OS.

 

Any thoughts appreciated.

 

( I guess I could pick an OS like Sparta and force those open directories to use that OS, manage the FAT update, and limit my complexity down to one OS.)

 

Thanks,

-Ed


Edited by eed002, Wed Jul 11, 2018 9:37 PM.


#46 eed002 OFFLINE  

eed002

    Space Invader

  • 18 posts

Posted Thu Jul 12, 2018 6:18 AM

Found the Sparata X reference manual...exactly what I needed.

 

However, as I think about my problem, I think the best thing is to not to try and merge the both worlds, but try to create an FTP DOS. 

Ed


Edited by eed002, Thu Jul 12, 2018 7:12 AM.


#47 DrVenkman OFFLINE  

DrVenkman

    River Patroller

  • 3,212 posts
  • Back off, man! I'm a scientist.
  • Location:KMBT

Posted Thu Jul 12, 2018 7:21 AM

Found the Sparata X reference manual...exactly what I needed.
 
However, as I think about my problem, I think the best thing is to not to try and merge the both worlds, but try to create an FTP DOS. 

Ed


A number of peripheral software emulators already allow mounting an entire directory as a virtual drive (RespeQt for one). SDX can read the contents, albeit with truncated filenames displayed.

#48 JR> OFFLINE  

JR>

    Moonsweeper

  • 252 posts

Posted Thu Jul 12, 2018 7:41 AM

And RespeQt is open source, so maybe you can get some ideas looking at how they handled it.



#49 flashjazzcat ONLINE  

flashjazzcat

    Quadrunner

  • 13,565 posts
  • Location:United Kingdom

Posted Thu Jul 12, 2018 9:00 AM

Look at the PCLink protocol (which works via a driver with SDX). It allows unambiguous client/server file management with absolutely no restrictions on the server's filesystem.



#50 eed002 OFFLINE  

eed002

    Space Invader

  • 18 posts

Posted Fri Jul 13, 2018 7:24 AM

Thanks for your help. 

 

After thinking about this, my biggest problem is fseek and FTP interoperability.  

 

I think I will be creating a special DUP.SYS that is parallel to DUP.SYS and called something else (FTPDOS).

 

FTPDOS will look like a standard unix prompt ("R4:> ....(command)"). I will have mount/umount command that will copy a .ATR (from ftp) to ESPFLASH and push out writes to ftp.

 

This will allow my to seek a file based ATR, do sector writes, and sync with the ftp server.

 

However, the FTPDOS will also allow me to access the ftp directory directly and load/save/run/del..., even copy from R4:(ftp) to D1:(sio) and vice versa.

 

This allows me to preserve the desired FMS within the A8 but still have the FTP access that I wanted.  This way a subsequent boot, would SIO boot from D1(SIO) if desired.

 

Anyways,  this is for a different thread, but still sortof ATR related.

 

Thanks,

Ed


Edited by eed002, Fri Jul 13, 2018 8:05 AM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users