Atari Flashback X Custom Firmware for USB roms and boxart

[Draxxon]

ive seen 2 or 3 games (moon patrol, i forget what else) that say there are 5200, but they are .xex files.

some of the AFB1 NESOAC were ports of 5200 games, but they are .nes

 

thats as close as ive gotten to 5200

 

when it comes to A800, I am clueless, are these just ports of 5200 games to 800?

Edited February 28, 2021 by Draxxon

[rocketfan]

13 minutes ago, Draxxon said:

are these just ports of 5200 games to 800?

Yes, I think most 5200 games have been ported to a800 at some point.  Also, a few were ported back the other direction. Who knows where something was first.

 

Both games Velvis mentioned (miner 2049er and Bountry Bob Stikes back - I should have done a multi-quote, but too late) are in the set we have been using,  but as .atr.  I think some games probably originally came on disk (.atr format is a disk image, where I think .xex is cart) because they had extra data files or something.  

Edited February 28, 2021 by rocketfan

[rocketfan]

47 minutes ago, Draxxon said:

rocketfan, can you explain again about the BASIC OS.

Yes, but I need to reproduce my steps to make sure I have it right.  I'll give it a try...

 

OK, First , I think it may related to which game you start on, and etc.  When I go to Galaxian, go to Keyboard, F1, Warm start, I see "READY" which I believe indicates basic.  If you are really patient you could actually type in a program!

 

However, and easier way is like this:

 

Put the attached .atr file on your nexus drive someplace.  That is a disk image which tries to auto-start a BASIC program.

In Keyboard, F1 to get the UI.

In Cartridge management go to where is says :none and navigate to the /emulator/ataribasic.rom and pick it as your cart (standard 8k cart).

Then back out of there, go into Disk management.  Pick tht .atr file as your first disk.

Back out to the main menu and select "Warm start"

The disk starts and the game will start.  It takes that game a long time to start while you stare at a blue screen - BASIC is really slow!

 

BTW, in that game you pull down then push forward to climb the building.

 

 

 

01_KOOKY KLIMBER.ATR

Edited February 28, 2021 by rocketfan

[Draxxon]

moving forward how should we sort this? 

throw it all in atari 800? or something more sorted?

And if most 5200 games were ported to a800, how do they play? 

could we just build an atari 5200 category out of those versions?

 

Rocket, I just went into emulator folder and clicked on this thru the 800 menu.

basic came up no sweat. can it be added to the main menu of 800 games with art 

as an entry?

 

ataribas.rom

Edited February 28, 2021 by Draxxon

[rocketfan]

25 minutes ago, Draxxon said:

moving forward how should we sort this? 

throw it all in atari 800? or something more sorted?

Between .atr and .xex I think once the game is running you won't know the difference.  And BTW, I just realized both the games Velvis mentioned are in the .xex folder, I was just searching wrong.

 

As far as 5200 I bet practically every game available for that can be found in a800 format - they are basically the same hardware.

 

So far I have found the emulator has a high degree of compatibility.     Basically aside from the PAL issue (I wrote a post on dealing with that, if need be).  There really are hundreds of games for a800, so to me it is just Cherry picking some of the best to start with, and thanks again for including my list.  That Drol game I mentioned is a good one!  There are also just tons of demos, but not sure how interesting they are to anyone else.  I like this "Robot" demo from Atari from 1984 really well.

Robot (1984)(Atari).zip

[Draxxon]

well, I guess the plan is to put .atr and .xex 400/800/XE games in the a800 category and filter out the 5200 ports and put them into their own 5200 set.

i really like the 5200, i never had an 800, a set w/ the silver and blue box art would be neat.

for basic games that run in the a800 emu menu, i put them in a new folder. /rom_a800/basic. easy peasy, no art, no name conventions.

I'll separate .atr from .xex with the "atari" and "paddle" Genre= sections.

Edited February 28, 2021 by Draxxon

[rocketfan]

Off on a tangent today, I pulled down the latest Stella sources and tried to build the Stella core from them.  It didn't work because of an unmet dependency in my Atari 800 build setup, but I'm not going into that...

 

