SeaGtGruff Posted September 26, 2005 Share Posted September 26, 2005 Tonight I almost got bB to work with M-Network's bankswitching scheme (16K ROM and 2K RAM), but it doesn't look like it's going to work without some changes being made in bB itself, or alternately a change in DASM. This is what I did: I saved/renamed the original 2600basicheader.asm file, then modified a copy of it so it begins compiling at $FA00 instead of $F000. I saved/renamed the original 2600basicfooter.asm file, then modified a copy of it so the scoretable begins at $FF90 instead of $FFAC (and removed the references to ROM2k), added names for the bankswitching hotspots, and added two routines at $FFEC and $FFE6 for calling subroutines from one bank to another bank, then returning to the calling bank. I saved/renamed the original 2600basic.h file, then modified a copy of it to add a variable named temp7 at $DA (which was an unused byte); this variable is needed by the go_back routine at $FFE6 so it knows which bank to switch back to before it does a RTS. Then I copied my draw_maze_2.bas program to draw_maze_3.bas, and modified it to move most of the code to bank 0 (which will be at $F000), and to move each of the subroutines to separate banks (1, 2, 3, 4, and 5, also located at $F000), so I could test whether the subroutine calls from one bank to another would work as expected. I also added ORG and RORG as needed to move the sections of code to their proper banks, converted the gosubs to asm routines that call the subroutines in other banks, and converted the returns to asm statements that use the go_back routine to restore the previous bank before RTSing to the calling location. The problem is, DASM won't let me compile backwards, so to speak. That is, if the beginning of the program (bB's standard routines) compiles at $FA00, then I can't use ORG to point a subsequent section of code back at $C000 as needed ($C000 would be bank 0, but RORG is used to make the addresses come across as $F000). Okay, so I compiled the bB code, then edited the resulting draw_maze_3.bas.asm file to move the code around, so the sections are in the proper order ($C000, then $C800, then $D000, then $D800, then $E000, then $E800, then $F000, and then $FA00). After rearranging the code in the asm file, I compiled it with DASM, and everything appeared to go correctly (no errors, and the resulting bin file is exactly 16K as it should be). But when I run it, I get a JAM instruction. That may be due to an error on my part, so I'll check further tomorrow night, because I think it should have worked if I didn't make any booboos. However, I think that this procedure is too much work for the average bB user. As I see it, there are two things that need to happen before bankswitching (at least with the M-Network scheme) can become a reality for bB: Either bB itself will need to be modified so that certain portions of code get put into the asm file ahead of the standard bB routines (which will probably involve some kind of new bB statement that would be able to control this, like maybe a new SET that can tell bB to put a certain section of code ahead of the standard bB stuff). Or DASM will need to be modified so that code can be compiled "out of order," like compiling a section of code at $FA00 through $FFFF, then compiling a section of code at $F000 through $F7FF, and then compiling a section of code at $C000, etc. Since that sort of situation could be a programming error, DASM would need to issue a warning instead of a fatal compile error, perhaps with a switch to control whether you want to get an error or just a warning. I still think that what I did should have worked, so the JAM instruction that I got when I ran the (apparently successfully compiled) code may very well be due to an oversight on my part. If I get it to work tomorrow night, I'll post instructions on how to do it, but right now it's definitely not for beginners, because it requires the addition of some assembly code, along with rearranging the bB-compiled asm file before compiling it with DASM. It seems like some new bB commands could be created to replace the assembly code, but the need to rearrange the code before compiling it with DASM is kind of a big stumbling block. Is this something that bB users would be interested in? If I can get the M-Network bankswitching to work with bB, it could open up a lot of possibilities, like moving the playfield RAM to one of the extra RAM banks so that all of the PF registers can be used, and the pixels could be shorter. For example, an asymmetrical playfield requires a minimum of five bytes per row (if we store the left and right PF0 values in one byte, high and low nibble, then shift the byte to move the second nibble to where it needs to be before moving it to PF0), so that could give 48 rows instead of 12 rows for the playfield, with each playfield pixel being 4 scanlines tall instead of 16 scan lines tall as they are now, if we use a 256-byte RAM bank. Or, if the 1K RAM bank is used to map the playfield, we could get playfield pixels that are only 1 scan line tall. Of course, either case would also mean writing new playfield drawing routines, along with a new kernel, which I'll help do if people are interested-- but I doubt I could do it alone, especially if bB and maybe also DASM would have to be modified as well. By the way, if we can move the playfield mapping out of page 0 and into an extra RAM bank, then we can get 48 more bytes of zero page variables. Michael Rideout Quote Link to comment Share on other sites More sharing options...
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.