Harmony, bankswitching, ROM, and RAM

[SeaGtGruff]

This might be a dumb question. Suppose I want to make a game that won't need a lot of ROM-- it might fit within 4K or less, or maybe it could be stretched to between 4K and 8K. But what I really need more than anything is extra RAM. 128 bytes of Superchip RAM would be nice, but even better would be 256 bytes of CBS RAM. Except I probably won't need 12K of ROM. Can the Harmony do a *smaller* version of the CBS RAM+ scheme, such as 4K of ROM and 256 bytes of RAM, or 8K of ROM and 256 bytes of RAM? Or maybe I'm not asking the right question. What's the cheapest version of the Harmony-- or maybe I really mean the Melody? If it won't be any cheaper to produce a 4K ROM cart with 256 bytes of RAM than it would to produce, say, a 16K ROM cart with 16K of RAM, then I guess it doesn't matter whether all the ROM and RAM actually gets used in the game. But it seems like a terrible waste to have a lot of ROM and RAM that isn't actually used by the game, and I'd rather not make people pay a higher price for the game if the game could be made for a cheaper price.

 

Michael

[+batari]

Well, there are a few different chips I can use to make Melody boards. Most of them will be made with the 32k flash/8k RAM chip because I already have these chips on hand.

 

Tthere is a chip with 8k flash and 2k RAM that I could use and it is cheaper, but slightly less than a dollar cheaper. If it was really important to someone, we could probably use these chips.

[SeaGtGruff]

Well, there are a few different chips I can use to make Melody boards. Most of them will be made with the 32k flash/8k RAM chip because I already have these chips on hand.

 

Tthere is a chip with 8k flash and 2k RAM that I could use and it is cheaper, but slightly less than a dollar cheaper. If it was really important to someone, we could probably use these chips.

I'm sure I could try to find ways of using up 8K ROM and 2K RAM in the game, but what kind of price are we talking about? I mean, let's say the game were to be sold in the AtariAge store. What would the 8K ROM / 2K RAM cart cost the buyer?

 

And I guess the question about bankswitching is already answered by the fact that the Harmony/Melody carts can support custom bankswitching methods? For example, I guess we could have a variation of the CBS scheme that has 8K of ROM in two 4K banks, and 2K of RAM that could be accessed as eight 256-byte banks?

 

Actually, this raises another question about RAM. Can the RAM be written and read using the same addresses, or must there be a 256-byte write area and a 256-byte read area?

 

Sorry if these questions seem pretty elementary, but I haven't been following all of the Harmony/Melody discussion closely, and I haven't bought a Harmony cart yet for doing game development with.

 

Michael

Edited August 24, 2010 by SeaGtGruff

[+batari]

Well, there are a few different chips I can use to make Melody boards. Most of them will be made with the 32k flash/8k RAM chip because I already have these chips on hand.

 

Tthere is a chip with 8k flash and 2k RAM that I could use and it is cheaper, but slightly less than a dollar cheaper. If it was really important to someone, we could probably use these chips.

I'm sure I could try to find ways of using up 8K ROM and 2K RAM in the game, but what kind of price are we talking about? I mean, let's say the game were to be sold in the AtariAge store. What would the 8K ROM / 2K RAM cart cost the buyer?

Well, the 8k/2k chip costs just 76 cents less than what I paid for each 32k/8k chip. I'll use either upon request, though, and it doesn't make any difference to me what chips I use, so if I were to build a number of Melody boards with 2k/8k chips, I would pass that savings on to Albert. However, I don't think a game made with them would really be any cheaper because he'd need to spend extra effort keeping track of these boards with slightly cheaper chips.

And I guess the question about bankswitching is already answered by the fact that the Harmony/Melody carts can support custom bankswitching methods? For example, I guess we could have a variation of the CBS scheme that has 8K of ROM in two 4K banks, and 2K of RAM that could be accessed as eight 256-byte banks?

 

Actually, this raises another question about RAM. Can the RAM be written and read using the same addresses, or must there be a 256-byte write area and a 256-byte read area?

 

Sorry if these questions seem pretty elementary, but I haven't been following all of the Harmony/Melody discussion closely, and I haven't bought a Harmony cart yet for doing game development with.

 

Michael

You can't quite use the full 8k flash or 2k RAM - the bankswitch code occupies some of that space, so maybe a little more than 7k/1.5k is more accurate. I could do 6 banks of 256 bytes of RAM (separate read and write ports) and something like 7k ROM in two 3.5k banks (the lower 0.5k per bank would be used by the RAM anyway.)

 

As for reading and writing to the same address, that depends what you mean. The Supercharger can do it, and there are other ways to do it with certain limitations (such as restricting areas as code or data only, and prohibiting instructions that read, modify and write, like INC, DEC, etc.)

 

However, what you probably wanted to know is if Harmony/Melody can do 4A50-style "magic writes." I don't think it can.

[Pioneer4x4]

Can I chime in with another related issue?

What modes can bBasic support?

[+batari]

Can I chime in with another related issue?

What modes can bBasic support?

Do you mean what bankswitching schemes can bB support?

 

