Superchip Bankswitching in bB

[SeaGtGruff]

batari BASIC version 0.99 lets you create 8K, 16K, and 32K games using the Atari F8, F6, and F4 bankswitching schemes. And with some simple changes to a few of bB's include files, you can create games using the Atari F8SC, F6SC, and F4SC bankswitching schemes. These are identical to the F8, F6, and F4 bankswitching schemes, except they include an additional 128 bytes of RAM in the Atari Superchip.

 

To add the Superchip changes to bB, download and unzip the appropriate attachment, then move the enclosed files into the directory where you keep bB's include files. Note that there are three patches, depending on which version of 0.99 you're using (0.99a, 0.99b, or 0.99c).

 

DO NOT TRY TO APPLY THESE PATCHES TO ANY VERSIONS BEFORE 0.99 (although those versions didn't support Atari bankswitching, anyway).

 

From now on, I'm going to refer to the "Superchip patch" as bB versions 0.99a2, 0.99b2, and 0.99c2. (I wanted to call it version 0.99d, but since there are three different patches, they need different names.)

 

The changes to the include files are as follows:

 

2600basic.h -- This file defines the addresses for bB's variables. If the option for the Superchip is specified in your bB program, then bB will include the superchip.h file (see below).

 

2600basicheader.asm -- This file sets the starting address for your bB program, depending on the ROM size that you've selected. If the option for the Superchip is specified in your bB program, then bB will fill the first 256 bytes of the ROM with a value of $FF, because these bytes are used for the Superchip's RAM. Your bB program will actually begin after these 256 "reserved" bytes.

 

fill_256.asm -- This is a new include file. It fills 256 bytes of memory with a value of $FF, and is used in 2600basicheader.asm and std_kernel.asm. If you're creating a 16K or 32K Superchip game, you must also include it in your game code, as described below.

 

std_kernel.asm -- This file contains bB's standard display kernel. If you've selected a ROM size that requires bankswitching (i.e., 8K, 16K, or 32K), then bB puts the display kernel at the beginning of the last bank. If the option for the Superchip is specified in your bB program, then bB will fill the first 256 bytes of the last bank with a value of $FF, and the display kernel will begin after these "reserved" bytes.

 

superchip.h -- This is a new include file. It defines the addresses for 128 new variables in the Superchip RAM area. These must be written to and read from using two different addresses, so each variable has been defined twice, as described below.

 

Once you've applied the appropriate Superchip patch, you're ready to start using Superchip bankswitching in your bB programs. However, there are a few rules you'll need to keep in mind.

 

The Superchip option is available only for 8K, 16K, and 32K games. If you try to specify the Superchip option in a 2K or 4K game, it won't work. To specify the Superchip option, simply "dim superchip" to some variable, as in the following example:

 

  set romsize 8k
  dim superchip = y

 

This is actually just a workaround to make bB add "superchip" to its list of constants, so the DASM assembler will know to compile the bB program in the appropriate manner. After batari officially adds support for the Superchip to bB, the Superchip option will probably need to be specified in some other fashion (presumably with a "set" statement).

 

If you specify the Superchip option in a bankswitched game, bB will automatically set aside the first 256 bytes of the first and last banks for the Superchip RAM, but right now there's no easy way to make bB automatically set aside the first 256 bytes of any other banks (since that will require a modification to the bB compiler itself). This means that if you select a ROM size of 16K or 32K, you'll need to add some inline assembly code at the beginning of some of the banks, as follows:

 

  set romsize 16k
  dim superchip = y

  rem * bank 1 code goes here

  rem **************************

  bank 2 : rem * start of bank 2

  asm
  include "fill_256.asm"
end

  rem * bank 2 code goes here

  rem **************************

  bank 3 : rem * start of bank 3

  asm
  include "fill_256.asm"
end

  rem * bank 3 code goes here

  rem **************************

  bank 4 : rem * start of bank 4

  rem * bank 4 code goes here

 

  set romsize 32k
  dim superchip = y

  rem * bank 1 code goes here

  rem **************************

  bank 2 : rem * start of bank 2

  asm
  include "fill_256.asm"
end

  rem * bank 2 code goes here

  rem **************************

  bank 3 : rem * start of bank 3

  asm
  include "fill_256.asm"
end

  rem * bank 3 code goes here

  rem **************************

  bank 4 : rem * start of bank 4

  asm
  include "fill_256.asm"
end

  rem * bank 4 code goes here

  rem **************************

  bank 5 : rem * start of bank 5

  asm
  include "fill_256.asm"
end

  rem * bank 5 code goes here

  rem **************************

  bank 6 : rem * start of bank 6

  asm
  include "fill_256.asm"
end

  rem * bank 6 code goes here

  rem **************************

  bank 7 : rem * start of bank 7

  asm
  include "fill_256.asm"
end

  rem * bank 7 code goes here

  rem **************************

  bank 8 : rem * start of bank 8

  rem * bank 8 code goes here

 

Note that you *must* put this "include" statement inside of an "asm" section, because if you don't, bB will process the "include" statement before it gets to the DASM assembler, and the desired code won't be included where it needs to be. These "include" statements are necessary *only* for 16K or 32K Superchip games, and *only* at the very beginning of the banks indicated above (banks 2 and 3 for a 16K game, and banks 2, 3, 4, 5, 6, and 7 for a 32K game). After batari officially adds Superchip support to bB, you shouldn't have to add these "include" statements to any of the banks, because the bB compiler should take care of this automatically.

 

As stated earlier, I've already defined 128 additional variables for the Superchip RAM. There are 26 user variables in bB, named "a" through "z," which are easy variable names to remember, but I didn't want to create variable names like "aa" or "ab" for the Superchip RAM. For one thing, there's no way to be sure that someone isn't using a particular combination of letters in their existing bB programs. Therefore, for the Superchip RAM variables I decided to just number the variables from 000 through 127. Each variable must be defined twice-- once for writing to RAM, and then again for reading from RAM-- so I've put "w" in front of the number for the write address, and "r" in front of the number for the read address. For example, you can say "w010 = 15" to write a value of 15 into variable 010, and then use "a = r010" to read the value of variable 010 and store it in variable a. You need to be careful to use the correct name, w### or r###, depending on whether you're putting a value into the variable, or getting a value out of it. For example, to increment a zero-page variable, all you need to do is say something like "a = a + 1"; but to increment one of the Superchip RAM variables, you'll need to say something like "w010 = r010 + 1" (i.e., read the value that's in variable 010, add 1 to it, and then write the new value back into variable 010).

 

