Superchip double-height playfield and kernel options

[jjsonique]

I've been looking into the goodness of 1.0, and I'm wondering --

 

If you use Superchip RAM and pfres to have a double-height playfield (say 24 or 32 lines)...

 

a) does the " playfield:" command still work normally for the extra rows ?

 

b) can you use the pfcolors and pfheights kernel options and adjust the color and height of the extra lines?

 

(I'll test this out myself tomorrow night, but thought I'd ask in case the answers are already known. )

 

Thanks,

JJ

Edited March 26, 2007 by jjsonique

[jbs30000]

I've toyed with it a little, so I can answer a couple of your questions.

 

A) Yes, the playfield works just fine.

 

B) I couldn't get pfcolors to work right and I didn't try pfheights.

 

Hope that helps a little.

[+batari]

B) I couldn't get pfcolors to work right and I didn't try pfheights.

It didn't occur to me that double-height would break pfcolors and pfheights but I independently tried them and found the same thing. I know the issue and will fix it eventually.

[jjsonique]

Ah, thanks batari and jbs30000. Good to know.

[Gorf]

Hey playfield people,

 

 

I just started to mess around with batari Basic today and first let me say.

 

Fred......Awsome! Beyond description!

 

 

Im using the draw.bas code to mess around a bit.

 

Anyway..I seem to have the players where I want but...

Why cant I seem to get any playfield to show up?

 

This line should set the forground pixels(on pixels) gray, no?

 COLUPF = 15

 

This line should set the background pixels(off pixels) black, no?

 COLUBK = 0

 

I want to turn these pixels on.

 

pfpixel 5 0 on : pfpixel 6 1 on : pfpixel 7 2 on : pfpixel 7 3 on

pfpixel 8 4 on : pfpixel 8 5 on : pfpixel 8 6 on : pfpixel 7 7 on

pfpixel 7 8 on : pfpixel 6 9 on : pfpixel 5 10 on

 

 

But when I set the COLUPF to anything but zero, the whole screen is filled

with that color.

 

This is the set up line at the top.

 

 include div_mul.asm
set kernel_options no_blank_lines
set romsize 8kSC
set smartbranching on
const pfres=12
pfclear
const noscore = 1
COLUPF = 15
COLUBK = 0

 

 

Im new at this so Im sure im not doing something I should.

 

Also.....how do I include the multisprite kernal?

 

thanks folks!

 

Again, Fred...Awsome!

 

Edited April 6, 2007 by Gorf

[SeaGtGruff]

This line should set the forground pixels(on pixels) gray, no?

 COLUPF = 15

 

This line should set the background pixels(off pixels) black, no?

 COLUBK = 0

 

I want to turn these pixels on.

 

pfpixel 5 0 on : pfpixel 6 1 on : pfpixel 7 2 on : pfpixel 7 3 on

pfpixel 8 4 on : pfpixel 8 5 on : pfpixel 8 6 on : pfpixel 7 7 on

pfpixel 7 8 on : pfpixel 6 9 on : pfpixel 5 10 on

 

 

But when I set the COLUPF to anything but zero, the whole screen is filled

with that color.

I think the problem is with the emulator, not your program. When you use the Superchip RAM for the playfield, you need to be sure that the emulator knows what type of cartridge image it's supposed to be emulating-- 8K with Superchip, or 16K with Superchip, or 32K with Superchip, depending on your romsize. When you compile a batari Basic game with the Superchip option, batari Basic initializes the first 256 bytes of all banks to $FF. If the emulator doesn't realize that it's supposed to be emulating a Superchip-enhanced cartridge, then the program won't be able to modify those 256 bytes (or really 128 bytes, since the first 128 bytes are the write addresses, and the second 128 bytes are the read addresses), because the emulator will treat those 256 bytes as ROM and won't let them be changed from their initial values when the program tries to write to them. If you use the Superchip RAM for the playfield, what this means is that the playfield will have all of its pixels turned on, and you won't be able to modify them.

 

If that's what is happening-- if the emulator isn't auto-detecting the cartridge format correctly-- then you have three options: (1) switch to a different emulator and see if it can auto-detect the cartridge format correctly; (2) upgrade to a newer version of the emulator you're using (if a newer version is available) and see if it can auto-detect the cartridge format correctly; or (3) tell the emulator which cartridge format it should be using for your game.

 

Which program editor are you using, and which emulator are you using? Is the emulator being called from within the editor, or are you starting up the emulator and then selecting your game from a list, or are you using a command line to run your game in the emulator?

 

Michael

[+batari]

But when I set the COLUPF to anything but zero, the whole screen is filled

with that color.

 

This is the set up line at the top.

 

 include div_mul.asm
set kernel_options no_blank_lines
set romsize 8kSC
set smartbranching on
const pfres=12
pfclear
const noscore = 1
COLUPF = 15
COLUBK = 0

EDIT: I missed the 8kSC in there. I'm going to second Michael's answer: you need to tell your emulator that the binary is 8k Superchip. I believe z26 will auto-detect Superchip, but Stella won't (not yet anyway - Stella developers mentioned that they are working on this.)

 

Also.....how do I include the multisprite kernal?

You do: set kernel multisprite

I should note that the multisprite kernel does not have kernel_options or the pfpixel command.

thanks folks!

 

Again, Fred...Awsome!

 

Thanks!

Edited April 7, 2007 by batari

[SeaGtGruff]

I believe z26 will auto-detect Superchip, but Stella won't (not yet anyway - Stella developers mentioned that they are working on this.)

Stella 2.3.5 should be able to auto-detect it, but previous versions probably won't.

 

