bB with native 64k cart support - 1.1d.reveng

[+Gemintronic]

@Sprybug: I've got a very early build of Princess Rescue called smb.bas that says it's from 6/22/2012 in the VisualbB comments. No idea which topic I got it from. It doesn't compile when I go 64k. Works fine up to 32k. Can you double check your versions? I'm not sure if it's a bug or not. It compiles but just gets a black screen.

 

In other news RevEngs build actually FIXES batari's Rally-B example that no longer worked due to slight differences between bB versions. Very cool!

 

I'll keep rooting through my .bas files recompiling them all until I've got more to report

[Sprybug]

I don't really know vbb all that well, but I believe it's usage of bblint is optional, so the one without bblint is skipping the check.

 

If your non-working vbb is calling an older bblint version it would explain the wrong end count, so try updating its bblint, or forgo using bblint by renaming or deleting it.

I'll just stick with build 558 since it's what I've been using anyway and it seems to work out okay. Another question though, even though it compiled okay, it said I had 0 bytes in bank 16. Is that supposed to be at nil and are all the sprite/playfield tables automatically going to the last bank just as it was in the previous releases? I just tried to run my compiled program for the first time and nothing happens (black screen), could I have too many sprites/playfield info overmaxing the bank and it's not reporting that I'm going over?

[Sprybug]

@Sprybug: I've got a very early build of Princess Rescue called smb.bas that says it's from 6/22/2012 in the VisualbB comments. No idea which topic I got it from. It doesn't compile when I go 64k. Works fine up to 32k. Can you double check your versions? I'm not sure if it's a bug or not. It compiles but just gets a black screen.

 

In other news RevEngs build actually FIXES batari's Rally-B example that no longer worked due to slight differences between bB versions. Very cool!

 

I'll keep rooting through my .bas files recompiling them all until I've got more to report

Well I am planning on releasing the whole basic source once Albert releases the ROM. It works on the standard 32k compilation. If it doesn't work at 64k then I don't know what to say, just stick with the old compilers on it. Interesting that you just get a black screen, because that's what is happening to Zippy too with this new 64k release.

[+Gemintronic]

Well I am planning on releasing the whole basic source once Albert releases the ROM. It works on the standard 32k compilation. If it doesn't work at 64k then I don't know what to say, just stick with the old compilers on it. Interesting that you just get a black screen, because that's what is happening to Zippy too with this new 64k release.

 

I have no idea where I got it from. I assume you posted some code because I was having trouble with my own side scrolling efforts. It has no monsters and no sound - just the first part of the first level. Would it be okay to post so RevEng can see if it's truly a compiler error?

[Sprybug]

I have no idea where I got it from. I assume you posted some code because I was having trouble with my own side scrolling efforts. It has no monsters and no sound - just the first part of the first level. Would it be okay to post so RevEng can see if it's truly a compiler error?

Sure. anything to help out. I just tried setting my romsize to 32k on Zippy and it played fine, but once I go to 64k, black screen and bank 16 comes in at 0 bytes, where before on bank 8 at 32k I had just over 1000 bytes left (yeah, I have a lot of sprites).

[+Gemintronic]

Sure. anything to help out. I just tried setting my romsize to 32k on Zippy and it played fine, but once I go to 64k, black screen and bank 16 comes in at 0 bytes, where before on bank 8 at 32k I had just over 1000 bytes left (yeah, I have a lot of sprites).

 

You, Sir, are a True Gentleman!

smb.bas

[RevEng]

Thanks guys. I'll check it out and let you know.

[RevEng]

I found the cause. For 64k, the current bank detection for a regular "return" is faulty. I need to rethink a big chunk of this work.

 

For now, if you stick to using "return thisbank" and "return otherbank" with 64k binaries it will work. Other bankswitching schemes aren't affected.

[Sprybug]

I found the cause. For 64k, the current bank detection for a regular "return" is faulty. I need to rethink a big chunk of this work.

 

For now, if you stick to using "return thisbank" and "return otherbank" with 64k binaries it will work. Other bankswitching schemes aren't affected.

Good catch. Should I start reorganizing my routines that if they needed to be called by any bank at any time that they are in their own bank outside the ones being called, or wait for the fix to happen because I do have routines called up by various parts of the programs at pretty much any time.

[RevEng]

After looking at it for a while, I've come to the conclusion that to fix 64k support under bB, something has to give.

 

bB uses the high nibble of the gosub source address on the stack as a source bank identifier - so it doesn't need to store which bank it came from - which works great so long as your source addresses don't overflow that top nibble... like they do with the second half of a 64k program.

 

