atari800-users — Atari800 users

[Atari800-users] Serial I/O (Was: Re: Removal of win32 (directx backend, not to be confused with SDL one))

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

On Mon, 22 Apr 2024 at 18:30, Miro Kropáček <mir...@gm...> wrote:

> On Mon, 22 Apr 2024 at 14:25, bebing--- via Atari800-users <
> ata...@li...> wrote:
>
>> The loading beeps don't really sound like beeps any more and the
>> "farting" SIO sounds sound very tinny, trebly, or thin.
>>
> Indeed! I have just discovered the same thing:
> https://github.com/atari800/atari800/issues/229#issuecomment-2068163115.
> I'll try to investigate where our beloved beep-beep-beep loading sound
> went.
>
As mentioned in the issue #229, I have taken a look. Most likely my memory
has been fooling me, I went through 1.3.6 - 5.2.0 and all I can say is that
the sound I/O was gradually getting better, not worse.

Of course, it is far away from what real hardware (and Altirra) sounds
like. But if you have some specific builds to point out where you feel the
sound was better, please do so.

Anyway, this investigation also uncovered that the serial i/o sound is
indeed included in the synchronized sound "framework", i.e. the switch
doesn't have any meaning anymore for those platforms using synchronized
sound.

I'm very much inclined to kick the volume only + serial i/o stuff out but
the DC and WinCE ports still use volumy only and not synchronized sound...
so that extended the question whether we want to:
- keep everything as is
- kick out volume only+serial i/o and leave dc/wince ports as is
- kick out also dc/wince along the way

Opinions?

-- 
http://mikro.atari.org

Re: [Atari800-users] Removal of win32 (directx backend, not to be confused with SDL one)

[Daniel S. <dse...@gm...>]

Hi!

On Mon, Apr 22, 2024 at 09:39:51AM +0200, zy...@po... wrote:
> 
> Hello,
> 

[snip]

> 
> When I am thinking of the current "market" with the emulators, I see the 
> following (this is, of course, subjective).
> 
> 
> Retro-Developers
> 
> I would say, this piece of market is dominated by Altirra, because of the 
> emulation accuracy, very capable debugging tools, and native GUI.
> 
> I don't believe atari800 can compete here, not now, not in the future.

I disagree :)

I consider myself a retro-developer, and I use atari800 over Altirra the
majority of the time - it is faster to startup, easier to use from
command line and easier to automate for testing. I only launch Altirra
to do final testing before releases and to solve problems difficult to
debug with the limited atari800 debugger.


Have Fun!

Re: [Atari800-users] Removal of win32 (directx backend, not to be confused with SDL one)

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

On Mon, 22 Apr 2024 at 14:25, bebing--- via Atari800-users <
ata...@li...> wrote:

> The loading beeps don't really sound like beeps any more and the "farting"
> SIO sounds sound very tinny, trebly, or thin.
>
Indeed! I have just discovered the same thing:
https://github.com/atari800/atari800/issues/229#issuecomment-2068163115.
I'll try to investigate where our beloved beep-beep-beep loading sound
went.

I'm not a fan of Altirra. I tried it once via wine and did not like it.

I guess it boils down to what one is accustomed to. I rarely use emulators
as I own real hardware and love using it so I had missed the whole Altirra
wave and how it took over Atari800's "market". However to be fair, Altirra
not only emulates correctly every obscure thing you throw at it but
additionally, Avery Lee (its author) has written an amazing Hardware guide
about all possible quirks you can imagine *and* occasionally
contributes with his knowledge to concrete Atari800 issues. So I'm really
grateful for Altirra and his author, no hard feelings whatsoever.

-- 
http://mikro.atari.org

Re: [Atari800-users] Removal of win32 (directx backend, not to be confused with SDL one)

[<be...@em...>]

Just chiming in to say I agree with this. I have to use xboxdrv to force the use of the joypad on my ps3 controller, otherwise it will use the analog nub. Also, at one point, the sounds from SIO activities changed. The loading beeps don't really sound like beeps any more and the "farting" SIO sounds sound very tinny, trebly, or thin.

Otherwise it's perfect! Been using it for thirty years or whatever. I'm not a fan of Altirra. I tried it once via wine and did not like it.



On Mon, 22 Apr 2024 09:39:51 +0200 (CEST)
<zy...@po...> wrote:

