atari800-users — Atari800 users

Re: [Atari800-users] Rasp Pi Zero W w/Atari800

[Cliff H. <ha...@bt...>]

Thanks Brandon.  I apologise in advance if this takes you back down a 
route you have already explored, but it will be worth it if we can 
expose a glitch in the system or show that all is well.

When I connect my Pi Zero to the TV it runs with a display resolution of 
1824x984 with no loading issues, so I think you should be OK with 
1360x768 - but it's great that you have another monitor to try as well.

When you have set everything up, try connecting via ssh and take a look 
at the loading with the "top" command.  The load varies a little 
depending on what atari800 is doing, but when it is sitting displaying 
the BASIC READY prompt on a 1280x1024 monitor, I see it using around 50% 
CPU:

top - 13:29:27 up  1:24,  3 users,  load average: 0.78, 1.06, 1.09
Tasks: 108 total,   1 running, 107 sleeping,   0 stopped,   0 zombie
%Cpu(s): 61.5 us,  2.9 sy,  0.0 ni, 35.6 id,  0.0 wa, 0.0 hi,  0.0 si,  
0.0 st
MiB Mem :    430.1 total,     76.0 free,    121.3 used,    232.8 buff/cache
MiB Swap:    100.0 total,    100.0 free,      0.0 used.    244.5 avail Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ 
COMMAND
   898 pi        20   0  334224  14316  11992 S  49.7 3.3  40:05.83 
atari800
   727 pi         9 -11  620728   9208   7936 S  13.5 2.1  11:05.93 
pulseaudio
    45 root       1 -19       0      0      0 S   1.9 0.0   1:35.65 
vchiq-slo+
  1707 pi        20   0   10280   2972   2488 R   1.3 0.7   0:10.62 top
    46 root       1 -19       0      0      0 S   0.3 0.0   0:15.85 
vchiq-rec+

... plus numerous other processes using less than 1% CPU each.

I've noticed that the sound is a little choppy when top is running, I 
guess because it keeps grabbing attention from the single core every 
time it updates its display.  If the problems you have seen were caused 
by another application competing with atari800 in this way I'm not 
entirely sure how we will go about identifying it, but we will see what 
we can find - and I'm sure there is enough expertise on this forum to 
help us pin it down.

Best Regards

Cliff

On 22/02/2021 22:11, Brandon wrote:
>
> Cliff
>
> Appreciate the details in this last email. I do have more than one Pi 
> Zero and a few SD cards ;-) , so I am not opposed to load another SD 
> card with the Rasp OS again and see if it might have been my install 
> or something else. With the minor effort it takes now for me to get 
> one up and running, I have no issues with doing another for testing 
> purposes. Also, I am running this currently on a 32” Sony that 
> registers at 1360x768 @ 60Hz when the Pi boots. Not sure if that makes 
> a difference in reference to your HD comments.
>
> I added a simple command in the cron to start Atari800 after auto 
> logon and it boots up to Atari800 in under 40 seconds from initial 
> power up to emulator. That’s pretty impressive to me.
>
> I have a 20” 4:3 monitor with built-in speakers that will prob become 
> the display for this unit once I get everything buttoned up on it.
>
> *From:*Cliff Hatch via Atari800-users 
> [mailto:ata...@li...]
> *Sent:* Monday, February 22, 2021 4:01 PM
> *To:* ata...@li...
> *Cc:* Cliff Hatch
> *Subject:* Re: [Atari800-users] Rasp Pi Zero W w/Atari800
>
> Brandon
>
> I'm glad you have found a solution.  I guess that effectively closes 
> the case - but from my perspective it leaves an unresolved puzzle.
>
> I did the Raspberry Pi builds for V4.2.0, so was interested to hear 
> about the problems you encountered.  The intention is that users 
> should be able to install atari800 with Pi OS on any machine (zero, 2, 
> 3 or 4)  and run it without difficulty. However, your experience 
> suggests that this is not always the case, and that there may be some 
> performance issues we could usefully fix - or at least document so 
> that others aren't tripped up by them.  I am only able to test the 
> builds on my own limited hardware, and there is always a chance that I 
> will miss something.
>
> The poor performance you observed in the interval following startup is 
> the kind of thing that might well have escaped my notice, but I have 
> looked for it over recent days and can't see it - the emulator always 
> starts at 100% for me.
>
> There is clearly a difference between your setup and mine, 
> particularly with regard to the Zero, which you found unusable with Pi 
> OS.  The symptoms you described (running below full speed with choppy 
> sound and video) do strongly suggest a loading issue, but we have 
> ruled out the possibility that you accidentally installed the Pi 4 
> version.  The only other thought I had was that you might be using a 
> Full HD monitor and the system was struggling to generate very high 
> definition images - but a few experiments with my TV seemed to rule 
> that out too.  It appears that Pi OS doesn't attempt to run the older 
> Pis at maximum resolution, but limits itself to settings it can manage 
> - I found that the CPU load imposed by atari800 remained around 50%, 
> as with my lower resolution monitors.
>
> In the absence of any other clues, maybe we will just have to leave 
> this as an unexplained mystery?
>
> Best Regards
>
> Cliff
>
> On 22/02/2021 17:29, Brandon wrote:
>
>     Chris
>
>     That did it
>
>     Set the following to 0
>
>     CONFIG_CHECK_DIETPI_UPDATES=0
>
>     CONFIG_CHECK_APT_UPDATES=0
>
>     Atari800 start at 100% speed.
>
>     Thanks!
>
>     *From:*Christian Groessler [mailto:ch...@gr...]
>     *Sent:* Monday, February 22, 2021 11:03 AM
>     *To:* ata...@li...
>     <mailto:ata...@li...>
>     *Subject:* Re: [Atari800-users] Rasp Pi Zero W w/Atari800
>
>     Can't you just disable the "update" startup script?
>
>     I think that's anyway better after you have a working setup.
>     Otherwise an update could break something.
>
>     regards,
>     chris
>
>     On 2/22/21 4:15 PM, Brandon wrote:
>
>         Cliff
>
>         I had the correct debian package installed for 0+2+3 buster.
>         Have you attempted to boot to the Rasp OS desktop and
>         immediately go into Atari800? This issue appears in the first
>         2-3 mins of booting the OS.
>
>         My guess would be that all OSes do similar update list checks
>         at the boot up time. This might point to the startup script as
>         the culprit.
>
>         I can live with the delay, but if I can find a solution I will
>         continue to work on it.
>
>         *From:*Cliff Hatch via Atari800-users
>         [mailto:ata...@li...]
>         *Sent:* Sunday, February 21, 2021 5:30 PM
>         *To:* ata...@li...
>         <mailto:ata...@li...>
>         *Cc:* Cliff Hatch
>         *Subject:* Re: [Atari800-users] Rasp Pi Zero W w/Atari800
>
>         Oops, I got the names of the Debian install packages wrong. 
>         They are*atari800_4.2.0_rpi0+2+3_stretch+buster.deb* and
>         *atari800_4.2.0_rpi4_buster.deb*
>
>         On 21/02/2021 21:04, Cliff Hatch via Atari800-users wrote:
>
>             Hi Brandon
>
>                 On boot up, DietPi is at 100% CPU usage for approx.
>                 2-3 minutes
>
>             OK, hopefully that accounts for the problem - let us know.
>
>             I'm still puzzling over the problems you encountered with
>             Pi OS on the Zero though:
>
>                 ... the PI ZERO W just isn't up to par on speed for
>                 the emulation. Choppy play and sound experiences at
>                 all times.
>
>             I can't replicate this on my system. I have the full
>             version of Pi OS + desktop installed, and atari800 runs at
>             full speed with total CPU loading around 50% - so there
>             seems to be plenty of spare capacity and no necessity to
>             resort to stripped down operating systems.
>
>             Is there any possibility that you might have accidentally
>             installed the Pi 4 version *rpi4_buster.deb*? It will
>             install and run on the older Pis, but seriously overloads
>             the cores on the Zero and 2.  The Pi 3 can manage it, but
>             will run the correct version
>             (*rpi0+2+3_stretch_buster.deb*) much more efficiently.
>
>             If you want to try
>             reinstalling*rpi0+2+3_stretch_buster.deb*,  take out the
>             installed version first, also delete its configuration
>             file because it contains fields that are specific to the
>             two versions.
>
>             Change to your home directory, then:
>
>              1. rm .atari800.cfg
>              2. sudo dpkg --remove atari800
>
>             and reinstall.
>
>             Cliff
>
>             On 21/02/2021 19:38, Brandon wrote:
>
>                 I believe I figured it out. Has nothing to do with
>                 Atari800.
>
>                 On boot up, DietPi is at 100% CPU usage for approx.
>                 2-3 minutes, then drops down to under 3% usage.
>
>                 On initial boot up the following two commands execute
>                 in order using 98-100% of CPU before the CPU usage drops.
>
>                 apt-get –q update
>
>                 apt –qq list –upgradeable
>
>                 Once these complete, everything runs smoothly. So now
>                 I need to see if I can opt out in the start-up and
>                 only execute them on demand when needed.
>
>
>
>
>
>
>                 _______________________________________________
>
>                 Atari800-users mailing list
>
>                 Ata...@li...  <mailto:Ata...@li...>
>
>                 https://lists.sourceforge.net/lists/listinfo/atari800-users
>
>
>
>
>
>
>               
>
>               
>
>             _______________________________________________
>
>             Atari800-users mailing list
>
>             Ata...@li...  <mailto:Ata...@li...>
>
>             https://lists.sourceforge.net/lists/listinfo/atari800-users
>
>
>
>
>
>           
>
>           
>
>         _______________________________________________
>
>         Atari800-users mailing list
>
>         Ata...@li...  <mailto:Ata...@li...>
>
>         https://lists.sourceforge.net/lists/listinfo/atari800-users
>
>
>
>
>     _______________________________________________
>
>     Atari800-users mailing list
>
>     Ata...@li...  <mailto:Ata...@li...>
>
>     https://lists.sourceforge.net/lists/listinfo/atari800-users
>
>
>
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Rasp Pi Zero W w/Atari800

[Brandon <ni...@gm...>]

Cliff

 

Appreciate the details in this last email. I do have more than one Pi Zero
and a few SD cards ;-) , so I am not opposed to load another SD card with
the Rasp OS again and see if it might have been my install or something
else. With the minor effort it takes now for me to get one up and running, I
have no issues with doing another for testing purposes. Also, I am running
this currently on a 32" Sony that registers at 1360x768 @ 60Hz when the Pi
boots. Not sure if that makes a difference in reference to your HD comments.

 

I added a simple command in the cron to start Atari800 after auto logon and
it boots up to Atari800 in under 40 seconds from initial power up to
emulator. That's pretty impressive to me.

 

I have a 20" 4:3 monitor with built-in speakers that will prob become the
display for this unit once I get everything buttoned up on it.

 

From: Cliff Hatch via Atari800-users
[mailto:ata...@li...] 
Sent: Monday, February 22, 2021 4:01 PM
To: ata...@li...
Cc: Cliff Hatch
Subject: Re: [Atari800-users] Rasp Pi Zero W w/Atari800

 

Brandon

I'm glad you have found a solution.  I guess that effectively closes the
case - but from my perspective it leaves an unresolved puzzle.

