Altirra 3.20 released

[Forrest]

Altirra 3.20 (32 bit) is not working as well under OSX 10.13.6/Wine Stable 4.01 as Altirra 3.10 (32 bit). FruityPete 1.1 started fine (NTSC, 130XE, Atari ROMS), but stopped working on level 2. See attached picture. The emulator didn't crash, but the game was unplayable after the video was corrupted.

 

Edited July 1, 2019 by Forrest

[phaeron]

12 hours ago, Forrest said:

Altirra 3.20 (32 bit) is not working as well under OSX 10.13.6/Wine Stable 4.01 as Altirra 3.10 (32 bit). FruityPete 1.1 started fine (NTSC, 130XE, Atari ROMS), but stopped working on level 2. See attached picture. The emulator didn't crash, but the game was unplayable after the video was corrupted.

 

I played Fruity Pete 1.1 off of Fandal's site in various configurations and was unable to reproduce this crash, even switching OSes and enabling internal BASIC. Please double-check your configuration, you mentioned 130XE but the window caption in your screenshot indicates an XL machine.

 

(Have to say, great game to those who made it.)

[Mclaneinc]

Yup, played it up to level 82 yesterday on the same config as the screen shot and had no issues...As the first release of Fruity Pete DID have issues with NTSC I wonder if there was an accidental swap of versions played?

 

As I don't use Wine I have no clue about it..

[darwinmac]

Phareon, Mclaneinc,

 

I think Forrest's comment was related to running Altirra under Wine and not necessarily suggesting that the problem resided in Altirra itself. I also run Altirra under Wine Stable 4.01 like Forrest, but I was unable to duplicate the error using the configuration Forrest showed in the screenshot. I did hear the music skip slightly during gameplay, but I didn't check it on my actual Atari hardware. It could happen there as well.

 

Previous posters in this thread had mentioned they run Altirra under Wine and I think Forrest was trying to give an alternate opinion based on his experience. I am running macOS Mojave (10.14) and not macOS High Sierra (10.13) like Forrest so I can't duplicate his results. In addition, there could be differences between his Mac and mine.

 

In any event, I don't see this an Altirra problem unless people running it natively under Windows find a problem. Some of us who don't want do use Windows, but do want access to Altirra, run it under Wine. However, we don't expect that configuration to be supported.

 

I agree that Fruity Pete is a fun game.

 

Bob C

[Mclaneinc]

I only wanted to show that there was no issue with Altirra running the game...I am sure the issue is in the running under Wine but like I say, I don't use it so can't really comment on that side..

[Roydea6]

I have a basic program with a large line gap from the first FOR  to the ending NEXT.  And atbasicx.com is throwing an error 13, but not Atari basic or Turbo Basic.

 

30 FOR P=1 TO Q

..

..

..

..

190 NEXT P:GOTO 30

the error occurs after one pass.

UPDATE: it seems that I had a bad or old rom flash in my U1M 800XL.  Re-flashing the rom cleared the problem.

Edited July 2, 2019 by rdea6
found problem was my own

[darwinmac]

Since Wine came up earlier in this topic, I would copy Altirra 3.90 to another directory and not overwrite Altirra 3.20 if you are using Wine. It appears that the changes made to remove XP support may affect Wine users as well. When I start 3.90 in Wine, the display is completely black. The Atari self test page doesn't even appear. I also don't hear any sound or video if I load a program.

 

I want to mention this is only a Wine issue (unsupported platform for Altirra). When I ran 3.90 in VMWare Fusion on my Mac, it ran perfectly.

 

Bob C

[Kyle22]

Let's enjoy some Wine and XP.

It's still technically possible, right?

 

Edit: 3.90 test 3 works fine for me on XP SP3 (completely updated to the present time [including] all the POSReady updates & stuff])

 

Edited July 3, 2019 by Kyle22
clarity

[phaeron]

To be clear, there haven't been any changes in 3.90 yet with regard to dropping XP support. It's still built with the same compiler and settings as 3.20 and doesn't use any Vista/7-only libraries so far. There have been a fair number of changes for dark mode support, but they aren't enabled by default.

 