>
> Hello,
>
>
>
>
>
>
> the discussion related to removal of outdated or non-maintained backends
> somehow provoked
>
>
>
> me to think about the future direction of the atari800 emulator, namely
> choice of the future
>
> features and enhancements.
>
>
>
>
> When I am thinking of the current "market" with the emulators, I see the
> following (this is, of course, subjective).
>
>
>
>
> Retro-Developers
>
> I would say, this piece of market is dominated by Altirra, because of the
> emulation accuracy, very capable debugging tools, and native GUI.
>
> I don't believe atari800 can compete here, not now, not in the future.
>
>
>
>
> Windows Retro Gamers
>
> I would also say that this market is taken. Both by Altirra and the most
> recent versions of XFormer. Of course, since SDL has decent support for
> Windows,
>
> there is no reason to give the Windows-SDL port up. However, we have no
> reasons to believe that there is a high demand for win32 binaries of atari
> 800.
>
> Not sure what the download statistics would say.
>
>
>
>
> Non-Windows Retro Gamers.
>
> This is where atari800 has minimum or no competition and can excel, and in
> my opinion this is where the functions of the emulator should expand mostly.
>
>
> What is lacking (and that topic was discussed before) is good support for
> non-keyboard controllers (gamepads, joysticks etc.) and good ability to map
> non-keyboard controllers to both joystick and non-joystick input. Also, the
> main menu of the emulator doesn't appear to be simple to use.
>
>
>
>
> That is not easy. The way I see it, the following would be needed.
>
> - Cut off targets that are no longer viable.
>
> - Keep the pace with the developments in SDL. Consider supporting targets
> such as sdl12, sdl12-compat, and SDL2.
>
> - Rethink how controls work in the emulator. Perhaps introduce a layer of
> virtual emulator controls, where one or more physical controls could be
> mapped to the virtual controls. This would allow mappings such as map JS
> button 4 and F1 both to the ENTER_MENU emulator virtual control, etc.
>
> - Rethink the structure of the main menu to be more friendly for gamers.
>
>
>
>
> I know, a lot of words....
>
>
>
>
> Michael
>
>
>
>
>
>

Re: [Atari800-users] Removal of win32 (directx backend, not to be confused with SDL one)

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

On Mon, 22 Apr 2024 at 10:31, Eric Sokolowsky <es...@gm...> wrote:

> I still use atari800 on Linux to play games. I'd love to see atx file
> support.
>
What exactly is missing? I have just fixed one ATX bug
<https://github.com/atari800/atari800/issues/218>, so I was testing an ATX
image just this weekend.


-- 
http://mikro.atari.org

Re: [Atari800-users] Removal of win32 (directx backend, not to be confused with SDL one)

[Eric S. <es...@gm...>]

I still use atari800 on Linux to play games. I'd love to see atx file
support.

Eric

On Mon, Apr 22, 2024 at 4:25 AM Miro Kropáček <mir...@gm...>
wrote:

> On Mon, 22 Apr 2024 at 09:41, <zy...@po...> wrote:
>
>> When I am thinking of the current "market" with the emulators, I see the
>> following (this is, of course, subjective).
>>
> I basically agree with your assessment, however there's yet one more
> group:  Non-Windows Retro Gamers on Retro Hardware. This includes all the
> Amiga, DC, Atari Falcon/TT/FireBee, WinCE etc ports.
>
> In my eyes, this is one of Atari800's strengths -- it still runs nicely on
> machines with clock rate below 100 MHz, if one doesn't insist on having all
> the fancy features enabled. For example FireBee users are really happy
> because their ColdFire (somewhat) Atari compatible machine got heaps of
> games to play thanks to Atari800.
>
> Then of course the interesting question is how many of these ports are
> still alive / maintained and I fear that except for my effort all of them
> are dead (see my callout in the other email). Also, the argument "Why can't
> we use their SDL forks?" is very valid. In the Atari Falcon/TT/FireBee case
> the answer is still performance (this definitely applies to sound
> processing but also to screen handling to some extent).
>
> So what I would like to do is to continuously make efforts towards merging
> Falcon and SDL backends, basically do what Petr mentioned earlier: as soon
> as some Atari800 backend has decent SDL support, drop it in favour of SDL.
>
> --
> http://mikro.atari.org
>
>
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users
>

Re: [Atari800-users] Removal of win32 (directx backend, not to be confused with SDL one)

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

On Mon, 22 Apr 2024 at 09:41, <zy...@po...> wrote:

> When I am thinking of the current "market" with the emulators, I see the
> following (this is, of course, subjective).
>
I basically agree with your assessment, however there's yet one more
group:  Non-Windows Retro Gamers on Retro Hardware. This includes all the
Amiga, DC, Atari Falcon/TT/FireBee, WinCE etc ports.

In my eyes, this is one of Atari800's strengths -- it still runs nicely on
machines with clock rate below 100 MHz, if one doesn't insist on having all
the fancy features enabled. For example FireBee users are really happy
because their ColdFire (somewhat) Atari compatible machine got heaps of
games to play thanks to Atari800.

Then of course the interesting question is how many of these ports are
still alive / maintained and I fear that except for my effort all of them
are dead (see my callout in the other email). Also, the argument "Why can't
we use their SDL forks?" is very valid. In the Atari Falcon/TT/FireBee case
the answer is still performance (this definitely applies to sound
processing but also to screen handling to some extent).

So what I would like to do is to continuously make efforts towards merging
Falcon and SDL backends, basically do what Petr mentioned earlier: as soon
as some Atari800 backend has decent SDL support, drop it in favour of SDL.

-- 
http://mikro.atari.org

Re: [Atari800-users] Removal of win32 (directx backend, not to be confused with SDL one)

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

On Po, 2024-04-22 at 09:39 +0200, zy...@po... wrote:
> That is not easy. The way I see it, the following would be needed.
> - Cut off targets that are no longer viable.

not really needed (unless they block the future development)

> - Keep the pace with the developments in SDL. Consider supporting
> targets such as sdl12, sdl12-compat, and SDL2.

this is being worked on and might be part of the nearest release.

> - Rethink how controls work in the emulator. Perhaps introduce a
> layer of virtual emulator controls, where one or more physical
> controls could be mapped to the virtual controls. This would allow
> mappings such as map JS button 4 and F1 both to the ENTER_MENU
> emulator virtual control, etc.

I believe we've got this improved recently as well. I (finally)
understand why it is important so if it's not there yet I'd support it
myself.

> - Rethink the structure of the main menu to be more friendly for
> gamers.

Yes, the menu should be improved somehow. Currently there's a mix of
actions (like "screenshot" and settings ("define joystick") that should
be separated probably at the top-most level. Also the menu nesting does
not make sense (to me, anyway) in some cases (saving of changes in a
sub-menu??). I am all for making it simpler and more clear, if
possible.

Petr

Re: [Atari800-users] Removal of win32 (directx backend, not to be confused with SDL one)

[<zy...@po...>]

Hello,






the discussion related to removal of outdated or non-maintained backends 
somehow provoked



me to think about the future direction of the atari800 emulator, namely 
choice of the future

features and enhancements.




When I am thinking of the current "market" with the emulators, I see the 
following (this is, of course, subjective).




Retro-Developers

I would say, this piece of market is dominated by Altirra, because of the 
emulation accuracy, very capable debugging tools, and native GUI.

I don't believe atari800 can compete here, not now, not in the future.




Windows Retro Gamers

I would also say that this market is taken. Both by Altirra and the most 
recent versions of XFormer. Of course, since SDL has decent support for 
Windows,

there is no reason to give the Windows-SDL port up. However, we have no 
reasons to believe that there is a high demand for win32 binaries of atari
800.

Not sure what the download statistics would say.




Non-Windows Retro Gamers.

This is where atari800 has minimum or no competition and can excel, and in 
my opinion this is where the functions of the emulator should expand mostly.


What is lacking (and that topic was discussed before) is good support for 
non-keyboard controllers (gamepads, joysticks etc.) and good ability to map 
non-keyboard controllers to both joystick and non-joystick input. Also, the 
main menu of the emulator doesn't appear to be simple to use.




That is not easy. The way I see it, the following would be needed.

- Cut off targets that are no longer viable.

- Keep the pace with the developments in SDL. Consider supporting targets 
such as sdl12, sdl12-compat, and SDL2.

- Rethink how controls work in the emulator. Perhaps introduce a layer of 
virtual emulator controls, where one or more physical controls could be 
mapped to the virtual controls. This would allow mappings such as map JS 
button 4 and F1 both to the ENTER_MENU emulator virtual control, etc.

- Rethink the structure of the main menu to be more friendly for gamers.




I know, a lot of words....




Michael

Re: [Atari800-users] DOC/PortMaintainers - give us a life sign! :)

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

On Ne, 2024-04-21 at 11:52 -0500, Steve Boswell wrote:
> Seems a bit redundant given that DOC/CREDITS exists

DOC/CREDITS = contributors (sometimes even from a century ago)