I did the Raspberry Pi builds for V4.2.0, so was interested to hear about
the problems you encountered.  The intention is that users should be able to
install atari800 with Pi OS on any machine (zero, 2, 3 or 4)  and run it
without difficulty.  However, your experience suggests that this is not
always the case, and that there may be some performance issues we could
usefully fix - or at least document so that others aren't tripped up by
them.  I am only able to test the builds on my own limited hardware, and
there is always a chance that I will miss something.

The poor performance you observed in the interval following startup is the
kind of thing that might well have escaped my notice, but I have looked for
it over recent days and can't see it - the emulator always starts at 100%
for me.

There is clearly a difference between your setup and mine, particularly with
regard to the Zero, which you found unusable with Pi OS.  The symptoms you
described (running below full speed with choppy sound and video) do strongly
suggest a loading issue, but we have ruled out the possibility that you
accidentally installed the Pi 4 version.  The only other thought I had was
that you might be using a Full HD monitor and the system was struggling to
generate very high definition images - but a few experiments with my TV
seemed to rule that out too.  It appears that Pi OS doesn't attempt to run
the older Pis at maximum resolution, but limits itself to settings it can
manage - I found that the CPU load imposed by atari800 remained around 50%,
as with my lower resolution monitors.

In the absence of any other clues, maybe we will just have to leave this as
an unexplained mystery?

Best Regards

Cliff

On 22/02/2021 17:29, Brandon wrote:

Chris

 

That did it

Set the following to 0

 

CONFIG_CHECK_DIETPI_UPDATES=0

CONFIG_CHECK_APT_UPDATES=0

 

Atari800 start at 100% speed.

 

Thanks!

 

From: Christian Groessler [mailto:ch...@gr...] 
Sent: Monday, February 22, 2021 11:03 AM
To: ata...@li...
Subject: Re: [Atari800-users] Rasp Pi Zero W w/Atari800

 

Can't you just disable the "update" startup script?

I think that's anyway better after you have a working setup. Otherwise an
update could break something.

regards,
chris

 

On 2/22/21 4:15 PM, Brandon wrote:

Cliff

 

I had the correct debian package installed for 0+2+3 buster. Have you
attempted to boot to the Rasp OS desktop and immediately go into Atari800?
This issue appears in the first 2-3 mins of booting the OS.

 

My guess would be that all OSes do similar update list checks at the boot up
time. This might point to the startup script as the culprit.

 

I can live with the delay, but if I can find a solution I will continue to
work on it.

 

From: Cliff Hatch via Atari800-users
[mailto:ata...@li...] 
Sent: Sunday, February 21, 2021 5:30 PM
To: ata...@li...
Cc: Cliff Hatch
Subject: Re: [Atari800-users] Rasp Pi Zero W w/Atari800

 

Oops, I got the names of the Debian install packages wrong.  They are
atari800_4.2.0_rpi0+2+3_stretch+buster.deb and
atari800_4.2.0_rpi4_buster.deb

On 21/02/2021 21:04, Cliff Hatch via Atari800-users wrote:

Hi Brandon

On boot up, DietPi is at 100% CPU usage for approx. 2-3 minutes

OK, hopefully that accounts for the problem - let us know. 

I'm still puzzling over the problems you encountered with Pi OS on the Zero
though:

... the PI ZERO W just isn't up to par on speed for the emulation. Choppy
play and sound experiences at all times.

I can't replicate this on my system.  I have the full version of Pi OS +
desktop installed, and atari800 runs at full speed with total CPU loading
around 50% - so there seems to be plenty of spare capacity and no necessity
to resort to stripped down operating systems. 

Is there any possibility that you might have accidentally installed the Pi 4
version rpi4_buster.deb?  It will install and run on the older Pis, but
seriously overloads the cores on the Zero and 2.  The Pi 3 can manage it,
but will run the correct version (rpi0+2+3_stretch_buster.deb) much more
efficiently.

If you want to try reinstalling rpi0+2+3_stretch_buster.deb,  take out the
installed version first, also delete its configuration file because it
contains fields that are specific to the two versions.

Change to your home directory, then:

1.	rm .atari800.cfg
2.	sudo dpkg --remove atari800

and reinstall.

Cliff

 

On 21/02/2021 19:38, Brandon wrote:

I believe I figured it out. Has nothing to do with Atari800.

 

On boot up, DietPi is at 100% CPU usage for approx. 2-3 minutes, then drops
down to under 3% usage. 

 

On initial boot up the following two commands execute in order using 98-100%
of CPU before the CPU usage drops.

 

apt-get -q update

apt -qq list -upgradeable

 

Once these complete, everything runs smoothly. So now I need to see if I can
opt out in the start-up and only execute them on demand when needed.








_______________________________________________
Atari800-users mailing list
Ata...@li...
https://lists.sourceforge.net/lists/listinfo/atari800-users








 
 
_______________________________________________
Atari800-users mailing list
Ata...@li...
https://lists.sourceforge.net/lists/listinfo/atari800-users







 
 
_______________________________________________
Atari800-users mailing list
Ata...@li...
https://lists.sourceforge.net/lists/listinfo/atari800-users






 
 
_______________________________________________
Atari800-users mailing list
Ata...@li...
https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Rasp Pi Zero W w/Atari800

[Cliff H. <ha...@bt...>]

Brandon

I'm glad you have found a solution.  I guess that effectively closes the 
case - but from my perspective it leaves an unresolved puzzle.

I did the Raspberry Pi builds for V4.2.0, so was interested to hear 
about the problems you encountered.  The intention is that users should 
be able to install atari800 with Pi OS on any machine (zero, 2, 3 or 4)  
and run it without difficulty.  However, your experience suggests that 
this is not always the case, and that there may be some performance 
issues we could usefully fix - or at least document so that others 
aren't tripped up by them.  I am only able to test the builds on my own 
limited hardware, and there is always a chance that I will miss something.

The poor performance you observed in the interval following startup is 
the kind of thing that might well have escaped my notice, but I have 
looked for it over recent days and can't see it - the emulator always 
starts at 100% for me.

There is clearly a difference between your setup and mine, particularly 
with regard to the Zero, which you found unusable with Pi OS.  The 
symptoms you described (running below full speed with choppy sound and 
video) do strongly suggest a loading issue, but we have ruled out the 
possibility that you accidentally installed the Pi 4 version.  The only 
other thought I had was that you might be using a Full HD monitor and 
the system was struggling to generate very high definition images - but 
a few experiments with my TV seemed to rule that out too.  It appears 
that Pi OS doesn't attempt to run the older Pis at maximum resolution, 
but limits itself to settings it can manage - I found that the CPU load 
imposed by atari800 remained around 50%, as with my lower resolution 
monitors.

In the absence of any other clues, maybe we will just have to leave this 
as an unexplained mystery?

Best Regards

Cliff

On 22/02/2021 17:29, Brandon wrote:
>
> Chris
>
> That did it
>
> Set the following to 0
>
> CONFIG_CHECK_DIETPI_UPDATES=0
>
> CONFIG_CHECK_APT_UPDATES=0
>
> Atari800 start at 100% speed.
>
> Thanks!
>
> *From:*Christian Groessler [mailto:ch...@gr...]
> *Sent:* Monday, February 22, 2021 11:03 AM
> *To:* ata...@li...
> *Subject:* Re: [Atari800-users] Rasp Pi Zero W w/Atari800
>
> Can't you just disable the "update" startup script?
>
> I think that's anyway better after you have a working setup. Otherwise 
> an update could break something.
>
> regards,
> chris
>
> On 2/22/21 4:15 PM, Brandon wrote:
>
>     Cliff
>
>     I had the correct debian package installed for 0+2+3 buster. Have
>     you attempted to boot to the Rasp OS desktop and immediately go
>     into Atari800? This issue appears in the first 2-3 mins of booting
>     the OS.
>
>     My guess would be that all OSes do similar update list checks at
>     the boot up time. This might point to the startup script as the
>     culprit.
>
>     I can live with the delay, but if I can find a solution I will
>     continue to work on it.
>
>     *From:*Cliff Hatch via Atari800-users
>     [mailto:ata...@li...]
>     *Sent:* Sunday, February 21, 2021 5:30 PM
>     *To:* ata...@li...
>     <mailto:ata...@li...>
>     *Cc:* Cliff Hatch
>     *Subject:* Re: [Atari800-users] Rasp Pi Zero W w/Atari800
>
>     Oops, I got the names of the Debian install packages wrong.  They
>     are*atari800_4.2.0_rpi0+2+3_stretch+buster.deb* and
>     *atari800_4.2.0_rpi4_buster.deb*
>
>     On 21/02/2021 21:04, Cliff Hatch via Atari800-users wrote:
>
>         Hi Brandon
>
>             On boot up, DietPi is at 100% CPU usage for approx. 2-3
>             minutes
>
>         OK, hopefully that accounts for the problem - let us know.
>
>         I'm still puzzling over the problems you encountered with Pi
>         OS on the Zero though:
>
>             ... the PI ZERO W just isn't up to par on speed for the
>             emulation. Choppy play and sound experiences at all times.
>
>         I can't replicate this on my system.  I have the full version
>         of Pi OS + desktop installed, and atari800 runs at full speed
>         with total CPU loading around 50% - so there seems to be
>         plenty of spare capacity and no necessity to resort to
>         stripped down operating systems.
>
>         Is there any possibility that you might have accidentally
>         installed the Pi 4 version *rpi4_buster.deb*?  It will install
>         and run on the older Pis, but seriously overloads the cores on
>         the Zero and 2.  The Pi 3 can manage it, but will run the
>         correct version (*rpi0+2+3_stretch_buster.deb*) much more
>         efficiently.
>
>         If you want to try reinstalling*rpi0+2+3_stretch_buster.deb*, 
>         take out the installed version first, also delete its
>         configuration file because it contains fields that are
>         specific to the two versions.
>
>         Change to your home directory, then:
>
>          1. rm .atari800.cfg
>          2. sudo dpkg --remove atari800
>
>         and reinstall.
>
>         Cliff
>
>         On 21/02/2021 19:38, Brandon wrote:
>
>             I believe I figured it out. Has nothing to do with Atari800.
>
>             On boot up, DietPi is at 100% CPU usage for approx. 2-3
>             minutes, then drops down to under 3% usage.
>
>             On initial boot up the following two commands execute in
>             order using 98-100% of CPU before the CPU usage drops.
>
>             apt-get –q update
>
>             apt –qq list –upgradeable
>
>             Once these complete, everything runs smoothly. So now I
>             need to see if I can opt out in the start-up and only
>             execute them on demand when needed.
>
>
>
>
>
>             _______________________________________________
>
>             Atari800-users mailing list
>
>             Ata...@li...  <mailto:Ata...@li...>
>
>             https://lists.sourceforge.net/lists/listinfo/atari800-users
>
>
>
>
>
>           
>
>           
>
>         _______________________________________________
>
>         Atari800-users mailing list
>
>         Ata...@li...  <mailto:Ata...@li...>
>
>         https://lists.sourceforge.net/lists/listinfo/atari800-users
>
>
>
>
>     _______________________________________________
>
>     Atari800-users mailing list
>
>     Ata...@li...  <mailto:Ata...@li...>
>
>     https://lists.sourceforge.net/lists/listinfo/atari800-users
>
>
>
>
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Rasp Pi Zero W w/Atari800

