Collection of fixes and best practices for Flashback Portable?

[+Gemintronic]

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.

 

[+Karl G]

Based on the link to the modified score routine, I'll assume that this is for a batari Basic game? Here's what I know based on what I remember from producing a AFP version of Space Game:

 

 - The score fix you mentioned is needed to avoid repeated digits in the score (the standard bB routine uses an early HMOVE for the score, presumably to avoid a visible HMOVE bar, which the AFP doesn't support).

 

 - If you use the Titlescreen Kernel, the 96x2 kernel will not work, since it relies on an early HMOVE to work. The 48x1 and 48x2 can be modified to remove the HMOVE, potentially. 

 

 - The starfield effect will not work on the AFP. 

 

 - The Multisprite kernel will not work on the AFP, as it also uses early HMOVEs to hide the HMOVE bars. It could be modified to use standard HMOVEs in the same way the score routine was modified, I'm sure. 

 

 - Sometimes a multi-bank ROM is not recognized if there is a lot of empty space in some of the banks. In this case, you can pad the babks by adding multiple data statements. Use a value other than $FF, though. 

 

 - if it's a SuperChip game, I *think* you need to fill the first 256 bytes at the beginning of each bank with zeros. I haven't had to do this myself, so I don't know if there's a way that is less horrible than doing it manually in a hex editor. 

 

 - Anything made with the DPC+ kernel will not work on the AFP. 

 

That's what I can remember at the moment. 

[+Gemintronic]

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.

[+Karl G]

I don't think initializing SuperChip RAM will fix the issue with those games. I believe the writing of zeros in the ROM helps it be detected correctly upon startup. If it's not, it never runs the initialization code. 

[Flojomojo]

@Gemintronic I love the Flashback Portable, but for your purposes, it might make more sense to use something with a well-documented emulator.
 

The PocketGo is $40 from US sellers on Amazon and last I checked, came with Stella preinstalled. It's less from China but will take longer to ship.

 

It has a bright and sharp IPS screen with a glass front and would be a good demo platform. 

[+Gemintronic]

21 minutes ago, Flojomojo said:

@Gemintronic I love the Flashback Portable, but for your purposes, it might make more sense to use something with a well-documented emulator.
 

The PocketGo is $40 from US sellers on Amazon and last I checked, came with Stella preinstalled. It's less from China but will take longer to ship.

 

It has a bright and sharp IPS screen with a glass front and would be a good demo platform. 

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.

[Nukey Shay]

I've had to fill the added Ram in Superchip roms with $FF's to get those to be detected by the portable.  100% reliable so far (if that was the only issue present).  On the other hand, the 8k hack of Atari's Pac-Man was triggering the Superchip detection for no discernable reason!

 

Some other concerns:

VBLANK writes can cause the portable's display to be shifted downward a number of lines.  This does not happen in every game...but fortunately, you can completely remove/ignore VBLANK writes for -any- game when running on the portable.

 

Code existing on bankswitch hotspots do NOT trigger the bank...for example, the init code $FFF6: JMP Clean_Start existing in the 2nd bank of an F8 game will not flip to the first bank as the destination address is read.  Such code will need to be relocated with a proper bankswitching instruction to work.

 

Multiple reads to SWCHA (during each frame) can cause problems occasionally...try to limit that to once per frame if possible.

 

There is a LOT of inconsistency when dealing with gfx/playfield registers, reset strobes, etc.  You may need to add or remove cycles from code when artifacts show up.

[Arenafoot]

On 1/12/2020 at 5:27 AM, Gemintronic said:

Is there a complete (as can be) list of fixes to get things to run on the AFP?

Yeah there is..... his name is @Nukey Shay !! 

But, seriously he is the "go-to guy" for AFP hacking/fixing.

[Nukey Shay]

Eeeeh!  No.  I'm only doing it because the real wizards have no interest in supporting a flaky emulator.  Just a fun diversion to me (that ultimately leads to nowhere, like a lotta my hacks).  It's like a game where every rule is broken.

[+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.