You can rename the new variables using the "dim" statement, the same way that you can rename a zero-page variable. However, be sure to dim two variables-- one for writing and one for reading-- and be sure to dim them to the correct variable names, as in the following example:

 

  set romsize 8k
  dim superchip = y

  dim w_number_of_player_hits = w000
  dim r_number_of_player_hits = r000

  dim w_number_of_enemy_hits = w001
  dim r_number_of_enemy_hits = r001

  rem * insert a bunch of bB program code here

  if collision(player0, missile1) then gosub player_hit

  if collision(player1, missile0) then gosub enemy_hit

  rem * insert a bunch of bB program code here

player_hit
  w_number_of_player_hits = r_number_of_player_hits - 1
  if r_number_of_player_hits = 0 then gosub player_dead
  return

enemy_hit
  w_number_of_enemy_hits = r_number_of_enemy_hits - 1
  if r_number_of_enemy_hits = 0 then gosub enemy_dead
  return

 

There's one more thing you need to know. When you compile a Superchip bankswitched game and then run it in an emulator, you may need to tell the emulator that the game uses the Superchip.

 

If you're using the Stella emulator and it doesn't correctly auto-detect the cartridge type, start the game, press the Tab key and click on "Game Properties." On the "Cartridge" tab, click in the "Type" box and click on the appropriate cartridge type (F8SC for an 8K Superchip game, F6SC for a 16K Superchip game, or F4SC for a 32K Superchip game). Then click on "OK" and "Exit Menu." Finally, press the backslash key ("\"), which is just above the Enter key, and click on "Reload ROM." Your game will now run correctly. You won't need to do this again the next time you play your game, unless you change it and recompile it. (Note that these instructions apply to the newer versions of the Stella emulator.)

 

If you're using the z26 emulator, it should auto-detect that your game uses the Superchip. If it doesn't, you'll need to start your game using the "-g" command line switch. Specify "-g2" for an 8K Superchip game, or "-g6" for a 16K superchip game, or "-g8" for a 32K Superchip game.

 

Now that I've posted the Superchip patch and explained how to use it, I'll post a few examples of things you might do with the extra RAM.

 

MR

Superchip_patch_0.99a2.zip

Superchip_patch_0.99b2.zip

Superchip_patch_0.99c2.zip

Edited September 15, 2006 by SeaGtGruff

[SeaGtGruff]

I'm glad no one downloaded the patches yet, because I made a minor change in them, and have just edited my previous post to reflect the changes and updated the attachments.

 

This program is an example of using the Superchip RAM to store the graphics for player0. This has two benefits, as follows:

 

(1) Normally, when you use bankswitching bB must store all of the player graphics data in the last bank, so it will be accessible to the display kernel. This means you're limited to only as much player graphics data as you can fit into the last bank-- and bB puts its own "system routines" in the last bank, which leaves even less room for your player graphics! But if you store the player graphics data in ROM as data, rather than using bB's "player0" and "player1" statements to define the player graphics data, then you can copy the data into Superchip RAM, set the player0 or player1 pointers to point to where the data is stored in the Superchip RAM, set the player0 or player1 height variable, and the Superchip RAM player graphics data will be accessible to any of the banks. That means you can store and load the player graphics data from any bank, and the display kernel in the last bank will still be able to see it. Consequently, you'll be able to fit a *lot* more player graphics data into your bB program!

 

(2) Normally, if you want to change the shape of a player, you must redefine the entire player using a new "player0" or "player1" statement. But sometimes the new player shape is virtually identical to the old player shape, except for a few lines of pixels that need to be different. If you store the player graphics data in Superchip RAM, you can change just the lines of pixels that need to be different, and leave the rest of the player shape unchanged. If you need to make a lot of these minor changes in the player shapes, then redefining the entire shape can use up more bytes than necessary, so you might be able to save some ROM space by changing just the lines of pixels that you need to. You could even use bit operations on the RAM data to turn individual player pixels on or off, or you could shift or rotate the RAM data, or you could scroll the RAM data up or down, etc.

 

MR

Superchip_RAM_player.bas

Superchip_RAM_player.bas.bin

[MausBoy]

This is still over my head as far as the commands you are using for storing and editing player graphics, but I should be able to figure it out from your examples.

 

It looks like almost all my projects are going to turn into bankswitched 16k games with the superchip, but now that makes me wonder how that will effect the playability. I'll want to release carts of them, and I hope this won't make that a huge undertaking, and I'm wondering how this will effect people who like to play homebrews on devices like the krok and cuttle carts.

 

Oh and by the way, thank you! The work you put in on this is awesome, and it opens up a huge new realm of possibilities with bB. With so many new variables it makes it seem like the sky is the limit with all my old projects. Now if a higher resolution playfield gets worked out, and the ability to use multiple pfheight and pfcolor tables, bB homebrews will be doing some highly impressive(and fun) things.

Edited September 11, 2006 by MausBoy

[SeaGtGruff]

This is still over my head as far as the commands you are using for storing and editing player graphics, but I should be able to figure it out from your examples.

I was thinking it should be possible to write some generic routines that could be used in any game to load a section of ROM into RAM. At the very least, a macro could be written to do it, but I think some sort of bB command would be better, because if you want to use an assembly macro in bB, you have to put it inside an "asm" statement. I realize that bB programmers may lack knowledge of assembly, so even something as "easy" as setting the player graphics pointers can seem daunting.

 

In fact, some kind of bB command or bB function to load ROM into RAM will probably be more or less essential, because it would probably waste ROM to have to write multiple routines for each and every time you want to copy some section of ROM into some section of RAM. It makes more sense to have a generic function you can pass parameters to-- the starting address (maybe in the form of a label), the number of bytes to copy, and the target address (also in the form of a label). It should take up less ROM in overhead, but that might depend on how it's implemented. This is something that needs to be looked into further.

 

It looks like almost all my projects are going to turn into bankswitched 16k games with the superchip, but now that makes me wonder how that will effect the playability. I'll want to release carts of them, and I hope this won't make that a huge undertaking, and I'm wondering how this will effect people who like to play homebrews on devices like the krok and cuttle carts.

It shouldn't make any difference. The programmable cartridges like the Krokodile Cartridge and the Cuttle Cart II can handle Atari's 8K, 16K, and 32K bankswitching formats with the Superchip, and so can the emulators like Stella and z26. I think the bigger question has always been whether you can produce actual cartridges today that use those formats, and the answer to that is, yes you can.

 

On the other hand, if you want to create, let's say, a game that uses M-Network's 16K bankswitching format with 2K added RAM, people will be able to play it on an emulator or programmable cart, but you probably won't be able to produce actual cartridges for your game.

 

Oh and by the way, thank you! The work you put in on this is awesome,

You're welcome. It was trivial to do, though-- or at least, it should have been. It's trivial to use the Superchip with bankswitching in assembly, and the only real catch about doing it in bB is to make bB skip over the first 256 bytes of each bank when it's compiling the bB program into assembly code. If it weren't for making some dumb-ass mistakes when I first attempted it, I would have had it all done back in July!

 

and it opens up a huge new realm of possibilities with bB. With so many new variables it makes it seem like the sky is the limit with all my old projects. Now if a higher resolution playfield gets worked out, and the ability to use multiple pfheight and pfcolor tables, bB homebrews will be doing some highly impressive(and fun) things.

Having extra RAM is a godsend, and does expand the possibilities. For example, I doubt if Centipede or Millipede could have been done without having extra RAM, because the mushroom field is done with the playfield, so you need to be able to turn each mushroom (or playfield pixel) on or off.

 

However, you need to apply common sense when you're designing your games. For example, before you can copy a player shape or a playfield into RAM, you first need to have the data defined in ROM. It's going to be most memory-efficient to use the "player0" and "player1" commands, and let bB put the data in the last bank and set the pointers itself, so I think you should still try to use that method as much as you can, and use the RAM method only when you run out of space in the last bank, or if for some reason you want to be able to modify a player shape one pixel or one line at a time without having to redefine the entire player.

 

By the way, if you're going to store (copy) the player data into RAM, and if the height of the player is going to be constant, you can set the player graphics pointers and the player height variable once at the beginning of your program, then leave them alone-- unless you use bB's "player0" and "player1" commands, since they set the pointers and height variables. In other words, you don't need to keep setting the pointers each time you move a new player shape into RAM, but you will need to set them again after using a "player0" or "player1" statement (if you want to use the RAM player again).

 

Also, as far as the color tables go, putting them in RAM would mean you could change the colors on a row-by-row basis, instead of having to redefine the entire color table.

 

MR

[MausBoy]

I downloaded the 99c patch, and the variables do not work for me. I followed the directions exactly, but I cannot change the value of the variables. They stay stuck at 255, and trying to write to some of them screws up my game ie characters jump around, player graphics become garbled.

 

I try something as simple as:

w001 = 0

if r001 = 0 then goto intro

 

and it does not work. however:

if r001 = 255 then goto intro

 

does work.

[SeaGtGruff]

I downloaded the 99c patch, and the variables do not work for me. I followed the directions exactly, but I cannot change the value of the variables. They stay stuck at 255, and trying to write to some of them screws up my game ie characters jump around, player graphics become garbled.

 

I try something as simple as:

w001 = 0

if r001 = 0 then goto intro

 

and it does not work. however:

if r001 = 255 then goto intro

 

does work.

My best guess is that the emulator you're using isn't autodetecting the cartridge format correctly, and you aren't explicitly telling the emulator that your game uses the Superchip.

 

If you're using z26, I think it should probably autodetect the cartridge type correctly, based on the ROM size and the presence of the 255 (or $FF) values in the first 256 bytes of the banks. But if z26 *isn't* autodetecting the fact that it's a Superchip cartridge format, then you'll need to modify the command line that's being used to run the game, and add the "-g" switch to it.

 

If you're using Stella, there's a good chance that it *isn't* autodetecting the format correctly. But if you're using Stella version 2.1 or 2.2, you can start running the game, then press the Tab key to pop up a menu, select the Game Properties button, click in the Type field, select the correct ROM size with the "+ ram" description, click OK, exit the menu, press the backslash key (between Backspace and Enter), and click Reload ROM. Then the RAM variables should work. Stella should remember the cartridge type automatically the next time you start your game, unless you change the code and recompile it again, in which case you'll need to repeat the process of selecting the correct format.

 

If you tell me what kind of setup you're using-- which program editor or IDE, and which emulator-- then I can help you better.

 

By the way, I'm having a lot of trouble getting the pfcolors and pfheights to work correctly in RAM. I've studied the way that bB does it when you *aren't* using the Superchip, and I've tried to set up the RAM the same way-- making sure that the address of playfieldcolorandheight is set correctly-- but it just won't work, and I haven't been able to figure out why not yet.

 

MR

[MausBoy]

I tried it in z26, and in stella, specifying that cart type. I tried auto-detect in stella also, and it didn't work either way. That was my first guess on what is wrong. Your demo source compiles and works correctly for me, but changing the specific variable used garbles the player graphic. I've tried quite a few things to see whats up, the only constant is that it does not work, besides that variables seem to want to hold the value 255.

 

I'm using 99c with 2600ide. I hadn't expiremented with pfcolor/height tables in ram yet, never got past these variable issues.

 

PS - I got close to the very first copy of 99c, maybe ours don't match up. Care to send me the version you developed this around?

 

PSS - there is some sort of flag that only allows for one instance of pfcolors and pfheights if both are used, could that have something to do with it? I can't be of much help other than to test and check if you post a source of your experiment, plus it would help me to see how you are trying to go about it.

 

PSSS - This happens with your demo source and my game is 8k, so it's not me forgetting the asm fill routine either.

Edited September 14, 2006 by MausBoy

[SeaGtGruff]

I'm using 99c with 2600ide.

Post your code, or pm it to me, and I'll see if I can figure it out.

 

MR

[MausBoy]

I can't post the exact code, but it goes something like:

 

set romsize = 8k

dim superchip = y

player0:

%01111011

end

main

COLUPF = 46 : COLUP0 = 11

player0x = 44 : player0y = 30

w001 = 0

if r001 = 255 then goto blah bank2

drawscreen

goto main

bank 2

blah

COLUBK = 56

drawscreen

goto blah

 

This will cause it to go to blah. Changing it to:

if r001 = 0 then goto blah bank2

 

will cause it to not go to blah.

 

PS - i just tried the exact code i posted, only with proper indentation. The problem described is exhibited with this code, tried in stella, autodetect or set to F8SC.

Edited September 14, 2006 by MausBoy

[SeaGtGruff]

PS - I got close to the very first copy of 99c, maybe ours don't match up. Care to send me the version you developed this around?

My bB setup may be different than yours, I have the files separated into different subdirectories (the main bB directory, plus an includes subdirectory and a projects subdirectory). Anyway, here are the files I'm using. If you have everything in one directory, then just move all of the files in the includes subdirectory into your bB directory (whatever you've called it).

 

