Jump to content
IGNORED

bB Bankswitching


SeaGtGruff

Recommended Posts

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

Link to comment
Share on other sites

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.

938116[/snapback]

 

Moving the playfield from ZP ram into non-ZP RAM would allow for higher vertical resolution, no doubt about that. Trying to add support for the far left and right edges, however, would require extra cycles that are probably in most cases better used for other things.

Link to comment
Share on other sites

I'd love to have smaller Playfield pixels, but does that mean we'd be giving up some other ability or cool feature?

 

(Off topic: I refuse to go to bed until the first draft of my maze thingy is done. It's taking me longer to put a sprite in there than it took to create the maze. Edit: Duh! I finally figured out how to move the player around correctly! I made it more complicated than it needed to be.)

Edited by Random Terrain
Link to comment
Share on other sites

DASM can assemble code out of order. It just can't do so for raw binaries (the -f3 switch). As a workaround which neither involves modifying DASM (you don't want to do that, believe me) nor modifying bBasic you could try using RAS mode (the -f2 switch).

 

From the DASM manual:

 

2  RAS (Random Access Segment)

The output file contains one or more hunks.  Each hunk consists
of a 2 byte origin (LSB,MSB), 2 byte length (LSB,MSB), and that
number of data bytes.  The hunks occur in the same order as
initialized segments in the assembly.  There are no restrictions
to segment ordering (i.e. reverse indexed ORG statements are
allowed).  The next hunk begins after the previous hunk's data,
until the end of the file.

 

You would have to write a small tool to remove the hunk headers and convert everything back into a raw rom image. This is an ugly hack too, but easy to pull of.

Link to comment
Share on other sites

DASM can assemble code out of order. It just can't do so for raw binaries (the -f3 switch). As a workaround which neither involves modifying DASM (you don't want to do that, believe me) nor modifying bBasic you could try using RAS mode (the -f2 switch).

 

From the DASM manual:

 

2  RAS (Random Access Segment)

The output file contains one or more hunks.  Each hunk consists
of a 2 byte origin (LSB,MSB), 2 byte length (LSB,MSB), and that
number of data bytes.  The hunks occur in the same order as
initialized segments in the assembly.  There are no restrictions
to segment ordering (i.e. reverse indexed ORG statements are
allowed).  The next hunk begins after the previous hunk's data,
until the end of the file.

 

You would have to write a small tool to remove the hunk headers and convert everything back into a raw rom image. This is an ugly hack too, but easy to pull of.

938292[/snapback]

 

Wow! That sounds like a much better idea as far as something that will be "easy" for most people. I mean, if I write a little utility program that reads the hunks and rearranges them into the finished format-- which I can do with no problem-- then I can modify the 2600baside.bat to compile with DASM using -f2 instead of -f3, and call my utility immediately after that to get the binary in proper order. I could even keep track of how many bytes are unused in each bank, and report it to the user after the utility has finished rearranging the hunks.

 

Hey, I like that! It isn't an ugly hack at all, it's a great solution! :)

 

So it looks like giving people the ability to use M-Network bankswitching with bB will be as easy as posting a couple of modified include files, documenting the rules in a simple manner that bB users can understand, letting them write their bB code the "normal" way-- except for the special rules related to switching banks or using the extra RAM, etc.-- and compile the bB program with a modified batch file that fixes things up "like magic" *and* tells them how much space they have left in the eight ROM banks.

 

Cool! I know what *I'm* going to be doing for the rest of the night! ;)

 

By the way, supercat had a great point about the playfield, kernel, and cycles. But I wasn't intending to try doing anything with that right now, anyway-- I just want to get the M-N bankswitching working at all for the time being. But as far as making a new kernel that maps the playfield to extra RAM, so shorter pixels and 40 positions can be used, it should be possible to create multiple kernels so programmers can pick the one they want to use. For example, if we reserve ROM bank 0 for different kernels, and let bB's standard routines go in bank 7, that still leaves six banks (or 12K) for the programmer's code. The only tricky part is jumping from one bank to another, which isn't that hard as long as you follow the rules.

 

Here's my plan for that:

 

 ORG $FF90
scoretable
 .byte %00111100
; etc. - 80 bytes of data for digits 0 through 9
 ORG $FFE0
rombank
 HEX 00 00 00 00 00 00 00
rambank
 HEX 00 00 00 00 00
do_it
 STA temp1
 STX temp2
 LDA rombank,Y
 JMP (temp1)