To tell an earlier version of Stella (such as 2.1) what kind of cartridge it's supposed to be, start the game in Stella, then press the TAB key and select GAME PROPERTIES. Then click in the the TYPE field and select F8SC (8K ATARI + RAM), and click OK, then EXIT MENU. Finally, press the backslash key (\, just above ENTER) and click RELOAD ROM. The game will restart with the correct cartridge format. The game will run with the correct cartridge format from now on, unless you change the code and recompile it, in which case the binary image will be different, and you'll have to go through the preceding process to once again tell Stella which cartridge format to use.

 

Michael

[Gorf]

You guys rock! I'll check it out now.

 

thanks dude!

 

Ok..I suppose I should ask....how many superchips

RAM's cam you have?

[Gorf]

That was it guys... a new version of Stella fixed it immediately!

 

Awsome! I'll post a bin as soon as I have something interesting.

[Gorf]

I removed the kernal opions command and replaced it with the

multisprite like you said.

 

 include div_mul.asm
set kernel multisprite
set romsize 8kSC
set smartbranching on

 

Why do I get the following?

 

M:\ATARI2~1\bB>call 2600bas game.bas
2600 Basic compilation complete.
DASM V2.20.07, Macro Assembler (C)1988-2003
  bytes of ROM space left in bank 1

[b] --> cycle74_HMCLR d07b[/b]
	1 file(s) copied.

M:\ATARI2~1\bB>

 

 

Does anyone have a multisprite example?

I'll take an example with even on player one screen in multiprite mode.

Edited April 7, 2007 by Gorf

[SeaGtGruff]

Ok..I suppose I should ask....how many superchips

RAM's cam you have?

 

As far as I know, you can have only one Superchip per cartridge, and it must be a cartridge (board) that was designed for the Superchip. So I guess that means you could (in theory) design a board for using two or more Superchips in a cartridge, but I don't know anything about how to do that.

 

However, you might not want to do that, because the Atari Superchip (and the other older methods of adding RAM to a cartridge, such as the CBS "RAM+" bankswitched carts, or the M-Network "E7" bankswitched carts) must write to RAM at one set of addresses, and read the RAM from another set of addresses, which uses up twice as many addresses in the cartridge as the number of bytes of RAM that are being added.

 

The newer types of RAM work differently, allowing you to add RAM using one address per byte-- that is, you can write to and read from the RAM at the same addresses, instead of having to write to one set of addresses and read from another set of addresses. You can also put program code in RAM and then execute it from RAM, which allows self-modifying code-- something you can't do with the older expansion RAMs (although you can do it in the builtin page-zero RAM).

 

John (supercat) has created a new bankswitching format called "4A50" that has 128K of ROM and 32K of RAM-- 4 times as much ROM as a 32kSC game, and 256 times as much expansion RAM-- but batari Basic hasn't been modified yet to let you create "4A50" games (that's something I've been toying with off and on), and I don't know how readily available the "4A50" boards are yet-- John can tell you more about that.

 

Michael

[Gorf]

Awsome! Good info...I will try to avoid any extra RAM but if need be

This is good to know.

 

Also is it possible to put player images in RAM?

In other words does the player graphic have to be store in ROM

or could one use a few bytes of RAM and point the player to that?

[SeaGtGruff]

Awsome! Good info...I will try to avoid any extra RAM but if need be

This is good to know.

I'm not sure I understand what you mean-- why avoid any extra RAM? The Superchip doubles the Atari 2600's available RAM from 128 bytes (page-zero RAM) to 256 bytes (128 bytes of page-zero RAM plus 128 bytes of Superchip RAM), so that's a good thing. Yes, you have to give up 256 bytes of ROM due to the way the Superchip RAM is addressed, but that's a small price to pay.

 

Also is it possible to put player images in RAM?

In other words does the player graphic have to be store in ROM

or could one use a few bytes of RAM and point the player to that?

Yes, you can put the players in either zero-page RAM or Superchip RAM, but right now there's no builtin procedure for doing this automatically, so you have to manage it yourself. All you need to do is set a player's pointers to point to wherever you want the player's graphics data to be, and also set the player's height so batari Basic knows how many bytes of RAM to read while drawing the player. A while back (before Superchip support was added to batari Basic) I posted an example of putting a player in zero-page RAM, so its shape could be dynamically modified during the game. And later I posted an example of putting a player in Superchip RAM. I'll search for them and post the links.

 

Michael

[Gorf]

Awsome! Good info...I will try to avoid any extra RAM but if need be

This is good to know.

I'm not sure I understand what you mean-- why avoid any extra RAM? The Superchip doubles the Atari 2600's available RAM from 128 bytes (page-zero RAM) to 256 bytes (128 bytes of page-zero RAM plus 128 bytes of Superchip RAM), so that's a good thing. Yes, you have to give up 256 bytes of ROM due to the way the Superchip RAM is addressed, but that's a small price to pay.

 

Also is it possible to put player images in RAM?

In other words does the player graphic have to be store in ROM

or could one use a few bytes of RAM and point the player to that?

Yes, you can put the players in either zero-page RAM or Superchip RAM, but right now there's no builtin procedure for doing this automatically, so you have to manage it yourself. All you need to do is set a player's pointers to point to wherever you want the player's graphics data to be, and also set the player's height so batari Basic knows how many bytes of RAM to read while drawing the player. A while back (before Superchip support was added to batari Basic) I posted an example of putting a player in zero-page RAM, so its shape could be dynamically modified during the game. And later I posted an example of putting a player in Superchip RAM. I'll search for them and post the links.

 

Michael

 

 

That would be excellent. I dont really mean 'limit' RAM but not use more than I have to.

I think I an do well with 256 bytes.