MR

 

PS - I'll post something about my pfheights/pfcolors testing later, if not tonight then tomorrow night or Friday.

bB_0.99c2.zip

[SeaGtGruff]

I can't post the exact code, but it goes something like:

 

set romsize = 8k

When I copied your code, indented it, saved it, and compiled it, I got an error because of the "set romsize" statement. There shouldn't be an equal sign in it, it should just be "set romsize 8k". If you put in the equal sign, bB doesn't like it and uses a 4k ROM size instead! And 4K ROMs can't use the Superchip RAM.

 

After I fix the "set romsize" statement and recompile, I get an orange screen. I set the cartridge type in Stella to F8SC, reload the ROM, and the screen goes to black.

 

I hope that's it!

 

MR

[CPUWIZ]

And 4K ROMs can't use the Superchip RAM.

 

Why, that doesn't make sense to me?

[SeaGtGruff]

And 4K ROMs can't use the Superchip RAM.

 

Why, that doesn't make sense to me?

What I meant was, you might be able to manufacture a 4K cartridge that uses the Superchip (I would think that it should work, there's no reason it shouldn't)... BUT... as far as I know, there were never any 4K Superchip games, the Superchip games were all 8K or 16K or 32K... so neither z26 nor Stella have an option to run a 4K ROM image with the Superchip RAM emulated. Thus, if you do write a 4K game that expects (and relies upon) the presence of a Superchip, you currently have no way to run it correctly in an emulator. However, I must admit that I haven't ever tried to fool the emulator by writing a 4K Superchip game and then telling the emulator that it's an 8K Superchip game (for all I know, that *might* work).

 

