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

[RevEng]

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.

 

Ok, I'll take a look where the best place for the autodetect string might be... probably before the vector info in the last bank.

 

I'll PM you with a test later this week.

[RevEng]

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

 

Interestingly, function calling doesn't appear to have bankswitch capability at all. Its hardcoded to use "jsr". It only appears to be function returning that can do bankswitching. (Since it's just a special "return" case, that part isn't all that surprising I guess)

[Sprybug]

Been changing the code all the returns have thisbank or otherbank and all the gosubs are going to proper banks. Bank 16 still reports 0 bytes available and I'm still getting a black screen, even before any calls to any functions I have made are done. What I can do is start a new basic file and start transferring code little by little over to the new source and compiling it until things start going wrong to try to determine what's going on.

[jwierer]

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.

if bblint is in the same folder as visualbB, it will try to run your code through bblint before compiling. If it's not there well then nothing happens.That explains the difference. Grabbing the latest bblint should remove the warnings, or just remove it from the folder.

 

-Jeff

[SeaGtGruff]

Been changing the code all the returns have thisbank or otherbank and all the gosubs are going to proper banks. Bank 16 still reports 0 bytes available and I'm still getting a black screen, even before any calls to any functions I have made are done. What I can do is start a new basic file and start transferring code little by little over to the new source and compiling it until things start going wrong to try to determine what's going on.

When I tried to call a user function last night, I was getting a black screen when trying to do it with bankswitching. I don't know if the reason's the same in your case, but in my case it was because I was trying to let batari Basic call the user routine but it was located in another bank and I hadn't yet figured out that I needed to call the function manually with inline assembly so I could switch banks. Thus, it was gosubbing to the correct ROM address for the user function, but not in the correct bank, causing the program to crash. You might be running into a similar type of issue-- trying to goto or gosub to a routine and you're ending up at the correct address but in the wrong bank.

[RevEng]

I'm still getting a black screen

I'd be happy to look at it if you PM it to me.

[RevEng]

Version 5 with the "return value" fix for 64k roms is in the first post.

 

We fixed Sprybug's problem tonight, which was tracked down to his using my old multiple font score_graphics.asm file. It wasn't aware of how to position itself in a 64k rom.

 

The game looks great!

[RevEng]

Thanks to some of sprybug's bug reports and some insights from valgrind, I've fixed some general bB issues...

• Added more conditional padding to pfheights table. Previously, if you were using pfheights without pfcolors and the pfheights table started in the first 20 bytes of a page, the playfield display would be corrupted due to page crossing. This would come and go as you add code to your program and the table shifted position in rom.
  
• Increased statements** memory allocation in 2600bas.c to match the 100x100 usage in statements.c. Sometimes unintended memory was being overwritten.
  
• Added length check to statement** population code in 2600bas.c. REM statements with long strings of non-space characters would overflow the memory, causing unintended memory to be overwritten.
  

 

If previously you ran into "unhandled exception" errors in later versions of Windows, this will probably fix it. Version 6 is in the first post.

[+Random Terrain]

I'm about to add a link to this from the bB page. Is this basically the same as the 32k Multikernel Framework, but with 64k instead?

[RevEng]

No. This is the same as regular 1.1d bB, except it has 64k rom format support and a number of general bB fixes. The provided 64k format works pretty much the same as the existing bB bankswitching schemes (kernel is in the last bank, along with all of the graphics) with the exception of a few 64k-specific rules listed in the first post.

 

My hope is batari will adopt most of this project into the main bB distribution, when the dust has settled a bit.

 

I'll probably release a 64k Multikernel Framework at some point in the future, for those that want projects with multiple kernels/sprites/playfields.

[+Random Terrain]

No. This is the same as regular 1.1d bB, except it has 64k rom format support and a number of general bB fixes. The provided 64k format works pretty much the same as the existing bB bankswitching schemes (kernel is in the last bank, along with all of the graphics) with the exception of a few 64k-specific rules listed in the first post.

 

