damaged atr?

[eegad]

I've just discovered an odd problem. Long ago, when the first emulators were coming about (mid-90s), I had the Rainbow 95 emulator. I actually remember spending one saturday afternoon uploading some diskcomm'd atari disk images (at 1200 baud!), and then downloading them on my pc to use with Rainbow. I also seem to recall having a utility that could convert .dcm files to .atr files, and doing that at some point. Well, I just went to use one of those old .atr files and found that they don't work with Altirra or Atari800WinPlus. They report the file as being "damaged" or an "unsupported format". But what's really odd is that if I fire up that old Rainbow emulator (which still seems to work okay in Win7), it WILL load those atr files just fine. Which makes me think that somewhere along the way the specs on the atr file format have changed???? What I can say for sure is that the .atr's that I've downloaded in more recent times are 92172 bytes (single density disks of course). But the old atr's that I converted myself way back when are all 92160 bytes. So obviously something is amiss. Anybody have a way for me to "fix" those old files so that Altirra will recognize and load them??? Obviously all the necessary data is there since Rainbow runs them fine....but something must be screwy with the header data or something.

[Roydea6]

• 
  Rename to xxxx.XFD because these have no header bytes..
  

  96 02 80 16 80 00 00 00 00 00 00 00 00 00 00 00
  

  
  Or something like that. It is diferent for each size of ATR.
  

[eegad]

Awesome - thanks, that did the trick!

[atari8warez]

I've just discovered an odd problem. Long ago, when the first emulators were coming about (mid-90s), I had the Rainbow 95 emulator. I actually remember spending one saturday afternoon uploading some diskcomm'd atari disk images (at 1200 baud!), and then downloading them on my pc to use with Rainbow. I also seem to recall having a utility that could convert .dcm files to .atr files, and doing that at some point. Well, I just went to use one of those old .atr files and found that they don't work with Altirra or Atari800WinPlus. They report the file as being "damaged" or an "unsupported format". But what's really odd is that if I fire up that old Rainbow emulator (which still seems to work okay in Win7), it WILL load those atr files just fine. Which makes me think that somewhere along the way the specs on the atr file format have changed???? What I can say for sure is that the .atr's that I've downloaded in more recent times are 92172 bytes (single density disks of course). But the old atr's that I converted myself way back when are all 92160 bytes. So obviously something is amiss. Anybody have a way for me to "fix" those old files so that Altirra will recognize and load them??? Obviously all the necessary data is there since Rainbow runs them fine....but something must be screwy with the header data or something.

 

If memory serves me correctly the Disk Communicator program had a habit of adding extraneous bytes at the end of the compressed disk files (.DCM). So when these files are converted to .ATR format, the .ATR header indicated that the file size is 92160 bytes (for single density disks) whereas the actual file size was larger. It is perhaps why some emulators don't load those .atr files.

 

For example I just discovered that AspeQt does an integrity check when loading a drive with an .atr. One file i tried recently (FTE's disk version of MAC/65) did not succesfuly load because of header size/actual size mismatch. I commented out the check routine and recompiled AspeQt and the file loaded with no problems and my 130XE was able to boot from it and able to run MAC/65 with no probs. I examined the .atr with an hex editor and seen that last 112 bytes were filled with 1A's and that exactly accounted for the size difference.

 

So my take on this is if an .atr file is actually larger than what the header indicates, the file can probably safely be mounted on a drive. However If the actual file size is smaller than the size indicated by the header value, then we may run into problems.

 

I am planning to implement that change in AspeQt, that way some of the unloadable .atr files would load and run.... what do you folks think about this?

[Marius]

Thomas Grasel wrote an ATR fixing tool.

 

I guess that tool will fix problem with aspeqt too.

 

Google for sio2usb abbuc grasel

[sloopy]

Fix the problem, not work around it... add the ability in AspeQt to work around the issue of a faulty header, not remove the header check...

 

as this will create the problem of two 'identical' atr's with the only difference being the bad data...

 

sloopy.

[atari8warez]

Fix the problem, not work around it... add the ability in AspeQt to work around the issue of a faulty header, not remove the header check...

 

as this will create the problem of two 'identical' atr's with the only difference being the bad data...

 

sloopy.

 

Sorry, I wasn't too clear on how I implemented the fix. I did not remove the check, I added logic to complement it, so that files larger than the header value still load, but not the other way around (I mean files smaller than the header value will fail to load -- as is currently the case --)

 

Ray

Edited January 28, 2012 by atari8warez

[atari8warez]

Thomas Grasel wrote an ATR fixing tool.

 

I guess that tool will fix problem with aspeqt too.

 

Google for sio2usb abbuc grasel

 

That's fine but I think AspeQt should still have that check. My approach on programming is to deal with the problem where it occurs rather than relying on outside fixes.