Atari 2600 extra RAM?

[Ecernosoft]

Hello!

I want to make ICT on the 3 big atari consoles: The 2600, 5200, and 7800. I've already finished ICT on the 2600, it's in 2.5K. 

However, it's more of a test. It's more of a game BUT I want to make something real now. Something you'd actually play. Something to push the 2600 (NO DSP!) to the limit.

Unfortunately if I want to do scrolling (Which I do) I want to use extra RAM. 72 bytes (56 bytes used via the 48 bytes for the screen and 8 more for the stack) is ok, but I really only have 64 because after the sprites, I use 8 more bytes. And then the missiles brings me down to 60 bytes.

I want to use extra RAM (256 bytes???) so I can make a bigger, better game.

I also need to start on the 2600 because if I dont, porting to weaker hardware will be tougher than porting to stronger hardware.

Before you ask, yes, the 5200 and 7800 will have better versions than the 2600 port, but the 2600 version isn't going to suck like it did for DK on the 2600 or INTV.

Also, ICT on 5200 might not be ported to the 8bit for reasons I'm not going to get into.

 

So, I'm wondering, what are the typical setups for extra RAM in 2600 games? Thanks!

Edited September 8, 2022 by Ecernosoft

[+SpiceWare]

This topic might help:

 

 

 

[+splendidnut]

Here's a link to page showing most of the Bank-switching schemes available and the ROM size / RAM size they provide.

 

https://www.taswegian.com/WoodgrainWizard/tiki-index.php?page=Bank-Switching

 

Typically, back in the day, most games with extra RAM used the Superchip (F8SC, F6SC, etc.) which provided 128 bytes of RAM.

[Ecernosoft]

18 minutes ago, splendidnut said:

Here's a link to page showing most of the Bank-switching schemes available and the ROM size / RAM size they provide.

 

https://www.taswegian.com/WoodgrainWizard/tiki-index.php?page=Bank-Switching

 

Typically, back in the day, most games with extra RAM used the Superchip (F8SC, F6SC, etc.) which provided 128 bytes of RAM.

So, I have a question...

Which code is for the SARA chip? And where is it located? It doesn't say.

Also, does the harmony support the SARA chip? I've seen Xenophobe on it, but that's it.

I think I'm going with the SARA unless I only need 12K for the game.

[+splendidnut]

So, SARA = Superchip = SARA Superchip which is the 128 byte RAM chip.

 

F8SC = (F8 Bankswithing + Superchip RAM)

 

Basic Harmony generally supports everything that uses <= 32kb ROM.   Harmony Encore can support over ROMs over 32kb.

[+SvOlli]

@Ecernosoft
I had some good experiences using SARA aka SuperChip for development.

• you can't put generated code in there for execution
• you can combine it with 4K as well as F8, F6, F4 bankswiching
• it "only" costs you 256 bytes of ROM per bank
• it's possible to build a cartridge using the original SARA chip for authenticity

I did a demo running on a PAL 2600 using the SARA chip

• Webpage: https://xayax.net/bang!/ (contains source code as archive as well as version running using Stellarator)
• Sourcecode as repository: https://git.h8u.de/Atari_2600_Prods/bang/

Sourcecode might be interesting, since I'm using "bankjsr/bankjmp/bankrts"-macros to jump between banks.

[Ecernosoft]

8 hours ago, splendidnut said:

So, SARA = Superchip = SARA Superchip which is the 128 byte RAM chip.

 

F8SC = (F8 Bankswithing + Superchip RAM)

 

Basic Harmony generally supports everything that uses <= 32kb ROM.   Harmony Encore can support over ROMs over 32kb.

I didn't know there was an encore! But just use a concerto instead

1 hour ago, SvOlli said:

@Ecernosoft
I had some good experiences using SARA aka SuperChip for development.

• you can't put generated code in there for execution
• you can combine it with 4K as well as F8, F6, F4 bankswiching
• it "only" costs you 256 bytes of ROM per bank
• it's possible to build a cartridge using the original SARA chip for authenticity

I did a demo running on a PAL 2600 using the SARA chip

• Webpage: https://xayax.net/bang!/ (contains source code as archive as well as version running using Stellarator)
• Sourcecode as repository: https://git.h8u.de/Atari_2600_Prods/bang/

Sourcecode might be interesting, since I'm using "bankjsr/bankjmp/bankrts"-macros to jump between banks.

Wait- you made Bang! ?

I've seen it and it's really good! Thanks for the source!

You know, I'm not sure why people like you never tried to make a game using your assembly knowledge. 

[+SvOlli]

Thanks for the kind words. On the web page, you'll also find some "behind the scenes" commentary. There it's also stated when SARA is used, and for what. That might help you finding examples. I still need to add photos of the "original SARA version" cartridge.

On 9/9/2022 at 12:40 PM, Ecernosoft said:

You know, I'm not sure why people like you never tried to make a game using your assembly knowledge. 