go_back
 LDY temp7
 LDA rombank,Y
 RTS
 .word start
 .word start

 

If you're in one of the banks at $F000 through $F7FF, and you want to *jump* to a routine in a different bank (without needing to return where you came from), you just do this:

 

 asm
 LDA #<target_routine
 LDX #>target_routine
 LDY #target_bank_number
 JMP do_it
end

 

Or, if you want to go to a subroutine and then come back to where you were, you just do this:

 

 temp7 = this_bank_number
 asm
 LDA #<target_routine
 LDX #>target_routine
 LDY #target_bank_number
 JSR do_it
end

 

And at the end of the subroutine you're calling, instead of using RTS to return, you just do this:

 

 asm
 JMP go_back
end

 

That will swap back to the original bank number (stored in temp7), then RTS to the address that the original JSR pushed on the stack. But it can get tricky if you have subroutines that call other subroutines-- which isn't really a very good thing in bB, anyway, since there's stack space for only a few gosubs or JSRs. And it's okay if you're jumping around in the same bank. But if you have to jump around between different banks (and want to be able to return back to each of them), you have to be very careful with temp7.

 

Or, if you want to pick one of the four 256-byte RAM banks at $F800, you just do something like this:

 

 asm
 LDY #desired_rambank_number; 1 through 4 for the 256-byte banks
 LDA rambank,Y
end

 

Anyway, thank you *very* much for the tip! :)

 

Michael Rideout

Link to comment
Share on other sites

I'd love to have smaller Playfield pixels, but does that mean we'd be giving up some other ability or cool feature?

938226[/snapback]

Yes and no... You wouldn't lose any features, but with the M-network bankswitching scheme, you'd give up the ability to easily make your games into carts.

 

However, if the new scheme is easily adaptable to Supercat's future carts, this may not be true forever.

Link to comment
Share on other sites

I'd love to have smaller Playfield pixels, but does that mean we'd be giving up some other ability or cool feature?

938226[/snapback]

Yes and no... You wouldn't lose any features, but with the M-network bankswitching scheme, you'd give up the ability to easily make your games into carts.

 

However, if the new scheme is easily adaptable to Supercat's future carts, this may not be true forever.

938622[/snapback]

Thanks. I can't imagine making anything people would want on a cartridge, so I can live with that. :) Being able to play on an emulator is good enough for me, especially if they keep improving the emulators so that even the sounds are exact. If I ever made something really good and those future carts came along, I would seriously think about it though.

 

Speaking of emulators, if I make a few games over time, I hope I'll be able to adjust the .bin file so that it shows the name of the game in Stella.

Link to comment
Share on other sites

I'd love to have smaller Playfield pixels, but does that mean we'd be giving up some other ability or cool feature?

938226[/snapback]

Yes and no... You wouldn't lose any features, but with the M-network bankswitching scheme, you'd give up the ability to easily make your games into carts.

938622[/snapback]

Yeah, I've thought about that, especially since the pure assembly game that I'd previously started on is using it, and I'd already been told by someone that (AFAIK) no one has produced an M-Network-style homebrew yet, so I'd have to get the cart made myself. :( But even if I have to play it strictly on an emulator, or through a Cuttle Cart or Krokodile Cart, I'd still like to finish it.

However, if the new scheme is easily adaptable to Supercat's future carts, this may not be true forever.

938622[/snapback]

That would be great! But then, I'd probably switch to his bankswitching scheme anyway, since it offers a lot more than the M-Network scheme does. The only reason I'm still set on M-Network's is because (AFAIK) it's the best one that the emulators can currently handle as far as extra RAM is concerned. But I've seen references to another scheme that z26 supports (and for all I know, Stella too), however it isn't documented at all, so I don't know if it offers any extra RAM, and if so, how much.

 

My progress so far is as follows:

 

I figured out what my problem was last night-- I forgot to put RORG in the footer, so DASM was assigning addresses from the $F000 bank area to the scoretable, bankswitching hotspots, etc. So I fixed that problem easily.

 

I don't have a decent modern language to work in on this old computer, so I wrote my rearranger program (which I'm calling "m-network-it.exe"!) in QuickBASIC, since I'm very familiar with that language. But the filenames have to abide by the old 8.3 rule, so I modified the 2600baside.bat to copy/rename the .bin file before calling m-network-it.exe, then to copy/rename the output file back to the original .bin name. Here's the output messages from the compile:

2600 Basic compilation complete.