[Brandon <ni...@gm...>]

Chris

 

That did it

Set the following to 0

 

CONFIG_CHECK_DIETPI_UPDATES=0

CONFIG_CHECK_APT_UPDATES=0

 

Atari800 start at 100% speed.

 

Thanks!

 

From: Christian Groessler [mailto:ch...@gr...] 
Sent: Monday, February 22, 2021 11:03 AM
To: ata...@li...
Subject: Re: [Atari800-users] Rasp Pi Zero W w/Atari800

 

Can't you just disable the "update" startup script?

I think that's anyway better after you have a working setup. Otherwise an
update could break something.

regards,
chris

 

On 2/22/21 4:15 PM, Brandon wrote:

Cliff

 

I had the correct debian package installed for 0+2+3 buster. Have you
attempted to boot to the Rasp OS desktop and immediately go into Atari800?
This issue appears in the first 2-3 mins of booting the OS.

 

My guess would be that all OSes do similar update list checks at the boot up
time. This might point to the startup script as the culprit.

 

I can live with the delay, but if I can find a solution I will continue to
work on it.

 

From: Cliff Hatch via Atari800-users
[mailto:ata...@li...] 
Sent: Sunday, February 21, 2021 5:30 PM
To: ata...@li...
Cc: Cliff Hatch
Subject: Re: [Atari800-users] Rasp Pi Zero W w/Atari800

 

Oops, I got the names of the Debian install packages wrong.  They are
atari800_4.2.0_rpi0+2+3_stretch+buster.deb and
atari800_4.2.0_rpi4_buster.deb

On 21/02/2021 21:04, Cliff Hatch via Atari800-users wrote:

Hi Brandon

On boot up, DietPi is at 100% CPU usage for approx. 2-3 minutes

OK, hopefully that accounts for the problem - let us know. 

I'm still puzzling over the problems you encountered with Pi OS on the Zero
though:

... the PI ZERO W just isn't up to par on speed for the emulation. Choppy
play and sound experiences at all times.

I can't replicate this on my system.  I have the full version of Pi OS +
desktop installed, and atari800 runs at full speed with total CPU loading
around 50% - so there seems to be plenty of spare capacity and no necessity
to resort to stripped down operating systems. 

Is there any possibility that you might have accidentally installed the Pi 4
version rpi4_buster.deb?  It will install and run on the older Pis, but
seriously overloads the cores on the Zero and 2.  The Pi 3 can manage it,
but will run the correct version (rpi0+2+3_stretch_buster.deb) much more
efficiently.

If you want to try reinstalling rpi0+2+3_stretch_buster.deb,  take out the
installed version first, also delete its configuration file because it
contains fields that are specific to the two versions.

Change to your home directory, then:

1.	rm .atari800.cfg
2.	sudo dpkg --remove atari800

and reinstall.

Cliff

 

On 21/02/2021 19:38, Brandon wrote:

I believe I figured it out. Has nothing to do with Atari800.

 

On boot up, DietPi is at 100% CPU usage for approx. 2-3 minutes, then drops
down to under 3% usage. 

 

On initial boot up the following two commands execute in order using 98-100%
of CPU before the CPU usage drops.

 

apt-get -q update

apt -qq list -upgradeable

 

Once these complete, everything runs smoothly. So now I need to see if I can
opt out in the start-up and only execute them on demand when needed.







_______________________________________________
Atari800-users mailing list
Ata...@li...
https://lists.sourceforge.net/lists/listinfo/atari800-users







 
 
_______________________________________________
Atari800-users mailing list
Ata...@li...
https://lists.sourceforge.net/lists/listinfo/atari800-users






 
 
_______________________________________________
Atari800-users mailing list
Ata...@li...
https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Rasp Pi Zero W w/Atari800

[Christian G. <ch...@gr...>]

Can't you just disable the "update" startup script?

I think that's anyway better after you have a working setup. Otherwise 
an update could break something.

regards,
chris


On 2/22/21 4:15 PM, Brandon wrote:
>
> Cliff
>
> I had the correct debian package installed for 0+2+3 buster. Have you 
> attempted to boot to the Rasp OS desktop and immediately go into 
> Atari800? This issue appears in the first 2-3 mins of booting the OS.
>
> My guess would be that all OSes do similar update list checks at the 
> boot up time. This might point to the startup script as the culprit.
>
> I can live with the delay, but if I can find a solution I will 
> continue to work on it.
>
> *From:*Cliff Hatch via Atari800-users 
> [mailto:ata...@li...]
> *Sent:* Sunday, February 21, 2021 5:30 PM
> *To:* ata...@li...
> *Cc:* Cliff Hatch
> *Subject:* Re: [Atari800-users] Rasp Pi Zero W w/Atari800
>
> Oops, I got the names of the Debian install packages wrong. They 
> are*atari800_4.2.0_rpi0+2+3_stretch+buster.deb* and 
> *atari800_4.2.0_rpi4_buster.deb*
>
> On 21/02/2021 21:04, Cliff Hatch via Atari800-users wrote:
>
>     Hi Brandon
>
>         On boot up, DietPi is at 100% CPU usage for approx. 2-3 minutes
>
>     OK, hopefully that accounts for the problem - let us know.
>
>     I'm still puzzling over the problems you encountered with Pi OS on
>     the Zero though:
>
>         ... the PI ZERO W just isn't up to par on speed for the
>         emulation. Choppy play and sound experiences at all times.
>
>     I can't replicate this on my system.  I have the full version of
>     Pi OS + desktop installed, and atari800 runs at full speed with
>     total CPU loading around 50% - so there seems to be plenty of
>     spare capacity and no necessity to resort to stripped down
>     operating systems.
>
>     Is there any possibility that you might have accidentally
>     installed the Pi 4 version *rpi4_buster.deb*?  It will install and
>     run on the older Pis, but seriously overloads the cores on the
>     Zero and 2.  The Pi 3 can manage it, but will run the correct
>     version (*rpi0+2+3_stretch_buster.deb*) much more efficiently.
>
>     If you want to try reinstalling*rpi0+2+3_stretch_buster.deb*, 
>     take out the installed version first, also delete its
>     configuration file because it contains fields that are specific to
>     the two versions.
>
>     Change to your home directory, then:
>
>       * rm .atari800.cfg
>       * sudo dpkg --remove atari800
>
>     and reinstall.
>
>     Cliff
>
>     On 21/02/2021 19:38, Brandon wrote:
>
>         I believe I figured it out. Has nothing to do with Atari800.
>
>         On boot up, DietPi is at 100% CPU usage for approx. 2-3
>         minutes, then drops down to under 3% usage.
>
>         On initial boot up the following two commands execute in order
>         using 98-100% of CPU before the CPU usage drops.
>
>         apt-get –q update
>
>         apt –qq list –upgradeable
>
>         Once these complete, everything runs smoothly. So now I need
>         to see if I can opt out in the start-up and only execute them
>         on demand when needed.
>
>
>
>
>         _______________________________________________
>
>         Atari800-users mailing list
>
>         Ata...@li...  <mailto:Ata...@li...>
>
>         https://lists.sourceforge.net/lists/listinfo/atari800-users  <https://lists.sourceforge.net/lists/listinfo/atari800-users>
>
>
>
>
>     _______________________________________________
>
>     Atari800-users mailing list
>
>     Ata...@li...  <mailto:Ata...@li...>
>
>     https://lists.sourceforge.net/lists/listinfo/atari800-users  <https://lists.sourceforge.net/lists/listinfo/atari800-users>
>
>
>
>
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Rasp Pi Zero W w/Atari800

[Brandon <ni...@gm...>]

Cliff

 

I had the correct debian package installed for 0+2+3 buster. Have you
attempted to boot to the Rasp OS desktop and immediately go into Atari800?
This issue appears in the first 2-3 mins of booting the OS.

 

My guess would be that all OSes do similar update list checks at the boot up
time. This might point to the startup script as the culprit.

 

I can live with the delay, but if I can find a solution I will continue to
work on it.

 

From: Cliff Hatch via Atari800-users
[mailto:ata...@li...] 
Sent: Sunday, February 21, 2021 5:30 PM
To: ata...@li...
Cc: Cliff Hatch
Subject: Re: [Atari800-users] Rasp Pi Zero W w/Atari800

 

Oops, I got the names of the Debian install packages wrong.  They are
atari800_4.2.0_rpi0+2+3_stretch+buster.deb and
atari800_4.2.0_rpi4_buster.deb

On 21/02/2021 21:04, Cliff Hatch via Atari800-users wrote:

Hi Brandon

On boot up, DietPi is at 100% CPU usage for approx. 2-3 minutes

OK, hopefully that accounts for the problem - let us know. 

I'm still puzzling over the problems you encountered with Pi OS on the Zero
though:

... the PI ZERO W just isn't up to par on speed for the emulation. Choppy
play and sound experiences at all times.

I can't replicate this on my system.  I have the full version of Pi OS +
desktop installed, and atari800 runs at full speed with total CPU loading
around 50% - so there seems to be plenty of spare capacity and no necessity
to resort to stripped down operating systems. 

Is there any possibility that you might have accidentally installed the Pi 4
version rpi4_buster.deb?  It will install and run on the older Pis, but
seriously overloads the cores on the Zero and 2.  The Pi 3 can manage it,
but will run the correct version (rpi0+2+3_stretch_buster.deb) much more
efficiently.

If you want to try reinstalling rpi0+2+3_stretch_buster.deb,  take out the
installed version first, also delete its configuration file because it
contains fields that are specific to the two versions.

Change to your home directory, then:

*	rm .atari800.cfg
*	sudo dpkg --remove atari800

and reinstall.

Cliff

 

On 21/02/2021 19:38, Brandon wrote:

I believe I figured it out. Has nothing to do with Atari800.

 

On boot up, DietPi is at 100% CPU usage for approx. 2-3 minutes, then drops
down to under 3% usage. 

 

On initial boot up the following two commands execute in order using 98-100%
of CPU before the CPU usage drops.

 

apt-get -q update

apt -qq list -upgradeable

 

Once these complete, everything runs smoothly. So now I need to see if I can
opt out in the start-up and only execute them on demand when needed.






_______________________________________________
Atari800-users mailing list
Ata...@li...
https://lists.sourceforge.net/lists/listinfo/atari800-users






 
 
_______________________________________________
Atari800-users mailing list
Ata...@li...
https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Rasp Pi Zero W w/Atari800

[Cliff H. <ha...@bt...>]

Oops, I got the names of the Debian install packages wrong.  They 
are*atari800_4.2.0_rpi0+2+3_stretch+buster.deb* and 
*atari800_4.2.0_rpi4_buster.deb*

