How much ram does the line buffer utilize and how?

[treep78]

So as some may know I'm working on a coprocessor cart for the 2600 which will essentially reduce the system's job to generating graphics and sound. As such I'm now trying to decide if it would be possible to build a frame buffer using the majority of the 4KB the system can address as it might be difficult to always know which part of the screen the 2600 is drawing. Essentially, the idea is that the coprocessor will write an atari rom to a ram chip which the 2600 will read. The chip will contain a bare minimum kernel, the sound the system should currently be playing, and the line buffer which gets drawn with the TIA. The issue is that I'm not sure I can get the two chips in sync enough to know which line the system is drawing at any one time. Therefor I want to know if it would be possible to write at least a partial frame buffer so that the ram could hold several line buffers at once and the 2600 could just request the one it needs. For example, the code contains a variable F which is equal to the current line being drawn, 1-10 (holding a 1/16 of the frame in a buffer), and depending on that it could draw one of the line buffers in the 'ROM'. I'm assuming for the moment that since the 2600 can only draw four colors per line that each of the 160 pixels is represented by a 2bit number, 0-3, plus the four color pallet meaning that the frame buffer would be 44bytes (which sounds low). Of course I could be completely wrong. I'm kind of a newbie on the 2600 so some input from the experts out there would her really appreciated. Thanks in advance!

Edited September 18, 2014 by treep78

[+SpiceWare]

0 bytes of RAM.

 

 

You really need to learn how the Atari works before you go any further.

 

Go thru this:

http://atariage.com/forums/forum/31-2600-programming-for-newbies/

 

And:

http://atariage.com/forums/blog/blog-148/cat-188-collect

 

Until you invest the time to learn that, it won't be worth anymore our time to help you.

[+SpiceWare]

since the 2600 can only draw four colors per line

 

See this Activision prototype as an example of how far off you are on your assumptions:

 

 

[yllawwally]

The 2600 is quirky beast. It's fun to work with because it's like a puzzle. The biggest challenge to what your trying to do is that the 2600 does not have a line buffer. It is run by objects. You can easily have more that 4 colors per line. You can't really get 160 pixels across. People have gotten 96 pixels with only 2 colors, while other use only 40 pixels across, and maybe 40 different colors. To be safe you would then need to have 160pixels with 40 colors. So 6 bits of data per pixel, about 120 bytes per lines. Might as well use 160 bytes per line, and 192 lines per screen. So you would need 19k to store a whole screen of data. However, it cannot readily display a bitmap. Which seems to be what your wanting to do. I'm not sure what your background is, but you're going to need some skill in electronics, and programming to pull this off. Your co-processor will need to be fast, minimum 70 Mhz, if it's risc. Double that if not. A That is just for it to feed the atari. It takes a lot of overhead to sync. The harmony cart runs at 70Mhz, and most of it's power is used to sync up to the atari. This carts has DPC+ which uses the leftover power of the ARM processor. You should look at that. It is the closes t thing that exists right now to what you want to do. Or at least the hardware portion of what you want to do.

http://atariage.com/forums/topic/157182-harmony-tech-specsprocessor-architecture/

[Mr SQL]

So as some may know I'm working on a coprocessor cart for the 2600 which will essentially reduce the system's job to generating graphics and sound. As such I'm now trying to decide if it would be possible to build a frame buffer using the majority of the 4KB the system can address as it might be difficult to always know which part of the screen the 2600 is drawing. Essentially, the idea is that the coprocessor will write an atari rom to a ram chip which the 2600 will read. The chip will contain a bare minimum kernel, the sound the system should currently be playing, and the line buffer which gets drawn with the TIA. The issue is that I'm not sure I can get the two chips in sync enough to know which line the system is drawing at any one time. Therefor I want to know if it would be possible to write at least a partial frame buffer so that the ram could hold several line buffers at once and the 2600 could just request the one it needs. For example, the code contains a variable F which is equal to the current line being drawn, 1-10 (holding a 1/16 of the frame in a buffer), and depending on that it could draw one of the line buffers in the 'ROM'. I'm assuming for the moment that since the 2600 can only draw four colors per line that each of the 160 pixels is represented by a 2bit number, 0-3, plus the four color pallet meaning that the frame buffer would be 44bytes (which sounds low). Of course I could be completely wrong. I'm kind of a newbie on the 2600 so some input from the experts out there would her really appreciated. Thanks in advance!

 

treep78,

very cool project!

 

The idea to have a graphics and sound subsystem abstracting the hardware is awesome and fun to do - you might want to take a look at the kernel of the latest version of the ASDK (linked in my signature). It is fully commented and does similar abstraction using software to create phantom hardware: a frame buffer for the screen (60 bytes of onboard RAM, expanded from 30) and a virtual world buffer (512 bytes, compressed into 256 bytes of extra RAM). The extra physical hardware I utilise is the 256 bytes of additional RAM from the CBS double SuperChip or a chunk of the SuperChargers static RAM - just a partial framebuffer would be entirely doable within the limits of the onboard RAM!

 

