Is Multisprite, bank switching and SARA allowable in batari together?

[Gorf]

I don't know that any game has gone to such lengths to combine a multi-sprite kernel and an assymetrical playfield. On the other hand, the beauty of the 2600 is that when you need such things and are willing to spend some code space for them, you can often do them.

 

Mega Man would like to have such a kernel.

 

 

It would be nice to have a Rom based screen alternating with a RAM based screen

where you can animate stuff and not have reflected playfields in the animated frame.

 

Here is a little demo of an alternating screen but its still reflected.

 

twofield.BAS

twofield.bas.bin

[+batari]

I don't know that any game has gone to such lengths to combine a multi-sprite kernel and an assymetrical playfield. On the other hand, the beauty of the 2600 is that when you need such things and are willing to spend some code space for them, you can often do them.

 

Mega Man would like to have such a kernel.

I posted a blog entry about such a kernel a while ago, and it should be possible in theory. My idea was to split the repositioning into as many pieces as possible to maximize time savings at the expense of code space. The final result would likely be that the kernel would nearly take up an entire bank. Doing so would leave no room for graphics.

 

The other problem would be RAM usage - each sprite would need a predefined indirect jump vector, at 2 bytes each. This would probably have to come from the user variables. Also, this would certainly leave no room for a RAM-based playfield.

 

All of the above could be done if the kernel required SC RAM by default, then one could shift all player and playfield graphics there.

[Gorf]

I don't know that any game has gone to such lengths to combine a multi-sprite kernel and an assymetrical playfield. On the other hand, the beauty of the 2600 is that when you need such things and are willing to spend some code space for them, you can often do them.

 

Mega Man would like to have such a kernel.

I posted a blog entry about such a kernel a while ago, and it should be possible in theory. My idea was to split the repositioning into as many pieces as possible to maximize time savings at the expense of code space. The final result would likely be that the kernel would nearly take up an entire bank. Doing so would leave no room for graphics.

 

The other problem would be RAM usage - each sprite would need a predefined indirect jump vector, at 2 bytes each. This would probably have to come from the user variables. Also, this would certainly leave no room for a RAM-based playfield.

 

All of the above could be done if the kernel required SC RAM by default, then one could shift all player and playfield graphics there.

 

 

We really need to add more ram to the cart area. Do we have circuits for such things?

[supercat]

We really need to add more ram to the cart area. Do we have circuits for such things?

 

They do. A 4A50-format bank switch cart can handle 128K of flash and 32K of RAM. Further, unlike any other 2600 cart, it allows RAM to be written in the "normal" way. On the SuperChip, incrementing a byte requires:

  ldx thebyte+$80
 inx
 stx thebyte

On the SuperCharger, it's

  ldx thebyte
 inx
 nop $1000,x
 nop
 ldx thebyte ; This one's really a write (X will receive the old value plus 1)

On one of my 4A50 carts, it's

  inc thebyte

[SeaGtGruff]

A 4A50-format bank switch cart can handle 128K of flash and 32K of RAM. Further, unlike any other 2600 cart, it allows RAM to be written in the "normal" way.

Even more significant, in my opinion, is that this lets us put program code in the extra RAM and then execute it, which means we can put an "unrolled" kernel in RAM and use the immediate address mode to load the TIA registers and perform more graphics changes on each scan line.

 

Michael

[djmips]

A 4A50-format bank switch cart can handle 128K of flash and 32K of RAM. Further, unlike any other 2600 cart, it allows RAM to be written in the "normal" way.

Even more significant, in my opinion, is that this lets us put program code in the extra RAM and then execute it, which means we can put an "unrolled" kernel in RAM and use the immediate address mode to load the TIA registers and perform more graphics changes on each scan line.

 

Michael

 

Is it possible to get a board and/or plans? Do we have a pcb or is it just wirewrap?

[SeaGtGruff]

Is it possible to get a board and/or plans? Do we have a pcb or is it just wirewrap?

You can read about the details of the 4A50 bankswitching scheme in supercat's blog. He's modified the z26 emulator to run 4A50 cartridge images, and has also added the bankswitching information needed to run 4A50 cartridge images on an actual Atari 7800 using the Cuttle Cart 2, but I don't think he's produced any 4A50 boards for sale yet, just prototypes.

 

I don't know how difficult it would be, but I think it would be great to modify both the Stella emulator and the Krokodile Cartridge files to allow them to run 4A50 cartridge images.

 

I'm going to convert my Sudoku WIP to the 4A50 format, and I'm also tinkering with a tile-based RPG engine in the 4A50 format, but both projects are essentially on hold right now until I can clear some other things off of my plate.

 