On 21/02/2021 21:04, Cliff Hatch via Atari800-users wrote:
>
> Hi Brandon
>
>> On boot up, DietPi is at 100% CPU usage for approx. 2-3 minutes
> OK, hopefully that accounts for the problem - let us know.
>
> I'm still puzzling over the problems you encountered with Pi OS on the 
> Zero though:
>
>> ... the PI ZERO W just isn't up to par on speed for the emulation. 
>> Choppy play and sound experiences at all times.
> I can't replicate this on my system.  I have the full version of Pi OS 
> + desktop installed, and atari800 runs at full speed with total CPU 
> loading around 50% - so there seems to be plenty of spare capacity and 
> no necessity to resort to stripped down operating systems.
>
> Is there any possibility that you might have accidentally installed 
> the Pi 4 version *rpi4_buster.deb*?  It will install and run on the 
> older Pis, but seriously overloads the cores on the Zero and 2.  The 
> Pi 3 can manage it, but will run the correct version 
> (*rpi0+2+3_stretch_buster.deb*) much more efficiently.
>
> If you want to try reinstalling*rpi0+2+3_stretch_buster.deb*, take out 
> the installed version first, also delete its configuration file 
> because it contains fields that are specific to the two versions.
>
> Change to your home directory, then:
>
>   * rm .atari800.cfg
>   * sudo dpkg --remove atari800
>
> and reinstall.
>
> Cliff
>
>
> On 21/02/2021 19:38, Brandon wrote:
>>
>> I believe I figured it out. Has nothing to do with Atari800.
>>
>> On boot up, DietPi is at 100% CPU usage for approx. 2-3 minutes, then 
>> drops down to under 3% usage.
>>
>> On initial boot up the following two commands execute in order using 
>> 98-100% of CPU before the CPU usage drops.
>>
>> apt-get –q update
>>
>> apt –qq list –upgradeable
>>
>> Once these complete, everything runs smoothly. So now I need to see 
>> if I can opt out in the start-up and only execute them on demand when 
>> needed.
>>
>>
>>
>> _______________________________________________
>> Atari800-users mailing list
>> Ata...@li...
>> https://lists.sourceforge.net/lists/listinfo/atari800-users
>
>
>
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Rasp Pi Zero W w/Atari800

[Cliff H. <ha...@bt...>]

Hi Brandon

> On boot up, DietPi is at 100% CPU usage for approx. 2-3 minutes
OK, hopefully that accounts for the problem - let us know.

I'm still puzzling over the problems you encountered with Pi OS on the 
Zero though:

> ... the PI ZERO W just isn't up to par on speed for the emulation. 
> Choppy play and sound experiences at all times.
I can't replicate this on my system.  I have the full version of Pi OS + 
desktop installed, and atari800 runs at full speed with total CPU 
loading around 50% - so there seems to be plenty of spare capacity and 
no necessity to resort to stripped down operating systems.

Is there any possibility that you might have accidentally installed the 
Pi 4 version *rpi4_buster.deb*?  It will install and run on the older 
Pis, but seriously overloads the cores on the Zero and 2.  The Pi 3 can 
manage it, but will run the correct version 
(*rpi0+2+3_stretch_buster.deb*) much more efficiently.

If you want to try reinstalling*rpi0+2+3_stretch_buster.deb*, take out 
the installed version first, also delete its configuration file because 
it contains fields that are specific to the two versions.

Change to your home directory, then:

  * rm .atari800.cfg
  * sudo dpkg --remove atari800

and reinstall.

Cliff


On 21/02/2021 19:38, Brandon wrote:
>
> I believe I figured it out. Has nothing to do with Atari800.
>
> On boot up, DietPi is at 100% CPU usage for approx. 2-3 minutes, then 
> drops down to under 3% usage.
>
> On initial boot up the following two commands execute in order using 
> 98-100% of CPU before the CPU usage drops.
>
> apt-get –q update
>
> apt –qq list –upgradeable
>
> Once these complete, everything runs smoothly. So now I need to see if 
> I can opt out in the start-up and only execute them on demand when needed.
>
>
>
>
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Rasp Pi Zero W w/Atari800

[Brandon <ni...@gm...>]

I believe I figured it out. Has nothing to do with Atari800.

 

On boot up, DietPi is at 100% CPU usage for approx. 2-3 minutes, then drops
down to under 3% usage. 

 

On initial boot up the following two commands execute in order using 98-100%
of CPU before the CPU usage drops.

 

apt-get -q update

apt -qq list -upgradeable

 

Once these complete, everything runs smoothly. So now I need to see if I can
opt out in the start-up and only execute them on demand when needed.

Re: [Atari800-users] Rasp Pi Zero W w/Atari800

[Brandon <ni...@gm...>]

Cliff:

 

Later in that thread, I mentioned I ended up swapping my microSD card into
my PI 3B because the PI ZERO W just isn't up to par on speed for the
emulation. Choppy play and sound experiences at all times. But I was on a
mission to get the Pi Zero W to work. So, that is why I went a different
route with slimmed down DietPi and no desktop on the Zero W. My Pi3 is used
in a full standup arcade I built with RetroPie, so I put my focus back into
getting the Zero working. 

 

Miro:

 

I usually would just change sound freq up or down then back out. Go back in
and reset the freq to what I want. Thing is it takes a few times until I see
the emu running at a steady 99-100%.

It seems like it might be a timing issue as if something is running in the
background on initial boot up. Runs super smooth once it gets over that
hump.

 

From: Cliff Hatch via Atari800-users
[mailto:ata...@li...] 
Sent: Sunday, February 21, 2021 5:13 AM
To: ata...@li...
Cc: Cliff Hatch
Subject: Re: [Atari800-users] Rasp Pi Zero W w/Atari800

 

Hi Brandon

Took several attempts to get it to run smoothly testing various OSes, etc.

You mentioned on AtariAge that you set the emulator up on a Pi Zero running
the latest release of Pi OS, and everything just worked.  Did something
eventually go wrong with Pi OS that caused you to switch to DietPi?
Specifically, did you have the same problem with choppy video and sound?

Cliff

On 19/02/2021 23:40, Brandon wrote:

Hello

 

Current member of AtariAge. Been messing around with my various Pi's and
decided to make a dedicated Atari800 Zero W. Took several attempts to get it
to run smoothly testing various OSes, etc. Finally got a stable and very
smooth running set-up. Installed DietPi with no desktop and only addition
was OpenSSH to communicate with my PC on Sandisk Ultra Plus 16Gb microSD.
Set GPU memory at 256 and the rest is stock default settings.

 

Atari800 settings:

-        All stock OSes and BASIC A,B & C available.

-        High Fidelity Pokey and Stereo Pokey ON @ 22050 Hz

-        Display filtering OFF

 

That's about the only things I changed from default settings.

 