DOC/PortMaintainers = current leaders of the porting efforts, having
kind of responsibility that the given OS/HW is well supported by
Atari800

With libSDL this is far less important because SDL allows us to have a
single source code that builds and runs on many platforms without any
changes.

Petr

> 
> 
> > On Apr 21, 2024, at 11:11 AM, Miro Kropáček
> > <mir...@gm...> wrote:
> > 
> > Hi,
> > 
> > I have just noticed that there's this file in our tree, most likely
> > hugely out of date. Even me, who has taken over the Atari Falcon/TT
> > port for a long time, hasn't noticed it until now.
> > 
> > Whoever is reading this message, can you take a look and let me
> > know whether you should or shouldn't be listed there? (or better
> > yet, if you access rights, update the file by yourself)
> > 
> > Thanks.
> > 
> > -- 
> > http://mikro.atari.org
> > 
> > 
> > _______________________________________________
> > 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] Removal of win32 (directx backend, not to be confused with SDL one)

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

Pushed.

I have noticed that win32/sound.c was still used by the "win" sound backend
(i.e. one had host=win, gfx=sdl and sound=win) which was for some reason
forced on my MSYS2 setup no matter what (./configure, ./configure
--with-sound=sdl, ...).

After cleaning up configure.ac and rebuilding everything I'm happy to
report that the SDL sound backend works equally well and most importantly
it is now set by default.

So whoever is going to package win32 (sdl) build, please keep in mind:

   - there's no reason to build it as 32-bit anymore (are there any 32-bit
   Win9x/XP users?)
   - there's no reason not to use sdl12-compat instead of SDL package
   (unless the previous point is not true?)
   - sound is now set by ./configure to "sdl", i.e. using the ThinAPI,
   synchronized sound etc
   - keyboard buffer issue with SDL_VIDEODRIVER=directx had actually been
   worked around: unless overridden, SDL on Windows uses
   SDL_VIDEODRIVER="directx" for fullscreen drawing and the default (I presume
   windib, Win32 GDI) when windowed.

At least that's how I understand things, feel free to correct me if I'm
wrong.

On Sun, 21 Apr 2024 at 17:30, Petr Stehlík <pst...@so...> wrote:

> Hi,
>
> I would say that OS/HW specific ports of Atari800 could/should be
> removed once the SDL version for that particular OS/HW works well
> enough. IOW, remove the win32 right away.
>
> Petr
>
>
> On Ne, 2024-04-21 at 01:31 +0200, Miro Kropáček wrote:
> > Hi,
> >
> > I'm wondering, is there any point in keeping the "win32" folder? The
> > last windx build was published (nearly exactly) 13 years ago in
> > 2.2.1. 3.0.0 and newer are provided with winsdl builds only (and
> > these should be compiled against sdl2 + sdl12-compat in the future,
> > see
> > https://github.com/atari800/atari800/issues/188#issuecomment-2067809989
> > ).
> >
> > Of course, there's more like amiga, dc, dos, wince, ... but since
> > falcon was lying dormant for about 9 years, I'll give them the
> > benefit of the doubt. But win32 is really pointless to have these
> > days.
> >
> > Anyone against removal?
> >
> > --
> > http://mikro.atari.org
> >
> >
> > _______________________________________________
> > 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
>


-- 
http://mikro.atari.org

Re: [Atari800-users] DOC/PortMaintainers - give us a life sign! :)

[Steve B. <st...@at...>]

Seems a bit redundant given that DOC/CREDITS exists


> On Apr 21, 2024, at 11:11 AM, Miro Kropáček <mir...@gm...> wrote:
> 
> Hi,
> 
> I have just noticed that there's this file in our tree, most likely hugely out of date. Even me, who has taken over the Atari Falcon/TT port for a long time, hasn't noticed it until now.
> 
> Whoever is reading this message, can you take a look and let me know whether you should or shouldn't be listed there? (or better yet, if you access rights, update the file by yourself)
> 
> Thanks.
> 
> --
> http://mikro.atari.org <http://mikro.atari.org/>
> 
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

[Atari800-users] DOC/PortMaintainers - give us a life sign! :)

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

Hi,

I have just noticed that there's this file in our tree, most likely hugely
out of date. Even me, who has taken over the Atari Falcon/TT port for a
long time, hasn't noticed it until now.

Whoever is reading this message, can you take a look and let me know
whether you should or shouldn't be listed there? (or better yet, if you
access rights, update the file by yourself)

Thanks.

