Jump to content
IGNORED

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


RevEng

Recommended Posts

I've finished adding the 64k/64kSC cart format to bB. (originally shown in the teaser thread.) The 64k support required changes to the bB binaries themselves, so you should plan to put it in a new bB directory if you want to use it.

 

All of the bug fixes to 1.1d that I'm aware of have been added here. Hopefully at some point batari will roll this up into the official dist.

 

Windows, Linux, and OS X 32-bit x86 binaries are included, which are compatible with the 64-bit versions of the OSes. For other CPUs and other Unix-like OSes, you should be able to type "make" in the main directory to rebuild the binaries, assuming a recent C compiler, make, and lex/flex are installed.

 

The included samples directory has a 64kbb.bas 64k cart example, as well as a 64kSC.bas 64kSC superchip cart example.

 

Download from 8bitdev.org

 

 

N.B.: When building 64k roms with 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, "return" is the same as "return thisbank")
  • Like 14
Link to comment
Share on other sites

Harmony maxes out at 32k, so no.

64k (EF) runs in stella. I even ensured that format autodetection worked by sticking an instruction that stella was looking for in a small bit of unused rom.

64k isn't available with DPC+, due to the fact that Harmony/Melody maxes out at 32k.

Link to comment
Share on other sites

I just overwrote my batariBASIC directory with your latest files. I compiled and playtested my latest game with these settings just fine:

 

set kernel_options player1colors pfcolors

set romsize 16k

 

I have an "ascension" scene that relies on batari BASIC jittering the score as I play havoc with the player1height and player1pos. It still shakes just fine!

  • Like 1
Link to comment
Share on other sites

