bB, bankswitching and the Atari Flashback Portable

[+Karl G]

Thus far, I have not been able to get any games made with bB that use bankswitching to work on the AFP. Even the simplest "hello world" using the standard kernel that works when compiled to 4K fails when it is changed to 8K. The bankswitching example on RT's site also doesn't work on the portable.

 

I do know that some people have had their bankswitched bB games work on the portable, however, so I am trying to figure out the relevant factor. Does anyone have any example bB code that uses multiple banks that DOES work on the portable? If I had a working example, then maybe I could figure out what is different.

 

Also, it has been suggested to me that perhaps it may be something that changed in more recent builds of bB. I am using RevEng's latest build. For those of you who have had success building for the portable, what version of bB were you using?

[Mr SQL]

PortableTest.bin

 

kdgarris,

I was able to compile your game with the older version - this one works on the portable

Noticed a couple of strange issues though:

 

/* block SQL comments in the code have to be removed, these must be new */

 

Then the compiler complained about a normal variable name near the end, then about the "-" sign...

didn't look like normal errors might be too much padding I just removed the -

so the line became more like "if myvar > thisvar then" instead of "if myvar > thisvar - 8 then"

 

I used not the original bB release but the version patched for pfcolors.

 

[+Karl G]

That's very strange - I did the same thing ... tried compiling with the old 1.0 version, having to make the same kinds of changes to get it to compile. The newer bB seems to be more forgiving of complex expressions. I just broke some of these up using temp variables. It also seems that my stripped down "game" behaves differently in Stella under this version as well.

 