DASM V2.20.10, Macro Assembler (C)1988-2004
     bytes of ROM space left
     3467 bytes of ROM space left
Complete.
       1 file(s) copied
Bank 0 bytes free = 809
Bank 1 bytes free = 1900
Bank 2 bytes free = 1833
Bank 3 bytes free = 2019
Bank 4 bytes free = 1531
Bank 5 bytes free = 2048
Bank 6 bytes free = 2048
Bank 7 bytes free = 836
Total bytes free = 13024
       1 file(s) copied

I'll probably reformat the "bytes free" messages to line up nicer and look more like the message from bB, something like:

   809 bytes of ROM space left in bank 0
  1900 bytes of ROM space left in bank 1
etc.

The output file looks great-- exactly 16K-- and the free bytes for the different banks seem to jive with what they should be, based on how much code I'd stuck in each bank. But when I run the program with z26 using the M-Network setting, I get a blank screen with a continuous clicking sound, so I've obviously got something screwed up in the program itself-- which isn't too surprising, considering how late it was when I committed major surgery on it last night to move things around into variuous banks. So I think the part about getting bankswitching to work with bB is basically done, but I need to start with a simpler test program. I'm almost certain that the problem with my maze program is the way the different subroutines get called, sometimes from each other, such that the temp7 variable I added at $DA is getting wiped out.

 

Michael Rideout

Link to comment
Share on other sites

So I think the part about getting bankswitching to work with bB is basically done, but I need to start with a simpler test program.

938707[/snapback]

One more comment before I fall into bed... Getting *any* bankswitching to work with bB was really my whole point, and the M-Network scheme is the only one I've ever used, so it was natural for me to pick that one to try with bB. Once I finish proving that it's doable, and that (at least for M-Network) it doesn't require much to be changed in bB itself, I expect that other people will start experimenting with other bankswitching schemes in bB.

 

Really, the biggest trick was learning how to use DASM (I know, RTFM-- and I only just found out about RORG yesterday, so that shows you how well I read those fine manuals), and then having to write a "post-processor" program that takes the DASM -f2 output and gets it all sorted out in proper order. *That* part was actually pretty easy; I'm surprised that most of the problems I had with it were because of the 8.3 filenaming restriction! And my "m-network-it.exe" program could easily be rewritten to handle a different bankswitching scheme, since it doesn't really have anything to do with M-Network per se, just the number of banks that are supposed to be in the finished .bin file! Once I get everything cleaned up and verify that it's all working as it should, I'll post the pseudocode for my post-processor program, so anyone who's inclined can rewrite it in a "real" language! ;)

 

Thank you again Tom for cluing me in about the -f2 option! And of course, thank you Fred for bB, and thank you Jacco for 2600ide!

 

Michael Rideout

Link to comment
Share on other sites

The output file looks great-- exactly 16K-- and the free bytes for the different banks seem to jive with what they should be, based on how much code I'd stuck in each bank. But when I run the program with z26 using the M-Network setting, I get a blank screen with a continuous clicking sound, so I've obviously got something screwed up in the program itself-- which isn't too surprising, considering how late it was when I committed major surgery on it last night to move things around into variuous banks. So I think the part about getting bankswitching to work with bB is basically done, but I need to start with a simpler test program. I'm almost certain that the problem with my maze program is the way the different subroutines get called, sometimes from each other, such that the temp7 variable I added at $DA is getting wiped out.

938707[/snapback]

Thanks for working on this, by the way. I had been thinking about doing some sort of bankswitching, but I wasn't sure of the best way to do it. It looks like you've found an effective way of keeping the banks separate. Also, I've been busy and unable to work on bB lately, and also haven't had time to even think much about bB either.

 

Anyway, I'm not sure why it isn't working, but I should point out that using indirect jumps is generally not a good idea because of the page-wrapping bug. I think that Woz was the first to find an effective workaround for this in around 1977 or 1978 (in the Apple II system monitor ROM, IIRC.) I use a variant of this in the on...goto code.

 

Here's how you might modify your code to workaround the JMP() bug. Basically, it creates a "fake" return address on the stack and the RTS jumps there.

...
do_it
 PHA
 TXA
 PHA
 LDA rombank,Y
 RTS
go_back
 LDY temp7
 LDA rombank,Y
 RTS
 .word start
 .word start

An RTS jumps to address+1, so you need to load address-1 into your registers:


 asm
 LDX #<(target_routine-1)
 LDA #>(target_routine-1)
 LDY #target_bank_number
 JMP do_it