I went back to Stella 6.1, because that is the earliest "modern" Stella that has a libretro folder setup to easily build the core.  It did build pretty easily with my environment.

 

The key thing:  I got a running Stella core, but it doesn't work right.  It is slow and maybe a little buggy.  What is does do is display/play games and have sound.  A huge bonus is the controls just work, no hacking and fussing with the Joystick input like I had to do on the 800 core!  Generally it runs about 1/2 normal speed.  You can play River Raid, but in slow motion.  Playing Battlezone is slow motion too, but also the sprite for your bullet seems to be missing (the enemies bullets do show up).

 

atGames may have tried to update Stella and run into something exactly like this.  You figure out how to build it, but then it is dysfunctional.  BTW, today I read that even Retroarch has stuck with "Stella 2014"!  So possibly they might have hit the same roadblock.

 

I don't have much time and energy to take it forward but maybe someone else does?  It seems like >50% odds it could be forced to work.  I have no idea about what's making it slow, (I mean, we can emulate Sega Genesis and Atari 800 without a sweat, which should be harder than Atari VCS...).  My gut says maybe it has to do with the sound emulation, or the up-scaling to the 720p video output.  I wonder if StephenA who is "The Stella Guy" (and has responded on this thread before) could help??  I will say that Stella code is neat and tidy compared to the A800 code.  Also there are decent comments in the Stella source code, which were not existing in the A800 sources!

 

So, I am uploading my SDK, a copy of the sources, the Makefile I modified, a shell script I used to setup the environment, and here are some notes:

 

The environment is the way it is - because of a long story.  It has to do with building for this closed platform.  I had to "go back in time" to get a working setup for the atari800 core.  A newer buildroot setup would not statically link in the c/c++ libs correctly in the shared library.  Then the older buildroot would not build in a more recent Ubuntu!    What I ended up doing was revive an old broken laptop with Ubuntu Mate 16.04, and loading Buildroot "2017.08" on it.  You could do the same in a virtual machine.  Instead of dealing with buildroot (although I will provide steps to get through that too) I think you can just use the SDK (I am uploading - 3.2gig) instead.

To reproduce my setup:

 

Have Ubuntu or Ubuntu mate 16.04 on real hardware or a VM.

It would be a shortcut to make your Ubuntu user named "ember" because then some paths would be able to stay the same.

Unzip the SDK in your home directory.   (/home/ember?)

Open a terminal in the SDK folder location, and run the "relocate" script that is in there.

Unzip the Stella sources in your home folder also.

The only Folder we need to worry about in the Stella release is the src/libretro one.

Replace the Makefile in src/libretro with the one I provide.  That just add two new platforms I was experimenting with (with similar results): "AFBX" and (I think) "classic_armv9".    

Drop the environment.sh in the src/libretro folder.

Edit the makefile and the environment.sh files and correct and  "ember" paths in there to accurately reflect your setup.

Open a terminal in the src/libretro location.

.  environment.sh   - this "sources" the environment - mainly you need the PATH for the SDK added.

"make platform=AFBX"  (or try classic_armv9)

after about 10 minutes you should get a stella_libreto.so, equally as dysfunctional as mine!

 

Any developers out there want to take on the challenge of figuring out what is going on?

 

For the really determined soul here are instructions for setting up a buildroot environment for the AFBX from scratch:

Download or use Git to pull down buildroot sources:

 

There are some dependencies for buildroot, you can install those like this (git is optional):

sudo apt install -y git build-essential wget cpio unzip rsync bc libncurses5-dev screen

"make wandboard_defconfig"  Gets you a long way!   Proper CPU settings - it is same CPU as Marsboard.
make menuconfig    (this "creates" the buildroot config menu on the fly)

 

In buildroot config menu set these things:
build options->libraries both static and shared
toolchain options->glibc for c library.
toolchain options->kernel headers 4.4
toolchain options->enable c++ support
target packages->Graphics Libraries I turned on everything sdl, sdl2, x.org xwindows system
target packages->libraries->compression-> zlib
target packages->libraries->graphics-> libpng

Save the config and exit
"make sdk"

Go do something else - that build takes some hours!

The SDK is found under the Output folder.

 