Frankly, I don't see any reason why homebrewers shouldn't start making 4K Superchip games, and then maybe the people who develop and maintain the emulators might add a 4K Superchip mode!

 

MR

[SeaGtGruff]

Frankly, I don't see any reason why homebrewers shouldn't start making 4K Superchip games, and then maybe the people who develop and maintain the emulators might add a 4K Superchip mode!

By the way, now that you have the Superchip in your store, I was wondering if it would be possible to put TWO (or more) Superchips on a cartridge, so that there would be 256 bytes (or more) of extra

RAM? I mean, I suppose it's just a question of mapping each Superchip to a different area of the cartridge-- 1st 256 bytes = write and read addresses for the 1st Superchip, 2nd 256 bytes = write and read addresses for the 2nd Superchip, etc.

 

MR

[CPUWIZ]

And 4K ROMs can't use the Superchip RAM.

 

Why, that doesn't make sense to me?

What I meant was, you might be able to manufacture a 4K cartridge that uses the Superchip (I would think that it should work, there's no reason it shouldn't)... BUT... as far as I know, there were never any 4K Superchip games, the Superchip games were all 8K or 16K or 32K... so neither z26 nor Stella have an option to run a 4K ROM image with the Superchip RAM emulated. Thus, if you do write a 4K game that expects (and relies upon) the presence of a Superchip, you currently have no way to run it correctly in an emulator. However, I must admit that I haven't ever tried to fool the emulator by writing a 4K Superchip game and then telling the emulator that it's an 8K Superchip game (for all I know, that *might* work).

 

