Feature Request: 7800 detect with bB

[vdub_bobby]

It would be cool if the next version of bB could detect whether or not the program was running in a 7800 or a 2600 (see here: http://www.atariage.com/forums/index.php?s...t&p=1148175 for code). Since more folks are putting bB games on carts, this would be a useful option to have that would require minimal extra code.

 

I know that jbanes, at least, was looking for something like that (follow link).

Edited October 3, 2006 by vdub_bobby

[jbanes]

And here I was just working out how to do exactly that!

 

It shouldn't be too tough for those who like to customize. You just need to rework the bBASIC startup.asm routines a bit. The only downside is that you need a variable in which to store the value. The current revision of bBASIC completely uses up all available memory. If you use custom routines, you can place the flag in one of the 26 scratch variables. If it becomes a standard routine, then you'd need to give something up. For example, using player1 colors costs missile1, so the variable is reassigned to the handle the colors.

[+batari]

It would be cool if the next version of bB could detect whether or not the program was running in a 7800 or a 2600 (see here: http://www.atariage.com/forums/index.php?s...t&p=1148175 for code). Since more folks are putting bB games on carts, this would be a useful option to have that would require minimal extra code.

 

I know that jbanes, at least, was looking for something like that (follow link).

Good idea! Here's an updated startup.asm file with relevant code. When your bB code begins, temp1 will contain 0 if it's a 2600, or 255 if it's a 7800. It's up to the programmer to copy it to memory somewhere else before temp1 gets overwritten by a routine or the kernel.

startup.zip

[vdub_bobby]

Cool! Now that's service!

Edited October 3, 2006 by vdub_bobby

[SeaGtGruff]

It would be cool if the next version of bB could detect whether or not the program was running in a 7800 or a 2600

Good idea! Here's an updated startup.asm file with relevant code.

By the way, Fred, I never emailed you anything about the Superchip, but I posted some modified includes for it in this forum, and I figured you could probably figure most of it out from there. The only other thing-- besides adding a "set" command so there's no need for the "dim superchip" workaround-- is to change the way the bB compiler handles the extra bankswitching code that it places at the end of every bank. Basically, when you add the extra bankswitching code at the end of a bank, followed by the "ORG" and "RORG" for the next bank, you need to fill the first 256 bytes of the new bank with "$FF" (easiest way is to just include the "fill_256.asm" file at that point). This will reserve the first 256 bytes of each bank for the Superchip, and filling those bytes with "$FF" should help the emulators auto-detect the cartridge format (at least, z26 auto-detects it correctly, although Stella seems to have a problem auto-detecting the 8KSC format). If you add official support for the Superchip, it's up to you whether to restrict it to bankswitching. My original modifications ignored the Superchip stuff if the game didn't use bankswitching, but after you posted your idea of doubling up a 4K-Superchip ROM so the emulators can handle it, I decided to allow the Superchip to be included in 4K games as well, on the assumption that CPUWIZ can make 4KSC boards for anyone who wants to design a 4KSC homebrew game and sell it.

 

MR

[jbanes]

If it becomes a standard routine, then you'd need to give something up.

 

Ooooor, you could just use a variable that's obliterated after the first drawscreen.

 

When your bB code begins, temp1 will contain 0 if it's a 2600, or 255 if it's a 7800. It's up to the programmer to copy it to memory somewhere else before temp1 gets overwritten by a routine or the kernel.