bB Bankswitching

[+stephena]

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.

938968[/snapback]

I'll bet this is because of the 'joystick emulates mouse' code. If you have any joysticks/gamepads plugged in, could you unplug them and try again? Obviously this will be fixed before the final release.

 

Also, feel free to email me directly at stephena@users.sf.net if this is getting too off-topic.

[SeaGtGruff]

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.

938867[/snapback]

I must have deleted the source and bin, so I had to create another test the same as the first. The display shows alternating red and black vertical stripes which are created in two different ways-- on the odd scan lines, the background is red, and the stripes are created by turning VBLANK on and off repeatedly. On the even scan lines, VBLANK is off all the time (well, except for when the Atari itself turns it on for the horizontal blanking), and the stripes are created by changing the color of the background between red and black repeatedly. On both odd and even scan lines, things are timed just right so everything should line up the same.

 

What happens is that Stella lines everything up exactly the same, so the vertical stripes have perfectly straight edges.

 

But on z26, the STA VBLANK and STA COLUBK instructions don't line up exactly the same, so the vertical stripes have jagged edges. The STA (or STY) VBLANK commands still take 3 machine cycles to execute, but the actual "color change" doesn't happen until 1 color clock later than expected!

 

When I first noticed this, my initial thought was that z26 had a bug. But I also knew from experimenting with other things that the Atari sometimes acted in a way I wasn't expecting-- for example, RESPx and RESMx (or RESBL) don't line up the same way; if I remember correctly, the missiles and ball get positioned one color clock to the left of where the players get positioned. So I wrote to Brad about Stella, and wrote to John about z26, explaining the issue and asking them if they knew which emulator was had the VBLANK timing correct-- Stella or z26. Brad said he looked at the schematics (which are pretty much gibberish to me, because I'm not an engineer and don't know how to interpret what the schematics show), and he said that, yes, it looked like VBLANK does require an extra color clock before the change occurs (or words to that effect). He said that if I could come up with a way to test this, and send him the program, he could try it out on a real Atari to see how it looked. So I created a program like the one attached below, and he said that the vertical stripes do appear to be jagged rather than straight.

 

Actually, I'd prefer that the Atari works the way that Stella does, because having VBLANK behave that way makes things a little more messy for doing crazy stuff like trying to "draw" with VBLANK by turning it on and off in the middle of a scan line! But if a real Atari acts funky about that, the way z26 emulates it, then I guess Stella should emulate the same behavior, too.

 