-- 
http://mikro.atari.org

Re: [Atari800-users] Removal of win32 (directx backend, not to be confused with SDL one)

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

Hi,

I would say that OS/HW specific ports of Atari800 could/should be
removed once the SDL version for that particular OS/HW works well
enough. IOW, remove the win32 right away.

Petr


On Ne, 2024-04-21 at 01:31 +0200, Miro Kropáček wrote:
> Hi,
> 
> I'm wondering, is there any point in keeping the "win32" folder? The
> last windx build was published (nearly exactly) 13 years ago in
> 2.2.1. 3.0.0 and newer are provided with winsdl builds only (and
> these should be compiled against sdl2 + sdl12-compat in the future,
> see
> https://github.com/atari800/atari800/issues/188#issuecomment-2067809989
> ).
> 
> Of course, there's more like amiga, dc, dos, wince, ... but since
> falcon was lying dormant for about 9 years, I'll give them the
> benefit of the doubt. But win32 is really pointless to have these
> days.
> 
> Anyone against removal?
> 
> -- 
> http://mikro.atari.org
> 
> 
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

[Atari800-users] Removal of win32 (directx backend, not to be confused with SDL one)

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

Hi,

I'm wondering, is there any point in keeping the "win32" folder? The last
windx build was published (nearly exactly) 13 years ago in 2.2.1. 3.0.0 and
newer are provided with winsdl builds only (and these should be compiled
against sdl2 + sdl12-compat in the future, see
https://github.com/atari800/atari800/issues/188#issuecomment-2067809989).

Of course, there's more like amiga, dc, dos, wince, ... but since falcon
was lying dormant for about 9 years, I'll give them the benefit of the
doubt. But win32 is really pointless to have these days.

Anyone against removal?

-- 
http://mikro.atari.org

[Atari800-users] 5.2.0 release

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

Hi all,

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

please send me binaries for platforms you master.

Thanks,

Petr

[Atari800-users] 5.1.0 release

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

Hi all,

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

Enjoy,

Petr

[Atari800-users] Why FujiNet + Atari800? -- Was re: Adding FujiNet Support to Atari800

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

On Thu, Aug 17, 2023 at 04:13:09PM +0200, Petr Stehl�k wrote:
> On Čt, 2023-08-17 at 16:09 +0200, Miro Kropáček wrote:
> > On Thu, 17 Aug 2023 at 00:37, Thom Cherryhomes <
> > tho...@gm...> wrote:
> > > "What can I do to help bring FujiNet to the Atari800 Emulator?"
> > > 
> > 
> > To put it shortly: provide a patch. :) 
> 
> It would be great to help others understand what FujiNet is and how it
> could be useful to Atari800 users.

I'm a huge fan of FujiNet, though I lack enough time or energy to
do a lot with it right now.  (That said, I HAVE done a few things;
see below!)  So I'll take a moment to be a cheerleader ;)


FujiNet is a hardware device for Atari 8-bits that connects via the
SIO port and simulates a number of typical Atari devices, such as
disk drives (D:), cassette (C:), printer (P:), modem (R:), clock (like
R-Time8 or APETime), and also provides some quite atypical things,
such as a CP/M system you can connect to (I suppose like an ATR8000;
I have no experience), S.A.M. speech synthesis (send the text strings
over SIO, and the audio comes back via SIO, similar to how you can hear
audio via Atari cassette drives).

The disk drive emulation works in two ways.  First is the fairly common
method: access ATR disk image files (as well as executable binaries;
in modern days people often name them XEX) off of a microSD card
(similar to SIO2SD, SDrive, and similar).  Second is accessing such files
over the internet.  People run special server software (TNFS; it was born
in the ZX Spectrum community) that hosts files, and the Atari, via a
FujiNet device, can browse them and mount those remote files onto their
virtual disk drives.  As you hear the SIO beeps while something loads,
appreciate the fact those disk sectors are travelling vast distances
across the globe!

(You can, of course, have a combination of disk images on your local
SD card, and disk images on one or more remove TNFS servers, mounted
on the virtual D1: thru D8: drives.  And, since FujiNet has an SIO
pass-thru port, you can have local drives, be they real -- 1050, XF551,
etc. -- or virtual -- SIO2SD, SIO2PC, APE, SDrive, etc. -- connected, too.)


To me, most importantly, the FujiNet offers a new kind of device, the
N: network device.  This allows the Atari to connect to remote systems
via a variety of protocols, including HTTP & HTTPS, FTP, SMB, etc.
For example, you can do something like:

  OPEN #1,4,0,"N:HTTPS://GOOGLE.COM/"