Because a game is more complicated and you mostly have quite some corner cases to consider. While a demo part, once it's running, it's always running.

 

Take the circular sprite multiplexer for example (the one in the C64 part): while that routine works quite well, but only if it's used like in the demo. If the sprites move more to the right or left, I'll get graphics errors. Also the list of sprites to display has to be sorted along with the additional data. While getting this done is doable, it's quite some work to do it well. And at some point, I just wanted to have it done. (The coding of that multiplexer took me 2 full weeks "after work" hacking and 4 failed attempts.)

 

So I rather keep hacking on the hardware than on game logic. But I'm still keen on porting "Adventure" to a platform like the C64, or so. Or rather, to get the code in a way that it's easy to port to any platform running on a 6502.

[Ecernosoft]

On 9/10/2022 at 3:33 PM, SvOlli said:

Thanks for the kind words. On the web page, you'll also find some "behind the scenes" commentary. There it's also stated when SARA is used, and for what. That might help you finding examples. I still need to add photos of the "original SARA version" cartridge.

Because a game is more complicated and you mostly have quite some corner cases to consider. While a demo part, once it's running, it's always running.

 

Take the circular sprite multiplexer for example (the one in the C64 part): while that routine works quite well, but only if it's used like in the demo. If the sprites move more to the right or left, I'll get graphics errors. Also the list of sprites to display has to be sorted along with the additional data. While getting this done is doable, it's quite some work to do it well. And at some point, I just wanted to have it done. (The coding of that multiplexer took me 2 full weeks "after work" hacking and 4 failed attempts.)

 

So I rather keep hacking on the hardware than on game logic. But I'm still keen on porting "Adventure" to a platform like the C64, or so. Or rather, to get the code in a way that it's easy to port to any platform running on a 6502.

What about the 7800? The 7800 is practically a GOD video wise.

No-other 8 bit (or 16 bit system for that matter) can do the insane things the 7800 can.

The 7800 can do:

-Over 200 sprites, usually 20-30 per line without* a background

- Sprites can be up to 512*16 in 320A and 320D

- Resolution of 320*224 with 9 colors (You usually do 320*192 to stay compatible with CRTs though) or 160*224 (Again, usually 160*192 in this mode) with 25 colors, colors can be changed on a per-scanline or multiple times on a per-scanline basis

- Sprites can be a row of characters or just graphics (In the character mode, each char is 1 or 2 bytes wide)

- 6 modes of graphics

-TIA for sound, but you can add your own sound

- 52K of ROM stock, 48K stock if you use HSC

And finally, backwards compatibility for the 2600 modes.

There is one limitation for video, it's called DMA.

The Maria has to stop the CPU when it reads gfx data and so the more you have on-screen, the more DMA. There are different ways to use more/less DMA (160A sprite at 128*16 uses less DMA then 160A chars at 128*16) and tradeoffs (Ex. 320B uses more DMA than 320A but allows for more colors than 320A), but it's great. 

[WhyLee commotari.club]

maybe you find a fast 5V compatible MCU from microchip, running at 48MHz or something like that. you could write a firmware that emulates ROM with bank switching and kind of adds RAM with a certain mechanism. of course this would be complicated. but you could use a single microcontroller that contains everything and such a cartridge would be cheap too. (only the pcb and the microcontroller)

[+Al_Nafuur]

2 hours ago, WhyLee commotari.club said:

maybe you find a fast 5V compatible MCU from microchip, running at 48MHz or something like that. you could write a firmware that emulates ROM with bank switching and kind of adds RAM with a certain mechanism. of course this would be complicated. but you could use a single microcontroller that contains everything and such a cartridge would be cheap too. (only the pcb and the microcontroller)

You could use the PlusCart Zero board the MCU (STM32F407) is running at 168MHz the board is open source and can be build by DIY.

 

https://gitlab.com/firmaplus/atari-2600-pluscart

 

 

 

[+SvOlli]

Damn, I missed the updates here...

On 9/24/2022 at 7:11 PM, Ecernosoft said:

What about the 7800?

Well it will be not the first platform I want to port to, because you can just insert the 2600 cartridge in the 7800 and play "Adventure". I think, I'll go for the C64 and use a "converter" for the graphics data, so I can still use the original game data.

 

In fact I'm going two ways right now. The C64 port is step 3. Step 1 is to strip down the original source code. I'm now at 229 bytes of unused ROM. This was done by removing the black/white option, which I'm sure no-one needs in 2022, as well as some unused code. I did some minor optimizations, for example the routines for collision detection were masking out the bits using AND instead of using the negative and overflow status bits.

 

Step 2 will be an extended kingdom with (hopefully) an extra castle and labyrinth, while still using only 4k and also without changing any graphics. For me Adventure has to look exactly that way, duck-dragons included. This looks like a low hanging fruit compared to the C64 port. Then I want to go for the C64 port.

 

