Atari800MacX Version 5.4.3 released - bug fix

[atarimac]

All,

I've released a quick bug fix version for Atari800MacX with the following fixes:

 

Bug Fixes (in version 5.4.3):

• Fixed issue with initial setting of Ultimate1mb and SIDE2 Preferences if they have not be set before.
• Fixed issue with Atari 800 Bounty Bob Strikes Back cartridge.  It still conflicts with the ? and H: patches so those will have to be turned off for the cartridge to work.

 

Since Ultimate1mb/SIDE2 is the main focus of the 5.4.x series, I wanted to get this out here as it's harder for people to try out that feature with the bugs that were in the initial ROM setup.

 

Mark

[tsom]

FYI: http://www.atarimac.com/downloads.php

 

[atarimac]

Thanks tsom!   I meant to put that in there......but, memory isn't the first thing to go, but I don't remember what is ? 

 

Or

 

https://github.com/atarimacosx/Atari800MacX/releases/tag/Release_5.4.3

 

[darwinmac]

@atarimac - I have a bug report for version 5.4.3 (and probably before). I just purchased Tristam Island (https://hlabrande.itch.io/tristam-island). It's a Infocom-style text adventure game. When I use the purchased game ATR (non-standard size of 138K), the disk crashes with an interpreter error (Internal Error #8033) as soon as you give it the command "GO NE". I'm sure that's coming from the open source Infocom interpreter and won't help you debug the problem. I see the disk stop at track 274 just before I see the error.

 

I tried the non-standard ATR in both Altirra (using Wine) and using real equipment (XEGS and Sdrive Max to load the ATR file). In both cases, the game doesn't crash when accessing that portion of the text adventure (z3) file. Unfortunately, the demo uses a standard ED disk size so the command doesn't crash the game in Atari800MacX. Since the interpreter is always reading the disk at each command, I'm assuming Atari800MacX is somehow getting confused by the disk. I've turned off all patches and the machine is set up as an NTSC XEGS.

 

I'm running macOS 10.15.7 on a late 2016 MacBook Pro with 16GB of memory (low end MacBook Pro so no Touch Bar). I'm aware this isn't a great bug report, but since Tristam Island is being sold (albeit cheaply), I can't simply give you the ATR.

 

Bob C

[kogden]

I finally got a more recent mac and gave this a whirl.  Still my favorite 8-bit emulator on the planet.

 

Any chance SIO2OSX will get an update eventually?  I really liked it for printer emulation, etc.  If not is there a good alternative for OSX that integrates well and includes a disk editor?

[Mathy]

Hello kogden

 

The Alpha version of SIO2OSX 3.0 doesn't recognize the SIO2PC hardware (independent of the version you are using).

 

Sincerely

 

Mathy

 

 

[atarimac]

@kogden, as Mathy said, there is an Alpha version of SIO2OSX that I compiled to be a 64 bit app, but unfortunately it does recognize SIO2PC hardware.  I'm not able to test it, as I don't currently have a working SIO2PC adapter, and one of my two Atari computers also did not survive my move.   I won't say never, but with the additional time needed for teaching in a COVID environment, and some health issues, I don't have time to get HW working and debug SIO2OSX.  The source is open source, if anybody has the time or means to look at it (https://github.com/atarimacosx/Sio2OSX ).

[atarimac]

@darwinmac, it's hard for me to guess on what might be wrong without being able to run the image.  How is the disk contstructed?  Does it use an autorun.sys that starts the actual program?  Could you move it to a normal sized disk image?

[darwinmac]

20 minutes ago, atarimac said:

@darwinmac, it's hard for me to guess on what might be wrong without being able to run the image.  How is the disk contstructed?  Does it use an autorun.sys that starts the actual program?  Could you move it to a normal sized disk image?

I completely understand. Hopefully, @hlabrand would be willing to send you an image. Since he is selling the game, I can’t provide it to you without his consent. 
 

The ATR does not seem to have a standard layout. Neither MakeATR, ATR image explorer, nor Atari800MacX could read the image. Therefore, I can’t tell if an   autorun.sys file was used. Since the game starts on boot up, I assume something like it us being used. 
 

My plan was to move it to a standard double-density disk image (180K). However, while I can download the z3 file, I cannot find the interpreter the developer is using. Without that, I can’t move the files to a standard disk image. 
 

Since I have mentioned Hugo in this message, I’m hoping he will respond as to whether I can provide the image to you. 
 

Bob C

[hlabrand]

Image file sent

[darwinmac]

25 minutes ago, hlabrand said:

Image file sent

Thanks. I’m hoping @atarimac can find out what’s happening. 
 

Bob C

[atarimac]

@darwinmac and @hlabrand, I have found why the emulator is returning SIO errors, which I'm sure is what is causing the emulator to fail. The ATR Header in the image indicates that the disk image is 720 sectors long, but looking at the file length, subtracting the 16 byte ATR header, it is 1076 128byte sectors long.

Atari800MacX uses the ATR header to determine the sector count, and so when the program tries to read a sector greater than 720, it gets returned an SIO error.  As to why Altirra and SDrive Max do not return errors, it may be they use the file size for sector count instead of expecting the header to be valid.  I can ask phaeron, I didn't find it at a quick look at the Altirra code.

I've fix the issue darwinmac was seeing, by using a hex editor on the file.  The 3rd and 4th bytes were 0x80 and 0x16  (0x1680, since th header wants the number of 16byte section, this is 720 sectors), and I changed them to 0xA0 0x21 (1076 sectors).  I can send the modified file to @hlabrand if desired.

[darwinmac]

@atarimac - Thanks for investigating this. I would think @hlabrand would be interested in the ATR file. However, since he is updating the program and I assume he will need a new ATR file, it would be good to find out how the ATR file is created. It sounds like a different program needs to be used to generate a valid ATR header. 
 

Based on the problem, I am concerned that the problem could occur later in the game since the ATR file is read constantly during the game. 
 

Bob C

[phaeron]

1 hour ago, atarimac said:

Atari800MacX uses the ATR header to determine the sector count, and so when the program tries to read a sector greater than 720, it gets returned an SIO error.  As to why Altirra and SDrive Max do not return errors, it may be they use the file size for sector count instead of expecting the header to be valid.  I can ask phaeron, I didn't find it at a quick look at the Altirra code.

Yes, Altirra does use the file length (diskimage.cpp, argument to LoadATR). There isn't a good reason for this behavior; it's so old it predates when Altirra had a file dialog or was even in source control yet.

[atarimac]

I will probably modify Atari800MacX to use file length as well (at least for the emulator portion, I will probably leave the ATR Image editors as they are).  And I understand the early design decisions.

 

@darwinmac I will let you know when I make the change.  I will probably not do an official release for just this change, I'll give you an Alpha build of the next version for it.

[darwinmac]

17 minutes ago, atarimac said:

@darwinmac I will let you know when I make the change.  I will probably not do an official release for just this change, I'll give you an Alpha build of the next version for it.

I’m glad you were able to diagnose the problem quickly. @hlabrand PMd me an updated ATR file with the correct header. As you saw, it eliminates the problem. As I replied to him, I hope he uses this updated ATR (with the correct header) in his updated versions. 
 

I agree this doesn’t merit a new version. At some point, a more important feature for me will be a universal binary for when I buy an M1 Mac (probably in 2021). 
 

Bob C

[atarimac]

 Bob,

Yes, I agree on the Universal binary, and I've been trying to keep the code base in good shape to do that.  As soon as someone in the community gets one, I can start to see if I can build one.  (I suspect I will need to have at least one machine on Big Sur at that point).  The plan on my side is to start a 6.x version at that point, that may coexist for awhile with 5.x versions, we will see.

 

The next release will have PCLINK so that modern Sparta Dos's can get to an H: like device.  After that, probably SIDE3, parts of FujiNet, and who knows. 

[darwinmac]

I’m glad you’ve had more time to commit to Atari800MacX recently. I have actual hardware, but I use your emulator to try out software first to see if it’s worth the effort to load it into the SD card to play on my XEGS. As much as I love Altirra and the effort phaeron puts into it, I prefer to have a Mac-native solution. 
 

I’m not sure if you’ll need Big Sur to create a universal binary or only Xcode 12.2. I completely understand why you don’t want to upgrade any of your production Macs to it until the end of the semester or the end of the academic year. I probably won’t upgrade to it until early January and it’s not used in my work.  
 

Bob C