end

Edited by batari
Link to comment
Share on other sites

I had been thinking about doing some sort of bankswitching, but I wasn't sure of the best way to do it.  It looks like you've found an effective way of keeping the banks separate.

 

It might have made sense to use a more advanced code generator than DASM in the first place (ca65/ld65 come to mind). But what do I care, I don't use bB, I just watch its progress when I'm bored enough at work :)

Link to comment
Share on other sites

Speaking of emulators, if I make a few games over time, I hope I'll be able to adjust the .bin file so that it shows the name of the game in Stella.

938692[/snapback]

This is accomplished by creating a new entry in the stella.pro/user.pro file. In fact, the next version of Stella will let you edit that info directly from within the emulator, so you'll never have to use a text editor at all.

 

You'll just start a game (making sure to specify the correct cartridge type), change any game properties from within the emulator, and then press 'Alt-s'. This will merge the properties for that game into the user.pro file (a personal properties file), and from that point on, the game will work with those settings/properties.

 

And at some point, you can then forward those properties to me, and I'll include it in the stella.pro file and everyone will have access to them.

Link to comment
Share on other sites

Speaking of emulators, if I make a few games over time, I hope I'll be able to adjust the .bin file so that it shows the name of the game in Stella.

938692[/snapback]

This is accomplished by creating a new entry in the stella.pro/user.pro file.

Oh I thought that info was in the .bin.

 

 

In fact, the next version of Stella will let you edit that info directly from within the emulator, so you'll never have to use a text editor at all.

That will be nice.

 

 

And at some point, you can then forward those properties to me, and I'll include it in the stella.pro file and everyone will have access to them.

That's also cool.

 

How many years do you think it will take to perfect the sound? Will an emulator ever be able to get perfect Atari 2600 sound quality?

Link to comment
Share on other sites

Speaking of emulators, if I make a few games over time, I hope I'll be able to adjust the .bin file so that it shows the name of the game in Stella.

938692[/snapback]

This is accomplished by creating a new entry in the stella.pro/user.pro file.

Oh I thought that info was in the .bin.

No. That's why, for example, z26 doesn't show the title of a game from within the emulation. It doesn't use a database of properties, and none of that stuff exists in the bin file itself.

 

How many years do you think it will take to perfect the sound? Will an emulator ever be able to get perfect Atari 2600 sound quality?

938819[/snapback]

A new sound backend was added by Brad Mott (original author of Stella) for this next release. It features more accurate sound, as well as slightly less CPU usage and support for stereo sound in those ROMs that support it.

 

As for perfection, it may never happen. But we're always trying :) To be honest, you need a half decent sound card to get better emulation with Stella. Cheaper onboard sound cards are known to cause problems. I personally use SB 128 or SBLive and have had no problems.

Link to comment
Share on other sites

A new sound backend was added by Brad Mott (original author of Stella) for this next release.  It features more accurate sound, as well as slightly less CPU usage and support for stereo sound in those ROMs that support it.

938840[/snapback]

Cool. I need to get one of the better SB cards one of these times because I also want to play around with music making software.

 

One of the 'tests' I use is E.T.  If an emulator (with good sound card) can get the sound of the ship landing at the beginning of the game right, it should be able to handle just about anything.

Link to comment
Share on other sites

A new sound backend was added by Brad Mott (original author of Stella) for this next release.  It features more accurate sound, as well as slightly less CPU usage and support for stereo sound in those ROMs that support it.

938840[/snapback]

Cool. I need to get one of the better SB cards one of these times because I also want to play around with music making software.

 

One of the 'tests' I use is E.T.  If an emulator (with good sound card) can get the sound of the ship landing at the beginning of the game right, it should be able to handle just about anything.

938848[/snapback]

Don't want to get too offtopic here, but while we're discussing Stella, there's three requests I'd like to throw in.

 

(1) Around the beginning of the year I think, I emailed Brad Mott and the person who does z26 (can't think of his name just now) about VBLANK timing, because I was experimenting with using the blanking to "draw" with (as part of a document I had started working on detailing the TV picture and the 2600's graphics features), but I noticed that z26 and Stella produced different results. Basically, turning the VBLANK on or off is delayed by 1 color clock in z26, but not in Stella. I wrote a test program, Brad tried it on a real Atari, and said yes, the VBLANK looks like it does have an extra color clock. (I think he actually checked the schematics first and it looked like there was an extra cycle in there, so he asked me to send him a test program.) Anyway, I'm not sure if that's been "fixed" yet in Stella, but it would be cool if it could be, since it would make Stella's behavior closer to a real Atari's. If you need it, I have (or can recreate) the test program.

 