I am very pleased with the outcome, but have an odd situation on initial
warm start-up. Atari800 will randomly fluctuate at speeds between 50-80%
initially. Games and sound are real choppy. But, if I make a change in the
settings menu (don't even need to save the change) and then back out of the
menu back to the game or software I am running, it runs smoothly at 98-100%
speed. It will run at full speed with no glitches of any kind. I've tested
it for over an hour at a time.

 

It's more of an annoyance then anything. Would like your thoughts on what
might be causing that initial speed restriction.

 

Thank you

 

Brandon

(AKA nismopc @ atariage forums)






 
 
_______________________________________________
Atari800-users mailing list
Ata...@li...
https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Rasp Pi Zero W w/Atari800

[Cliff H. <ha...@bt...>]

Hi Brandon

> Took several attempts to get it to run smoothly testing various OSes, etc.

You mentioned on AtariAge that you set the emulator up on a Pi Zero 
running the latest release of Pi OS, and everything just worked.  Did 
something eventually go wrong with Pi OS that caused you to switch to 
DietPi?  Specifically, did you have the same problem with choppy video 
and sound?

Cliff

On 19/02/2021 23:40, Brandon wrote:
>
> Hello
>
> Current member of AtariAge. Been messing around with my various Pi’s 
> and decided to make a dedicated Atari800 Zero W. Took several attempts 
> to get it to run smoothly testing various OSes, etc. Finally got a 
> stable and very smooth running set-up. Installed DietPi with no 
> desktop and only addition was OpenSSH to communicate with my PC on 
> Sandisk Ultra Plus 16Gb microSD. Set GPU memory at 256 and the rest is 
> stock default settings.
>
> Atari800 settings:
>
> -All stock OSes and BASIC A,B & C available.
>
> -High Fidelity Pokey and Stereo Pokey ON @ 22050 Hz
>
> -Display filtering OFF
>
> That’s about the only things I changed from default settings.
>
> I am very pleased with the outcome, but have an odd situation on 
> initial warm start-up. Atari800 will randomly fluctuate at speeds 
> between 50-80% initially. Games and sound are real choppy. But, if I 
> make a change in the settings menu (don’t even need to save the 
> change) and then back out of the menu back to the game or software I 
> am running, it runs smoothly at 98-100% speed. It will run at full 
> speed with no glitches of any kind. I’ve tested it for over an hour at 
> a time.
>
> It’s more of an annoyance then anything. Would like your thoughts on 
> what might be causing that initial speed restriction.
>
> Thank you
>
> Brandon
>
> (AKA nismopc @ atariage forums)
>
>
>
>
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Rasp Pi Zero W w/Atari800

[Miro K. <mir...@gm...>]

Hi Brandon,

Atari800 will randomly fluctuate at speeds between 50-80% initially. Games
> and sound are real choppy. But, if I make a change in the settings menu
> (don’t even need to save the change) and then back out of the menu back to
> the game or software I am running, it runs smoothly at 98-100% speed.
>
Does it matter what option you change?

-- 
http://mikro.atari.org

[Atari800-users] Rasp Pi Zero W w/Atari800

[Brandon <ni...@gm...>]

Hello

 

Current member of AtariAge. Been messing around with my various Pi's and
decided to make a dedicated Atari800 Zero W. Took several attempts to get it
to run smoothly testing various OSes, etc. Finally got a stable and very
smooth running set-up. Installed DietPi with no desktop and only addition
was OpenSSH to communicate with my PC on Sandisk Ultra Plus 16Gb microSD.
Set GPU memory at 256 and the rest is stock default settings.

 

Atari800 settings:

-        All stock OSes and BASIC A,B & C available.

-        High Fidelity Pokey and Stereo Pokey ON @ 22050 Hz

-        Display filtering OFF

 

That's about the only things I changed from default settings.

 

I am very pleased with the outcome, but have an odd situation on initial
warm start-up. Atari800 will randomly fluctuate at speeds between 50-80%
initially. Games and sound are real choppy. But, if I make a change in the
settings menu (don't even need to save the change) and then back out of the
menu back to the game or software I am running, it runs smoothly at 98-100%
speed. It will run at full speed with no glitches of any kind. I've tested
it for over an hour at a time.

 

It's more of an annoyance then anything. Would like your thoughts on what
might be causing that initial speed restriction.

 

Thank you

 

Brandon

(AKA nismopc @ atariage forums)

[Atari800-users] Additional peripherals - SONari, PokeyMax, SIDari

[Cyprian K. <cyp...@gm...>]

Hi Team,

first of all thanks for this great emulator.
I recently bought SONari and PokeyMax. The first one has two integrated
lovely YM2149F chips, and the second one emulates YM/AY (and more) on the
FPGA level. There is also another nice cart called SIDari with SID chip.
Would it be possible to add support for them? Would be cool to have them
integrated into the atari800.

Thanks

Regards
Cyprian

Re: [Atari800-users] Correct artifact setting for Flight Simulator II

[<be...@op...>]

It seems to me that the atari800 emulator fills in pixels in-between artifacted pixels with the artifact color. 99% of the time this makes it look better. The following example would show two vertical red lines on a real computer, but will show as a solid red block in the emulator:

Artifacted pixels on a Real Atari:
o o
o o
o o

Artifacted pixels on atari800:
ooo
ooo
ooo

I don't know if there is a solution to this, just pointing out what I see. I might like an option to not fill in space between artifacted pixels.

Blair

On Mon, 8 Feb 2021 17:20:23 -0600
Chuck Bermingham <cc...@gm...> wrote:

> I am running atari800 Version 4.1.0 on Linux Mint 20.1, Kernel 5.4.0-65 
> Generic.
> 
> I have a fairly typical setup; 1920 by 1080 graphics over HDMI, 60 HZ 
> refresh rate.
> 
> When I run FS-II and don't specify artifacts, the artificial horizon 
> shows as a lot of vertical lines, so I guessed it must rely on artifacting.
> 
> When I use artifacting of any kind, the artificial horizon shows with 
> different colors, depending on the mode; however, the airspeed indicator 
> is illegible because of artifacting.
> 
> 
> 
> I have a strange feeling this has something to do with how atari800 is 
> handling display-list interrupts, but that's just a guess at this point.
> 
> Does anyone know if there is a "magic" artifact configuration for FS-II?
> 
> -- 
> Charles Bermingham
> cc...@gm...
> (773)736-6865 (Home): (773)412-3785 (Mobile)
> 
> 
> 
> 
> 
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Correct artifact setting for Flight Simulator II

[Petr S. <pst...@so...>]

It'd worth testing out the most up-to-date version from git because
there have been quite some changes, I think.

I know I am "slow" in making releases. I usually work on them when I
attend an Atari users convention but you know there weren't any in last
12 months for obvious reason.

Thanks,

Petr

Bill Kendrick píše v Po 08. 02. 2021 v 20:41 -0800:
> It's been a while, but I recall that with artifacting on, the
> brightnes
> (of COLPF1, shadowed at COLOR1, aka SETCOLOR 1,h,l aka POKE 709,xxx)
> and hue (of COLPF2) were not being taken into account properly.
> 
> This was a while ago, and before some of the fancier new display
> options were added.  And I admit, I tried to get Atari800 that I have
> installed on my work laptop here (for lunch break fun) to reproduce
> it,
> but I can't eve get artifcating to occur at all, now!  Weird. :-/
> 
> -bill!
> 
> On Mon, Feb 08, 2021 at 05:20:23PM -0600, Chuck Bermingham wrote:
> > I am running atari800 Version 4.1.0 on Linux Mint 20.1, Kernel
> > 5.4.0-65 Generic.
> > 
> > I have a fairly typical setup; 1920 by 1080 graphics over HDMI, 60
> > HZ refresh rate.
> > 
> > When I run FS-II and don't specify artifacts, the artificial
> > horizon
> > shows as a lot of vertical lines, so I guessed it must rely on
> > artifacting.
> > 
> > When I use artifacting of any kind, the artificial horizon shows
> > with different colors, depending on the mode; however, the airspeed
> > indicator is illegible because of artifacting.
> > 
> > 
> > 
> > I have a strange feeling this has something to do with how atari800
> > is handling display-list interrupts, but that's just a guess at
> > this
> > point.
> > 
> > Does anyone know if there is a "magic" artifact configuration for
> > FS-II?
> > 
> > -- 
> > Charles Bermingham
> > cc...@gm...
> > (773)736-6865 (Home): (773)412-3785 (Mobile)
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Atari800-users mailing list
> > Ata...@li...
> > https://lists.sourceforge.net/lists/listinfo/atari800-users
> > 

Re: [Atari800-users] Correct artifact setting for Flight Simulator II

[Bill K. <nb...@so...>]

It's been a while, but I recall that with artifacting on, the brightnes
(of COLPF1, shadowed at COLOR1, aka SETCOLOR 1,h,l aka POKE 709,xxx)
and hue (of COLPF2) were not being taken into account properly.

This was a while ago, and before some of the fancier new display
options were added.  And I admit, I tried to get Atari800 that I have
installed on my work laptop here (for lunch break fun) to reproduce it,
but I can't eve get artifcating to occur at all, now!  Weird. :-/

-bill!

On Mon, Feb 08, 2021 at 05:20:23PM -0600, Chuck Bermingham wrote:
> I am running atari800 Version 4.1.0 on Linux Mint 20.1, Kernel
> 5.4.0-65 Generic.
> 
> I have a fairly typical setup; 1920 by 1080 graphics over HDMI, 60
> HZ refresh rate.
> 
> When I run FS-II and don't specify artifacts, the artificial horizon
> shows as a lot of vertical lines, so I guessed it must rely on
> artifacting.
> 
> When I use artifacting of any kind, the artificial horizon shows
> with different colors, depending on the mode; however, the airspeed
> indicator is illegible because of artifacting.
> 
> 
> 
> I have a strange feeling this has something to do with how atari800
> is handling display-list interrupts, but that's just a guess at this
> point.
> 
> Does anyone know if there is a "magic" artifact configuration for FS-II?
> 
> -- 
> Charles Bermingham
> cc...@gm...
> (773)736-6865 (Home): (773)412-3785 (Mobile)
> 
> 
> 
> 
> 
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users
> 

-- 
-bill!
Sent from my computer

[Atari800-users] Correct artifact setting for Flight Simulator II

[Chuck B. <cc...@gm...>]

I am running atari800 Version 4.1.0 on Linux Mint 20.1, Kernel 5.4.0-65 
Generic.

I have a fairly typical setup; 1920 by 1080 graphics over HDMI, 60 HZ 
refresh rate.

When I run FS-II and don't specify artifacts, the artificial horizon 
shows as a lot of vertical lines, so I guessed it must rely on artifacting.

When I use artifacting of any kind, the artificial horizon shows with 
different colors, depending on the mode; however, the airspeed indicator 
is illegible because of artifacting.



I have a strange feeling this has something to do with how atari800 is 
handling display-list interrupts, but that's just a guess at this point.

Does anyone know if there is a "magic" artifact configuration for FS-II?

-- 
Charles Bermingham
cc...@gm...
(773)736-6865 (Home): (773)412-3785 (Mobile)

[Atari800-users] Moving toward building Atari800 (was: Re: Atari800-users Digest, Vol 109, Issue 2)

[Chris C. <chr...@gm...>]

Sorry for the change-of-subject; I just now noticed the instruction to do
that, in the generated headers.  Mea culpa.

Date: Mon, 14 Dec 2020 03:27:45 +0100
> From: Tomasz Krasuski <tom...@in...>
>
>
...

https://github.com/atari800/atari800
>
> and press the large green "Code" button, then in the pull-down menu
> "Download ZIP".


Thanks!  I'll do that soon, then refer back to your earlier advice.

> First, I need to sort out what I need to have, and where to get it.?
> All of the requirements and necessary links are described in
> DOC/BUILD.android, they are:
>
>   * a Cygwin or MinGW environment, such as MSYS2,
>   * JDK 1.8 + Ant,
>   * an old Android SDK,
>   * an old Android NDK.
>

Last night in the course of other things I happened across a little info
about MinGW, so that's progress.  Could you perhaps be a little more
specific, though, as to what constitutes "an old" Android SDK/NDK?  I've
never done Android development before.

Though I'm not sure if building on a 32-bit Windows will work.


Yeah, being still at XP has been awkward for a long time, in an
ever-increasing  number of ways -- but XP is the last version of Windows
that allows me to do certain things.  I have a 64-bit Win 7 desktop system,
but that hasn't been booted since 2014 when the HDD died, and a *really
really slow *Win 10 machine that may have been designed to really run only
XP or 7.  So, I have options, if worse comes to worst.  For now, though,
I'd still like to be able to *run *my builds on 32-bit XP, so...

Java 1.8
> is available for 32-bit; the old Android SDK supports 32-bit, too; the
> NDK also seems to contain 32-bit tools; but the MSYS2 environment is no
> longer provided for 32-bit architectures. It might be required to use an
> older installation package of MSYS2 that was built for 32-bit, or to use
> MinGW instead, which AFAIK is 32-bit only.
>

How many of these things apply to Windows, Android, or *both?*  For reasons
of history, I'm uncomfortable with the idea of, for instance, the Windows
version possibly having Java in it.  I want this thing to run as blazingly
fast as possible, and with Java being an *interpreted *language (last I
heard), it's going to be slower than pure machine code...  (My need for
speed comes because I enjoy pushing the limits of the good ol' Atari in
terms of sheer number-crunching.  Right now I have an *atari800 *session
running a little ray-tracer I wrote in Kyan Pascal; it's supposed to fill
the whole GR.9 screen, eventually, but -- in Turbo mode, which is giving me
about 300% of realtime speed -- it has taken about 42 hours to fill just
the *first three columns* (of pixels).  I need every ounce of
faster-than-normal speed I can get, for things like this.)

Or wait till past New Year for that new computer :-)
>

Even if I  still try to make an XP version, at the speed I typically get
around to things I'll have a new machine before I get to doing any serious
work on this.  I've got about 1200 floppies I need to image for emulation
before they totally rot away, and don't currently have my actual *hardware *up
and running to read them.  Again, that's a whole other discussion, probably
not even for this forum.

The SDL version (--with-video=sdl --with-sound=sdl) supports OpenGL, but
> does not require it.


Oh, so it's a *runtime *option?  What am I seeing on the screen when I'm *not
*using those options?


> It is also possible to build a DirectX target
> (--target=directx), but it is not maintained anymore, as the SDL version
> surpasses it.
>

I've never worked with *any *of them, so it doesn't much matter to me.  But
thanks for letting me know where things stand.  (Another of my many
bucket-list projects is to figure out how people write the kind of playably
fast (sometimes *too *fast, heheh) videogames in which everything is built
of chunky cubes, which move, fall apart, etc. in realistic ways.  Again, I
want to know how to get that kind of *speed.*)

> How many different executables could I build, in theory, and still
> > have Windows GUI environment similar to what I'm used to? ?(How do I
> > /even tell /what I /currently have?/) ?Please advise.
>
> I'm not sure if I understand the question. There is no Windows GUI in
> any version of Atari800. Aren't you possibly referring to the old
> Atari800Win PLus? That was a separate project, and it is not maintained
> for more than 10 years AFAIK.
>

Mea culpa, again.  I used the wrong jargon.  I didn't mean "Windows GUI" as
in having literal Windows-style pulldown menus etc. -- though I *have *used
(and, frankly, preferred in some ways), the long-dead PLus branch; I meant,
"will *differences, *if any, will I see, and experience, in *atari800 **running
on Windows, *with different choices of SDL, OpenGL, DirectX, "or
whatever?"  I.e., will specific choices among those affect the speed,
look-and-feel, or anything else, of the emulation experience, *at runtime?*
 Sorry for the confusion.

Again, I'm not sure if I understand the question.


Looks like I asked the same thing twice, due to a long edit session and
failing to remove a redundant paragraph.  Me culpa Part III...


> If you want to check
> what the SDL version looks like, just get the
> atari800-4.2.0-win32-sdl.zip package from our releases page:
>
> https://github.com/atari800/atari800/releases


Thanks; I'll do that.

To build it by yourself, see DOC/BUILD.windows, specifically section I)
> Building using Cygwin, MinGW, MinGW-w64, MSYS2 etc. If you fail, let us
> know.
>