Getting back to the original topic, I've written a modified version of batari Basic's pf_drawing.asm file, to allow the use of playfield drawing commands with a Superchip-resident playfield in the multisprite kernel. The playfield is still symmetrical or reflected (as is the ROM-resident playfield in the multisprite kernel), so you can draw with only the left pixels (0 through 15), and your drawing will be reflected on the right half of the playfield. Now I just need to finish writing up some instructions on how to use the new multisprite_SCpf_drawing.asm routines in batari Basic programs.

 

Michael

[Gorf]

engine in the 4A50 format,

 

 

Now this cart is the 128k ROM and 32k RAM?

and all that ram can be easily accessed?

[SeaGtGruff]

engine in the 4A50 format,

 

 

Now this cart is the 128k ROM and 32k RAM?

and all that ram can be easily accessed?

Yes, that's right.

 

Briefly, the 4K cartridge area at $F000 to $FFFF is divided into four zones.

 

The first is a 2K zone at $F000 to $F7FF, which can be pointed to any 2K bank of ROM from the second 64K of the cartridge's 128K of ROM, or any 2K bank of RAM from the cartridge's 32K of RAM.

 

The second is a 1.5K zone at $F800 to $FDFF, which can be pointed to any 1.5K bank of ROM from the second 32K of the cartridge's 128K of ROM (i.e., from the second half of the first 64K), or any 1.5K bank of RAM from the cartridge's 32K of RAM. (A 1.5K bank is just like a 2K bank, except the last 512 bytes or 0.5K of the 2K bank are not included.)

 

The third is a 256-byte or 0.25K zone at $FE00 to $FEFF, which can be pointed to any page (256 bytes) of ROM from the first 64K of the cartridge's 128K of ROM, or any page (256 bytes) of RAM from the cartridge's 32K of RAM.

 

The fourth is a 256-byte or 0.25K "fixed" zone at $FF00 to $FFFF, which always points to the same page of ROM.

 

Michael

[+stephena]

I don't know how difficult it would be, but I think it would be great to modify both the Stella emulator and the Krokodile Cartridge files to allow them to run 4A50 cartridge images.

This is on the TODO list for Stella, but it's really difficult for me to find time to work on the project lately.

[Gorf]

engine in the 4A50 format,

 

 

Now this cart is the 128k ROM and 32k RAM?

and all that ram can be easily accessed?

Yes, that's right.

 

Briefly, the 4K cartridge area at $F000 to $FFFF is divided into four zones.

 

The first is a 2K zone at $F000 to $F7FF, which can be pointed to any 2K bank of ROM from the second 64K of the cartridge's 128K of ROM, or any 2K bank of RAM from the cartridge's 32K of RAM.

 

The second is a 1.5K zone at $F800 to $FDFF, which can be pointed to any 1.5K bank of ROM from the second 32K of the cartridge's 128K of ROM (i.e., from the second half of the first 64K), or any 1.5K bank of RAM from the cartridge's 32K of RAM. (A 1.5K bank is just like a 2K bank, except the last 512 bytes or 0.5K of the 2K bank are not included.)

 

The third is a 256-byte or 0.25K zone at $FE00 to $FEFF, which can be pointed to any page (256 bytes) of ROM from the first 64K of the cartridge's 128K of ROM, or any page (256 bytes) of RAM from the cartridge's 32K of RAM.

 

The fourth is a 256-byte or 0.25K "fixed" zone at $FF00 to $FFFF, which always points to the same page of ROM.

 

Michael

 

 

That is a ton of RAM for a 2600 game. Those RAM locations could be RAM based playfields too I suppose?

Im already RE- learning the value of a bit with just a handful of bytes to play with and I'm loving it. Im doing

some pretty bold stuff with this batari stuff and I think I could eventually rock the 2600 world with the help I

get from you folks around here.

 

I assume this format will eventually be allowabel in batari?

[Gorf]

I don't know how difficult it would be, but I think it would be great to modify both the Stella emulator and the Krokodile Cartridge files to allow them to run 4A50 cartridge images.

This is on the TODO list for Stella, but it's really difficult for me to find time to work on the project lately.

 

 

It really makes life easier to dev with an emu like Stella. The 4A50 support would really

open up the doors to some interesting stuff, I would bet.

 

Thanks for all your hard work on Stella!!

 

If my plate was not so full , I'd love to help work on such a project, but unfortunately,

there are only 48 hours in a day(or it seems that long yet nothing gets done STILL .)

Edited May 14, 2007 by Gorf

[SeaGtGruff]

That is a ton of RAM for a 2600 game.

Yes, but you know how it goes-- at first it seems like more than you could ever use, but once you start thinking of ways to use it, you suddenly discover that you wish it were 32MB of RAM instead of 32KB.

 

