Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

45 Excellent

About rocketfan

  • Rank
    Star Raider

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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!
  2. 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!
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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.
  8. I'm attaching a new runcommand script, which goes in /emulator. The only difference - a few extra lines to allow the .atr extension in addition to existing .xex for the atari800 emulator. I experimented with the Broduerbund game "Drol" which is an excellent game with good music. There are both black and white and color versions of that game but for whatever reason it doesn't exist as an .xex file (that I found, but I didn't look too hard). Anyway, both those came up fine. When I ran a basic program (which is a bit complicated, using the emulator UI) it was also from a .atr file. Draxxon, I must have played 3 dozen games from your release last night without any glitches. Mainly 800, 2600, and arcade. Only one file would not load - the a800 Drelbs.xex. I think you might have used one that says "req OSb" which I think has something to do with PAL systems (maybe some Atari expert knows if that is right?) but the other non-OSb one worked OK when I dropped it in. runcommand
  9. Thank you Draxxon. Great release! I just played Atari Video games for the last two hours! 👾
  10. No worries on the NES swap core, more of just a curiosity thing. I did get an Atari BASIC program running on the AFBX, btw. And it proved more or less .ATR support is working, but I am going to experiment a bit more with that.
  11. Draxxon, did you say you have an NES core that flips the A & B buttons? I thought I saw it and have been meaning to ask you, but now I can't find the comment. If so, can you provide the flipped one? I want to see if I can use it to play Castelian!
  12. The actual coinOps stufff is (I believe) all going to be compiled 64Bit ARM not 32Bit ARM like this device uses, so no way just to take their stuff and run it directly. Also, I think I read it is not open source. Just my opinion, but seems like the CoinOpsX/CoinOps people had full cooperation, and maybe even sponsorship from atGames. Bottom line, I think it would be VERY difficult or impossible to get that running on this device. BTW, the .uce files used by the legends ultimate for the roms also contain box art, a custom bezel, and the emulator core (64Bit) for each game. There are thousand of those out there available if you look around. This kind of goes back to Brad_from_the_80s saying he was originally interested in putting a whole new UI on there. I don't know what Brad had in mind, but IMO the current setup is decent and especially with the various themes. The device is somewhat low CPU horsepower and memory but works well for Atari and some other old-school emulation. The Nexus version has turned this into a little "Atari Museum" IMO (@Draxxon: plus bonus systems, which I also like), and the interface feels good for that (as opposed to the CoinOPS - "emulate anything and Everything" world). There are a few rough edges like the "Paddle Games, Atari Games" categories would be nice if they could be dynamic instead of just hard-wired (though we could change them to some other hard-wired words). We are currently lacking "Bezel Per Game" as mentioned by several folks along the way. I believe bezel per game is doable, if desired. In addition to the box art, for every game that wants a custom bezel, add something like DonkeyKong.b.png (the bezel). Then it could be made to work... If we only had the retromenu/retroplayer sources it would really be nice! 🙂
  13. Here is an updated Atari800 core. This modifies the select/option/virtual keyboard. IMO using the second joystick for a "shift" function was awkward, and I ran into several games that would start up as soon as Joy2 Fire was pressed, so you couldn't really use the mechanism with those games. Now: Joy1 Start == start Joy1 Select == virtual/on-screen keyboard In the virtual keyboard, you have SEL, OPT, STA keys on both pages. So, if your game needs option or select, bring up the OSK and do those from there. Then select EKB, to get out of the OSK and start your game as normal. One thing I notice is the OSK buttons work better in some games than others. For example in DonkeyKong Junior they seem to be very reliable, but in Dig Dug I may have to press Opt/Sel a few times to get them to "take". I think that must come down to the actual game implementation. Looking around and much to my surprise, you can in fact bring up the emulator UI using F1 on the second page of the OSK. Use at your own risk, but some of the functionality works in there. For example, you can launch a different game by browsing directly to it. When in that emulator UI, use Joy1 Fire to go into a menu/select and Joy1 Start to back out. Some things "take" and others don't. For example in Sound options you can change the buffer length, but not the output rate (if you go back in you will see it reverts back). Another example of non-working functionality is that saving a new config file fails. Probably just the path is set wrong but I have not dug into it. All that functionality is more like gravy to me. I have not investigated other than play with it and wiring up the Start button right so you could back out of menus. BTW, it looks like warm reset takes you to BASIC??? At least I was able to do A=8 then PRINT A. I used to be an Atari BASIC wizard, but apparently the beer has killed all those brain cells! There would definitely be a way to run Atari BASIC programs if you put the right stuff on your drive - I have done that from other similar versions of the emulator. I tested a little on one and two player games and they seem OK, but as usual please let me know if I broke anything. atari800_libretro.so
  14. If you have paddles, have a custom FW installed, and one of Draxxon's flash drive setups you could give it a try. I would look for the mame2000/37b5 version of the rom (warlord.zip) and rename it warlord.zim. Place it in the /game folder on your drive so you can just access it from the external USB device menu. Then just see what happens. I don't even have a guess if it will work. If you see any movement at all you might then be able to adjust the per game MAME control settings to make it work (hopefully you can adjust the analog sensitivity and speed factors). I'm not sure if you will see the MAME config menu when you start it, if not you need to disable rewind on the game and then (I think) you can hit rewind to get in there. Rewind is disabled by changing the /rom/data/retroplayer.ini file and adding lines like this: [Rewind] warlord.zim=2
  15. I saw some talk about porting the whole setup to AFB9. I think that has an SD card? If so, the paths to the media that are harcdoded in various places probably need to be modified for it. For example the scripts runcommand and startup.sh have a bunch of references to "/media/usbhd-sda1/..." So (I think) those all have to get changed to something like (but I'm not sure - this is from LFB2018) /media/usbhd-mmcblk0p1/... Also, there is one path hardwired like that in the atari800 core - which is where it looks for the atari800.cfg file, so that will need to be updated also.
  • Create New...