Atari++ 1.81 available for download

[ivop]

20 hours ago, thorfdbg said:

...and here we go, another tiny update to release 1.83. As usual, you find the sources here:

 

http://xl-project.com/downloads.html

 

This release fixes the defects reported above, and improves ATX support. In particular, the ALSA sound support was not as cycle precise as it should have been as the CPU emulation counted cycles the CPU never executed. This was fixed, and the quality of the ALSA output improved noticably.

Also, ATX support was improved. Due to misinterpretation of the format, weak sector support was partially broken, and timing was made more precise. Also, the ATX driver did not report deleted sectors correctly.

 

This seems to fix my alsa backend, too!

 

[TheMontezuma]

Hello Thomas,

Recently I have been working a little bit with the Atari++ emulator.

The background is that I have built a Raspberry Pi into an Atari case, similar to what Tynemouth documented in his blog:

http://blog.tynemouthsoftware.co.uk/2014/03/atari-65xe-usb-keyboard.html

After that I experimented with Atari800 to load the games from a real drive (over 1050-2-PC):

https://github.com/atari800/atari800/issues/22

But that didn't work out very well.

Then I found an article:

https://www.raspberrypi.org/forums/viewtopic.php?t=24729

and also wanted to try out your Emulator (1.83)

In the current image:

https://downloads.raspberrypi.org/raspbian_full_latest

there is no SDL pre-installed and AUDIO in the emulator doesn't work.

After I installed SDL, I was able to rebuild the emulator, but it says goodbye immediately after starting:

Quote

Failure: Invalid argument:
Failed to narrow the format space

It would be great if you could explain how to run Atari++ 1.83 on the Raspberry Pi with Raspbian.

I wanted to try loading from a real floppy, but that did not work either.

I started Atari++ this way:

./atari++.exe -directserial true -enable.1 false

It read 3 sectors from the floppy and then it stopped:

 

 

Do you have an idea?

Best regards
Marcin

 

[thorfdbg]

1 hour ago, TheMontezuma said:

Hello Thomas,

Recently I have been working a little bit with the Atari++ emulator.

 

After I installed SDL, I was able to rebuild the emulator, but it says goodbye immediately after starting:

It would be great if you could explain how to run Atari++ 1.83 on the Raspberry Pi with Raspbian.

I would not start with SDL output as it is neither the best nor the least demanding. Try to install the X11/Xorg development files, and the alsa (libasound-dev) development files, and then see what "configure" has to say. If you'd post the output of "configure", I can possibly hunt this down.

[TheMontezuma]

23 hours ago, thorfdbg said:

I would not start with SDL output as it is neither the best nor the least demanding. Try to install the X11/Xorg development files, and the alsa (libasound-dev) development files, and then see what "configure" has to say. If you'd post the output of "configure", I can possibly hunt this down.

Thanks for recommendations. I'm not a hardcore Linux freak, so I'm not going to experiment too much.

I hoped that Raspberry Pi is so popular platform, that you would be interested in bringing up the atari++ there.

An emulator reading from a real floppy is a pretty cool feature, but I can live with atari800 emulator if the atari++ can't easily run on RPI.

 

 

 

[thorfdbg]

2 hours ago, TheMontezuma said:

I hoped that Raspberry Pi is so popular platform, that you would be interested in bringing up the atari++ there.

I am, but cannot without a raspi, so I need your feedback. As said, in order to compile the emulator on the raspi, you need to install some development files, then compile the sources with "make".

[thorfdbg]

Just uploaded the sources for Basic++ 1.08 to http://www.xl-project.com/downloads.html, a step I must have forgotten. I also bumped Os++ to release 1.9 which fixes two bugs, one wrong branch in the E: handler implementation, and one bug in the support for random-access disks in FMS++ (i.e. the mode with AUX2 = 128) which were broken due to an oversight on my end. The sources are on the same page, along with the manuals.

 

I also updated the system disk http://www.xl-project.com/download/system.atr for fms++, which contains the dup menu and many other useful tools. Here, I updated the FMS++ "overlay manager" which can now also relocate the FMS++ disk buffers under the Os in case no switching cartridge is found. This gives you a whopping memlo as $800, or more than 37500 free bytes in Basic. The memory footprint of Fms++ with the overlay manager active then goes down to 256 bytes. That is not quite my record with Dos 2.XL which had around 160 bytes, but it gives you a lot more room for Basic compared to 2.0S or 2.5 with memlo = $1C7C.

 