Those RAM locations could be RAM based playfields too I suppose?

Absolutely; they could be anything you want them to be-- playfield memory, player/missile/ball memory, player color tables, playfield color tables, playfield height tables, or even executable code-- anything you might want to put in (or copy to) RAM so that you can modify it.

 

I assume this format will eventually be allowabel in batari?

Yes, I think so. I sat down earlier this year to figure out how best to do that, but I backed off from it for the time being. I'm planning to get back on it eventually-- maybe not in time for it to be included in the next batari Basic release, but if not, then hopefully in the next release after that.

 

Michael

[SeaGtGruff]

I assume this format will eventually be allowabel in batari?

Yes, I think so. I sat down earlier this year to figure out how best to do that, but I backed off from it for the time being. I'm planning to get back on it eventually-- maybe not in time for it to be included in the next batari Basic release, but if not, then hopefully in the next release after that.

I really should rephrase that. A couple of years ago, I posted some bB modifications that enabled the creation of "E7" or M-Network bankswitched games with batari Basic, which is what I later used to start working on Sudoku in a mixture of batari Basic and assembly. That was before batari added bankswitching to bB-- and when he did add bankswitching, he did *not* add "E7" bankswitching, but instead added only "F8," "F6," and "F4" bankswitching. Why wasn't "E7" included, you may ask? It's really very simple. If you develop a homebrew game using bB, chances are you're going to want to get some carts made of it-- either a few "vanity carts" for yourself, or a "limited run" release, or a full-fledged "My game is going to be sold through the AtariAge website ohmygodimsoexcitedicantbreathe" release. Well, it just so happens that cartridges that use "F8," "F6," and "F4" bankswitching are very readily available today-- but cartridges that use "E7" bankswitching are *not* available! Consequently, "E7" bankswitching was left out of the new releases of bB (although it isn't difficult to add it to bB v1.00 as an "unofficial" customization).

 

As far as "4A50" bankswitching is concerned, I can add that capability to bB and post the modifications for others to use if they wish-- but whether or not it will be officially incorporated into any future release of bB is up to batari, and I expect that it may hinge on if or when cartridges that use "4A50" bankswitching become readily available. This sort of becomes a "chicken and egg" quandry, because "4A50" bankswitching won't "take off" unless people start creating games with it, but people will be more likely to create games with it if it's easier to write programs for it. So hopefully, if I add "4A50" bankswitching to bB in an "unofficial" capacity, it will help encourage people to develop for it, which will help it "take off," which will make it more likely to be added to an official bB release.

 

Michael

[Gorf]

As far as "4A50" bankswitching is concerned, I can add that capability to bB and post the modifications

Michael

 

 

Add it in and I'll use it!!!

 

I would never ask you to go through such a task and

then not at least try to make some use of it.

 

If you guys add to batari the few things i've requested, I promise

(if I ever figure out what I erally want to do here ) a great treat

for all 2600 fans....all i'll say is if I can get this further along...the

'storm' is coming.

[MausBoy]

I would definately use it, if it's integrated into bB. The huge amounts of ram and rom would allow for some of my more ambitious projects to be completed. A lot of what you guys are talking about it over my head though.

 

Thanks again for all your work on the SC Michael!

[Gorf]

I would LOVE 4A50!!!! Bring it on!

[Glenn Jupp]

Just want to add some more abject pleading for 4A50 bankswitching in bBasic. After all, you can never have too much memory to waste...

[Gorf]

I would bet 32k of RAM would be rather useful in pulling off some very interesting tricks on the 2600.

The the 128k ROM would be almost limitless to the 2600 coders. That would be almost like adding 32

megs RAM and 128 megs ROM.

 

 

 

BTW, Am I the only one who noticed that batari only has 26 system bytes...as in '26'00?

I wonder if fred did that by design?

 

I know... a totally goofy question...

 

Edited May 31, 2007 by Gorf

[supercat]

BTW, Am I the only one who noticed that batari only has 26 system bytes...as in '26'00?

I wonder if fred did that by design?

 

I think it's 26 bytes because there are 26 letters in the modern Roman alphabet.

[Gorf]

Perhaps Fred could clarify.

Edited June 4, 2007 by Gorf

[+batari]

Perhaps Fred could clarify.

Yup, Supercat is correct. Also, on a related subject in this thread, inquiring minds would like to know the status of the 4A50 boards.

[Gorf]

Perhaps Fred could clarify.

Yup, Supercat is correct. Also, on a related subject in this thread, inquiring minds would like to know the status of the 4A50 boards.

 

 

Yes...it could come in handy for what I want to do.

All that RAM could make life a lot simpler.