So take a look at the test program, run it on a real Atari if you can (because I can't, unfortunately), and let me know what you find out.

 

Michael Rideout

 

Stella

 

z26

BLNKTEST.ZIP

[potatohead]

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.

 

Very cool! I'm actually interested in supercats scheme the most. I know we don't have hardware just yet, but when we do I think it's gonna be great. From a programming standpoint, it's got a lot to offer with the biggie being ordinary RAM writes. I'm thinking this will enable a fairly sane Bb / cart combination.

 

Since I'm new, and only using some assembly at the moment, I'm going to defer to others here as to which scheme is better, popular, etc...

 

Kind of looking forward to my next game after Ooze.

 

Thanks a bunch for heading this direction.

[SeaGtGruff]

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.

938715[/snapback]

My initial thought was that it would be great if bB and DASM could do it all in one step, without having to hack the .asm file before using DASM to compile it. But after Tom pointed out the -f2 option to me, and I didn't have too much trouble making a "post-processor" program to take the compiled chunks and rearrange them into the proper order (as well as putting blank filler bytes where needed), I've changed my mind about it. Basically, I now think a "post-processor" is the best way to do it, just as normal bB compiles are a two-step process-- compile the bB code to get the .asm file, then compile the .asm file to get the .bin file. Having everything done in separate phases like that keeps it more flexible. And I should be able to modify my "m-network-it" post-processor program to accept a switch that specifies the desired bankswitching method, so the final .bin file is correctly rearranged and sized for that method.

 

I haven't tried the PHA method yet-- I took a detour to make the VBLANK test and post it, in the interests of helping to make Stella more authentic in the way it emulates the Atari's quirks-- but one thing that sort of bothers me about the PHA method is that it uses up stack space. True, it essentially pops the stack right away by using RTS, but I'm thinking in terms of subroutines that call other subroutines, and the fact that subs can be nested only three at a time in bB, so using PHA like that boils down to having no more than two nested subs. That could just be part of the "rules and regulations" about how things must be done, but it would also be nice if there were a solution around the indirect JMP bug that doesn't involve using the stack any more than necessary.

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.

938715[/snapback]

Yeah, I read on the stella list that you busy doing other things and wouldn't be able to get back to bB development for a few weeks at least. That's okay; v0.35 has a few quirks still, but they can be worked around, and it would be good to let people get used to v0.35's capabilities without having to learn anything related to new features in the forthcoming v0.4.

 

Keeping the banks separate is pretty easy, but it did require a few minor changes in the header and footer includes, which I was kind of leery about doing since I'd like to keep bB as close to "straight from the box" as possible without posting any modified includes. But I think you could make some minor changes in the header and footer includes to accommodate bankswitching, perhaps using a new SET variable to specify whether bankswitching will be used, and then you could start the header with the proper ORG based on that variable ($F000 for standard bB programs, or somewhere else for bankswitched programs), with similar changes in the footer. In fact, if I work out the ways to get the other bankswitching methods working with bB, then you might be able to incorporate it into v0.4. And it might be nice to add a few new commands that are specifically for bankswitching stuff, to cut down on the need for adding inline asm routines as I'm doing now.

 

So let me get M-Network going, then I'll work on the other methods, modify my post-processor as needed, and post everything I've done so you can examine it.

 

By the way, I'm thinking of experimenting with other kernels that use extra RAM, and I'm thinking of leaving bB's stuff alone, but maybe having another command or "call" to do draw the screen with the alternate kernel(s). That way, people can continue using the default kernel, or use an alternate kernel, even in the same program. But I'm getting a little ahead of myself!

 

Aside from tinkering slightly with the header and footer, I already stated that I added a temp7 variable at $DA, which was labeled as "unused" in the .h file. I was reluctant to do that, because I didn't know if you were planning to use that byte for something else in v0.4, but it just looked so convenient and inviting sitting there unused! Hey, at least I kept the name of the new variable consistent with the others, since it follows right behind temp1 through temp6.

 

And one more thing before I sign off for a bit to work on bankswitching again... The z26 documentation has this to say about bankswitching:

 

Offbeat Cartridge Formats (Bank Switching)

z26 currently supports the following schemes:

1. Standard 8K bank switching.

2. Standard 16K bank switching.

3. Atari Super-Chip.

4. CBS Ram Plus.

5. Parker Brothers 8K.

6. TigerVision 8K.

7. Activision FE 8K.

8. Atari 32K.

9. M-Network 16K.

10. Pitfall II.

11. Starpath.

12. Megaboy.

13. Compumate.

14. Extended TigerVision (to 512K).

15. UA Ltd. 8K.

16. ‘EF’ 64K (used by Paul Slocum‘s Homestar Runner RPG.

 

Kevin Horton's document on bankswitching doesn't mention Paul Slocum's "EF" method at all. Does anyone know where I can find anything written up about it? Does it have any extra RAM? As soon as I post this, I'm going to search the web a bit for any information, but if someone can point me to some information, that would be great!

 

Michael Rideout

[+batari]

Kevin Horton's document on bankswitching doesn't mention Paul Slocum's "EF" method at all. Does anyone know where I can find anything written up about it? Does it have any extra RAM? As soon as I post this, I'm going to search the web a bit for any information, but if someone can point me to some information, that would be great!

 

Michael Rideout

939172[/snapback]

That's because "EF" is for a single game that hasn't been released yet. The game has been in development for several years, and the emulators and the CC2 have supported the scheme for a while.

 

There is no formal specification of the scheme on the internet anywhere, but you could learn about how it works by looking at emulator source code. Or asking Paul Slocum.

[supercat]

But on z26, the STA VBLANK and STA COLUBK instructions don't line up exactly the same, so the vertical stripes have jagged edges. The STA (or STY) VBLANK commands still take 3 machine cycles to execute, but the actual "color change" doesn't happen until 1 color clock later than expected!

 

I did a demo of an Archon board (F4 bankswitching, but an actual game would require a big-RAM scheme) and it uses VBLANK to draw the left and right borders. Z26 matches a real machine. Look in the Homebrew Forums for the "Archon possible?" thread.

[Tom]

This is information I got from Al a while ago about EF bankswitching:

 

The bankswitching uses "hot spots" like F8, F4, and F6 bankswitching. There are 16 4K banks - hotspots for the 64K version were defined by Paul Slocum (whom we designed this board for originally):

 

1FE0 => BANK0

1FE1 => BANK1

1FE2 => BANK2

1FE3 => BANK3

1FE4 => BANK4

1FE5 => BANK5

1FE6 => BANK6

1FE7 => BANK7

1FE8 => BANK8

1FE9 => BANK9

1FEA => BANK10

1FEB => BANK11

1FEC => BANK12

1FED => BANK13

1FEE => BANK14

1FEF => BANK15

[+stephena]

What happens is that Stella lines everything up exactly the same, so the vertical stripes have perfectly straight edges.

 

But on z26, the STA VBLANK and STA COLUBK instructions don't line up exactly the same, so the vertical stripes have jagged edges. The STA (or STY) VBLANK commands still take 3 machine cycles to execute, but the actual "color change" doesn't happen until 1 color clock later than expected!

Thanks for the binary. It looks like this was already fixed at some point, because in the latest CVS build the screen looks exactly the same as z26 output. If you like, you can try one of the Stella nightlies from the webpage specified earlier in this thread.

[+Random Terrain]

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.

938968[/snapback]

I'll bet this is because of the 'joystick emulates mouse' code. If you have any joysticks/gamepads plugged in, could you unplug them and try again? Obviously this will be fixed before the final release.

 

Also, feel free to email me directly at stephena@users.sf.net if this is getting too off-topic.

939009[/snapback]

Unplugging the controller fixed it. After trying E.T., the ship landing and even foot steps of the FBI guy do not sound the same. As you said, my sound card may not be good enough, so it's impossible to tell until I get a good SB card. With the setup I have right now, the higher sound of the ship landing sounds pretty close, but the lower sound isn't right.

[potatohead]

I've changed my mind about it. Basically, I now think a "post-processor" is the best way to do it.

 

Agreed. Your solution is pretty slick.

 

but I'm thinking in terms of subroutines that call other subroutines, and the fact that subs can be nested only three at a time in bB, so using PHA like that boils down to having no more than two nested subs. That could just be part of the "rules and regulations" about how things must be done, but it would also be nice if there were a solution around the indirect JMP bug that doesn't involve using the stack any more than necessary.

 

Having subs only two levels deep is not that big of a deal, though it might be given the larger projects the additional RAM and ROM make possible. Still, ease and reliablity in page management is king.

 

Using flags to handle game states is not too bad. Gets messy quick if one does not document things. When I wrote Ooze the second time, using mostly flags because of the gosub bug, I learned a few things.

 

Multi-purpose subroutines are expensive in terms of space. This is the downside to flags. More stack capability would have allowed slower, but far tighter program loops. I don't think time would have been an issue though. It turns out that one can do a lot of little branches cheap. IMHO, it all comes down to program space. If space is tight, the stack really helps you out because you get the most for the address space. If space is not really the issue, the limited gosub is less of a problem because it then becomes possible to manage things on your own with few worries, other than keeping it right.

 

I'm sort of a stack snob really. Miss it on the 6502 because it's so limited in the first place. A one page stack really sort of sucks because it's only good for subs and variable passing. Anything beyond that gets risky quick, compared to a real stack. Programming on the CoCo, with the 6809 and it's two very nice stacks was sweet.

 

IMHO, the stack needs to be used sparingly on 6502 systems no matter what. There just is not enough of it. Far better to gain address space and use a pointer. That's just the way the CPU is.

 

The 6502 is fast but quirky it seems. This forces some style choices. Largely ignoring the stack, but for times when it really, really matters, is one of them.

 

Of course, there is the issue of normal RAM writes with supercats scheme. If we see working carts, Bb could then use the additional on cart RAM for storage, thus freeing up a lot of stack!

 

I haven't looked at all the schemes, but the ones I did check out, made RAM writes some sort of hack. Funky addressing, counting cycles all makes the whole thing hard from a Bb perspective. Major changes would be required to get things working --if the RAM were to be used for variables & such. The user could always make a subroutine or function that handled these things.

Edited September 28, 2005 by potatohead