The included samples\msdpc.bas could probably be removed so as not to confuse people (doesn't compile).


Compile started at 7/27/2013 11:03:57 PM
Compiling C:\BatariBASIC\samples\msdpc.bas
2600 Basic compilation completed.
DASM V2.20.07, Macro Assembler (C)1988-2003
free ram: 9
DPC free RAM=
 bytes of ROM space left in bank 1
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to and try again.
 bytes of ROM space left in bank 2
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to and try again.
 bytes of ROM space left in bank 3
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to and try again.
 bytes of ROM space left in bank 4
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to and try again.
 bytes of ROM space left in bank 5
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to and try again.
 bytes of ROM space left in bank 6
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to and try again.
 bytes of ROM space left in graphics bank
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
free ram: 9
DPC free RAM= 603
 107 bytes of ROM space left in bank 1
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
 2961 bytes of ROM space left in bank 2
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
 3924 bytes of ROM space left in bank 3
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
 3924 bytes of ROM space left in bank 4
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
 3924 bytes of ROM space left in bank 5
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
 3924 bytes of ROM space left in bank 6
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
 3324 bytes of ROM space left in graphics bank
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
free ram: 9
DPC free RAM= 603
 107 bytes of ROM space left in bank 1
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
 2961 bytes of ROM space left in bank 2
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
 3924 bytes of ROM space left in bank 3
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
 3924 bytes of ROM space left in bank 4
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
 3924 bytes of ROM space left in bank 5
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
 3924 bytes of ROM space left in bank 6
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
 3324 bytes of ROM space left in graphics bank
WARNING: size parameter in banksw.asm too small - the program probably will not work.
Change to 34 and try again.
Compilation completed at 7/27/2013 11:03:57 PM
view output file:///C:/BatariBASIC/samples/bin
Post compilation files deleted

Link to comment
Share on other sites

Got it to compile, and it looks great!

 

 

I was wondering if you can add an extra wrapper around the echo statements in statements.c, so that the amount of bytes left in each bank would not be repeated unless many passes are done. I think this will work:

 

 

 printf(" IF ECHO%d\n",bank-1);
 printf(" echo \"    \",[(start_bank%d - *)]d , \"bytes of ROM space left in bank %d\")\n",bank-1,bank-1);
 printf(" ENDIF\n");
 printf(" ECHO%d = 1\n",bank-1);

 

 

There is a hidden danger in bankswitching. RevEng, you know the basic structure of how BB is allocating memory so maybe you can decide if it will be a problem. Simply put, a branch from the last page in the bank to the second last page (say $FFxx to $FExx) now has a big chunk rom that will actually trigger hotspots. That is, if you are branching to from $FFxx to $FEE0-$FEEF, then the high address remains as $FF before it gets corrected to $FE, and you will trigger a bankswitch and likely crash the program.

 

 

If BB is assigning data in this region then that will solve the problem. Otherwise it would be nice if the process could check and avoid these dangers through some padding...

 

 

Keep up the great work,

Jeff

Link to comment
Share on other sites

Melody maxes out at 32k.

 

Melody

Additionally, Melody boards can be built with a 128K Flash chip, replacing the Melody's standard 32K of Flash memory. And if 8K of RAM isn't enough for you, up to 64K of RAM can be added instead. This allows for a Melody board containing 128K of Flash memory and 64K of RAM. And if that's not enough, the Melody can be fitted with an optional EEPROM chip up to 4MB in size!

 

DPC+ would need to be modified to support more that a 32k flash memory.

  • Like 1
Link to comment
Share on other sites

I can't wait to give this a try. I'll keep my fingers crossed. My zippy code is REALLY LARGE right now and I won't be surprised if it barfs on it.

BTW, in an unrelated thing I spent a lot of Saturday programming the Hill Zone music and it doesn't sound bad actually. I'll include info about it in my Zippy thread later.

Edited by Sprybug
  • Like 1
Link to comment
Share on other sites

Thanks for all of the thank-you's and kind words, guys. Fingers crossed that we'll see some new 64k homebrews come out of this!

 

 

While you are messing with the source, can you add a help command that returns an accurate version so it's easy to tell the different compiler versions apart?

 

Since it's a small change I'll add that when the next bug fix goes in. Overall I'm trying to avoid making changes, other than 64k support and bug fixes, so its easier for batari to audit and accept.

 

 

I was wondering if you can add an extra wrapper around the echo statements in statements.c, so that the amount of bytes left in each bank would not be repeated unless many passes are done.

 

dasm doesn't assign a value to the "bytes of ROM space left" calculation in the first pass, due to not knowing start_bank# because the echo proceeds those labels. Also, it might not know other banks in later passes if conditional assembly and assembly includes are used.

 

Here's a sample compile of a simple 16k rom with a kernel test I built a while back...

 

DASM V2.20.09, Macro Assembler (C)1988-2003
bytes of ROM space left in bank 1
bytes of ROM space left in bank 2
3941 bytes of ROM space left in bank 1
bytes of ROM space left in bank 2
3941 bytes of ROM space left in bank 1
1788 bytes of ROM space left in bank 2
Complete.
Build complete.

 

Since there's no way of knowing which pass will be the final one ahead of time, I agree with batari's solution to punt and just repeat the information each pass. (annoying as it may be)

 

[edit - looks like I misread your post the first time around. skipping the first pass for bank switching roms can be done, for sure.]

 

 

There is a hidden danger in bankswitching...

 

Thanks for the warning! bB keeps the hotspots themselves out of reach of the bB coder. The user bB code gets the space from the start of the bank to the beginning of the bank switching code, and the bank switching code itself proceeds the hot spots. The area from the beginning of the hot spots to the end of the rom aren't available to user bB code.

Link to comment
Share on other sites

64k (EF) runs in stella. I even ensured that format autodetection worked by sticking an instruction that stella was looking for in a small bit of unused rom.

 

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.

  • Like 1
Link to comment
Share on other sites

dasm doesn't assign a value to the "bytes of ROM space left" calculation in the first pass, due to not knowing start_bank# because the echo proceeds those labels.

 

Yes, that is right. The wrapper I designed ignores the first pass, and does passes 2 and up. If "bank" gets obliterated perhaps something else could be used as a counter. If not, then it was just a nice to have feature anyway and nothing mission critical.

 

 

Thanks for the warning! bB keeps the hotspots themselves out of reach of the bB coder. The user bB code gets the space from the start of the bank to the beginning of the bank switching code, and the bank switching code itself is proceeds the hot spots. The hot spot rom is off-limits.

 

Then this will happen from time to time. It can happen with lots of bankswitching schemes... but as soon as you get to a large chunk of uninterrupted bytes like $FEE0-$FEEF, then the chances of hitting one with a branch increases. It would be nice to have some type of post process check for this and give a warning.

Link to comment
Share on other sites

Yes, that is right. The wrapper I designed ignores the first pass, and does passes 2 and up. If "bank" gets obliterated perhaps something else could be used as a counter. If not, then it was just a nice to have feature anyway and nothing mission critical.

 

Yeah, clued in just as you were posting this and was editing my original. Definitely this could be added.

 

 

Then this will happen from time to time. It can happen with lots of bankswitching schemes... but as soon as you get to a large chunk of uninterrupted bytes like $FEE0-$FEEF, then the chances of hitting one with a branch increases. It would be nice to have some type of post process check for this and give a warning.

 

Got ya now. Where does the "fix" delay in update come from here? Does the address line change a byte at a time instead of atomically when a branch crosses a page boundary, hence the extra cycle penalty?

 

Presently there's no guard for that in bB. I hear you that it's more likely to happen with twice the number of hotspots than 32k... gotta think this over a bit.

 

Thanks for the education!

Link to comment
Share on other sites

I don't know how big the issue is since I just got my hands on this. Maybe one of my earlier suggestions could be a workaround.

 

I mentioned a hybrid multi-kernel scheme. Maybe divvy things up by master switches. Say, 2 32k kernels that each see their own respective 32k. Or, 4 16k kernels that each think they own their own 16k of ROM. A new "master switch" command could be added to bB to switch between kernels.

Link to comment
Share on other sites

I don't know how big the issue is since I just got my hands on this.

 

Its new to me, but apparently it's an issue for a branch from the last 256 bytes of the rom to a certain 16 bytes in the second last 256 bytes of rom. Gotta go look if bB constructs any backward moving branches. I don't recall any. It might not. [edit - a "for... next" loop crossing that final page boundary would be one possible source]

 

If I understand correctly, the same problem exists for 32k bankswitching in bB, but the range of bytes that would trigger it from a branch destination would be 8 bytes. and 16k would have 4 bytes that might trigger it.

 

This isn't a show stopper by any means. It would probably be rare to hit it - about twice as frequently as we're currently hitting it with 32k - but the nice thing to do would be to flag it.

 

 

Maybe one of my earlier suggestions could be a workaround.

 

The same hotspots would be ultimately involved in your suggestions, so I don't think there's a solution there.

Link to comment
Share on other sites

If I understand correctly, the same problem exists for 32k bankswitching, but the range of bytes that would trigger it would be 8 bytes. and 16k would have 4 bytes that might trigger it.

 

Yes, that is correct. I first found the issue here. I think this is something that would be really hard to debug in BB. It may have already happened to a BB user before without them knowing it. The game would just crash for no reason. They might have changed a few lines of code and it would work again when the branch moved out of that critical area (like going to $FEE8-$FEE9 from $FFxx for F8 bankswitching). However, with 64K bankswitching you have a much larger area to avoid, and changing a few lines of code might not be enough to move the branch. It would cause a lot of grief to the BB user since everything looks okay in their code.

 

 

Also, a little of topic, but this glitch is useful as technique to purposely bankswitch without a cycle penalty. You could check a flag, and if true bankswitch to do something, otherwise continue in the current bank. The bankswitch is for free as it is already part of the decision process. I did demo of triggering the bankswitches here, but it's not much to see. Just a green screen ha ha.

 

Edit: You would pay a +1 cycle penalty for crossing the page boundary on the branch though.

  • Like 1
Link to comment
Share on other sites

Ok, thanks again for the education - I understand it much better now, and managed to trigger it intentionally with a test program. (stella rocks!)

 

I think I can add a conditional echo into the generated "for... next" assembly code that will spit a warning out when the branch is from the last page to an address in the previous page that has a low byte the same as a hot spot.

 

I need to do some auditing to be sure, but I think "for... next" is the only bB code that would generate reverse branches. [edit - looks like I'll also need to handle "if...then label"]

Link to comment
Share on other sites

the first post now has an updated v3 version.

 

Additions include reverse branch hotspot warning, suppression of the first pass "ROM space left" output, and "-v" version switch for 2600basic.exe.

 

I also added a "64kbranchbug.bas" branch bug triggering test to the samples directory, in case anybody was curious to see the output.

 

Thanks for all the input, guys!

  • Like 1
Link to comment
Share on other sites

the first post now has an updated v3 version.

 

Additions include reverse branch hotspot warning, suppression of the first pass "ROM space left" output, and "-v" version switch for 2600basic.exe.

 

I also added a "64kbranchbug.bas" branch bug triggering test to the samples directory, in case anybody was curious to see the output.

 

Thanks for all the input, guys!

Okay RevEng, I gave it a shot.

 

I currently run 2 version of VbB depending on what I'm doing.

I usually run build 558 because I find it a little less buggy, doesn't crash and I don't take advantage of the newer features.

It runs BEAUTIFULLY IN IT. Coimpiles Zippy at 64k with no errors to report.

 

However, like I've been finding with build 566, something goes wrong when I use that version.

Here's what I get when I try to compile with that version of VbB:

 

[7/28/2013 6:45:33 PM] bblint found the following errors in zippy05.bas

warning(): Found 113 commands that use end, and 115 "end" commands.

Precompilation failed, aborted at 7/28/2013 6:45:41 PM

 

I went through my entire code using Find "End" and they all seemed to be assigned to where they need to be and I don't see any extra ends hanging around. Yet, using build 558 of VbB seems A-OK! I don't get it.

  • Like 1
Link to comment
Share on other sites

It may just be an old copy of bblint. Try copying the latest one into your vbb directory.

 

If that doesn't fix it, PM me the source and I'll try to track it down.

Hmm. I have just one bblint file in my entire VbB related directories and its bblint.win32 in the one for build 566. The directory for build 558 doesn't have one and that's the one that seems to work fine.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...