Four colours per line are achieved with artifacting, so there's no additional RAM req for this but it only works on NTSC. The screen resolution is 20x10 (large tile pixels) from a 92x20 pixel virtual world. Sprites are also abstracted as 64-bit 8x8 objects (there are polynomial counters to set these so you may want to abstract them in your kernel as well) and can map to the screen or to virtual world tile coordinates.

 

Some of the larger resolutions being talked about here (beyond 40 pixels per line) are being done with the sprite objects since the playfield graphics only have the 20 bit (2.5 byte) line buffer internally (Spice, how did you get 0?).

[treep78]

SpiceWare, thanks for the links and tutorials, looking through those now.

 

Mr. SQL, any chance you could fill me in on how the 2600 addresses on cart ram? The ram chip I'm using is 32k and the 2600 is only addressing 4K of it for the ROM and it would be cool if I could get it to address more. I don't quite know how bank switching works, but maybe I could use that to let the 2600 address enough data to put an entire frame buffer on the RAM chip.

[+SpiceWare]

Spice, how did you get 0?

 

There's 128 bytes of RAM in the Atari, none of which are used as a frame/line buffer by TIA.

 

Within the registers of the TIA are a number of bits that control how a line is generated, but they're not a buffer in any traditional sense.

[Mr SQL]

SpiceWare, thanks for the links and tutorials, looking through those now.

 

Mr. SQL, any chance you could fill me in on how the 2600 addresses on cart ram? The ram chip I'm using is 32k and the 2600 is only addressing 4K of it for the ROM and it would be cool if I could get it to address more. I don't quite know how bank switching works, but maybe I could use that to let the 2600 address enough data to put an entire frame buffer on the RAM chip.

 

Sure, there aren't enough address lines to read/write the RAM so you get a penalty - each byte takes twice as much space with an area reserved for writing and a seperate address for reading (both contiguous blocks). If you have 256 bytes of extra cart RAM it eats 512 bytes of address space leaving only 3.5k addressable ROM per 4k bank!

 

The SuperCharger model is my favourite; no penalty whatsoever and it can address any of the bytes in the entire 6K as RAM (static RAM, better still) or ROM. The earlier build of the ASDK and the latest build show both models respectively with some helpful comments on the addressing scheme.

 

Bank switching is loads of fun, there are some complex models but here is a simplified overview on switching the entire 4k address space without having to precalculate anything (it's even easier with 2k bank switching because you don't lose your place):

http://atariage.com/forums/topic/210550-learn-assembly-in-8-hours-with-bb-and-the-asdk/?p=2746526

[Mr SQL]

 

There's 128 bytes of RAM in the Atari, none of which are used as a frame/line buffer by TIA.

 

Within the registers of the TIA are a number of bits that control how a line is generated, but they're not a buffer in any traditional sense.

 

The TIA registers feel like RAM to me, the CPU's too; the Fairchild Channel F has 64 bytes of register-only RAM.

[+SpiceWare]

 

The TIA registers feel like RAM to me, the CPU's too; the Fairchild Channel F has 64 bytes of register-only RAM.

 

Not to me - you can't write a value to a TIA register and read it back.

 

And of course some registers are time based - you can't do something like this:

    LDA #10
    STA XPOSP0

to set the horizontal position of player 0. Instead you have to wait for a specific cycle of time then strobe the register RESP0 to set the gross position, then use HMP0 + HMOVE to shift player 0 to where you really want it to be as strobing isn't accurate enough.

[treep78]

 

Not to me - you can't write a value to a TIA register and read it back.

 

And of course some registers are time based - you can't do something like this:

    LDA #10
    STA XPOSP0

to set the horizontal position of player 0. Instead you have to wait for a specific cycle of time then strobe the register RESP0 to set the gross position, then use HMP0 + HMOVE to shift player 0 to where you really want it to be as strobing isn't accurate enough.

Of course since my model doesn't use players, balls, or paddles that isn't an issue.

[+SpiceWare]

Of course since my model doesn't use players, balls, or paddles that isn't an issue.

 

paddles?

 

Without using the players, ball(singular) or missiles then you could at most display 40 pixels across.

 

The players, missiles and ball are the equivalent to sprites in modern nomenclature. They're very limited of course, each of the players are an 8x1 image. Each of the missiles and ball are a 1x1 image.

[treep78]

Ya, I think I got confused there for a sec. What I meant to say is that I'm not using them for gameplay, they're being sacrificed to produce the games horizontal pixels. If I remember correctly I get 1 color for player and missile 0, same for 1, then a background color and a play field color. That's how I came up with 4 colors per line. I'm hoping to be able to generate additional colors by having those four colors be red, blue, green, and black and changing their positions each time the screen is drawn to create additional colors. Not sure how yet, but I'm working on it.

[iesposta]

paddles?

 

Without using the players, ball(singular) or missiles then you could at most display 40 pixels across.

 