buildroot_2017_08_sdk.tar.gz environment.sh Makefile stella_libretro_61_slow.so stella-6.1.zip

Edited March 1, 2021 by rocketfan

[rocketfan]

On top of all that in my last post, I found the Stella 6.1 core supports the following options, which can be placed with the other core options in your retroplayer.ini file:

stella_filter=disabled
stella_crop_hoverscan=disabled
stella_ntsc_aspect=par
stella_pal_aspect=par
stella_palette=standard
stella_console=ntsc
stella_stereo=off
stella_phosphor=auto
stella_phosphor_blend=0
stella_paddle_joypad_sensitivity=0

Edited March 1, 2021 by rocketfan

[rocketfan]

2 hours ago, Draxxon said:

Rocket, I just went into emulator folder and clicked on this thru the 800 menu.

basic came up no sweat. can it be added to the main menu of 800 games with art 

as an entry?

Yes, as a way to get to the basic "READY" prompt that will work, but not sure how useful that is....  Maybe it is a shortcut to start games but I'm not sure.  The atari800 emulator is a little weird because a lot of options go in the atari800.cfg file.  Like I think you can set so it has a "basic cartridge plugged in" on startup, except that is bad for some games because it chews up some of the memory, so you really can't have it all the time.  From my perspective the whole config file approach is like they didn't consider that running different content needs different options on the fly.  Fortunately most games from that set seem to run well with the config like it is down in the /emulator folder!

[Draxxon]

What do you think of these?

[rocketfan]

I just noticed the buildroot SDK from my previous book-length post looks truncated. It is 3.? Gig on disk and took forever to upload but the download only shows 881M so maybe it exceeded some limit.

 

The buildroot 2017.08 sources I used are HERE

That is a tiny download, so maybe building from scratch (if you have a few hours) is the way to go.

 

PS - Nice three-D box art Draxxon!

Edited March 1, 2021 by rocketfan

[Draxxon]

So, just in the main NTSC-U menu. small box thumbs are the same 2d ones, big ones are now 3D.

I think im going to put a transparent light burst behind it baked into the BG screen.

 

Edited March 1, 2021 by Draxxon

[MrFister]

13 hours ago, rocketfan said:

On top of all that in my last post, I found the Stella 6.1 core supports the following options, which can be placed with the other core options in your retroplayer.ini file:

stella_filter=disabled
stella_crop_hoverscan=disabled
stella_ntsc_aspect=par
stella_pal_aspect=par
stella_palette=standard
stella_console=ntsc
stella_stereo=off
stella_phosphor=auto
stella_phosphor_blend=0
stella_paddle_joypad_sensitivity=0

Overscsan setting?  Would this work on the flashback x's?

Reason I ask is because my little 32in. tv overscans and doesn't have an overscan setting.

This is the absolute reason not to buy cheap tv's!

[rocketfan]

5 hours ago, MrFister said:

Would this work on the flashback x's?

I have only seen the dump from the Flashback 9 provided at some point by Draxxon.  That environment/Linux looks the same (except the path to SD card vs. thumb drive appearing in the /emulator/retromenu portion) so I'm pretty sure any core working on AFBX will work on the AFB9.  Earlier than the AFB9 is a mystery to me.

 

Also, I checked and the old/original (working) core doesn't seem to support any of those settings.

[Draxxon]

question...

if a game has no box art, is there a way to "goto" a generic, default image for "No Box Art"?

So that nothing ever shows up blank, or if there is no art available, or "fix" a bad file path name,

or someone new to this adds a game to play.

 

Edited March 1, 2021 by Draxxon

[rocketfan]

14 minutes ago, Draxxon said:

if a game has no box art, is there a way to "goto" a generic, default image for "No Box Art"?

That business with the matching .png and .s.png is all handled within the retromenu program.  I guess it was just designed for the atGames case where adding games to the rom folder (by the customer) was not a priority.  I can't think of a way we could do it, though with sources to retromenu I'm sure it would be very easy. 

 

Another approach would be to have a custom program to add a game which would copy the game to the appropriate folder, make copies of your "default" artwork renamed as needed, and edit the all-games.ini with the right information.  That would make it easy for a person who is new to the whole thing to add their own games.  Did I see something like that in the very early days of the thread?

