ATR issues Atari800Mac 5.0.1

[Marius]

Hi All,

 

Here is another problem I run into with Atari 800Mac. 

 

I was trying my 16MB Games ATR that was running MyPicoDos. It booted, but did not list the games in the MyPicoDos menu. Garbage instead.

Then I created a double density disk with Atari800Mac, and put some games on it. But that ATR did not want to boot on real hardware (it was a double density disk, 180K). Not attached. I already deleted it -> do not want to make this too complicated. 

Finally I created 2 ATR's on my Atari 65XE using Abbuc SIO2USB. Those ATR's should be fine. They boot on real hardware. 

 

The double density ATR crashes Atari 800Mac. 

TSTDD.ATR

 

 

The single density ATR boots, but gives Disk Error!

TSTSD.ATR

 

I remember people here were investigating the source of this emulator. Perhaps someone can test it with other distributions of Atari800 emulator?

 

I hope we can get a good working Atari800Mac emulator eventually on Mac. I do not use it for development, but mostly for some quick tests. It is a pity that it works not entirely well. 

Any suggestions or other test reports are highly appreciated. 

 

@skr Could you dive into the source about this issue? 

 

 

 

 

 

 

TSTSD.ATR TSTDD.ATR

Edited January 19, 2020 by Marius
Added extra screenshot, and right placement of screenshots in txt.

[Marius]

Oh and another thing... when one swaps disks and presses WARM reset, it seems that disks are not swapped at all. 

 

I can be wrong, but it did not happen here... 

 

A cold boot did swap them though.

[EddyFree]

 

I don't have a Mac but I tried booting those disk images with Altirra though and the Double Density one crashed out. The Single Density had no problem.

 

After further inspection, it seems the Double Density image had a bad "paragraphs" value in the ATR header. Changing bytes 3 and 4 from $00 $2D ($2D00) to $E8 $2C ($2CE8) made it bootable for me.

 

This was a common problem I had with some older versions of SIO2PC when I imaged some disks years ago. Emulators didn't like them. IIRC it has to do with differences in the way the boot sectors are considered in the disk geometry on Double Density disks by various programs.

 

 

[Marius]

5 hours ago, EddyFree said:

 

I don't have a Mac but I tried booting those disk images with Altirra though and the Double Density one crashed out. The Single Density had no problem.

 

After further inspection, it seems the Double Density image had a bad "paragraphs" value in the ATR header. Changing bytes 3 and 4 from $00 $2D ($2D00) to $E8 $2C ($2CE8) made it bootable for me.

 

This was a common problem I had with some older versions of SIO2PC when I imaged some disks years ago. Emulators didn't like them. IIRC it has to do with differences in the way the boot sectors are considered in the disk geometry on Double Density disks by various programs.

 

 

Oh that is interesting!

That would mean that OR the firmware in Sio2USB (which is a standalone device created by Abbuc-Raf, not a Sio2PC device!) has a bug; which I will report as soon as possible, OR the used software (I used YASH) has a bug... I will check that out. 

So that would clear up the Crash. That does not explain though why Atari800Mac does give the garbage in the 16MB ATR and the 'disk error' in the Single Density disk. 
 

I will check out in a hex editor what you wrote about the ATR header. That is extremely interesting. Many thanks for your investigation, this is a very important find. 

I can Google the ATR headers info to get more insight. But my experience is that there is also information around that is not accurate. What is in your opinion a good source of this information?

 

[Marius]

This is getting weirder and weirder. 

 

I created DD ATR's with both the original Sio2USB Shell and Yash, and both they create the right ATR size/header ... what you described)

 

But... the DD ATR that Atari800Mac produces is wrong. That is the one with the wrong header. So I was wrong in my initial post. The DD ATR was created with Atari800 and not with Sio2USB-device.

 

Hmmm. Another bug in Atari800Mac emulator then. 

[+skr]

I´m just digging into makeATR to make a standalone ATR utility for Mac OS X, but I´m heavily lacking on time right now, as I´m working way toooooo much. So progress is very slow, and I still have to learn, how to deal with Xcode, as I´m totally used to MS Visual Studio.

 

[+CharlieChaplin]

Hmmm,

 

I do not have Mac computers, so let's make a wild guess... maybe it is size related ?!? - The 183,xxx bytes vs. 184,xxx bytes ATR images ? The shorter ATRs use boot sectors with 128bytes each, while the longer ATRs use boot sectors with either a) 256 bytes each, b) 128 bytes each, but 384bytes padded at the end or c) other method(s).

 

Afaik, the old SIO2PC.exe (16Bit DOS program by N.Kennedy) works fine with both 183,xxx and 184,xxx ATR images, while some A8 emulators and some A8 hardware & software does not. But maybe your problem does not have anything to do with this at all... (I am not a Mac guy)...

 

 

Edit: Yes, your TESTDD.ATR uses 184,336 bytes and shows as 180k in Windows, alas, thats the "non-standard length" for an A8 DD ATR image (whereas 183,952 bytes is the standard and shows as 179k in Windows).

 

 