If you drop into the debugger, does the Step In command run some instructions at least? No sound also is kind of weird, that implies that the emulator simply isn't ticking cycles.

 

[darwinmac]

Phaeron,

 

Thanks for the clarification. I didn't realize the dropping of XP/Vista support had not yet started. It took a little time for me to figure out how to use the debugger (I'm not a developer), but I was able to see the "Step In" command running different instructions. Since it appears to work on an actual XP machine (Kyle22), the problem appears to be in the unsupported platform (Wine).

 

I'll be interested if other Mac/Linux users who use Wine for Altirra have the same problem or if it's limited to me. Since I have actual hardware that I use for my gaming, I only tend to use Altirra (or Atari800MacX) to determine if a game is worth my time loading it onto the XEGS. I don't want to take up more of your time on a platform that you don't officially support. I'm very grateful for all of the work you put into Altirra.

 

Bob C

[phaeron]

It's true that running on Mac or Linux through Wine is not supported, but I do watch the reports as sometimes the bugs really are in the core and just manifest differently in the Wine environment.

 

In this case, the issue may be related to the display path. Wine doesn't quite emulate everything in DirectX, and if something is going fubar in the display path it could explain what we're seeing here. The reason is that if Altirra thinks it is running faster than real time, it will drop audio frames in tandem with video frames to try to keep playing audio roughly in sync even in turbo mode. Therefore, if something goes wrong and it drops all video frames, it will also go audio silent. This would also mesh with the behavior you're seeing in the debugger which implies that the emulation itself is ticking normally.

 

I need to check 3.90 with Dr.Memory to see if a memory access or GDI handle issue has crept in, but otherwise, something else you could try is changing to a different graphics API in Tools > Options > Display. Direct3D 9 or Direct3D 11 is usually optimal on Windows, but the other modes can be useful to diagnose on Wine.

 

[darwinmac]

Phaeron,

 

I didn't mean to sound dismissive. I just didn't want to sound entitled and expect you to fix this for me. I've tried the different display options with no change. If I tried Direct3D 11, it crashes Altirra to the point that I can't run 3.20 until I delete Altirra's registry entry and set everything up again.

 

It'd be great if you find an underlying problem that makes it work again for me in Wine. If not, as said previously, I'll have a great version in 3.20 to use when needed.

 

Actually, unless the Wine developers find a way to have a 64-bit Wine run 32-bit applications well, it'll be academic for me since Apple is eliminating 32-bit support in the next version of macOS (10.15 - Catalina).

 

Bob C

[phaeron]

5 minutes ago, darwinmac said:

I didn't mean to sound dismissive. I just didn't want to sound entitled and expect you to fix this for me. I've tried the different display options with no change. If I tried Direct3D 11, it crashes Altirra to the point that I can't run 3.20 until I delete Altirra's registry entry and set everything up again.

 

It'd be great if you find an underlying problem that makes it work again for me in Wine. If not, as said previously, I'll have a great version in 3.20 to use when needed.

No offense taken, I'm just curious as to what's going on here. I appreciate that you understand the implications of running under Wine, actually.

 

Crashing on D3D11 is not great, that means things are definitely goofy since Wine has supported D3D11 for some time and Altirra's D3D11 support has not changed recently. If you end up in this situation again, run the program with the /d3d9 command line switch to force the display settings back to default to get back in.

 

You could also try disabling the Vertical Sync option under View, in case something is funky there. That having been said, I would have expected something to show up with all display APIs off, in which case Altirra uses GDI -- the bottom of the barrel of graphics APIs in Windows that sucks terribly but should work in all cases.

 

Otherwise, bit of a head scratcher here, I'll just have to run some sanity checks here to make sure everything's at least sane on Windows.

 

5 minutes ago, darwinmac said:

Actually, unless the Wine developers find a way to have a 64-bit Wine run 32-bit applications well, it'll be academic for me since Apple is eliminating 32-bit support in the next version of macOS (10.15 - Catalina).

The 64-bit version of Altirra wouldn't suffice?

 

[darwinmac]

42 minutes ago, phaeron said:

No offense taken, I'm just curious as to what's going on here. I appreciate that you understand the implications of running under Wine, actually.

 