Natively, bB can do 2k, 4k, and F8, F6, F4 with or without Superchip. There was also a Supercharger and E7 demo but neither is native.

 

Currently, some work is being done on a DPC+ kernel. Actually, the kernel is the easy part - the hard part is the support code for it.

[Pioneer4x4]

Can I chime in with another related issue?

What modes can bBasic support?

Do you mean what bankswitching schemes can bB support?

 

Natively, bB can do 2k, 4k, and F8, F6, F4 with or without Superchip. There was also a Supercharger and E7 demo but neither is native.

 

Currently, some work is being done on a DPC+ kernel. Actually, the kernel is the easy part - the hard part is the support code for it.

I know I've asked in the past, and kinda remember. I was meaning what modes with the extra ram available on the harmony and melody are supported?

I think just the sara chip, correct?

[SeaGtGruff]

I think I've decided to go with M-Network bankswitching, because even though I need only 256 bytes for the playfield (actually 240 bytes), I could use another 144 bytes for the ball. And if I make it a multi-player game, I could store separate playfields for each player, and flip back and forth between them as each player's turn comes up.

 

The "bad" thing is, it isn't even my game idea , but it intrigued me enough to want to write a custom kernel for it!

 

Michael

[A.J. Franzman]

Do you really need 240 bytes (not bits) for the playfield?

[SeaGtGruff]

Do you really need 240 bytes (not bits) for the playfield?

Yes, 240 bytes, but not for the playfield. Each byte will be a color value, and there will actually be no playfield pixels used, except on the very last row, which isn't part of the main game screen per se. This is for a cystom kernel I'm working on for the thread about the "Blast Em" game (I think the thread title is "A game idea," or "an idea for a game"). It isn't even my game idea , but I was intrigued enough by the challenge and the overall game concept to want to write a custom kernel for it.

 

Michael

[Thomas Jentzsch]

Yes, 240 bytes, but not for the playfield. Each byte will be a color value, and there will actually be no playfield pixels used, except on the very last row, which isn't part of the main game screen per se. This is for a cystom kernel

Hm, sounds like you are drawing something dynamic, right? Else you could draw it from ROM.

 

Does the content change or is it "just" scrolling? I see a problem outside the kernel here. Handling 240 bytes of RAM requires quite a lot of CPU time. So even if you get that much RAM (e.g. E7 bankswitching which I use for my Elite demo), you have to be able to update it.

 

Then you have several options:

1. Update as much as you can frame by frame. This will result into heavy tearing.

2. Add double buffering, no tearing but maybe a lower frame rate and definitely more RAM required (Elite demo).

3. Identify changed areas and only update those in RAM, less tearing and higher frame rate (that's what Andrew and I used for Boulder Dash)

4. Combine 2. and 3., might become faster than 2. but not always.

 

So before you solely concentrate on the kernel, also think about handling it.

[SeaGtGruff]

Yes, 240 bytes, but not for the playfield. Each byte will be a color value, and there will actually be no playfield pixels used, except on the very last row, which isn't part of the main game screen per se. This is for a cystom kernel

Hm, sounds like you are drawing something dynamic, right? Else you could draw it from ROM.

 

Does the content change or is it "just" scrolling? I see a problem outside the kernel here. Handling 240 bytes of RAM requires quite a lot of CPU time. So even if you get that much RAM (e.g. E7 bankswitching which I use for my Elite demo), you have to be able to update it.

 

Then you have several options:

1. Update as much as you can frame by frame. This will result into heavy tearing.

2. Add double buffering, no tearing but maybe a lower frame rate and definitely more RAM required (Elite demo).

3. Identify changed areas and only update those in RAM, less tearing and higher frame rate (that's what Andrew and I used for Boulder Dash)

4. Combine 2. and 3., might become faster than 2. but not always.

 

So before you solely concentrate on the kernel, also think about handling it.

The only times the RAM would need to be updated are (1) when a game starts; (2) when a block is being "fired" into the playing grid; (3) when blocks are being removed due to matching up 3 or more blocks of the same color in a row; and (4) when all of the blocks drop down 1 row as a new row pops up at the top. Case (1) shouldn't be a problem, as the RAM can be set up while a "get ready" screen is displayed, before the grid appears. Case (2) is also no problem; and case (3) shouldn't be too much of a problem, either, because the logic for testing for matches-- and removing them-- could be split across different frames if necessary. If there's any problem with time, it would most likely occur during case (4).

 

Last night I realized that my initial code for drawing a single line of colors depended on the ball's data being in zero-page RAM, but then I decided on absolute addressing, which would take up 1 too many cycles. But then I figured I could move one or more columns of colors into zero-page RAM to free up some cycles, and today I realized I can use ROM for the ball, and use absolute,X indexing. So in theory, I should need only 256 bytes of extra RAM, which would work with the CBS RAM+ scheme. On the other hand, if I stick with the E7 M-Network scheme, I can use the 4 different 256-byte pages of RAM as screen buffers-- while one page of RAM is being displayed, another page of RAM can be set up (across multiple frames, if necessary) and then displayed when ready by flipping RAM pages.

 

Michael

[Thomas Jentzsch]

Can you link me to some screenshots or mockups of the game you are trying to reproduce?