I haven't yet made a new version of Atari++ with this Os, just awaiting more feedback for the current version.

 

[thorfdbg]

atari++

 

By demand, the above is a atari++ version compiled for Raspian, just the binary. No sound, X11 output. That's just how far I got in 5 minutes.

 

Have fun!

 

[CaptainMidnight]

On 5/12/2020 at 5:45 PM, thorfdbg said:

atari++ 1.66 MB · 9 downloads

 

By demand, the above is a atari++ version compiled for Raspian, just the binary. No sound, X11 output. That's just how far I got in 5 minutes.

 

Have fun!

 

Hi would really like to get a working build of atari++ on the Raspberry Pi 4B (RPi4B), when trying to make this file, there are various warnings during the make process, but the atari++ does complete.

 

It fails to work when run with: -

 

pi@phoenix-pi-x64:~/test/atari++ $ ./atari++
Failure: Invalid argument:
failed to narrow the format space

 

Can you offer any advice on what prerequisites are required to allow a successful build / operation. I'd like to bottom this issue out so can I provide any specific debug output to assist?

[CaptainMidnight]

Reference build system is a Raspberry Pi 4B - 8GB, running Pi OS 64-bit.

 

 

For info, ./configure output :-

 

(see attached file)

 

For info, make output :-

 

(see attached file)

configure output.txt make output.txt

Edited July 15, 2020 by CaptainMidnight
Removed code windows and instead attached output files.

[CaptainMidnight]

... whoops, obviously, the AtariAge forum system doesn't produce scroll code windows - OK point noted, will just post attachments.

[+DjayBee]

28 minutes ago, CaptainMidnight said:

the AtariAge forum system doesn't produce scroll code windows

Define them as "spoiler", then they can be opened when needed

[CaptainMidnight]

3 minutes ago, DjayBee said:

Define them as "spoiler", then they can be opened when needed

argh ok, point taken ?

[Mr Robot]

1 hour ago, CaptainMidnight said:

It fails to work when run with: -

 

pi@phoenix-pi-x64:~/test/atari++ $ ./atari++
Failure: Invalid argument:
failed to narrow the format space

 

Can you offer any advice on what prerequisites are required to allow a successful build / operation. I'd like to bottom this issue out so can I provide any specific debug output to assist?

 

What window manager are you running on your pi?

 

 

[CaptainMidnight]

10 minutes ago, Mr Robot said:

 

What window manager are you running on your pi?

 

 

.... it'll be the standard lxde I would of assumed, so maybe also have to change to X11 then I'm assuming or am I missing something subtle specific to the pi?

[Mr Robot]

If you are running any window manager at all, x11 should work ok, it gets trickier if you are trying to run without a window manager loaded to integrate with something like RetroPie

 

[CaptainMidnight]

Yeah that's what I would have thought, but I've got a nagging feeling it's a pi specific issue - I'll have to build another pi image with the standard raspbian 32-bit image to try and eliminate some possibilities from the not running equation...... 

 

I'd be interested to hear from any other pi atari++ users, just to try and discount the various options. The other pi alternative, atari800 just works but has SIO implmentation issues with some disk formats - HowfenDos being one of them.

 

I've got both an Intel NUC and RPi4B8 at my disposal for atari emulation - the NUC is running altirra 3.90 - rock solid (so disappointed that this is windows only, they have now brought out an arm64 vervision for windows tablets but not buildable on a pi), just would like to get the little pi sorted as with it being quad core @2Ghz should easily be up to the task.

[Mr Robot]

1 hour ago, CaptainMidnight said:

SIO implmentation issues with some disk formats - HowfenDos being one of them

I've addressed that in GitHub

atari800 (and I think Atari++) don't emulate Atari drives very accurately, try creating a blank atr and formatting it to DS/DD ala XF551 for example. Only Altirra accurately emulates the different drive types and uses the drives firmware to do it properly.

[CaptainMidnight]

3 hours ago, Mr Robot said:

I've addressed that in GitHub

atari800 (and I think Atari++) don't emulate Atari drives very accurately, try creating a blank atr and formatting it to DS/DD ala XF551 for example. Only Altirra accurately emulates the different drive types and uses the drives firmware to do it properly.

Yes saw your updates thanks, much appreciated.

 

As confirmed through my GitHub comments, Atari++ drive emulation of the double/US double density format and menu writing process just works, but unfortunately atari800 fails with i/o errors, although atari800 (wrt display scaling etc) appears the more polished emulator.

 

I'll look at trying out your suggestion. Thanks again for your help