Frankly, I don't see any reason why homebrewers shouldn't start making 4K Superchip games, and then maybe the people who develop and maintain the emulators might add a 4K Superchip mode!

 

MR

 

10-4

 

The emulator argument makes sense.

[+batari]

maybe the people who develop and maintain the emulators might add a 4K Superchip mode!

You can just double up the 4k image to 8k and it will run in an emulator.

 

Also, you could use multiple Superchips on one cart. You just need some address decoding logic for chip selection, which is fairly trivial to design. The problem is going to be board size and the price point of the cart+chips if you need too many chips.

 

But I could be wrong in all this, as my mind is elsewhere since my vacation starts tomorrow...

[CPUWIZ]

maybe the people who develop and maintain the emulators might add a 4K Superchip mode!

You can just double up the 4k image to 8k and it will run in an emulator.

 

Also, you could use multiple Superchips on one cart. You just need some address decoding logic for chip selection, which is fairly trivial to design. The problem is going to be board size and the price point of the cart+chips if you need too many chips.

 

But I could be wrong in all this, as my mind is elsewhere since my vacation starts tomorrow...

 

Yes, of course, the emu would never know! Makes perfect sense.

 

That is completely feasable, space would not really be an issue, cost maybe. I think I could design a board that would be able to do 3 x 4K + 3 x SC, but it wouldn't be too cheap, in terms of parts.