C64 is rather good, since I can convert the playfield graphics to text mode graphics. 40 characters for width matches, for height, I can convert the 7 lines of data to a height of 3 characters each, giving me 21 lines of 25 lines available on the screen. Most of the sprites can be converted with no or minimal changes. The dragon is 22 lines high, while the C64 sprites are 21 lines high. The "easter-egg message" will be needed to split into more than one sprite, or changed completely.

[Ecernosoft]

1 hour ago, SvOlli said:

Damn, I missed the updates here...

Well it will be not the first platform I want to port to, because you can just insert the 2600 cartridge in the 7800 and play "Adventure". I think, I'll go for the C64 and use a "converter" for the graphics data, so I can still use the original game data.

 

In fact I'm going two ways right now. The C64 port is step 3. Step 1 is to strip down the original source code. I'm now at 229 bytes of unused ROM. This was done by removing the black/white option, which I'm sure no-one needs in 2022, as well as some unused code. I did some minor optimizations, for example the routines for collision detection were masking out the bits using AND instead of using the negative and overflow status bits.

 

Step 2 will be an extended kingdom with (hopefully) an extra castle and labyrinth, while still using only 4k and also without changing any graphics. For me Adventure has to look exactly that way, duck-dragons included. This looks like a low hanging fruit compared to the C64 port. Then I want to go for the C64 port.

 

C64 is rather good, since I can convert the playfield graphics to text mode graphics. 40 characters for width matches, for height, I can convert the 7 lines of data to a height of 3 characters each, giving me 21 lines of 25 lines available on the screen. Most of the sprites can be converted with no or minimal changes. The dragon is 22 lines high, while the C64 sprites are 21 lines high. The "easter-egg message" will be needed to split into more than one sprite, or changed completely.

Yeah, I can see that.

[+SvOlli]

I think I found a nice on the fly conversion routine. This screenshot is from VICE/x64 (note the READY. prompt). Bits are taken from VCS code using copy/paste, color is hardcoded as of now.

[Ecernosoft]

6 minutes ago, SvOlli said:

I think I found a nice on the fly conversion routine. This screenshot is from VICE/x64 (note the READY. prompt). Bits are taken from VCS code using copy/paste, color is hardcoded as of now.

Cool! Why is this not in C64 forum? 

[+SvOlli]

Because it's only a small piece in the puzzle. The project is intended to be released on a demo party in 2023 or 2024 (they have not decided, when the next will be). Once of the next things to code will be a sprite converter. Also I need to implement a parser for the full room data, not only the graphics.

 

Edit: also as of now, I'm using self modifying code, to compensate for the lack of having STA (zp),X. Since I'd like to have it on the C64 as a ROM cart as well (8k or 16k), this is something that needs to be addressed as well.

Edited October 12, 2022 by SvOlli

[Ecernosoft]

Just now, SvOlli said:

One of the next things to code will be a sprite converter. 

You could just use a box for the player...

And honestly, the bitmaps are very low res. If they get over the C64 sprite limit size (Not sure if hires = 24*21 or 16*16) then you run into issues but you can just stack two sprites on top of eachother.

[+SvOlli]

Yes, that idea also came to mind (sprites are 24x21). But still this needs to be implemented. It would be also nice to have no flickering any more (or at least, less). The missile sprites for the left and right barriers will be implemented using charset instead.

Edited October 12, 2022 by SvOlli

[Ecernosoft]

1 minute ago, SvOlli said:

Yes, that idea also came to mind (sprites are 24x21). But still this needs to be implemented. It would be also nice to have no flickering any more (or at least, less). The missile sprites for the left and right barriers will be implemented using charset instead.

Well, you get 3 24*42 sprites plus an item for the player and the player itself if you need "tall" sprites.

Or, 6 if you can do it in one sprite.

[+SvOlli]

There are four sprites that will be problematic:

- the dragon with mouth open (22 lines)

- the brige (being enlarged in hardware, and the C64 can only do "double", which I need to use as default)

- the "torch" lighting up the dark mazes (32 lines)

- the "signature" of Warren Robinett (96 lines)

Right now I'm thinking about replacing the "Warren Robinett" sprite with PETSCII graphics (works fine, as it is static), for the other three, I don't need to have an instant answer. Everything else can just be a single sprite.

Edited October 12, 2022 by SvOlli

[Ecernosoft]

2 minutes ago, SvOlli said:

There are four sprites that will be problematic:

- the dragon with mouth open (22 lines)

- the brige (being enlarged in hardware, and the C64 can only do "double", which I need to use as default)

- the "torch" lighting up the dark mazes (32 lines)

- the "signature" of Warren Robinett (96 lines)

Right now I'm thinking about replacing the "Warren Robinett" sprite with PETSCII graphics (works fine, as it is static), for the other three, I don't need to have an instant answer. Everything else can just be a single sprite.

Dragon w/ mouth open can be fixed by removing one line.

The bridge? Can't you do it in double? 32*32 still too small? (Yes, I know it's really 16*16 but 2*2 pixels)

The torch can be fixed via double.

The signature can be done in Text characters. Or, a custom tileset.