Jump to content

Photo

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


349 replies to this topic

#26 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,829 posts

Posted Sun Jul 28, 2013 9:53 PM

@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 :)

#27 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 540 posts

Posted Sun Jul 28, 2013 10:10 PM

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?

#28 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 540 posts

Posted Sun Jul 28, 2013 10:14 PM

@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.

#29 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,829 posts

Posted Sun Jul 28, 2013 10:21 PM

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?

#30 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 540 posts

Posted Sun Jul 28, 2013 10:25 PM

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).

#31 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,829 posts

Posted Sun Jul 28, 2013 10:26 PM

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!

Attached Files

  • Attached File  smb.bas   13.09KB   195 downloads


#32 RevEng ONLINE  

RevEng

    River Patroller

  • Topic Starter
  • 4,674 posts
  • Bitnik
  • Location:Canada

Posted Sun Jul 28, 2013 10:44 PM

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

#33 RevEng ONLINE  

RevEng

    River Patroller

  • Topic Starter
  • 4,674 posts
  • Bitnik
  • Location:Canada

Posted Mon Jul 29, 2013 9:49 AM

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.

#34 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 540 posts

Posted Mon Jul 29, 2013 4:44 PM

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.

#35 RevEng ONLINE  

RevEng

    River Patroller

  • Topic Starter
  • 4,674 posts
  • Bitnik
  • Location:Canada

Posted Mon Jul 29, 2013 5:58 PM

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.

#36 RevEng ONLINE  

RevEng

    River Patroller

  • Topic Starter
  • 4,674 posts
  • Bitnik
  • Location:Canada

Posted Mon Jul 29, 2013 6:03 PM

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".

#37 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 540 posts

Posted Mon Jul 29, 2013 9:52 PM

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.

#38 CPUWIZ OFFLINE  

CPUWIZ

    Sheriff

  • 32,214 posts
  • Cartridge Recycler
  • Location:SoCal

Posted Mon Jul 29, 2013 9:57 PM

:cool:



#39 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,829 posts

Posted Mon Jul 29, 2013 11:02 PM

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



#40 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • 6,122 posts
  • Location:Canada

Posted Mon Jul 29, 2013 11:24 PM

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

#41 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 540 posts

Posted Mon Jul 29, 2013 11:53 PM

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.

#42 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,829 posts

Posted Mon Jul 29, 2013 11:56 PM

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 :)

#43 CPUWIZ OFFLINE  

CPUWIZ

    Sheriff

  • 32,214 posts
  • Cartridge Recycler
  • Location:SoCal

Posted Tue Jul 30, 2013 2:08 AM

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. ;)

#44 Sprybug OFFLINE  

Sprybug

    Dragonstomper

  • 540 posts

Posted Tue Jul 30, 2013 2:40 AM

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?

#45 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Tue Jul 30, 2013 2:58 AM

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."

#46 RevEng ONLINE  

RevEng

    River Patroller

  • Topic Starter
  • 4,674 posts
  • Bitnik
  • Location:Canada

Posted Tue Jul 30, 2013 9:08 AM

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".

#47 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Tue Jul 30, 2013 10:17 AM

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.

#48 RevEng ONLINE  

RevEng

    River Patroller

  • Topic Starter
  • 4,674 posts
  • Bitnik
  • Location:Canada

Posted Tue Jul 30, 2013 11:29 AM

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.

#49 stephena OFFLINE  

stephena

    River Patroller

  • 2,961 posts
  • Stella maintainer
  • Location:Newfoundland, Canada

Posted Tue Jul 30, 2013 12:20 PM

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.

#50 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Tue Jul 30, 2013 12:35 PM

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"?




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users