Besides, regarding MyPicoDOS, some A8 harddisk interfaces and emulators do not like its highspeed option, so better use a version without any highspeed (the MypicoDOS barebone version).

 

(Think I still have a 16MB ATR image somewhere, where bootsectors 1-3 are stored on sectors 1-6 or something like that and therefore the ATR does not work and thanks to its size I have not been able to correct it.)

 

[EddyFree]

On Tuesday, January 21, 2020 at 4:37 AM, Marius said:

This is getting weirder and weirder. 

 

I created DD ATR's with both the original Sio2USB Shell and Yash, and both they create the right ATR size/header ... what you described)

 

But... the DD ATR that Atari800Mac produces is wrong. That is the one with the wrong header. So I was wrong in my initial post. The DD ATR was created with Atari800 and not with Sio2USB-device.

 

Hmmm. Another bug in Atari800Mac emulator then. 

OK, I went and dug around some of my old source codes because I knew I dealt with this problem before and ended up just patching the ATR headers to get them to work with the Atari800Win emulator.

Let me see if I can explain it a little better.

 

IIRC, the OS expects the first 3 "boot sectors" to be "single density"(128 bytes each).

 

So if you have a Single Density disk image, no problem. But how do you handle 128 byte boot sectors in "Double Density" with 256 byte sectors? What would the first 3 sectors look like size-wise in a "disk image" and how to access sector 4 onward?

 

There are 4 ways to "map it".

 

Layout one, you could use the first 128 bytes of each of the first three 256-byte sectors to contain the boot code, the last 128 bytes of each sector being nulls. Probably the most straight-forward, easiest and less confusing to implement, but not popular for some reason. Sector 4 access is straightforward as all sectors are uniform in size. So, the first 3 sectors would be 768 bytes total with sector 4 starting at byte 769.

 

Layout two, you could "pack" the first three 128-byte sectors into double-density sector 1 and the first half of double density sector 2. But then you'd have to "pad" the last half of sector 2 with nulls and have an empty Double Density sector 3 so that sector 4 is accessible with 256-byte geometry. So, here you would use 2 double density sectors for the boot code and one nulled which is 768 bytes with sector 4 starting at 769 as above.

 

Layout three, the most popular for emulators, you could make the first 3 sectors Single Density, and the rest of the image in Double Density sectors.  So, the first three sectors would be
384 bytes total and sector 4 would start at 385. An emulator would detect this format by determining if the image dimensions are uneven in this scheme.

 

Layout four is the same as layout three but pads the end of the image with 384 nulls to make it end on an even boundary. Sector 4 would start at 385 as above.

 

So basically, once an emulator knows the image is double density from the header, it needs to figure out what layout the image is so it knows how to handle the boot sectors and where sector 4 starts. It will see if the paragraphs specified in the header end on even 256 byte boundaries(totalbytes/256 = whole number). If not, the disk image must be layout three.

 

But if it does end on an even 256 byte boundary, an emulator would have to figure the disk is either layout one, two, or four above. Then it would most likely check for those 128 null bytes in the last half of sector 1 to determine if it's layout one, otherwise it's got to be layout two or four. A test for an empty sector 3 would indicate layout two, and if not it has to be layout four. Now, if the disk image is completely blank(all nulls), it could be layout one, two, OR four. The only way to tell is if there was version information in the ATR header, which is not the case.

 

Let's take a look at some examples:

 

Your TSTDD.ATR(184336 bytes) has an ATR header "paragraph size" of 11520. That's 11520x16=184320 bytes which is EVENLY divisible by 256, so it must be layout one, two, or four. Looking deeper, since there are no blocks of 128 nulls in the first 3 double density sectors it must be layout four.

 

Second example(random). MUSCHA GAMES0004(183952 bytes) has a paragraph size of 11496. That's 11496x16=183936 bytes. 183936/256=718.5, not evenly divisible so it has to be layout three.

 

From what I can tell, most emulators don't detect layout four. Once they see the image size(paragraphs*16) are evenly divisible by 256 on a double density disk, they assume all sectors are 256 bytes. So sector 1 loads in with no problem, but sector 2 loads in the image's sector 3 area, and sector 3 loads in the images 2nd half of DD sector 4 area. Thus, that's what causes your crashes or other issues.

 

The easiest way to fix this is to patch the ATR header as I mentioned above so emulators think the image is layout three. Since the affected disk image is usually larger, this shouldn't cause any write problems on the last sectors when using in emulators and such.

 

[EddyFree]

Here's a graphical example I put together using Altirra v3.

 

Here is a hex dump of your TSTDD.ATR color coded to show the 3 single density boot sectors and sector 4 which is the first double density sector:

 

Running Disk Wizard II on Altirra, I set the Patched TSTDD as drive one and snap-shotted the first 3 sectors. Then I set the original TSTDD as drive one and snap-shotted the first 3 sectors. Then I put them all side by side and made this pic where you can easily see what is happening:

 

Hope this helps.

 

And BTW, as for your single density disk issue, the emulator probably doesn't support the high-speed IO code in the menu program. Hit H to turn it off and hit 1(or whatever disk number) to reload the disk. See if that helps.