My current code abuses that top nibble to explictly refer to the bank # during a bankswitch gosub, and munges it back to a valid mirror address for the bankswitch return. Not a problem, except bB allows for using "return" to return from both regular gosubs and bankswitch gosubs, and there's no way for my 64k return code to discern which type of gosub was used. So either I munge local gosubs too (slower, wasteful of ROM), rewrite the whole thing to use stack memory to track the source bank too (slower, wasteful of RAM) or I can just restrict bB in 64k mode a wee bit and make bB coders aware of the restrictions. I didn't take the decision lightly, but I'm going to do the latter.

 

Henceforth if to create 64k binaries in this version of bB...

• you must explicitly use "gosub label bank#" with "return otherbank".
  
• you must explicitly use "gosub label" with "return" or "return thisbank". (under 64k in the recently posted version, "return" does the same as "return thisbank")
  

I suspect a great many bB coders already do this, due to "return thisbank" and "return otherbank" being much more efficient than "return", but I'm sure it will run contrary to someone's approach, so buyer beware.

 

None of this will apply to other bankswitch formats, which work just as they did under other bB releases.

 

The first post has the updated binary.

[RevEng]

Good catch. Should I start reorganizing my routines that if they needed to be called by any bank at any time that they are in their own bank outside the ones being called, or wait for the fix to happen because I do have routines called up by various parts of the programs at pretty much any time.

 

I can't get a fix without trading off too much ram or cycles, so time to re-org.

 

If you want a single routine that can be called from the local bank and other banks, then always call it with "gosub label bank#" and use "return otherbank", even from the local bank. There's a bit of a cycle penalty, so if the routine is called a lot you probably want to create a local version instead so you can use "gosub label" and "return".

[Sprybug]

I can't get a fix without trading off too much ram or cycles, so time to re-org.

 

If you want a single routine that can be called from the local bank and other banks, then always call it with "gosub label bank#" and use "return otherbank", even from the local bank. There's a bit of a cycle penalty, so if the routine is called a lot you probably want to create a local version instead so you can use "gosub label" and "return".

Alright, i can do that. It's still worth the trade-off to get an extra 32K of ROM, by a long shot. Thanks for looking into that for us. I'll reorganize my code in the near future, save it as a special 64k version in case I ever have to revert, give it a compile and let you know of the results.

[CPUWIZ]

 

[+Gemintronic]

Game with SARA chips require donor carts, correct?

 

Perhaps a sticky with acceptable donors should be posted somewhere. I've located sizes.txt but sifting through that has been pretty eye straining.

 

UPDATE: this post seems to give a pretty good list

Dig Dug

Crystal Castles

Millipede

Stargate

Defender II

Jr. Pac-Man

Desert Falcon

Dark Chambers

Super Football

Sprintmaster

Fatal Run

Off the Wall

Shooting Arcade

Secret Quest

Radar Lock

Save Mary!

KLAX

[Omegamatrix]

Here's another I came up with:

 

 

NTSC (rarity determined by AtariAge Database)

++++++++++++++++++++++++++++++

 

8k

===

Defender II - R4 red

Stargate - R4 silver

Elevator Action - prototype

 

16k

===

Crack'ed - prototype

Crystal Castles - R2 silver

Dark Chambers - R4 red

Desert Falcon - R4 red

Dig Dug - R2 silver

Jr. Pac-Man - R2 red

Klax - prototype

Millipede - R3 silver

Off the Wall - R5 red

Radar Lock - R4 red

Save Mary! - prototype

Secret Quest - R4 red

Shooting Arcade - prototype

Sprintmaster - R4 red

Super Football - R2 red

 

32k

===

Fatal Run - prototype

 

 

 

PAL (rarity determined by PAL Cart Database)

++++++++++++++++++++++++++++++

 

8k

===

Defender II - R5 red

Stargate - R4 silver

 

16k

===

Crystal Castles - R2 silver, R4 red

Dark Chambers - R4 red

Desert Falcon - R3 red

Dig Dug - R2 silver, R8 red

Jr. Pac-Man - R3 red

Klax - R4 red

Millipede - R4 silver, R3 red (with rainbow picture), R4 red

Off the Wall - R3 red

Radar Lock - R3 red

Save Mary! - prototype

Secret Quest - R4 red

Shooting Arcade - prototype

Sprintmaster - R3 red

Super Football - R3 red, R3 Red (7800 end label)

 

32k

===

Fatal Run - R4 red

[Sprybug]

Game with SARA chips require donor carts, correct?

 

Perhaps a sticky with acceptable donors should be posted somewhere. I've located sizes.txt but sifting through that has been pretty eye straining.

 

UPDATE: this post seems to give a pretty good list