None of that really matters though - it looks like whatever issue I'm having isn't related to bB version from my own testing. To get 1.0 to work on my mac, I had to recompile the binaries, and even run the windows version of dasm through wine (since there was no sources for dasm in that bundle. Still, same result on my end.

 

On what platform were you compiling? One would think that wouldn't make a difference, but there must be something different since you got a different result than I did.

[+Karl G]

Here is an even more simplified example - an 8k "hello world" with filler data. It fails on the portable when compiled with either version of bB.

helloworld.bas

helloworld.bas.bin

[+Random Terrain]

I didn't look at it closely, but it seems like data is trying to be accessed from another bank. Am I seeing that correctly? The bB page says "All data tables, regular or sequential, must be located in the same bank where they are read. If you try to access data in another bank, there will be no errors, but the data you get will certainly be incorrect."

 

In a program with more than one bank, I continue the main loop from bank to bank and read what needs to be read in each bank.

[+Karl G]

The data isn't read at all in this case. It's only there to fill up the banks, since Mr SQL suggested that the portable might not detect banks that are mostly empty. The only thing the code does is increment the score when fire is pressed. I wanted to reduce the problem to the simplest case to help rule out issues with the code itself. Also, to be clear, it only fails on the portable, which doesn't have the best emulator (but is still fun for many games).

[+Random Terrain]

What happens if you put a dummy loop in the second bank along with the unused data?

[iesposta]

First thing I think of is Illegal Opcodes.

 

batari Basic may or may not use illegal opcodes.

The Flashback Portable may or may not handle illegal opcodes.

 

Maybe a large compiled batari Basic .asm source could be searched for common illegal opcodes?

[Mr SQL]

That's very strange - I did the same thing ... tried compiling with the old 1.0 version, having to make the same kinds of changes to get it to compile. The newer bB seems to be more forgiving of complex expressions. I just broke some of these up using temp variables. It also seems that my stripped down "game" behaves differently in Stella under this version as well.

 

None of that really matters though - it looks like whatever issue I'm having isn't related to bB version from my own testing. To get 1.0 to work on my mac, I had to recompile the binaries, and even run the windows version of dasm through wine (since there was no sources for dasm in that bundle. Still, same result on my end.

 

On what platform were you compiling? One would think that wouldn't make a difference, but there must be something different since you got a different result than I did.

 

I used a Windows XP system that I keep offline from 2002 to compile it. I haven't tried on Windows 10 or the mac.

You should be able to duplicate my results with the 1.0 download form batari's site plus the pfcolors update using wine or soft windows.

 

Oh, I edited the file in an editor and used the command line (run COMMAND or CMD to get there) to compile: "compile game.bas"

[+Karl G]

What happens if you put a dummy loop in the second bank along with the unused data?

 

No dice, but thanks for the suggestion. For an 8K rom, the bB seems to put the kernel in the second bank, anyway, so both banks are getting used regardless.

[+Karl G]

I was able to compile your game with the older version - this one works on the portable

 

I only just noticed that the version you compiled is 4K. I can make this and others work when I compile to 4K, too (both on the older version and the latest). My problem is only specifically with bankswitched games compiled with bB not running on the portable.

[Mr SQL]

 

I only just noticed that the version you compiled is 4K. I can make this and others work when I compile to 4K, too (both on the older version and the latest). My problem is only specifically with bankswitched games compiled with bB not running on the portable.

Hmmm... I tried to compile the 8K HelloWorld and it freezes on the "loading..." screen, haven't seen that screen freeze before looks like a new kind of loading error, so far I would always see them load and then glitch but they get past the loading screen. Gives me a theory the portable doesn't like $FF as filler data since bitd that meant "unused" and it wants the RAM area to be unused/$FF but wants that ROM area filled (Portable logic).

 

Trying with the $FF changed to different filler data ... got it

I relaced $FF with 55 no $ just 55 decimal and boom it works:

Helloworld3.bin

[+Karl G]

Hmmm... I tried to compile the 8K HelloWorld and it freezes on the "loading..." screen, haven't seen that screen freeze before looks like a new kind of loading error, so far I would always see them load and then glitch but they get past the loading screen. Gives me a theory the portable doesn't like $FF as filler data since bitd that meant "unused" and it wants the RAM area to be unused/$FF but wants that ROM area filled (Portable logic).

 

Trying with the $FF changed to different filler data ... got it

I relaced $FF with 55 no $ just 55 decimal and boom it works:

Helloworld3.bin

 

Yes! Success! It also worked with the latest RevEng build on my larger WIP that I haven't posted yet (16K romsize). Thanks so much for figuring this out!

 

I wish there were an automated way to generate this filler data as part of the build, but I'll definitely settle for filling it in myself (and it may not be necissary once my bankes become more filled with my own code and data.

[Mr SQL]

 

Yes! Success! It also worked with the latest RevEng build on my larger WIP that I haven't posted yet (16K romsize). Thanks so much for figuring this out!

 

I wish there were an automated way to generate this filler data as part of the build, but I'll definitely settle for filling it in myself (and it may not be necissary once my bankes become more filled with my own code and data.

You're welcome! Very cool it's working on the other build as well.

 

Looking forward to playing your game on the portable!

[+Karl G]

I was wondering if anyone had any clever ideas on how a game might be able to detect whether or not it is running on the portable? This would be handy to work around some its limitations without having to give up on features when not running on the portable, and not have to produce two different version of the game.

[Nukey Shay]

7800 detection works by checking for specific values in user RAM when cold start begins. VCS (the actual console) detection *could* work by checking for value $FD in the stack pointer (don't know if anybody has taken advantage of that yet). The portable has a definite playfield issue where updating the registers too soon (but still within the range allowed by actual hardware) can cause screen garble on the portable. So a short routine where a sprite collision with playfield could feasibly be used for AFP detection. However, this probably won't work once emulation gets better on newer versions of the portable.

[Mr SQL]

Location 24 (decimal) holds a different value on the Portable.

[DirtyHairy]

7800 detection works by checking for specific values in user RAM when cold start begins. VCS (the actual console) detection *could* work by checking for value $FD in the stack pointer (don't know if anybody has taken advantage of that yet). The portable has a definite playfield issue where updating the registers too soon (but still within the range allowed by actual hardware) can cause screen garble on the portable. So a short routine where a sprite collision with playfield could feasibly be used for AFP detection. However, this probably won't work once emulation gets better on newer versions of the portable.

 

Checking SP does not work if starting from harmony as the BIOS modifies it. There's a very useful test ROM by Omegamatrix that displays the initial state here: http://atariage.com/forums/topic/230219-startup-values-of-the-2600/?do=findComment&comment=3081055

Edited June 24, 2017 by DirtyHairy

[+Karl G]

Location 24 (decimal) holds a different value on the Portable.

 

It looks like you are correct! It holds 152 on the Portable, and 100 on Stella. I'm not sure what it shows on real hardware. So, for now at least, here's my kludgy AFP detection, in case anyone else finds it useful:

   temp1 = [24]
   if temp1 = 152 then PortableBit3{3} = 1

[Mr SQL]

 

 

It looks like you are correct! It holds 152 on the Portable, and 100 on Stella. I'm not sure what it shows on real hardware. So, for now at least, here's my kludgy AFP detection, in case anyone else finds it useful:

   temp1 = [24]
   if temp1 = 152 then PortableBit3{3} = 1

 

Excellent! Very cool you went with the Portables value to set the bit.

 

That location is different on the real hardware too, It may start out the same as in Stella but if you plug a Sega Pad in (or paddles) it changes - I've used it to make sure players used a Joystick for KC Munchkin and not a sega pad because KC bounces off the walls and you really need joystick precision to play.

 

Interesting thing I noticed on my Vader and Jr models is that over time, that value can change on it's own with the temperature.

 

Change time can vary between 20 minutes to a few hours with variable temp and a day or more in a climate controlled environment.

[Nukey Shay]

Actually, results would vary on actual hardware (since you're reading from a write-only register). Unreliable!

[DirtyHairy]

Nothing drives the bus, and, therefore, the result of the read is not well defined and may change over time.

 

To be more precise, a TIA read depends only on the lowest four bits of the address, so reading from 0x18 is the same as reading from 0x08, and that's INPT0. The TIA will only drive the highest three bit of the bus, and in the case of INPT0, that's either 0x00 or 0x80, depending on the charge of the capacitor in paddle readout circuit. The remainder of the bus is floating and will usually reflect its last driven state, but this can change and differ on real hardware. If the read is done via a "LDA $18", I would expect the result to either be 0x18 or 0x98 (=152). I am not sure why Stella gives you 100, but it is impossible to tell what is really going on without looking at the generated assembly. Do you perchance have "tiadriven" enabled?

Edited July 3, 2017 by DirtyHairy

[Nukey Shay]

batari Basic may or may not use illegal opcodes.

It does...wasting 3 cycles translates as a triple-NOP (WHY?? I dunno).

 

The Flashback Portable may or may not handle illegal opcodes.

Triple-NOP is supported by AFP. Ought to have supported Vblank better, but I digress.

[Mr SQL]

Actually, results would vary on actual hardware (since you're reading from a write-only register). Unreliable!

 

I think DirtyHairy is correct, it's the cap that's changing state over time with the temperature on real hardware and why the value changes when you plug in a sega pad or paddles. kdgarris used the AFP value which should be reliable on the AFP (no cap to change state).