(2) One thing I like about z26 is that I can switch palettes from NTSC to PAL to SECAM on the fly, which might be kind of pointless for game-playing purposes (if the emulator can auto-detect the game type based on the scan line count and then auto-select the correct palette), but it has come in handy more than once. Stella has no way to specify or select the palette like that.

 

(3) Also, it would be great if Stella (and z26 for that matter) could be modified to use a palette file-- the way some versions of Atari800Win do-- so the user could tweak the palette to hopefully get the colors a little closer to a real Atari's (which I can tell you from experience is pretty difficult to do, especially due to the inherent color instability with NTSC video, coupled with the uncertainty of how someone has the tint/brightness/contrast settings on their TV).

 

Michael Rideout

Link to comment
Share on other sites

The output file looks great-- exactly 16K-- and the free bytes for the different banks seem to jive with what they should be, based on how much code I'd stuck in each bank. But when I run the program with z26 using the M-Network setting, I get a blank screen with a continuous clicking sound, so I've obviously got something screwed up in the program itself-- which isn't too surprising, considering how late it was when I committed major surgery on it last night to move things around into variuous banks. So I think the part about getting bankswitching to work with bB is basically done, but I need to start with a simpler test program. I'm almost certain that the problem with my maze program is the way the different subroutines get called, sometimes from each other, such that the temp7 variable I added at $DA is getting wiped out.

938707[/snapback]

Thanks for working on this, by the way. I had been thinking about doing some sort of bankswitching, but I wasn't sure of the best way to do it. It looks like you've found an effective way of keeping the banks separate. Also, I've been busy and unable to work on bB lately, and also haven't had time to even think much about bB either.

 

Anyway, I'm not sure why it isn't working, but I should point out that using indirect jumps is generally not a good idea because of the page-wrapping bug. I think that Woz was the first to find an effective workaround for this in around 1977 or 1978 (in the Apple II system monitor ROM, IIRC.) I use a variant of this in the on...goto code.

 

Here's how you might modify your code to workaround the JMP() bug. Basically, it creates a "fake" return address on the stack and the RTS jumps there.

...
do_it
 PHA
 TXA
 PHA
 LDA rombank,Y
 RTS
go_back
 LDY temp7
 LDA rombank,Y
 RTS
 .word start
 .word start

An RTS jumps to address+1, so you need to load address-1 into your registers:


 asm
 LDX #<(target_routine-1)
 LDA #>(target_routine-1)
 LDY #target_bank_number
 JMP do_it
end

938715[/snapback]

Thanks for the tip, the indirect JMP bug may be part of what's wrong with my maze program, so I'll try that when I get home.

 

Also, what would you guys say are the degrees of popularity of the bankswitching methods, as far as which ones homebrewers seem to prefer the most, and also which ones are easiest to produce carts for? I'll expand the bB bankswitch stuff to accommodate the other schemes besides M-Network, but it would be nice to know which ones to tackle first.

 

Michael Rideout

Link to comment
Share on other sites

Thanks for the tip, the indirect JMP bug may be part of what's wrong with my maze program, so I'll try that when I get home.

Does that bug have anything to do with programming in batari Basic or is that just about assembly language?

Link to comment
Share on other sites

A new sound backend was added by Brad Mott (original author of Stella) for this next release.  It features more accurate sound, as well as slightly less CPU usage and support for stereo sound in those ROMs that support it.

938840[/snapback]

Cool. I need to get one of the better SB cards one of these times because I also want to play around with music making software.

 

One of the 'tests' I use is E.T.  If an emulator (with good sound card) can get the sound of the ship landing at the beginning of the game right, it should be able to handle just about anything.

938848[/snapback]

I'll have to try the E.T. game on a real machine to see how it's supposed to sound. Unfortunately, the sound code isn't my strong point in the Stella codebase, so I can't do much about it if it's not quite correct. But I'll pass all suggestions along to Brad, who is much more familiar with that part of the code.

Link to comment
Share on other sites

Basically, turning the VBLANK on or off is delayed by 1 color clock in z26, but not in Stella. I wrote a test program, Brad tried it on a real Atari, and said yes, the VBLANK looks like it does have an extra color clock. (I think he actually checked the schematics first and it looked like there was an extra cycle in there, so he asked me to send him a test program.) Anyway, I'm not sure if that's been "fixed" yet in Stella, but it would be cool if it could be, since it would make Stella's behavior closer to a real Atari's. If you need it, I have (or can recreate) the test program.