[SeaGtGruff]

I'd originally modified bB to enable Superchip support only if bankswitching is being used, but I just changed it to allow the Superchip in a 4K game. All I had to do was comment out a couple of ifs. I've updated the attachments at the top of this thread with the new files, in case anyone wants to make a 4K Superchip game. If you examine the modified files, you'll notice I didn't comment out the same if in the 2600basicheader.asm file, as I did in the 2600basic.h and std_kernel.asm files. This is by design, not by accident! If you aren't using bankswitching, then the line to include "fill_256.asm" at the beginning of the kernel will be all you need, so you would *not* want to include it again in the 2600basicheader.asm file, but you *would* want to include it again if you're using bankswitching.

 

I tried folling Stella by saying that the 4K game was an 8K Superchip game, but it didn't work. So if you want to develop a 4K Superchip game, you'll need to double up the finished game in order to run it as an 8K Superchip game in Stella (but you shouldn't need to double up the actual RON if you make an actual cartridge-- assuming the 4K cartridge has been modified to map a Superchip into the first 256 bytes of ROM).

 

MR

[MausBoy]

It wasn't the equals, that was me typing something in wrong here. I would instantly notice on compile that there was a wrong number of "bytes left in bankx" anyway. I still have had no luck getting anything to work with 99c. The program I posted is pretty basic, if it works for you and not me there is no telling what's going on. I've tried it in z26 and stella, with and without the proper settings.

 

PS - I forgot a disk last time, tonight I'm taking home your uploaded files and i'll replace mine with these, and also check the dates to see if any of your files were newer. I'll let you know asap if this fixed my problems.

 

CPUWIZ - Could you give an estimate of what a 16k rom + 256k ram superchip pcb would cost? I'm betting it would take the greatest homebrew ever, but even with that would it be commercially viable to put something like this together?

Edited September 17, 2006 by MausBoy

[SeaGtGruff]

It wasn't the equals, that was me typing something in wrong here. I would instantly notice on compile that there was a wrong number of "bytes left in bankx" anyway. I still have had no luck getting anything to work with 99c. The program I posted is pretty basic, if it works for you and not me there is no telling what's going on. I've tried it in z26 and stella, with and without the proper settings.

If you post the actual code you're trying to compile, including a .BIN of the compiled code, it may help me figure out what's going on.

 

PS - I forgot a disk last time, tonight I'm taking home your uploaded files and i'll replace mine with these, and also check the dates to see if any of your files were newer. I'll let you know asap if this fixed my problems.

I hope that fixes your problem. Another thought is that if you've upgraded to 0.99c from 0.99a, then you may have problems. It might be best to wipe out your previous bB installation before upgrading, then install 0.99b fresh (instead of installing it on top of 0.99a), apply the 0.99c patch from batari, and then apply the 0.99c2 patch that I posted above. Also, batari had included the source files with 0.99a and 0.99b, and you don't need them. I don;t know if they might cause problems being in the same directory as everything else, but I set my installation up with different subfolders-- a source folder that I moved all the source files into, an includes folder that I moved all the include files into, a projects folder where I keep all my bB programs, and then the main folder where I keep all of the executables and batches. If you do this, you must change the batch files so they can find everything.

 

CPUWIZ - Could you give an estimate of what a 16k rom + 256k ram superchip pcb would cost? I'm betting it would take the greatest homebrew ever, but even with that would it be commercially viable to put something like this together?

I think you meant 256 bytes RAM, not 256K RAM. Anyway, do you mean two Superchips instead of just one Superchip? Remember that each Superchip takes up twice as much ROM space as the bytes of RAM that it's adding, so adding 256 bytes (two Superchips) will mean you have 512 fewer bytes of usable ROM in each 4K bank.

 

MR

[MausBoy]

I did mean two superchips. The extra space required would be no problem, I would just like a really high resolution playfield and multiple instances of pfheights/pfcolors, so that I can finally do nice looking software sprites with pfpixels.

 

I stupidly extracted your zip without backing up my bB directory, it ruined my install beyond repair. After a dozen botched efforts, I finally got a new working directory, and the superchip variables work now. The only trade-off is that the 'pfpixel' command crashes all my programs now; strange eh?

[SeaGtGruff]

I did mean two superchips. The extra space required would be no problem, I would just like a really high resolution playfield and multiple instances of pfheights/pfcolors, so that I can finally do nice looking software sprites with pfpixels.

I'll have to figure out the pfheights/pfcolors problem, it will be nice to be able to move them into Superchip RAM.

 

I stupidly extracted your zip without backing up my bB directory, it ruined my install beyond repair. After a dozen botched efforts, I finally got a new working directory, and the superchip variables work now. The only trade-off is that the 'pfpixel' command crashes all my programs now; strange eh?

I'll look into that. As far as I know, what I posted was version 0.99b with the 0.99c patch applied to it, then the minor changes I made in a few of the includes files for the Superchip (I really didn't change very much, believe it or not). But I can't say that I've ever tried to use "pfpixel" yet with 0.99c. I'll try it out and look at the code for "pfpixel"-- as I recall, it's in a separate includes file with the other pf drawing routines. I know I didn't touch that file, but I have all of the incarnations of bB on my computer, from 0.1 through 0.99c (in their own folders, so they don't interfere with each other), so I'll see what I can find out.

 

In any case, I'm glad the RAM variables are working for you now!

 

MR

[+atari2600land]

Sorry for necroposting here, but I'm thinking about making GoSub 2 a Superchip title. Is there a file to download like attached in the first post but only for bB version 1.0, or would the 0.99c one work OK?

[SeaGtGruff]

Sorry for necroposting here, but I'm thinking about making GoSub 2 a Superchip title. Is there a file to download like attached in the first post but only for bB version 1.0, or would the 0.99c one work OK?

I'll review this thread from the beginning to see what you're referring to, and I'll post any Superchip updates to v1.0 that you might need.

 

Michael

[Dragnerok X]

I could be wrong here, but IIRC, doesn't bB 1.0 come with superchip bankswitching built-in?