[rocketfan]

I have been thinking about the Stella issues (can't help myself) and here are some opinions/WAGs:

 

1) I see Stella 6.1 has a bunch or rendering options for the video.  I tried turning all that off in the core options, but just seeing those options makes me think Stella could be doing a lot of image filtering/processing/scaling steps it doesn't need to do when running as a libretro core.  The whole advantage of "the cores" is that they can focus on emulating the hardware, fill a video buffer (and maybe sound buffer, I'm less familiar with that) when the callback is made by the libretro front-end (in our case retroplayer) then the front end can do the final scaling and interaction at the hardware level.  That's the whole advantage of the core approach and why these front ends can provide a consistent interface across so many emulators.  That approach allows the "scanline filter" on our AFBX to work and look the same across all the emulators.  I'm just guessing that Stella "running as a core" may not disable a lot of processing that is only necessary if it is a standalone application and has to do all of the display processing without a front-end in the picture.  So that is an area I would investigate if looking into this.

 

2) On the missing sprite in battlezone, it could be a synchronization issue with the Libretro video buffer callback.  I actually saw and fixed a problem like this related to the OSK in the Atari800 core.  In there the OSK was originally being rendered in the input polling loop.  So it would show up about every 5th video frame and you could hardly see it.  I changed the keyboard rendering to happen right after the video buffer is filled each time (presumably driven by a callback from the front-end) so it appears much more solid/consistent.  I'm assuming that the VCS playfield and sprites might be rendered as seperate "layers" by the emulator, and possibly the sprites are happening kind of asynchronous to filling/passing the buffer for the libretro front end, but I did not look at the code, and this is still just more theorizing.

 

One more note, in the "Stella core Makefile" I provided I set a variable "AFBX" so in the source code you could modify things to try by bracketing them in #ifdef AFBX ...  #endif blocks.

 

Edited March 1, 2021 by rocketfan

[Draxxon]

the sega genesis flashback had a program for adding games. the Game Manager.

nothing like that around here, unless you mean me. lmmfao.

 

we just used the makeini.bat here.

Edited March 1, 2021 by Draxxon

[+stephena]

2 hours ago, rocketfan said:

I see Stella 6.1 has a bunch or rendering options for the video.  I tried turning all that off in the core options, but just seeing those options makes me think Stella could be doing a lot of image filtering/processing/scaling steps it doesn't need to do when running as a libretro core.  The whole advantage of "the cores" is that they can focus on emulating the hardware, fill a video buffer (and maybe sound buffer, I'm less familiar with that) when the callback is made by the libretro front-end (in our case retroplayer) then the front end can do the final scaling and interaction at the hardware level.  That's the whole advantage of the core approach and why these front ends can provide a consistent interface across so many emulators.  That approach allows the "scanline filter" on our AFBX to work and look the same across all the emulators.  I'm just guessing that Stella "running as a core" may not disable a lot of processing that is only necessary if it is a standalone application and has to do all of the display processing without a front-end in the picture.  So that is an area I would investigate if looking into this.

The 6.x Stella core in libretro does indeed disable all post-processing effects.  No time/resources is spent on emulating that part; it is already disabled when building as a libretro module.  It is working exactly as you suggest; just feed raw video and audio data to libretro, and let it handle all other rendering options.

[rocketfan]

2 hours ago, stephena said:

The 6.x Stella core in libretro does indeed disable all post-processing effects.  No time/resources is spent on emulating that part; it is already disabled when building as a libretro module.  It is working exactly as you suggest; just feed raw video and audio data to libretro, and let it handle all other rendering options.

Hi Stephen, first thank you for responding!  I'm just an old Atari fan and hacker trying to guess what may be going on.  ?  That's good news about it not doing the extra vid processing.  Any other thoughts where to look?  I tend to doubt it is the speed of the device itself (I believe: Rockchip RK3066 ARM Cortex-A9 Dual-Core @ 1.6Ghz, but I think only 128MB RAM).  I know you mentioned it would be difficult to get going on this device, and generally getting to even compile a core for the device (which is running Linux under the hood, BTW) was a real hurdle.  But since the Atari800 core is now mostly working I felt like it would be worth a shot.  At least for 6.1 the build process was not bad, and now seeing River Raid running (1/2 speed) it feels sort of close  (yes, or maybe very far).  This thread is busy but mainly just a few of us postings lots.  No one else has stepped forward and said they would dig into it, so I was thinking of trying to figure out how to just outright disable audio to see if speed is improved.  Any other suggestions of how to debug it would be greatly appreciated. 

 

 