and then use GET #1... or INPUT #1... to read the results.
(As a VERY simple example.)

Personally, I used this functionality, combined with small web
application I wrote (in *cough* PHP), to fetch and display the
current NASA Astronomy Photo of the Day (APOD) right on the Atari.
(So if one launches the program today, for example, and hits the
[F] key, you'll see an 80x192, 4096-color rendition of the photo
"A Roll Cloud Over Wisconsin". :) )

Atop this, the FujiNet offers JSON decoding (and maybe also XML?
if not, it's at least planned).  This allows you to tell the FujiNet
to download and _parse_ a JSON file, and the Atari can access the
parts of it that it's interested in, without having to do all of
the data storage and string manipulation inside the Atari itself.

I used this functionality to create my International Space Station
(ISS) tracker.  Unlike my APOD viewer, it does NOT have a bespoke
corresponding web app backend.  It simply connects to existing
API endpoints on the Internet -- something tons of other desktop
and web apps do.  It talks to one (https://wheretheiss.at/) to
ask for the current latitude and longitude coordinates of the ISS,
and another (http://open-notify.org/) to fetch the names of everyone
currently in space.  It displays this info within an otherwise
extremely simple Atari application.  (Map of the world is baked in,
and it uses Player/Missile Graphics to position the ISS.)

Versions of this app have been re-implemented on a number of other
systems that the FujiNet now supports, including the Apple II,
Coleco ADAM, and Atari Lynx.  A slimmed down version of the Atari
ISS tracker could probably be written in plain Atari BASIC in
a few dozen lines of code.  (If you just want the lat. & long., it'd
probably fit in 5 lines of code!)


Other fun apps include a weather app (with forecast), a news reader
(as in, capital-N News, like newspapers, TV, AP, Reuters; not like
Usenet news), realtime chat room, etc.


Obviously, the FujiNet allows for over-the-internet multiplayer games.
A Reversi game written in Atari BASIC (IIRC, and old, preexisting game
from the 1980s?) was updated to support FujiNet.  A brand new 5-card
Stud Poker game, supporting 6 or 8 human players (plus server-controlled
bots) and multiple "tables", all accessible via a game room "lobby",
with realtime chat recently added, is an extremely polished example of
a brand _new_ game that utilizes FujiNet.  (The game lobby is accessible
via the web, so you can see whether anyone's playing the games; see:
http://fujinet.online:8080/)


Speaking of games, another interesting feature FujiNet + TNFS servers
offer is the ability to _share_ a high score table.  A number of games
have been patched to offer this.  In some cases, no actual patch to
the Atari game was even required.  Basically, the TNFS server is told
"this ATR disk image is _read only_ ... _except_ this/these sector(s)".

Then, when someone plays a game, and gets a high score, and the Atari
tries to save it back to the D: drive, the TNFS server _accepts_
those write operations, thus placing their high score onto the disk
image file _on the TNFS server_.  So when someone else loads and plays
the game, they'll see the new high score (or table of top scores)!
These high scores have even been exposed via the web; see:
http://scores.irata.online/  Can you beat CHM's high score of
583,510 points on Pac-Man?! ;) )


So... back to Atari800.  Why?  Why would anyone need or want support
for FujiNet's functionality on their Atari800 emulator?  Frankly,
I would only care about support for ONE feature: the "N:" device.
And why?  So I can more rapidly develop and test any updates to
my existing network apps (APOD Viewer & ISS Tracker), or any new
apps and games I might decide to create.

When creating those apps (this was before I realized how trivial
it was to run my own local TNFS server <facepalm>), I would build
my app (cross-compiled via CC65) on my Linux laptop, copy the XEX
executable binary to an SD card, and insert it into my (increasingly
flakey, and currently returning from repair) Ultimate SD Cart,
or my SIO2SD device -- because SD is less fidgety than microSD that
FujiNet uses.  In other words, I would "sneakernet" the file from
my laptop to my Atari.  Then I'd boot my Atari and test, determine
that something did or didn't worked, and repeat this tedious loop.

Or, in the case of the ISS tracker, I had two "builds".  One was
a local test build with fake JSON data that got baked into the
Atari (and at this time, I was parsing it by hand, because FujiNet's
built-in JSON parsing was not working), and the other was the
"production" version that actually talked to the FujiNet N: device.

I would build the test version, and could run it locally under
Atari800 ("atari800 -run iss.xex").  That helped while I did things
like polishing the UI, testing the math, etc. etc.  But when I needed
to actually confirm it all worked and could show me live data,
I'd have to do that SD-card-based "sneakernet" described above.
(Today, I would just have TNFS running, and launch the XEX over the
network.  I am no longer living like a caveman.)


I recently took the time to try out the Altirra emulator, which I of
course needed to run under Wine (I use Linux, it's a Windows app).
I was able to use the virtual FujiNet device plugin for Altirra,
and was able to briefly get my virtual Atari running on my laptop
to connect to the Internet.  Theoretically, between my two real
Ataris, and two real FujiNets, and my virtual Atari & virtual FujiNet,
I could have taken up three spaces in one of those 5-card stud games!
I would literally need to run between two rooms in my house to do so,
though. ;)

(IIRC, there's also a way to get Altirra to use a _real_ FujiNet
device, via an SIO2PC or APE cable.  My knowledge in these parts
is extremely limited.  If you asked me how I got Altirra + virtual
FujiNet working, I'd have to tell you to wait 10 minutes while
I go dig up the documentation again.  It was not difficult, but it's
not something I do every day. ;) )


I've said, for a long time (again, rapid development is niiiice!),
that it would be awesome if Atari800 could offer, at the very least,
an N: device (with at least _some_ the features FujiNet offers, e.g.
JSON parsing).  In the meantime, a full virtual FujiNet device has
been implemented, and can be attached to Altirra.  So I would like
to hope that it's matter of time and a little effort to get it
attached to Atari800, too!

As mentioned, I have very little time.  (I'm burning my free time
during vacation writing this email, and working on a new little
Atari 8-bit game ;) )  And more importantly, I don't have any clue
how to create virtual devices that can be included in (or added
onto, as a plugin -- is this even possible?) the Atari800 emulator.