Yes, I'll try to see how far I can get, on my own, before having to pester
you guys.

> Be advised that I work very slowly.
>
> Me too, no problem ^_^
>

:-)

(Apropos of nothing -- this isn't strictly an emulator issue, so maybe I
shouldn't mention it, but, I recently wrote a nice little Atari BASIC
program that does on-screen preview of a Daisy-Dot font stored in *.NLQ *file
format (at least, as far as I have yet observed it).  This might be "old
hat" at this point in history, but if it's not, and anybody would like a
copy, just let me know.  Combined with *atari800*'s screenshot feature,
it's very easy to produce a nice little "visual catalog" of the fonts --
which I find especially handy in this post-dot-matrix-printer age.

I've also recently solved a problem that annoyed me for years, on Windows:
how to get the output of multiple BASIC *LPRINT *statements (really,
*any *open-write-close
sequence on the P: device) into a *single *host-system file, rather than
each going into a *separate *file.  I don't have the magic incarnation
handy just now, but wanted to mention it so I didn't forget.  If you want
the info and I don't produce it soon, feel free to pester me for it via
private email.  One of the feature-function enhancements I hope to make is
to implement finer control over the print aspects of the emulation, so that
weird hacks won't be necessary.

Thanks again,

Chris

Re: [Atari800-users] Atari800-users Digest, Vol 108, Issue 3

[Tomasz K. <tom...@in...>]

On 05.12.2020 at 08:15, Chris Chiesa wrote:
>
>
>     Date: Sat, 28 Nov 2020 19:30:15 +0100
>     From: Tomasz Krasuski <tom...@in...
>     <mailto:tom...@in...>>
>     Subject: Re: [Atari800-users] Building Atari800
>
> Before I move on to point-by-point remarks, after reading your reply I 
> have identified the probable cause of at least some of my problems:  I 
> seem to have a different sourcecode package than you are talking 
> about.  I have something named *atari800-ATARI800_4_2_0.zip*, which 
> differs in every detail you mention.  I assume that means that what I 
> have here is outdated.  What should I have downloaded instead, and 
> where do I find it?

Yes, this package of yours is the last released version, not the latest 
development version. To get the package with the latest changes in 
source code, go to the GitHub project page:

https://github.com/atari800/atari800

and press the large green "Code" button, then in the pull-down menu 
"Download ZIP". The resulting archive will contain DOC/BUILD.android and 
all the other changes I wrote about.


> First, I need to sort out what I need to have, and where to get it.  
> Basically, what I need are the latest versions of the build tools that 
> still work on 32-bit XP, the latest version of source code that can be 
> built with those tools, and the complete set of "just the right 
> versions" of all the other required libraries, DLLs, etc., to work 
> /with each other, /and with the chosen versions of the toolchain, on 
> 32-bit XP.  If experience is any indication, this could be a fairly 
> large challenge, or even impossible, at this late date.  One /huge 
> /thing you could do to help me would be to */provide me with all of 
> these items, /if you have them*.  If you don't have them, maybe you 
> could at least help me /identify /and /find /them.

All of the requirements and necessary links are described in 
DOC/BUILD.android, they are:

  * a Cygwin or MinGW environment, such as MSYS2,
  * JDK 1.8 + Ant,
  * an old Android SDK,
  * an old Android NDK.

Though I'm not sure if building on a 32-bit Windows will work. Java 1.8 
is available for 32-bit; the old Android SDK supports 32-bit, too; the 
NDK also seems to contain 32-bit tools; but the MSYS2 environment is no 
longer provided for 32-bit architectures. It might be required to use an 
older installation package of MSYS2 that was built for 32-bit, or to use 
MinGW instead, which AFAIK is 32-bit only.

Or wait till past New Year for that new computer :-)


> One thing that has to happen first, is that I need to confirm (or 
> change) my opinion that what I want to build /really is /"the SDL 
> version."  How do DirectX and OpenGL fit in?

The SDL version (--with-video=sdl --with-sound=sdl) supports OpenGL, but 
does not require it. It is also possible to build a DirectX target 
(--target=directx), but it is not maintained anymore, as the SDL version 
surpasses it.


> How many different executables could I build, in theory, and still 
> have Windows GUI environment similar to what I'm used to?  (How do I 
> /even tell /what I /currently have?/)  Please advise.

I'm not sure if I understand the question. There is no Windows GUI in 
any version of Atari800. Aren't you possibly referring to the old 
Atari800Win PLus? That was a separate project, and it is not maintained 
for more than 10 years AFAIK.


> If it turns out that I can't do some, or all, of this, due to 
> limitations make the changes I want, due to limitations of technology 
> or intellect, I'll simply turn over my wishlist to the community and 
> beg those better-equipped than myself to do them for me!
>
> One prerequisite for doing even that, is to confirm that I "really do" 
> want "the SDL version," specifically.  I don't actually know.  I don't 
> even know /by what criteria I would even make the choice./  The only 
> question that comes to mind is, "Will there be 
> feature/function/performance differences depending on what I choose?" 
>  I want something as similar as possible to what I'm used to, but I 
> don't know what /that /uses; I didn't build it myself.  Please advise.

Again, I'm not sure if I understand the question. If you want to check 
what the SDL version looks like, just get the 
atari800-4.2.0-win32-sdl.zip package from our releases page:

https://github.com/atari800/atari800/releases

To build it by yourself, see DOC/BUILD.windows, specifically section I) 
Building using Cygwin, MinGW, MinGW-w64, MSYS2 etc. If you fail, let us 
know.


> My long-term goal is to try to make some feature-function enhancements 
> I've been wishing for (in my head), /if I can./ (Don't worry, though, 
> that some branch off an obsolete version of the project, or code that 
> isn't platform-agnostic, or that only works on Windows, will 
> contaminate the master repository: I have no idea how to do that, even 
> if I wanted to!)  If it turns out that I'm not up to the challenge, 
> I'll just have to turn over my wish list to those better qualified.
>
> Thanks again.  I look forward to hearing from, and working with, you.  
> Be advised that I work very slowly.

Me too, no problem ^_^

-- 
Regards,
Tomek

Re: [Atari800-users] Atari800-users Digest, Vol 108, Issue 3

[Chris C. <chr...@gm...>]

>
>
> Date: Sat, 28 Nov 2020 19:30:15 +0100
> From: Tomasz Krasuski <tom...@in...>
> Subject: Re: [Atari800-users] Building Atari800
>

Before I move on to point-by-point remarks, after reading your reply I have
identified the probable cause of at least some of my problems:  I seem to
have a different sourcecode package than you are talking about.  I have
something named *atari800-ATARI800_4_2_0.zip*, which differs in every
detail you mention.  I assume that means that what I have here is
outdated.  What should I have downloaded instead, and where do I find it?
I don't remember where I got this one, but I *think *I went first to
Sourceforge (where this project "used to live"), saw a note that it had
moved to Github, then went and got it from *there.  *It's also possible
that I had to limit myself to the "newest version that can still be
built/run on 32-bit Windows XP (Pro SP3, if that matters)."  .

Please advise.

On 28.08.2020 at 02:30, Chris Chiesa wrote:
>
> 1) On Windows, I want to build the SDL version ... ...the SDL 1.2 source
> code, ...only

> SDL 2.0 appears to be available.


As it happens, shortly after posting that, I was able to get the SDL 1.2
source package, with the help of someone at the SDL organization.


> It is no longer needed to get that file from SDL sources. It is already
> included in Atari800. I have removed the offending paragraph from
> DOC/BUILD.windows.
>

I probably don't need to mention it, but that file is not present in the
zip I have. There is a folder *src/sdl* containing several *.c *files, but
none by the name (*SDL_win32_main.c*) stated in this zip's copy of
*Build.windows*. The closest matching filename is plain old *main.c*.


> > 2) A bugfix or two mention Colleen, the Android version of Atari800.?
> > The build instructions in the source package don't discuss that at
> > all, though.? How do I go about building that version?

I have just fixed a few bugs today that prevented Colleen from building.
> I have also updated DOC/BUILD.android to make it current. It is now
> possible to build Colleen using these instructions, both on Windows and
> Linux.
>

Thanks for fixing the bugs, but you're way beyond me.  By now you won't be
surprised to hear that there *is no *file *BUILD.android *in my zip, either
in *DOC *or *src/android *for what it's worth.


> Chris, if you need any assistance with building the Android port, I am
> ready to help. If DOC/BUILD.android is not detailed enough, then please
> show me what parts require improvements.
>

Thank you.  I accept your offer!

First, I need to sort out what I need to have, and where to get it.
Basically, what I need are the latest versions of the build tools that
still work on 32-bit XP, the latest version of source code that can be
built with those tools, and the complete set of "just the right versions"
of all the other required libraries, DLLs, etc., to work *with each other, *and
with the chosen versions of the toolchain, on 32-bit XP.  If experience is
any indication, this could be a fairly large challenge, or even impossible,
at this late date.  One *huge *thing you could do to help me would be
to  *provide
me with all of these items, if you have them*.  If you don't have them,
maybe you could at least help me *identify *and *find *them.

On the plus side, I have reason to hope I might have a brand-new, 64-bit,
Windows 10 machine by a little past New Year's...  Being the procrastinator
that I am, it's not entirely impossible that by the time I get around to
actually pursuing any of this, most of the difficulties may have vanished.
I have neither received, nor can make, any promises, though, so let's
proceed as though that *won't *happen, and hope for a pleasant surprise.

One thing that has to happen first, is that I need to confirm (or change)
my opinion that what I want to build *really is *"the SDL version."  How do
DirectX and OpenGL fit in?  How many different executables could I build,
in theory, and still have Windows GUI environment similar to what I'm used
to?  (How do I *even tell *what I *currently have?*)  Please advise.

If it turns out that I can't do some, or all, of this, due to limitations
make the changes I want, due to limitations of technology or intellect,
I'll simply turn over my wishlist to the community and beg those
better-equipped than myself to do them for me!

One prerequisite for doing even that, is to confirm that I "really do" want
"the SDL version," specifically.  I don't actually know.  I don't even know *by
what criteria I would even make the choice.*  The only question that comes
to mind is, "Will there be feature/function/performance differences
depending on what I choose?"  I want something as similar as possible to
what I'm used to, but I don't know what *that *uses; I didn't build it
myself.  Please advise.

Once I have all the tools and prerequisites, I can attempt a build, and
will doubtless have the types of questions you may have been expecting when
you offered to help! ;-)

My long-term goal is to try to make some feature-function enhancements I've
been wishing for (in my head), *if I can.* (Don't worry, though, that some
branch off an obsolete version of the project, or code that isn't
platform-agnostic, or that only works on Windows, will contaminate the
master repository: I have no idea how to do that, even if I wanted to!)  If
it turns out that I'm not up to the challenge, I'll just have to turn over
my wish list to those better qualified.

Thanks again.  I look forward to hearing from, and working with, you.  Be
advised that I work very slowly.

Chris

Re: [Atari800-users] Building Atari800

[Tomasz K. <tom...@in...>]