The players, missiles and ball are the equivalent to sprites in modern nomenclature. They're very limited of course, each of the players are an 8x1 image. Each of the missiles and ball are a 1x1 image.

The Ballblazer kernel updates Background and it come out to three pixels wide, is that 3 color clocks?

Could you have 53 horizontal pixels if you changed just background?

[+SpiceWare]

The Ballblazer kernel updates Background and it come out to three pixels wide, is that 3 color clocks?

Could you have 53 horizontal pixels if you changed just background?

 

That fastest that you could change the background color is this:

 

 sta COLUBK
  stx COLUBK
  sty COLUBK

 

Each STore command takes 3 CPU cycles, or 9 color clocks.

[Thomas Jentzsch]

Given the flexibility of the TIA, there is an almost unlimited number of possible display kernels. Just for one scanline. And sophisticated games tend to have complex multi line kernels and special kernels for special screen areas. And each of those kernels is manually tailored to the game's special requirements. And those kernels can interact with each other.

 

If you want to represent any possible kernel with a framebuffer, you need one byte (7 bit to be precise)/pixel, 160 bytes/scan line, ~32k per frame. By far not all combinations the framebuffer could support would be possible. But if you make it any simpler, there is a big chance that you cannot support everything the TIA can do.

 

How you convert the framebuffer content into TIA writes? No clue. And by far the most possible framebuffer content cannot be handled by the TIA. How would you identify that?

 

IMO DPC+ is maximizing already what you can squeeze of of the TIA. Unless someone finds a way to update a TIA register in less than 3 cycles.

[+SpiceWare]

IMO DPC+ is maximizing already what you can squeeze of of the TIA. Unless someone finds a way to update a TIA register in less than 3 cycles.

 

DPC+ gets you down to 5 cycle TIA register updates. Someday we'll get around to writing the bus-stuffing bankswitch driver to get that down to 3

[Thomas Jentzsch]

Oh, I thought you already had tested that.

 

Any chance to use e.g. lda #imm (where imm is a TIA address) to store the bus-stuffed value into the TIA?

[ZackAttack]

Oh, I thought you already had tested that.

 

Any chance to use e.g. lda #imm (where imm is a TIA address) to store the bus-stuffed value into the TIA?

Since the cart cannot force an active write signal I believe you must use a 6507 opcode that performs a write in order to buss-stuff a value into the TIA. Using a read-modify-write instruction would get it down to a 2.5 cycle average, but the writes occur in adjacent cycles (R R R W W) so you would end up getting every other pixel drawn 4 times the size of the one next to it. Including the illegal opcodes the best bet still appears to be a STA, STX, or STY with zeropage addressing.

[ZackAttack]

Oh, I thought you already had tested that.

 

Any chance to use e.g. lda #imm (where imm is a TIA address) to store the bus-stuffed value into the TIA?

Since the cart cannot force an active write signal I believe you must use a 6507 opcode that performs a write in order to buss-stuff a value into the TIA. Using a read-modify-write instruction would get it down to a 2.5 cycle average, but the writes occur in adjacent cycles (R R R W W) so you would end up getting every other pixel drawn 4 times the size of the one next to it. Including the illegal opcodes the best bet still appears to be a STA, STX, or STY with zeropage addressing.

[+SpiceWare]

supercat did a test project back in 2011 but, to the best of my knowledge, nothing has been done beyond that. See his topic Bus jamming experiments/issues over in the restricted Harmony Cart Development forum, it's currently the 7th topic.

[+Gemintronic]

In order to truly win he needs to put the GPU in main.

 

 

True fact!

[Mr SQL]

supercat did a test project back in 2011 but, to the best of my knowledge, nothing has been done beyond that. See his topic Bus jamming experiments/issues over in the restricted Harmony Cart Development forum, it's currently the 7th topic.

That forum sounds really interesting Spice! How do I gain programmer access to view this information?

 

Good point about the TIA playfield registers; agree they don't feel like RAM outside of the kernel since we can't read them back, but inside the kernel they feel indistinguishable since the system automatically reads them back for us to paint the screen and we can't lda/sta for other purposes without breaking the beam.

[+Gemintronic]

I think this guy wants something like Hellbound Hellraiser for the NES. Basically, a kernel that thinks it's strictly:

 

A. Drawing a static picture from what it thinks is SARA RAM.

B. Storing the state of various input (switches and joysticks) into "SARA" RAM.

 

The "SARA" RAM is actually RAM accessible to an ARM chip (maybe an M0).

 

So, the game runs on an ARM chip and sends the screen output to that special area of RAM. The VCS kernel knows nothing but to draw the screen from data in RAM and stuff the input values in there too.

 

The VCS and ARM never have to talk to each-other directly so the kernel could reside in a traditional 4k ROM chip. The tricky part is allowing access to the same RAM chip from both CPUs.

 

DISCLAIMER: I fully admit I'm way over my head and am talking nonsense!

[Nukey Shay]

More from the "over my head" department: I don't suppose that there is any way to theoretically have a coprocessor exploit the TXS instruction? That's only 2 cycles.