Harmony is supposed to "emulate" the Sara, however in a 64k cart, the Harmony doesn't support that much ROM space, so you'd have to have a kind of Frankenstein's monster like this to do it. I don't think Albert would be able to support this with a big run of homebrew games.

[+Gemintronic]

Harmony is supposed to "emulate" the Sara, however in a 64k cart, the Harmony doesn't support that much ROM space, so you'd have to have a kind of Frankenstein's monster like this to do it. I don't think Albert would be able to support this with a big run of homebrew games.

 

..and then there's the problem of not being able to clone Albert from soy (yet). Say, if you need to release a game and Sprybug someone comes out with an AtariAge blockbuster you'll need to find alternative sources

[CPUWIZ]

Harmony doesn't support that much ROM space, so you'd have to have a kind of Frankenstein's monster like this to do it.

 

It only looks like that because it supports 8K,16K,32K and 64K + SARA at once, the ZIF sockets are purely for convenience and the switch toggles an address line from PLD controlled to VCC. I can have thousands of these boards made, the SARA chip is the key. Luckily Dig Dug and Crystal Castles are very common.

[Sprybug]

I can't get a fix without trading off too much ram or cycles, so time to re-org.

 

If you want a single routine that can be called from the local bank and other banks, then always call it with "gosub label bank#" and use "return otherbank", even from the local bank. There's a bit of a cycle penalty, so if the routine is called a lot you probably want to create a local version instead so you can use "gosub label" and "return".

One other question, since I was just going through my code, I was reminded that I made a few functions. At the end of a function, there's a return then a value number to return with. Now you can't put a thisbank or otherbank on those. Does this effect functions too?

[SeaGtGruff]

One other question, since I was just going through my code, I was reminded that I made a few functions. At the end of a function, there's a return then a value number to return with. Now you can't put a thisbank or otherbank on those. Does this effect functions too?

Based on compiling the sgn function example and looking at the assembly listing, it appears that when you return a value from a function, the value is placed in the Y register and then moved to the A register. I'm not sure why it's put in both places, because the calling code gets the return value from A. Anyway, if you need to return a value but need to return to a different bank, you could probably use inline assembly to load the return value into A and then use "return otherbank."

[RevEng]

One other question, since I was just going through my code, I was reminded that I made a few functions. At the end of a function, there's a return then a value number to return with. Now you can't put a thisbank or otherbank on those. Does this effect functions too?

 

Since bB doesn't auto-bankswitch when it calls functions (it just does a "jsr .function") I'll treat it as a special case of "gosub label", that is, in a 64k binary "return value" will do a local return.

 

That said, l need to modify the "return value" 64k code to keep the right return value. Right now it's trying to bankswitch back and messing up the value.

 

For now either do as SeaGtGruff suggests, or just stick the value in an unused temp# variable and just use plain old "return".

[SeaGtGruff]

For now either do as SeaGtGruff suggests, or just stick the value in an unused temp# variable and just use plain old "return".

Note, if you want to try what I suggested, it turns out you'll need to modify both the function definition and the function call. I did it successfully last night-- modified the "sgn" function example from Random Terrain's web page to set the return value using inline assembly and return from the function call using "return otherbank," but then I had to modify the call to use inline assembly as well so it could call the function in another bank. So it's doable, but not elegant.

 

An alternative is to put all statements that call the functions in the same bank as the functions, then use gosubs to go to the specific call statement you want to use. That would use more cycles because you'd have nested subroutines.

[RevEng]

Now you can't put a thisbank or otherbank on those.

 

Actually, I just noticed that the bB source code allows for "return [value] thisbank" and "return [value] otherbank". If you use the former with 64k and (local) function calls, it works as expected.

[+stephena]

SInce you're kind of defining the EF format for bB, maybe now is the time to add better autodetection for Stella. The current string(s) that Stella searches for are a result of the EF ROMs in the wild, but there's no reason that we couldn't add a more specific string to search for. For example, the 4A50 scheme actually stores $4A $50 in the ROM, and DPC+ does something similar. Maybe a 'EFEF' string could be added at some set location, and similar done for the SC version ('EFSC').

 

Vintage bankswitch schemes have to resort to heuristics to determine the correct type, but there's no reason to do this for future EF ROMs, since the format is relatively new. PM me for further discussion if you're interested in this.

 

Sorry to respond to myself. WRT this item, I plan to do the 3.9.1 release sometime in the next few weeks. It would be great if this could be finalized and added for then.

[SeaGtGruff]

Actually, I just noticed that the bB source code allows for "return [value] thisbank" and "return [value] otherbank". If you use the former with 64k and (local) function calls, it works as expected.

But what about calling a function in another bank? Is it just "a=myfunction(b) bank2"?