On 28.08.2020 at 02:30, Chris Chiesa wrote:
> 1) On Windows, I want to build the SDL version for maximum 
> features/functionality.  The build instructions say to extract a file 
> from the SDL 1.2 source code, and give the URL for libsdl.org 
> <http://libsdl.org>. When I go there, though, only SDL 2.0 appears to 
> be available. Where would I get 1.2 source code, in this day and age?  
> Or would 2.0 work too?  I'm on 32-bit XP Pro SP3, at the moment, if 
> that matters.

It is no longer needed to get that file from SDL sources. It is already 
included in Atari800. I have removed the offending paragraph from 
DOC/BUILD.windows.


> 2) A bugfix or two mention Colleen, the Android version of Atari800.  
> The build instructions in the source package don't discuss that at 
> all, though.  How do I go about building that version?
I have just fixed a few bugs today that prevented Colleen from building. 
I have also updated DOC/BUILD.android to make it current. It is now 
possible to build Colleen using these instructions, both on Windows and 
Linux.

Chris, if you need any assistance with building the Android port, I am 
ready to help. If DOC/BUILD.android is not detailed enough, then please 
show me what parts require improvements.

Regards,
-- 
Tomek

Re: [Atari800-users] colors

[Kay S. <ke...@sa...>]

Thanks for the detailed and informative reply, Tomek.

I can't take a photo of my Pole Position cart quite yet. I just moved, and
my Atari isn't set up yet.

For the Atari8BitBot, I ended up with the look I wanted by bumping the
saturation, brightness and contrast way up, so I'd get screenshots that
"pop" for twitter. It may not be perfectly accurate, but it's good for this
use.

COLOURS_NTSC_SATURATION=0.76
COLOURS_NTSC_CONTRAST=0.90
COLOURS_NTSC_BRIGHTNESS=-0.70

-Kay


On Wed, Nov 18, 2020 at 5:47 PM Tomasz Krasuski <tom...@in...>
wrote:

> I'm sorry I'm a bit late to reply, but since I am the person responsible
> for Atari800 colours, I guess I might provide some input here.
>
> 1. Every Atari computer unit produces somewhat different colours. The
> video generation process is analogue in nature. Obtained colours depend on
> adjustment of the colour pot at the bottom of the computer, on the
> adjustments of the TV, and even on the temperature of the chips inside the
> computer. That's why there are many different palette files available.
>
> 2. Palette files were a useful tool to obtain colours the user wanted back
> when we didn't know better (especially as every user wanted slightly
> different colours due to point 1.), but now we have both NTSC and PAL GTIA
> colour generation reverse-engineered, so palettes should be considered
> obsolete.
>
> 3. Atari800MacX is, judging from your screenshot, still being based on
> incorrect colour model from the old Atari800. It still uses the old "black
> level/white level" nomenclature, as you noticed.  Without using palette
> files, it will be impossible to match its output in Atari800.
>
> 4. Though if you use the same palette file in Atari800 and Atari800MacX,
> and disable "Also adjust external palette"  in Atari800 and "Adjust File
> Palette" in Atari800MacX, the display will be 100% identical in both
> emulators. But it's best to avoid palette files in Atari800 altogether,
> because...
>
> 5. The Display Settings menu of Atari800 contain several parameters to
> adjust the display - brightness, contrast, saturation, tint, gamma, and
> GTIA delay (the last one represents the colour pot in the Atari computer).
> They replicate the functionality of the TV adjustments and more, and they
> are meant to allow replicating of every possible colours produced by real
> Atari computers, thus eliminating the need for palette files. We provide
> reasonable default settings though - it's probably best to just use the
> defaults, by selecting the "Color preset -> Standard" setting.
>
> 6. All those settings mentioned in p. 5 are stored separately for NTSC and
> PAL though. If you switch the video system in Atari800, you can adjust the
> setting for that video system independently.
>
> 7. NTSC and PAL GTIAs generate colours differently. The end result is,
> colours on PAL and NTSC are significantly different (you shall notice it
> when you switch System Settings -> Video system). The main difference is,
> the phase shift is different in PAL. Hue #1 is greenish-yellow on NTSC, but
> golden on PAL; other 14 hues are also shifted. That is why you see the
> discrepancy between Atari800 and Atarii800MacX: the Real.act palette was
> created from output of a PAL Atari computer, while you are running Atari800
> with the video system set to NTSC.
>
> 8. You know the reputation of "Never The Same Color". The issue with the
> default NTSC colour preset in Atari800 is, it represents only the output of
> more modern TV sets. If you connect an Atari to a modern LCD TV, you get a
> palette matching the default Atari800 preset. (Except the possible
> difference of brightness, contrast etc.). Same if you output to a CRT
> monitor with correctly-calibrated colours, like the ones they used in TV
> studios. But for some reason, many CRT TV sets sold to the public during
> Atari's heyday (and later, too) displayed significantly different colours -
> in particular hue #1 was more golden. That display can be easily reproduced
> in Atari800 by setting Tint (while having video system set to NTSC) to ca.
> 0.14-0.18. Coincidentally, the resulting NTSC colours become then
> remarkably similar to PAL ones. (This might explains why PAL GTIA colours
> are what they are - when designing PAL GTIA, they probably chose the
> colours to match what they have seen on NTSC, not knowing that their CRT
> monitors were not exactly cailbrated.)
>
> 9. The issue described in p. 8 was already a problem in the early 1980s.
> Different NTSC software was written with different assumptions with regards
> to colours. Let's look at "Pole Position" and "Rescue on Fractalus!" for
> instance. For both titles we have contemporary reference footage - for
> "Pole Position" there is that scene in "D.A.R.Y.L.", and for "Rescue on
> Fractalus!" there is the 1984 Lucasfilm press conference video.
>
> The "Pole Position" cartridge dynamically adjusts its colour palette
> depending on the TV system the Atari computer uses, specifically to address
> the NTSC/PAL differences. It was clearly written under the assumption that
> NTSC hue #1 is greenish-yellow. When run under Atari800 with the Default
> preset, the sky is blue, grass is green, and curbs are red-white. If tint
> is adjusted to 0.14 or beyond, all colours are way off.
>
> "Rescue on Fractalus!" though was written with the assumption that hue #1
> is golden. The mountains, which use hue #1, are supposed to be brown, not
> greenish as displayed on the default hue setting. The sky is also too much
> on the green side. If instead tint is adjusted to 0.14 (and saturation is
> overriden way up to 1.0), the mountains, the sky and other colours match
> the 1984 footage much more closely (though not ideally - an old VCR tape
> introduces its own colour issues).
>
> So, to sum it up - just adjust NTSC tint to 0.14 or a bit more, and
> Atari800 should match your real TV's output much closer. Have in mind
> though, that some software will then look worse. Could you run "Pole
> Position" on your real TV and tell us what colours you see?
>
> Best regards
> --
> Tomek
> On 16.10.2020 at 00:46, Kay Savetz wrote:
>
> Thanks. I'll try this.
>
> -K
>
> On Thu, Oct 15, 2020 at 6:42 AM Cliff Hatch via Atari800-users <
> ata...@li...> wrote:
>
>> I don't have any experience of Atari800MacX, but I get good colour
>> reproduction with Atari800 on Linux using the default video settings:
>>
>> COLOURS_NTSC_SATURATION=0
>> COLOURS_NTSC_CONTRAST=0
>> COLOURS_NTSC_BRIGHTNESS=0
>> COLOURS_NTSC_GAMMA=2.35
>> COLOURS_NTSC_HUE=0
>> COLOURS_NTSC_GTIA_DELAY=26.8
>> COLOURS_NTSC_EXTERNAL_PALETTE=
>> COLOURS_NTSC_EXTERNAL_PALETTE_LOADED=0
>> COLOURS_NTSC_ADJUST_EXTERNAL_PALETTE=0
>>
>> I tried changing to your saturation, contrast, brightness and gamma
>> settings.  This had a small effect only - the display still looked good.
>>
>> However, loading the Real.act palette gave me very distorted colours,
>> similar to those you have seen.
>>
>> I don't know the history of the external palettes.  The only one that
>> gives me reasonable results is XFormer.act, but even it is not great - a
>> little too bright.  Strangely, the one called default.act produces similar
>> distortion to Real.act (so I guess there must be a default internal palette
>> that is different to the external one).
>>
>> The best settings I can find are the above defaults, with no external
>> palette loaded.
>>
>> Best Regards
>>
>> Cliff
>> On 14/10/2020 16:33, Kay Savetz wrote:
>>
>> Because the way the settings work on the two systems are completely
>> different. I don't know how to make them the same.
>>
>> I've figured out that I can set COLOURS_NTSC_EXTERNAL_PALETTE to
>> Real.act, which is a start. But the colors still don't match, and the
>> terminology between the linux config file and the Mac preferences is
>> different enough that I don't know what to change. (e.g. Saturation,
>> Contrast vs. Black Level, Intensity.)
>>
>> On linux:
>>
>> COLOURS_NTSC_SATURATION=0.26
>> COLOURS_NTSC_CONTRAST=0.72
>> COLOURS_NTSC_BRIGHTNESS=-0.16
>> COLOURS_NTSC_GAMMA=2
>> COLOURS_NTSC_HUE=0
>> COLOURS_NTSC_GTIA_DELAY=26.8
>> COLOURS_NTSC_EXTERNAL_PALETTE=Real.act
>> COLOURS_NTSC_EXTERNAL_PALETTE_LOADED=1
>> COLOURS_NTSC_ADJUST_EXTERNAL_PALETTE=1
>>
>> On Mac:
>>
>> [image: Screenshot 2020-10-14 at 8.07.19 AM.jpg]
>>
>>
>>
>>
>> On Wed, Oct 14, 2020 at 12:09 AM Miro Kropáček <mir...@gm...>
>> wrote:
>>
>>> Are you sure you are using the same palette and/or NTSC/PAL settings?
>>>
>>> On Wed, 14 Oct 2020 at 06:12, Kay Savetz <ke...@sa...> wrote:
>>>
>>>> Hi Atari800 people,
>>>>
>>>> Today I made a little program on Atari800MacX, then copied it to
>>>> @Atari8bitBot on Twitter, which uses atari800 on linux. I noticed that the
>>>> colors are very different. Frankly, I like the Mac colors better (and I
>>>> think they are more accurate to my real Atari.)
>>>>
>>>> Atari800MacX has many color palette options. I use Real.act, which I
>>>> think is the default.
>>>>
>>>> Can someone suggest settings for the Linux atari800.cfg to make the
>>>> colors better?
>>>>
>>>> Thanks
>>>> Kay
>>>>
>>>> [image: Screenshot 2020-10-13 at 8.59.22 PM.jpg]
>>>>
>>>>
>>>> _______________________________________________
>>>> Atari800-users mailing list
>>>> Ata...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/atari800-users
>>>>
>>>
>>>
>>> --
>>> http://mikro.atari.org
>>>
>>>
>>> _______________________________________________
>>> Atari800-users mailing list
>>> Ata...@li...
>>> https://lists.sourceforge.net/lists/listinfo/atari800-users
>>>
>>
>>
>> _______________________________________________
>> Atari800-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/atari800-users
>>
>>
>>
>> _______________________________________________
>> Atari800-users mailing list
>> Ata...@li...
>> https://lists.sourceforge.net/lists/listinfo/atari800-users
>>
>
>
> _______________________________________________
> Atari800-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/atari800-users
>
>
>
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users
>