Crashing on D3D11 is not great, that means things are definitely goofy since Wine has supported D3D11 for some time and Altirra's D3D11 support has not changed recently. If you end up in this situation again, run the program with the /d3d9 command line switch to force the display settings back to default to get back in.

 

You could also try disabling the Vertical Sync option under View, in case something is funky there. That having been said, I would have expected something to show up with all display APIs off, in which case Altirra uses GDI -- the bottom of the barrel of graphics APIs in Windows that sucks terribly but should work in all cases.

 

Otherwise, bit of a head scratcher here, I'll just have to run some sanity checks here to make sure everything's at least sane on Windows.

 

The 64-bit version of Altirra wouldn't suffice?

 

I tried disabling Vertical Sync, but there was no change in behavior. I did finally uncheck all display APIs (I didn't realize that was an option). That didn't help either.

 

To answer your question, yes, the 64-bit version of Altirra would suffice but it won't help me with old programs like MakeATR and MSA Converter (for creating images for my ST emulator). Both of those executables are 32-bit only.

 

I loaded Fruity Pete since it was discussed earlier in the thread. When I run in debug mode from 3.20, I see various different assembly language instructions. However, from 3.90 test 3, I only see the same two instructions:

 

(1726:  0, 34) A=BF X=00 Y=00 S=DD P=B5 (N  I C)  0000: FF 00 FF          ISB $FF00,X  [$FF00]

(1726:  0, 43) A=BE X=00 Y=00 S=DD P=B5 (N  I C)  0003: 00                BRK

(1726:  0, 52) A=BE X=00 Y=00 S=DA P=B5 (N  I C)  0000: FF 00 FF          ISB $FF00,X  [$FF00]

(1726:  0, 61) A=BD X=00 Y=00 S=DA P=B5 (N  I C)  0003: 00                BRK

 

When I run Fruity Pete in debug mode on 3.20, I see a yellow line in the bottom half of the screen that's being redrawn and covered with black like it's disappearing. I know I'm not describing it well. In 3.9 test 3, I see the yellow line at the very top of the screen with the same redraw action.

 

I hope any of the information will be useful.

 

Bob 

[phaeron]

1 minute ago, darwinmac said:

I loaded Fruity Pete since it was discussed earlier in the thread. When I run in debug mode from 3.20, I see various different assembly language instructions. However, from 3.90 test 3, I only see the same two instructions:

 

(1726:  0, 34) A=BF X=00 Y=00 S=DD P=B5 (N  I C)  0000: FF 00 FF          ISB $FF00,X  [$FF00]

(1726:  0, 43) A=BE X=00 Y=00 S=DD P=B5 (N  I C)  0003: 00                BRK

(1726:  0, 52) A=BE X=00 Y=00 S=DA P=B5 (N  I C)  0000: FF 00 FF          ISB $FF00,X  [$FF00]

(1726:  0, 61) A=BD X=00 Y=00 S=DA P=B5 (N  I C)  0003: 00                BRK

Check the firmware settings, this looks suspiciously like Altirra can't find the OS ROM file you have selected.

 

[Forrest]

Please ignore my prior post/picture. I rebooted my Mac and I've played FruityPete v1.1  3 times since then and the game works fine.

[darwinmac]

9 hours ago, phaeron said:

Check the firmware settings, this looks suspiciously like Altirra can't find the OS ROM file you have selected.

 

Phaeron,

 

You're the man! Previously, I only looked at the Firmware Manager and it showed all of the detected ROMs and I thought Altirra found everything. After your post, I picked one of the Kernel ROMs and selected Settings. That's when I found out Altirra was looking for the ROMs in the download directory for 3.9 and NOT the original Altirra directory where I have 3.20 kept. As soon as I copied the ROM files from my main Altirra directory to the 3.9 directory, then I saw the Self Test screen and Fruity Pete loaded correctly.

 

I still have Altirra crash if I enable D3D11. Thanks for the information on the /D3D9 switch to get Altirra running again without deleting the registry entry and setting up Altirra again. The D3D11 crash could easily be accounted for by changes in Wine.

 

I've used Wine since I was a Linux user who wanted to run Apple's old QuickTime player. It's an amazing engineering feat, but I'm very aware that it's not the same thing as running Windows. 

 

Bob C

[Mclaneinc]

Don't forget that in tools / settings you can delete the settings without touching the registry...

 

I imagine Phaeron does not want people going near that part of the OS (and with good reason  )  (  I should be honest and say I used to tell people to kill the settings that way before he introduced the bit in tools..)

 

Phaeron slapped my hand for it

[darwinmac]

Paul,

 

The problem was Altirra would crash before I could get to the Tools menu. 

 

Bob C

[Mclaneinc]

Hi Bob

 

Yes, sorry, I'd sort of lost track of the issue...Hope it didn't come across as patronising....Was not meant to..Just trying to keep people away from the registry

[Yaron Nir]

Phareon,

great work! thanks for releasing new version, you're da man!

 

Cheers,

Yaron

[darwinmac]

10 hours ago, Mclaneinc said:

Hi Bob

 

Yes, sorry, I'd sort of lost track of the issue...Hope it didn't come across as patronising....Was not meant to..Just trying to keep people away from the registry

No problem. I didn’t know about the Tools/Settings option so I can use that in the future, if needed. 

 

I understand why Phareon (Avery) doesn’t want people messing with Registry. In my case, since I’m not running an actual Windows machine, it wouldn’t hurt much even if I screwed it up. 

 

For most people, it would be a big problem so his advice is still the correct approach. Since Altirra doesn’t spread entries all through the Registry (I’m looking at you, Microsoft), I felt comfortable deleting the entry named virtualdub.org. 

 

Bob C 

[Mclaneinc]

Yeah, its the only place its stored unless you run altirra in portable mode and then it makes an ini where the exe is and stores the settings there..

 

Its hard to tell how savvy a person is sometimes and the last thing any of us want is a fellow Atari user with a screwed up machine..

 

The old better to be safe than sorry thing...Have fun

[phaeron]

Yeah, it's just the old generic obligatory you-can-cause-damage-to-your-system-with-improper-use-of-the-registry-editor warning, just like the California Prop 65 cancer and EU cookie warnings. There's no problem going in and editing or deleting Altirra's settings in the Registry if you're comfortable with the Registry Editor. But for those who are not, the options in the recent versions of the program itself for deleting and migrating the Registry settings are the better and easier choice.

 

[scotty]

Avery, Got a question....   I decided to convert a short and simple Microsoft Basic program to Atari Basic.  I copied the source code from plain text, and pasted it in to Atari Basic in Altirra ro make changes.   For some reason, all of my REM statements and all of my line were converted to upper case.  I can understand basic commands like 'print' being change to 'PRINT', but even the stuff I had in quotation marks became capitalized.  (IE: 10 print "Hello" became 10 PRINT "HELLO").   Is there a reason why it is doing that and a fix?

 

Here is the source code after the conversion:

10 REM Atari Basic, XL/XE Version of 99 Bottles of beer.
20 REM Modified by SirScotty in July 2019 
30 REM Modified from Eric Carr's MS Basic Version, Found on this site.
40 REM Cleaned up for Atari Basic as well as BasicXL and BasicXE from OSS.
45 REM "WE NEED MORE BEER!!!" was added by me, for a laugh.
46 REM Type the number 160 at the READY prompt to delete it.
47 REM This was my first time using Atari Basic in over THIRTY FIVE YEARS!!
48 REM I think I did pretty good for being so rusty.
50 FOR X=99 TO 1 STEP -1
60 IF X>0 THEN PRINT X;" bottle";
70 IF X<>1 THEN PRINT "s";
80 PRINT " of beer on the wall, "
85 PRINT X;" bottle";
90 IF X<>1 THEN PRINT "s";
100 ? " of beer..."
110 PRINT "Take one down, pass it around,"
120 PRINT X-1;" bottle";
125 X=X-1
130 IF X<>1 THEN PRINT "s";
140 PRINT " of beer on the wall."
145 PRINT 
150 IF X>0 THEN GOTO 60
160 PRINT "WE NEED MORE BEER!!!"

 

Edited July 7, 2019 by scotty
add stuff