Starpath Supercharger question

[Tickled_Pink]

Just been reading up on the Supercharger. How did increasing the RAM increase the resolution of games? Surely there was more to it than that?

[OldSchoolRetroGamer]

Well, if you think about it just an increase in RAM would allow for more data packed in. I THINK this allowed the use of higher resolution and therefore the programmer could add more detail and that extra detail now had the extra memory required to be stored in. At least that is how my non techy brain understands the details of the device. Of course if their is more to it hopefully somebody with more knowledge can chime in.

[DirtyHairy]

The decisive advantage of supercharger games is that the code is loaded into RAM and run from there. This allows for self-modifying code, which in turn allows more TIA writes per scanline.

[Mr SQL]

Just been reading up on the Supercharger. How did increasing the RAM increase the resolution of games? Surely there was more to it than that?

 

Yes - the VCS only has 128 bytes so being able to allocate additional RAM allows for better graphics.

 

The SuperChip added another 128 bytes and CBS RAM doubled that to 256 extra bytes which was enough to enable similarly enhanced graphics as shown by Tunner Runner and Escape from the Mind Master.

 

I wrote a cross compiler to turn SuperCharger games into CBS RAM games so they could run on the Atari Flashback Portable; here's one SuperCharger game that grew too big to run on the SuperCharger but still runs as a CBS RAM game:

 

http://atariage.com/forums/topic/269548-supercharger-spaceinvaders/

 

 

The decisive advantage of supercharger games is that the code is loaded into RAM and run from there. This allows for self-modifying code, which in turn allows more TIA writes per scanline.

 

Agree dynamic RAM structures allow for more TIA writes, but the SuperCharger actually takes more cycles to modify them. Most SuperCharger games don't self modify code and take a penalty hit on dynamic RAM structures for graphics.

[Tickled_Pink]

Still struggling to get my head around the concept of RAM being used to improve graphics. Sure, RAM works alongside other GPUs to provide screen RAM and buffer space but the architecture of the 2600 doesn't have that. I always thought that resolution on the 2600 was dependent on how quickly code could be processed to send data to the TIA as soon as possible. Not sure how extra RAM improves that. Faster access times over ROM?

Edited March 21, 2019 by Tickled_Pink

[RevEng]

[...]I always thought that resolution on the 2600 was dependent on how quickly code could be processed to send data to the TIA as soon as possible. Not sure how extra RAM improves that. Faster access times over ROM?

Not faster access times compared to ROM per se, because RAM and ROM are running from the same clock here. Instead, having gobs of RAM makes quicker instruction modes more useful, and can simplify more complicated logic in-kernel. Here are a couple examples, though this is by no means exhaustive.

 

1. An in-RAM kernel loads constant values (very quick) and stores them to certain TIA registers. When you want the constant value to change, you just change the instruction itself, prior to running the kernel. (There are more compact ways to run a RAM kernel than this, but this example is extreme and simpler to explain.)

 

2. Instead of figuring out in-kernel when player graphics should start and stop being drawn, the kernel just loads the graphics sequentially from big ram buffers. In some bit of non-kernel code (where time is less precious) you can copy the sprite image to the part of the buffer where you want it to appear. The same technique can serve player colors, missiles, the ball, and playfield.

 

Hopefully that helps!

[+SpiceWare]

Still struggling to get my head around the concept of RAM being used to improve graphics.

On way would be to unroll the kernel, turn this:

 

 

Into this:

 

The numbers in green are the instruction cycle count followed by the cumulative cycle count for each scanline. Note the cumulative count for the sta COLUP1 instruction in both versions.

 

In the first it ends at 32, so you have 39 cycles left per scanline to make other updates. 39 from:

• 76 cycles per line
• -32 cycles to update both players & their colors
• - 5 cycles for the loop logic

In the second it ends at 20 and leaves 56 cycles left per scanline to make other TIA updates. 56 from:

• 76 cycles per line
• -20 cycles to update both players & their colors

If the code is in ROM then the lda # instructions are all hard coded, so could not be changed to reflect the players moving around the screen.

 

If the code is in RAM then the lda # instructions can all be changed programatically.

 

 

 

Note: I'm ignoring the 3 cycles for sta WSYNC as you can free that up if you use exactly 76 cycles per scanline.

 

 

[Mr SQL]

Still struggling to get my head around the concept of RAM being used to improve graphics. Sure, RAM works alongside other GPUs to provide screen RAM and buffer space but the architecture of the 2600 doesn't have that. I always thought that resolution on the 2600 was dependent on how quickly code could be processed to send data to the TIA as soon as possible. Not sure how extra RAM improves that. Faster access times over ROM?

 

Just like the GPU's you described only we write soft graphics chips -

 

batari BASIC takes the extra SuperChip RAM and surfaces all 128 bytes as a 1024 pixel grid of 32x32 pixels.

 

Flashback BASIC uses twice as much RAM for the 96x20 tile virtual world (2000 pixel grid).

 

And there are some recent threads on the batari BASIC forum showing the advantages of RAM based sprites and dynamic colors over RAM pointers to static ROM data. Multiple RAM buffers for graphics is the advantage I've explored including a soft blitter chip, but that acceleration all happens outside the kernel.

 

RAM based dynamic kernels sound interesting as well, I'd like to see an example.