For those who DO have time and skill, but may not have the info
required on adding devices to the Atari800 emulator, is there
any kind of documentation anyone could point us to?


Atari 8-bit'ing for 40 (holy crap) years, Atari800 emulating for
at least 25 years, and FujiNet-working for just under 3 years...

-- 
-bill!
Sent from my computer

Re: [Atari800-users] Adding FujiNet Support to Atari800

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

On Čt, 2023-08-17 at 16:09 +0200, Miro Kropáček wrote:
> On Thu, 17 Aug 2023 at 00:37, Thom Cherryhomes <
> tho...@gm...> wrote:
> > "What can I do to help bring FujiNet to the Atari800 Emulator?"
> > 
> 
> To put it shortly: provide a patch. :) 

It would be great to help others understand what FujiNet is and how it
could be useful to Atari800 users.

> Atari800 had its peak (at least for now) in the past but still it's a
> fast and reliable emulator usable even on really slow platforms. So
> the rule is: whatever is submitted and it's not total rubbish gets
> merged. ;)

I don't agree with most of the words above.

Petr

Re: [Atari800-users] Adding FujiNet Support to Atari800

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

On Thu, 17 Aug 2023 at 00:37, Thom Cherryhomes <tho...@gm...>
wrote:

> "What can I do to help bring FujiNet to the Atari800 Emulator?"
>
To put it shortly: provide a patch. :)

Atari800 had its peak (at least for now) in the past but still it's a fast
and reliable emulator usable even on really slow platforms. So the rule is:
whatever is submitted and it's not total rubbish gets merged. ;)


-- 
http://mikro.atari.org

Re: [Atari800-users] Adding FujiNet Support to Atari800

[Thom C. <tho...@gm...>]

p.s. sorry, I meant to say:

"What can I do to help bring FujiNet to the Atari800 Emulator?"

-Thom

On Wed, Aug 16, 2023 at 5:09 PM Thom Cherryhomes <tho...@gm...>
wrote:

> Hello all.
>
> I am Thom Cherryhomes, the firmware engineer for FujiNet.
>
> The Altirra emulator added support for custom devices, and Jan Krupa
> (@apc) was able to port the firmware for the FujiNet to run on standard
> PCs, replacing the ESP-IDF calls with POSIX and WIN32 calls.
>
> This was implemented with three pieces:
>
> Fujinet-PC, the ported FujiNet firmware:
> https://github.com/FujiNetWIFI/fujinet-pc which connects to:
>
> The Fujinet-emulator-Bridge, via UDP:
> https://github.com/FujiNetWIFI/fujinet-emulator-bridge
>
> And finally to Altirra via a custom device in python.
>
> What could I do to help bring Altirra to the Atari800 emulator?
>
> -Thom
>