[Velvis]

Is it possible to have one menu for many systems? IE rather than have 2600, 800, and arcade games, separate, could a few of each be displayed and run from one main menu? 

[rocketfan]

10 minutes ago, Velvis said:

Is it possible to have one menu for many systems? IE rather than have 2600, 800, and arcade games, separate, could a few of each be displayed and run from one main menu? 

Yes, they can be mixed together.  Draxxon sets it up the way I would, organized by platform and category, but you could have a "favorites" folder with any mixture of games in it.  If you call that /rom it will be the startup folder and you might not need to switch around at all.  You could start from Draxxon's setup as a template for your thumb drive since it contains all the needed parts, and do anything you want from there.  There is a limit of the number of games before the menu load gets super slow (and you will wait 30 or 40 seconds with a blank screen), but I think it is pretty large.  I believe Draxxon/others said it is somewhere above 400 games.    

 

One thing - the retroplayer.ini in the data folder under the rom folder will need core options for any cores the games in there use.  AFAIK it doesn't hurt anything to include extra options either.

Edited March 2, 2021 by rocketfan

[Velvis]

Thank you. 

Is it significantly slower to use a USB 2 drive vs USB 3?

[rocketfan]

6 minutes ago, Velvis said:

Is it significantly slower to use a USB 2 drive vs USB 3?

Well, maybe - but I never really compared.  I believe the ports on the device are only 2.0, but like with SD cards the actual memory speed likely also plays a role.  I guess newer/3.0 sticks probably have significantly faster flash on them. The space needed for these games is so small that I have just used a handful of really old drives I had laying around and it has been OK to me, but that is pretty subjective!  I do wish these devices had an SD card slot but it has actually been easier to pop in and out the thumb drive considering how many times that is needed when testing things.

[Draxxon]

2 hours ago, Velvis said:

Is it possible to have one menu for many systems? IE rather than have 2600, 800, and arcade games, separate, could a few of each be displayed and run from one main menu? 

YES! the system is completely flexible. I'm pretty sure you can run any type of rom from any folder now. unless you need to change some extra setting in the /rom_x/data/retro file. like turning off the mame nag screens. Anyone can totally cut & paste their own list. and run it all from the rom folder. but at around ~500 games, it is gonna take longer than stock to turn on. 1000+ games was 30 seconds. The folders were the only way to add more than that without having to wait. everything (except HB) is around ~4 seconds (stock) load time now. NTSC pretty much eats up the stock /rom folder. but who knows, you could probably add quite a few to /rom before it starts to bog down on boot up again. 100~200?. (I'm not entirely sure what specifically causes the bog down BTW)

I feel like I have asteroids/deluxe arcade versions for mame mostly playable. I mapped thrust to up and space jump to down. i think it plays okay. Avalanche Arcade, same deal, no paddles but stick "works". I implemented all the atari 2600, 7800, 8bit, and homebrew 3d box art i had. i didnt do 3d "boxes" for the arcade games, but they do look slick, they just dont match the flyers. I also swapped Kevin's box art images he shared with our project that were higher quality when applicable. 

That said, not everything has a 3d box, so the old 2d one remains in those cases. A handful of boxes dont match each other as well. Moving forward, adding future games means I will need two sets of box art (2d and 3d). It is an extra step in the workflow. A real PITA, but after the whole AFBX box art fiasco, I was ready to pull the trigger on this idea. these 3d boxes were actually in the ATARIv1.0 pack a year ago.

Also, be on the look out for 1-button basic games that play in atari 800 basic mode. they are just getting added to a folder for the 800 emu menu, so no art and no naming conventions mean i can just drop them in there, easy peasy and be done.

Edited March 2, 2021 by Draxxon