Re: [Atari800-users] colors

[Tomasz K. <tom...@in...>]

I'm sorry I'm a bit late to reply, but since I am the person responsible 
for Atari800 colours, I guess I might provide some input here.

1. Every Atari computer unit produces somewhat different colours. The 
video generation process is analogue in nature. Obtained colours depend 
on adjustment of the colour pot at the bottom of the computer, on the 
adjustments of the TV, and even on the temperature of the chips inside 
the computer. That's why there are many different palette files available.

2. Palette files were a useful tool to obtain colours the user wanted 
back when we didn't know better (especially as every user wanted 
slightly different colours due to point 1.), but now we have both NTSC 
and PAL GTIA colour generation reverse-engineered, so palettes should be 
considered obsolete.

3. Atari800MacX is, judging from your screenshot, still being based on 
incorrect colour model from the old Atari800. It still uses the old 
"black level/white level" nomenclature, as you noticed.  Without using 
palette files, it will be impossible to match its output in Atari800.

4. Though if you use the same palette file in Atari800 and Atari800MacX, 
and disable "Also adjust external palette"  in Atari800 and "Adjust File 
Palette" in Atari800MacX, the display will be 100% identical in both 
emulators. But it's best to avoid palette files in Atari800 altogether, 
because...

5. The Display Settings menu of Atari800 contain several parameters to 
adjust the display - brightness, contrast, saturation, tint, gamma, and 
GTIA delay (the last one represents the colour pot in the Atari 
computer). They replicate the functionality of the TV adjustments and 
more, and they are meant to allow replicating of every possible colours 
produced by real Atari computers, thus eliminating the need for palette 
files. We provide reasonable default settings though - it's probably 
best to just use the defaults, by selecting the "Color preset -> 
Standard" setting.

6. All those settings mentioned in p. 5 are stored separately for NTSC 
and PAL though. If you switch the video system in Atari800, you can 
adjust the setting for that video system independently.

7. NTSC and PAL GTIAs generate colours differently. The end result is, 
colours on PAL and NTSC are significantly different (you shall notice it 
when you switch System Settings -> Video system). The main difference 
is, the phase shift is different in PAL. Hue #1 is greenish-yellow on 
NTSC, but golden on PAL; other 14 hues are also shifted. That is why you 
see the discrepancy between Atari800 and Atarii800MacX: the Real.act 
palette was created from output of a PAL Atari computer, while you are 
running Atari800 with the video system set to NTSC.

8. You know the reputation of "Never The Same Color". The issue with the 
default NTSC colour preset in Atari800 is, it represents only the output 
of more modern TV sets. If you connect an Atari to a modern LCD TV, you 
get a palette matching the default Atari800 preset. (Except the possible 
difference of brightness, contrast etc.). Same if you output to a CRT 
monitor with correctly-calibrated colours, like the ones they used in TV 
studios. But for some reason, many CRT TV sets sold to the public during 
Atari's heyday (and later, too) displayed significantly different 
colours - in particular hue #1 was more golden. That display can be 
easily reproduced in Atari800 by setting Tint (while having video system 
set to NTSC) to ca. 0.14-0.18. Coincidentally, the resulting NTSC 
colours become then remarkably similar to PAL ones. (This might explains 
why PAL GTIA colours are what they are - when designing PAL GTIA, they 
probably chose the colours to match what they have seen on NTSC, not 
knowing that their CRT monitors were not exactly cailbrated.)

9. The issue described in p. 8 was already a problem in the early 1980s. 
Different NTSC software was written with different assumptions with 
regards to colours. Let's look at "Pole Position" and "Rescue on 
Fractalus!" for instance. For both titles we have contemporary reference 
footage - for "Pole Position" there is that scene in "D.A.R.Y.L.", and 
for "Rescue on Fractalus!" there is the 1984 Lucasfilm press conference 
video.

The "Pole Position" cartridge dynamically adjusts its colour palette 
depending on the TV system the Atari computer uses, specifically to 
address the NTSC/PAL differences. It was clearly written under the 
assumption that NTSC hue #1 is greenish-yellow. When run under Atari800 
with the Default preset, the sky is blue, grass is green, and curbs are 
red-white. If tint is adjusted to 0.14 or beyond, all colours are way off.

"Rescue on Fractalus!" though was written with the assumption that hue 
#1 is golden. The mountains, which use hue #1, are supposed to be brown, 
not greenish as displayed on the default hue setting. The sky is also 
too much on the green side. If instead tint is adjusted to 0.14 (and 
saturation is overriden way up to 1.0), the mountains, the sky and other 
colours match the 1984 footage much more closely (though not ideally - 
an old VCR tape introduces its own colour issues).

So, to sum it up - just adjust NTSC tint to 0.14 or a bit more, and 
Atari800 should match your real TV's output much closer. Have in mind 
though, that some software will then look worse. Could you run "Pole 
Position" on your real TV and tell us what colours you see?

Best regards
-- 
Tomek

On 16.10.2020 at 00:46, Kay Savetz wrote:
> Thanks. I'll try this.
>
> -K
>
> On Thu, Oct 15, 2020 at 6:42 AM Cliff Hatch via Atari800-users 
> <ata...@li... 
> <mailto:ata...@li...>> wrote:
>
>     I don't have any experience of Atari800MacX, but I get good colour
>     reproduction with Atari800 on Linux using the default video settings:
>
>     COLOURS_NTSC_SATURATION=0
>     COLOURS_NTSC_CONTRAST=0
>     COLOURS_NTSC_BRIGHTNESS=0
>     COLOURS_NTSC_GAMMA=2.35
>     COLOURS_NTSC_HUE=0
>     COLOURS_NTSC_GTIA_DELAY=26.8
>     COLOURS_NTSC_EXTERNAL_PALETTE=
>     COLOURS_NTSC_EXTERNAL_PALETTE_LOADED=0
>     COLOURS_NTSC_ADJUST_EXTERNAL_PALETTE=0
>
>     I tried changing to your saturation, contrast, brightness and
>     gamma settings.  This had a small effect only - the display still
>     looked good.
>
>     However, loading the Real.act palette gave me very distorted
>     colours, similar to those you have seen.
>
>     I don't know the history of the external palettes.  The only one
>     that gives me reasonable results is XFormer.act, but even it is
>     not great - a little too bright. Strangely, the one called
>     default.act produces similar distortion to Real.act (so I guess
>     there must be a default internal palette that is different to the
>     external one).
>
>     The best settings I can find are the above defaults, with no
>     external palette loaded.
>
>     Best Regards
>
>     Cliff
>
>     On 14/10/2020 16:33, Kay Savetz wrote:
>>     Because the way the settings work on the two systems are
>>     completely different. I don't know how to make them the same.
>>
>>     I've figured out that I can set COLOURS_NTSC_EXTERNAL_PALETTE to
>>     Real.act, which is a start. But the colors still don't match, and
>>     the terminology between the linux config file and the Mac
>>     preferences is different enough that I don't know what to change.
>>     (e.g. Saturation, Contrast vs. Black Level, Intensity.)
>>
>>     On linux:
>>
>>     COLOURS_NTSC_SATURATION=0.26
>>     COLOURS_NTSC_CONTRAST=0.72
>>     COLOURS_NTSC_BRIGHTNESS=-0.16
>>     COLOURS_NTSC_GAMMA=2
>>     COLOURS_NTSC_HUE=0
>>     COLOURS_NTSC_GTIA_DELAY=26.8
>>     COLOURS_NTSC_EXTERNAL_PALETTE=Real.act
>>     COLOURS_NTSC_EXTERNAL_PALETTE_LOADED=1
>>     COLOURS_NTSC_ADJUST_EXTERNAL_PALETTE=1
>>
>>     On Mac:
>>
>>     Screenshot 2020-10-14 at 8.07.19 AM.jpg
>>
>>
>>
>>
>>     On Wed, Oct 14, 2020 at 12:09 AM Miro Kropáček
>>     <mir...@gm... <mailto:mir...@gm...>> wrote:
>>
>>         Are you sure you are using the same palette and/or NTSC/PAL
>>         settings?
>>
>>         On Wed, 14 Oct 2020 at 06:12, Kay Savetz <ke...@sa...
>>         <mailto:ke...@sa...>> wrote:
>>
>>             Hi Atari800 people,
>>
>>             Today I made a little program on Atari800MacX, then
>>             copied it to @Atari8bitBot on Twitter, which uses
>>             atari800 on linux. I noticed that the colors are very
>>             different. Frankly, I like the Mac colors better (and I
>>             think they are more accurate to my real Atari.)
>>
>>             Atari800MacX has many color palette options. I use
>>             Real.act, which I think is the default.
>>
>>             Can someone suggest settings for the Linux atari800.cfg
>>             to make the colors better?
>>
>>             Thanks
>>             Kay
>>
>>             Screenshot 2020-10-13 at 8.59.22 PM.jpg
>>
>>
>>             _______________________________________________
>>             Atari800-users mailing list
>>             Ata...@li...
>>             <mailto:Ata...@li...>
>>             https://lists.sourceforge.net/lists/listinfo/atari800-users
>>             <https://lists.sourceforge.net/lists/listinfo/atari800-users>
>>
>>
>>
>>         -- 
>>         http://mikro.atari.org <http://mikro.atari.org>
>>
>>
>>         _______________________________________________
>>         Atari800-users mailing list
>>         Ata...@li...
>>         <mailto:Ata...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/atari800-users
>>         <https://lists.sourceforge.net/lists/listinfo/atari800-users>
>>
>>
>>
>>     _______________________________________________
>>     Atari800-users mailing list
>>     Ata...@li...  <mailto:Ata...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/atari800-users  <https://lists.sourceforge.net/lists/listinfo/atari800-users>
>
>
>     _______________________________________________
>     Atari800-users mailing list
>     Ata...@li...
>     <mailto:Ata...@li...>
>     https://lists.sourceforge.net/lists/listinfo/atari800-users
>     <https://lists.sourceforge.net/lists/listinfo/atari800-users>
>
>
>
>
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Atari800-users Digest, Vol 107, Issue 3

[Chris C. <chr...@gm...>]

On Wed, Oct 14, 2020 at 11:33 AM <
ata...@li...> wrote:

>
> Message: 1
> Date: Wed, 14 Oct 2020 08:33:16 -0700
> From: Kay Savetz <ke...@sa...>
> To: ata...@li...
> Subject: Re: [Atari800-users] colors
> Message-ID:
>         <CAJAWWXqrukkJ9H2=
> EFZ...@ma...>
> Content-Type: text/plain; charset="utf-8"
>
> Because the way the settings work on the two systems are completely
> different. I don't know how to make them the same.
>

I am a deep-diving engineer, so the following may be "a bit too much" by
some people's standards, but bear with me...

Clearly, at some time someone figured out -- dare I say
"reverse-engineered?" possibly-suffcient specs seem to appear in the Atari
Hardware Manual) -- how CTIA and GTIA generated colors, in order to create
a reasonable/proper palette for Atari800 in the first place.  Could the
same process simply be revisited to select appropriate RGB equivalents
for *whatever
*platform on which one finds oneself?  I confess that, this process
presumably having been done once, "in the beginning," it's not clear to me
why we find ourselves needing to tweak it.

Chris