[Atari800-users] Adding FujiNet Support to Atari800

[Thom C. <tho...@gm...>]

Hello all.

I am Thom Cherryhomes, the firmware engineer for FujiNet.

The Altirra emulator added support for custom devices, and Jan Krupa (@apc)
was able to port the firmware for the FujiNet to run on standard PCs,
replacing the ESP-IDF calls with POSIX and WIN32 calls.

This was implemented with three pieces:

Fujinet-PC, the ported FujiNet firmware:
https://github.com/FujiNetWIFI/fujinet-pc which connects to:

The Fujinet-emulator-Bridge, via UDP:
https://github.com/FujiNetWIFI/fujinet-emulator-bridge

And finally to Altirra via a custom device in python.

What could I do to help bring Altirra to the Atari800 emulator?

-Thom

Re: [Atari800-users] Ram-Cart support

[Jerzy K. <jer...@po...>]

Hello.
At last I made pull request for RAM-Carts and SiDiCar cartridges support 
https://github.com/atari800/atari800/pull/184
I apologise that my account (mono6502) on github is not connected with 
my email account I'm using on this list.

 From my last post I've added 8M, 16M and 32M RAMCART-s and SiDiCar 
emulation.
MEMORY_CopyFromCart and MEMORY_CopyToCart may be useful for "writable 
cartridge support" issue https://github.com/atari800/atari800/issues/109

Best regards
Jerzy Kut aka Mono / Tristesse



W dniu 20.04.2020 o 10:18, Petr Stehlík pisze:
> Jerzy Kut píše v So 18. 04. 2020 v 14:51 +0200:
>>   
>>> Patch is available to download from
>>> http://mono.i-demo.pl/atari800/atari800-4.2.0-ramcart.patch and
>>> ready to
>>> apply e.g. by:
>>>
>>> $ git patch atari800-4.2.0-ramcart.patch
>> it should be:
>>
>> $ git apply atari800-4.2.0-ramcart.patch
> 
> Ideally you'd create a pull request in GitHub.
> 
> Petr
> 
> 
> 
> 
> 
> _______________________________________________
> Atari800-users mailing list
> Ata...@li...
> https://lists.sourceforge.net/lists/listinfo/atari800-users

Re: [Atari800-users] Second fire button?

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

On Wed, Mar 15, 2023 at 03:44:57PM +0200, Peter Dilov via Atari800-users wrote:
> Because it uses two type of shooting - bombs and machine gun:
> https://www.youtube.com/watch?v=cKNhJxwD3Dw. One fire button is
> needed for the bombs and one for the machine gun.

If it's like the Atari 2600 version, it just shoots & drops bombs
every time you hit fire. (It's been a while since I played, but
I've had the game for about 40 years ;) )

I would agree that having the option for a 2nd firebutton would be
nice in Atari800 -- both via keyboard, and true joystick/gamepad input
on the device running the emulator (for example I have a PlayStation
(original) to USB controller adapter that I've used with PS and PS2
game pads under Linux in the distant past).

Basically, a way to map a fire button to a lo/hi on the appropriate
PADDLE input.  I've got my 1200XL sitting next to me with a
Sega Genesis controller plugged in, and I've got 7800 Pain... err
ProLine controllers that I can try on it.  I can PEEK around to see
what they do.

I also have a controller adapter from EdLaddin (who made my big
arcade stick) that, lets me use my Sega Genesis controllers
on the 7800, and have two button inputs without killing my hands
with its stock controllers:

  https://edladdin.com/Seagull-78-Controller-Adapter-v20-ec-2-001b.htm

I suppose if anyone creates Atari 8-bit games that can use the
7800 controllers (but do not, like my own game, support Genesis
controllers), I could just use that with my 8-bit too ;-)

-bill!

Re: [Atari800-users] Second fire button?

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

On St, 2023-03-15 at 15:13 +0100, Robert Demming via Atari800-users
wrote:
> The Atari 7800 had joypads with two buttons. Both buttons were
> connected to the same joystick button input but each button was also
> connected to one of the paddle inputs so the paddle inputs could be
> used to see which of the two buttons were pressed.
> Both buttons acted the same on games that only supports one button
> (e.g. 2600 games on 7800 console but also when connected to an Atari
> 2600 or Atari 8-bit).

this is a pretty cool idea. Worth emulating, if it is used by any
software.

Petr