Edited July 15, 2020 by CaptainMidnight
slight correction for clarity

[Mr Robot]

If you create a blank disk in atari800 you get a sssd atr file, if you format it using dos 3 it becomes an ssed atr. Trying DOS XE will identify the SD file as an 810 and the ED file as a 1050. There is no way to create an DD atr or QD atr using atari800 which is a problem. I keep blank SD, ED, DD, QD files around for when I need a new blank disk.

 

As for the US Doubler, the US Doubler was a hardware upgrade for the 1050 and it's not emulated at all in atari800. If you use a DD or QD file you may get some functionality but I don't know how much.

 

This is all off topic for this Atari++ thread so I'm going to repost it on github if you wish to continue the discussion.

[CaptainMidnight]

Yes, sorry all for the diversion, will move this to github.

 

Still interested in any pi users out there currently using Atari++ ?

[thorfdbg]

On 7/15/2020 at 11:45 AM, CaptainMidnight said:

Hi would really like to get a working build of atari++ on the Raspberry Pi 4B (RPi4B), when trying to make this file, there are various warnings during the make process, but the atari++ does complete.

 

It fails to work when run with: -

 

pi@phoenix-pi-x64:~/test/atari++ $ ./atari++
Failure: Invalid argument:
failed to narrow the format space

 

Can you offer any advice on what prerequisites are required to allow a successful build / operation. I'd like to bottom this issue out so can I provide any specific debug output to assist?

This looks like the emulator cannot set the target format of the alsa sound output. You may try to disable the sound.

 

[CaptainMidnight]

1 hour ago, thorfdbg said:

This looks like the emulator cannot set the target format of the alsa sound output. You may try to disable the sound.

 

Thanks for the suggestion, I'll test that theory out when I rebuild the RPi using the standard 32-bit OS image, just in case the current 64-bit beta image is at fault. 

[thorfdbg]

On 7/15/2020 at 8:38 PM, CaptainMidnight said:

As confirmed through my GitHub comments, Atari++ drive emulation of the double/US double density format and menu writing process just works, but unfortunately atari800 fails with i/o errors, although atari800 (wrt display scaling etc) appears the more polished emulator.

If you want better/more scaling options, use the SDL video output, which offers some interesting options for that. The X11 output is very bare bone, but fast even on slow machines.

[CaptainMidnight]

5 hours ago, thorfdbg said:

If you want better/more scaling options, use the SDL video output, which offers some interesting options for that. The X11 output is very bare bone, but fast even on slow machines.

Unfortunately, there appears to be some issues with Atari++ which causes concern and currently are show stoppers wrt investigating it's suitability for my projects.

 

1. As documented previously, I still can't create a working build on one of the target operating systems, i.e the RPi Pi OS - work ongoing on this, although no breakthroughs as of yet....

 

2. From what I've seen from Atari++ on my Windows 10 systems anything other than full screen is or appears compromised running in a window on a FHD display for dev work - maximum windows size/scaling appears limited? (native window scaling seems absent and preset window sizes seem too small)

 

I'd have to double check but I think the Windows dev build is already using SDL output, not too sure on that at the moment, but offers a very limited selection of window geometry.

 

[Update: sorted the graphics scaling and screen size issue on the Windows dev build]

 

Any further assistance or advice you could offer on the above points would be greatly appreciated.

 

 

Edited July 18, 2020 by CaptainMidnight
Further testing.

[thorfdbg]

10 hours ago, CaptainMidnight said:

Unfortunately, there appears to be some issues with Atari++ which causes concern and currently are show stoppers wrt investigating it's suitability for my projects.

 

1. As documented previously, I still can't create a working build on one of the target operating systems, i.e the RPi Pi OS - work ongoing on this, although no breakthroughs as of yet....

 

2. From what I've seen from Atari++ on my Windows 10 systems anything other than full screen is or appears compromised running in a window on a FHD display for dev work - maximum windows size/scaling appears limited? (native window scaling seems absent and preset window sizes seem too small)

 

I'd have to double check but I think the Windows dev build is already using SDL output, not too sure on that at the moment, but offers a very limited selection of window geometry.

 

[Update: sorted the graphics scaling and screen size issue on the Windows dev build]

 

Any further assistance or advice you could offer on the above points would be greatly appreciated.

 

 

The only issue I see is that alsa has a hickup, which you can workaround by disabling the sound on the command line, and lots of harmless compiler warnings, but as you wish, here is another release candidate for the 1.84 with hopefully some of the issues addressed.

atari++.tgz