My hope is batari will adopt most of this project into the main bB distribution, when the dust has settled a bit.

 

I'll probably release a 64k Multikernel Framework at some point in the future, for those that want projects with multiple kernels/sprites/playfields.

 

 

Thanks. So has this made my wish come true and removed the 7,000 step process to get a bug-free DPC+ version of bB that I mentioned here:

 

http://atariage.com/forums/topic/214487-are-we-all-programming-on-the-same-page/#entry2792049

[RevEng]

That's the intent. If it has any bugs, they aren't ones that are publicly known.

[+Random Terrain]

It's now on the bB page:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#akmme_64k_bb

 

Since this has removed the 7,000 step process that I mentioned in my post above, it looks like it's time for me to try to make DPC+ programs. Is there an up-to-date explanation for how to make DPC+ games? If so, I need to start adding it to the bB page in a new section.

[CPUWIZ]

Just keep in mind, that 64K + DPC+ will not work.

[+Random Terrain]

Just keep in mind, that 64K + DPC+ will not work.

 

Thanks. I'll need to make sure that's clear when we compile some updated DPC+ information to add to the bB page. But it will work for up to 32k, right?

[CPUWIZ]

Yep.

[RevEng]

I'm not sure there's any one place for DPC+ info. It's mostly spread out.

 

Check out the bundled msdpc.bas in the samples directory, as well as batari's release thread.

 

We really need a DPC+ features example page, at least to bootstrap the official docs.

[+Random Terrain]

I'm not sure there's any one place for DPC+ info. It's mostly spread out.

 

Check out the bundled msdpc.bas in the samples directory, as well as batari's release thread.

 

We really need a DPC+ features example page, at least to bootstrap the official docs.

 

Thanks. I'll compile whatever I find and post it in a new thread and ask people to check it to make sure everything is correct.

[RevEng]

Version 7 is in the first post.

 

Using the DPC+ pull command with multiple values and ranges wasn't working as intended. Fixed.

[RevEng]

Version 8 is in the first post. I fixed a bug in the multisprite header that I introduced when I added 64k support.

[RevEng]

My 2600 is packed away at the moment. Does anyone care to see if this "mystery" binary runs on harmony like it does in stella?

 

dpcpfread.bas.bin

[CPUWIZ]

My 2600 is packed away at the moment. Does anyone care to see if this "mystery" binary runs on harmony like it does in stella?

 

dpcpfread.bas.bin

 

Crashes horribly, but I have not updated my Harmony, since I got it (first run #3 - virgin). So it's probably not a huge surprise.

[RevEng]

Yeah, it's a DPC+ binary, and the first harmony firmware didn't have DPC+ support. Thanks for giving it a shot, though.

 

Anybody with a DPC+ compatible firmware care to try?

[+Random Terrain]

My 2600 is packed away at the moment. Does anyone care to see if this "mystery" binary runs on harmony like it does in stella?

 

dpcpfread.bas.bin

 

I downloaded and installed this:

 

http://sourceforge.n...monycart/files/

 

I downloaded a couple of other programs directly to the Harmony cart and they worked. But when I download dpcpfread.bas.bin to the Harmony cart and turn on the Atari, the last program downloaded runs instead of that. Is there something special that I need to do?

 

Is it because the ROM size is 32768 bytes? I just answered my own question. It's not the size because Seaweed Assault is the same size and it works.

[+stephena]

Yeah, it's a DPC+ binary, and the first harmony firmware didn't have DPC+ support. Thanks for giving it a shot, though.

 

Anybody with a DPC+ compatible firmware care to try?

 

I put it on the SD card and loaded it that way. The score at the bottom of the screen is being updated as in Stella (and are stable), but the blue graphics at the top are jumping up and down. It could be my TV, or maybe vsync/vblank issues that Stella isn't emulating.