Please send me that test program. If it hasn't already been fixed, I can ask Brad to look at it again.

 

(2) One thing I like about z26 is that I can switch palettes from NTSC to PAL to SECAM on the fly, which might be kind of pointless for game-playing purposes (if the emulator can auto-detect the game type based on the scan line count and then auto-select the correct palette), but it has come in handy more than once. Stella has no way to specify or select the palette like that.

Actually, it does. Pressing Ctrl-f toggles between NTSC and PAL, with appropriate change in palette and framerate. But it works much better in current CVS code. We don't yet support SECAM mode at all, but that will be added after the next release.

 

(3) Also, it would be great if Stella (and z26 for that matter) could be modified to use a palette file-- the way some versions of Atari800Win do-- so the user could tweak the palette to hopefully get the colors a little closer to a real Atari's (which I can tell you from experience is pretty difficult to do, especially due to the inherent color instability with NTSC video, coupled with the uncertainty of how someone has the tint/brightness/contrast settings on their TV).

The only thing stopping me from doing this was a built-in GUI. Now that Stella has one, that feature will be included in version 2.1. I haven't specced the interface yet, but there might be tint/brightness/contrast sliders directly in the GUI. But it won't make it into the next release (2.0), which we're trying to push out the door any time now.

Link to comment
Share on other sites

I'll have to try the E.T. game on a real machine to see how it's supposed to sound.  Unfortunately, the sound code isn't my strong point in the Stella codebase, so I can't do much about it if it's not quite correct.  But I'll pass all suggestions along to Brad, who is much more familiar with that part of the code.

Thanks. Besides being a good test, it's also easy to get to since it's right at the start of the game. If Brad is pretty good with sound, listening to the E.T. ship landing on a real machine will help him to perfect Stella sound. Listening to the tune on the logo screen wouldn't hurt either.

Link to comment
Share on other sites

I'll have to try the E.T. game on a real machine to see how it's supposed to sound.  Unfortunately, the sound code isn't my strong point in the Stella codebase, so I can't do much about it if it's not quite correct.  But I'll pass all suggestions along to Brad, who is much more familiar with that part of the code.

Thanks. Besides being a good test, it's also easy to get to since it's right at the start of the game. If Brad is pretty good with sound, listening to the E.T. ship landing on a real machine will help him to perfect Stella sound. Listening to the tune on the logo screen wouldn't hurt either.

938868[/snapback]

Actually, why don't you try it as well and let me know. You can download a beta version from http://www.hardcoders.org/stella_nightly. I assume you're using Windows. If not, then the last binary is from the 7th, as there seems to be a problem with the automatic Linux builds.

Link to comment
Share on other sites

Also, what would you guys say are the degrees of popularity of the bankswitching methods, as far as which ones homebrewers seem to prefer the most, and also which ones are easiest to produce carts for? I'll expand the bB bankswitch stuff to accommodate the other schemes besides M-Network, but it would be nice to know which ones to tackle first.

 

Michael Rideout

938861[/snapback]

By far the most popular would be F8. There are countless homebrews that use this scheme. Second would probably be F6. These schemes are farily easy to implement and understand, but unfortunately they do not add any additional RAM.

 

When I was thinking about bankswitching, I was thinking about first implementing F8, perhaps by placing the kernel, functions, routines, and graphics all in one bank and the compiled bB code in another. It wouldn't be a perfect split but it would allow for larger games.

 

bB would need to me modified first to place the graphics in the other bank, but everything else could be placed there for now.

Link to comment
Share on other sites

Thanks for the tip, the indirect JMP bug may be part of what's wrong with my maze program, so I'll try that when I get home.

Does that bug have anything to do with programming in batari Basic or is that just about assembly language?

938863[/snapback]

Just assembly language.

Link to comment
Share on other sites

Actually, why don't you try it as well and let me know.  You can download a beta version from http://www.hardcoders.org/stella_nightly.  I assume you're using Windows.  If not, then the last binary is from the 7th, as there seems to be a problem with the automatic Linux builds.

Thanks. I use Windows XP and got the SDL.dll and stella-nightly-latest-win32.zip, but the mouse keeps pulling hard to the left so I'll have to wait for the next latest version.

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...