Gemintronic

The fellow that I was collaborating with decided to go with an Android based portable so the AFP specific build wasn't needed anyway. I tried this combination as a "best practices" for AFP compatibility: * Manually write zeros to all available RAM * No high res title screen (possible unsupported HMOVES) * Use the AFP safe score kernel for batariBASIC projects. * Fill each bank to the brim with data. Putting in dummy static arrays if needed (hoping the cart type detection is appeased). Trouble is, even with doing that I feel the chance for working is potluck.

What's a good 64 bit IDE to use with this? Also, thank you!

I forgot about the PocketGo. That's a wonderful option! Thank you for reminding me. Was tempted to explore Stella ports for the PSP and DS. But, that would be more hassle then just buying a portable that intentionally facilitates homebrew.

I appreciate the insight! I might try to use the modified standard kernel and write zeros to available RAM at startup and try again. I accidentally posted in the general development section but also [ now ] realize any fixes are probably by assembly coders. Should expect to insert some inline assembly for said fixes.

I've got an upcoming title that needs to run on an Atari Flashback Portable at an expo. No power at the tables. Is there a complete (as can be) list of fixes to get things to run on the AFP? Seen a score fix: https://atariage.com/forums/topic/281369-atari-flashback-portable-score-fix-for-bb/ ..and, I vaguely remember code to initialize memory? If anyone else has a clue about that please chime in.

It depends on which kernel you're using but all of them I've seen have this behavior. The only solution I've come up with is to manually figure out which x position each sprite needs to stop at before looping. Typically using some code to display the x position as a decimal number in the score.

I usually include the 6lives_statusbar.asm https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#lifecounterstatusbar Gives you a long status bar and a sprite life counter. Good stuff!

In another thread someone was trying to use data tables for sound engine use. I suggested using seperate variables for each sound that would act as both duration and the sound effect itself. Nukey Shay suggested using a variable for bitwise flags and another variable for duration. My addled brain came up with a scheme that has a big problem: Say, an enemy needs a torpedo sound. Simple! Raise the torpedo sound flag and set the duration: def torpedosound=soundlfag{0} def lasersound=soundlfag{0} soundflag{0} = 1 duration = 25 But, now the player fires and needs his laser sound played. So, we set the laser sound flag: soundflag{1} = 1 duration = 35 The torpedo flag hasn't finished yet so the duration get overwritten with the duration of the laser! I can also imagine the game needing the opposite where a laser sound is playing but needds the torpedo sound to play (thus overriding the torpedo sound). I never had to worry about this with my single variable for a specific sound method. Each sound was always run if it was more than 0. Since the variable was also the duration each sound couldn't mess with the others duration or priority. How does one use just one variable for sound flags and a single duration variable given the two issues presented (priority and duration being overridden)?

I usually use a duration variable for each sound effect. So, to activate a laser blast sound I set its variable to something non-zero like 15. Each cycle of the main program loop I check for the laser blast sound variable to be more than zero. If it is I set the sound registers appropriately and then decrement the laser blast duration variable. The big drawback is, of course, each sound effect takes up an entire variable.

For the kernels that support pfscroll you could make a routine that pfscroll's up or down determined by a counter variable that increments at the top of the main program loop. For more fine grained shaking you could play around with playfieldpos With help from bogax I created a 4 way scrolling demo that uses playfieldpos. https://atariage.com/forums/topic/218190-smooth-vertical-scrolling-from-data-want-4-way/

I've not heard of a homebrew ROM that doesn't work if given the proper physical cart and board. Some games might better on either a real TV or LCD panel. For instance: Some games flicker the left 8 pixels of a sprite then the right 8 pixels of that sprite. So, you see only half the sprite at any one time. Depending on using a CRT TV or LCD monitor it may look hard to see.

Looks like it's scripted. But, I like the idea of BASIC within BASIC

I'd talk to a lawyer before plunking money down to try to rent someone's dump of their games. Right now it sounds like you're going by what you think is allowed and what we are pretty sure wont work. Alternatively, you could avoid the issue altogether by getting permission from homebrew authors to stream their games. You can test the waters with offering retro titles without incurring the wrath of Nuntendo, Atari, etc.. I'm sure many game makers would be happy to see their game shared for a little slice of the ad revenue or subscription fee.

I think the conundrum here is that, in keeping with the no illegal ROMs criteria, collectors would have to sell you their physical collection. In the US you can still make personal backups. So, you get their collection and then you personally dump the ROMs. Am I looking at this wrong?

Cheating really depends on your vision for the game. Also, how tied you want to be to extra hardware when it comes time to physically create yer game. Making a 4k ROM game physically is something almost anyone can do. DPC+ requires AtariAge to make it for you. So, if "from scratch" matters enough your options change. Personally, I'd try making a 4k game first and move your way up.