help to understand andrew's full colour bitmap mode

[+grafixbmp]

I get how it works but for the best version he came up with, I was wondering, for a still image, how many actual frames are used and how much data it takes to display a BG still image (ie: the picture of the blue car demo)? I have an idea for a game concept that could use this technique. Also, conceivably, how many images could be done with a bankswitched 32K rom?

[+Andrew Davie]

I get how it works but for the best version he came up with, I was wondering, for a still image, how many actual frames are used and how much data it takes to display a BG still image (ie: the picture of the blue car demo)? I have an idea for a game concept that could use this technique. Also, conceivably, how many images could be done with a bankswitched 32K rom?

 

That was a truly lovely car. Ford Laser 3 door hatchback, 1981 model. I bought it for $8500 in 1987 or thereabouts and sold it in 1999 for just $50. It was still working but had become, in my opinion, unsafe to drive. I hope this helps.

 

Cheers

A

[+grafixbmp]

I get how it works but for the best version he came up with, I was wondering, for a still image, how many actual frames are used and how much data it takes to display a BG still image (ie: the picture of the blue car demo)? I have an idea for a game concept that could use this technique. Also, conceivably, how many images could be done with a bankswitched 32K rom?

 

That was a truly lovely car. Ford Laser 3 door hatchback, 1981 model. I bought it for $8500 in 1987 or thereabouts and sold it in 1999 for just $50. It was still working but had become, in my opinion, unsafe to drive. I hope this helps.

 

Cheers

A

Actualy, I bought a 1988 Dodge Omni hatchback from my best friend for $400 when I was out my own car so I would have a car for work. It was about a year ago and it only had just a bit over 64,000 miles on it at the time. It has still not rolled over 100,000 yet. It was originaly owned by an elderly lady who drove it no more than 10/15 miles a week.

 

But I digress. I was actually more curious about atari things. I guess the only thing about the actual question that would help the most would be how many images would you think would fit on a 32K bankswitched rom

 

edit:

I was simply thinking of game styles like resident evil, silent hill, and alone in the dark.

When Hi color images were acheived on a gameboy color by constantly changing the raster inputs for the screen, this new mode was then used for several games as title screens and such. However it wasn't untill alone in the dark 4 The new nightmare came out for GBC that it was fully utilized for in game graphics. This game was nice in my opinion, even though it lacked the overall depth of the big console ports like the dreamcast version. I thought an original game idea played in a similar way would work on the atari. but that would depend on how much space it required for a cart then it would have to be tweaked a bit for a decent game to fit well.

Edited January 13, 2008 by grafixbmp

[+Andrew Davie]

But I digress. I was actually more curious about atari things. I guess the only thing about the actual question that would help the most would be how many images would you think would fit on a 32K bankswitched rom

 

6 bytes per line (5 if you pack PF0) for a single colour. Triple this for R/G/B triplets.

192 lines/screen.

6 * 3 * 192= 3456 bytes/frame. Or 2880 if you pack.

32K/2880 (leave some overhead for game logic!) = 11 frames. But you'd have to have each frame carefully organised to avoid page crossings, requiring something like a ram-based cart. In any case, let's say 10 frames maximum.

Cheers

A

[vdub_bobby]

6 bytes per line (5 if you pack PF0) for a single colour. Triple this for R/G/B triplets.

192 lines/screen.

6 * 3 * 192= 3456 bytes/frame. Or 2880 if you pack.

32K/2880 (leave some overhead for game logic!) = 11 frames. But you'd have to have each frame carefully organised to avoid page crossings, requiring something like a ram-based cart. In any case, let's say 10 frames maximum.

But if you just used PF1/PF2 (reflected) for a narrower picture, and didn't use the entire screen's height, instead using, say, 160 lines, you're down to 4 * 3 * 160 = 1920.

 

Gets you up to 16 frames. Probably not enough for a game, still.

Edited January 14, 2008 by vdub_bobby

[+grafixbmp]

Maybe I could arange data and do some kind of smart framing style. not all pictures need every color in certain areas where all the data would be just zeros. That could just be blanked. but knowing where to draw the next lines and not to draw is the hard part. Basicaly, "If it isn't needed, don't use it" also Some of the images could be simplified and parts could be reused. maybe a type of selective tiling. And first and foremost, not all of the screen will be used. If I could create some generic parts that look good and could be reused, I could maybe make several extra pics using parts from others.

I was thinking about a survival horror set in the woods where a camping group is and people dissapear and you have to figure out what happened to them by solving problems/puzzles to advance. like find a rope and use it to swing from a tree across a river. I hope to make this a dark game. Even though it is hard to portray emotion through a 2600 game. If I can come up with some non moving BG pics and then have player 0 be who you control then you just move around and go from frame to frame getting items and fighting creatures here and there. It might work. just fitting it all in there may be difficult.

[vdub_bobby]

Yeah, if were clever you could probably increase the number of pics. And maybe use some of the players/missiles to add detail to a more generic location.

 

And also - the 2007 Holiday cart uses a 64K board which I *think* will be available for homebrewers to use. So that doubles your space right there.

[+grafixbmp]

Yeah, if were clever you could probably increase the number of pics. And maybe use some of the players/missiles to add detail to a more generic location.

 

And also - the 2007 Holiday cart uses a 64K board which I *think* will be available for homebrewers to use. So that doubles your space right there.

That is rather cool. an actual 64K cart size with it's own bank switching scheme. I would love to see the specks for that. I bet I could shove about 50 images onthat sucker. That is accounting for a tiled or strip graphic layout. and enough combiations for each part to arange so many diffrent BG images I bet a survival horror game could be made.

 

Like in some scenes, the sky have a few clouds at night and a moon. This of course is drawn with the big pixels. some paths to walk that would be about 8 to 14 combinations which could then be reused over and over again for diffrent scenes. THe main graphic could be a regular sprite like normal who is the guy in the wooods. I can actualy do some nice graphics. I did amario and luigi that someone just that was scary good. I call the game Survival: the dark woods. Other games like it could be in like a sieres of games. Survival: THe swamp of sarrow. or Survival: THe forbidden mountains. Just diffrent places for thoes type of games to take place. I bet if this could be done, it would be kick ass.

[supercat]

That is rather cool. an actual 64K cart size with it's own bank switching scheme. I would love to see the specks for that. I bet I could shove about 50 images onthat sucker. That is accounting for a tiled or strip graphic layout. and enough combiations for each part to arange so many diffrent BG images I bet a survival horror game could be made.

 

Some sort of 64K cart will most likely be available, but I'm not sure if the X07 banking scheme will be released for general use, since it has a special feature which allows something people have never seen and heard before, but which might be too confusing for most programmers to handle.

[vdub_bobby]

but which might be too confusing for most programmers to handle.

Yeah, since 2600 programming in general is sooooo simple.

 

There are so many complicated banking schemes out there I'm surprised you can say that with a straight face.

[+batari]

That is rather cool. an actual 64K cart size with it's own bank switching scheme. I would love to see the specks for that. I bet I could shove about 50 images onthat sucker. That is accounting for a tiled or strip graphic layout. and enough combiations for each part to arange so many diffrent BG images I bet a survival horror game could be made.

 

Some sort of 64K cart will most likely be available, but I'm not sure if the X07 banking scheme will be released for general use, since it has a special feature which allows something people have never seen and heard before, but which might be too confusing for most programmers to handle.

A different PLD program could turn them off, but I wonder if it might be useful to offer both PLD programs in case a programmer does find a use for the features?

 

Either that, or allow the feature to be turned on and off via software control (i.e. a special hotspot.)

[supercat]

Either that, or allow the feature to be turned on and off via software control (i.e. a special hotspot.)

 

It may make sense to have X07 as a semi-general-purpose banking scheme at some point, but let's tease people with it for a little while as "exclusive" and see if anyone can figure out how it works.

 

Having a hotspot to turn the feature on and off would probably not be practical, since that would require another latch, which simply isn't there.

Edited January 16, 2008 by supercat

[+batari]

Having a hotspot to turn the feature on and off would probably not be practical, since that would require another latch, which simply isn't there.

I thought there might be a few free macrocells (though I haven't examined the PLD code too much.) Does your HDL compiler do automatic logic minimization?

[supercat]

I thought there might be a few free macrocells (though I haven't examined the PLD code too much.) Does your HDL compiler do automatic logic minimization?

 

Automatic logic minimization on a 16V8 What could one put in a 16V8 that would be complicated enough to require such a thing?

 

Actually, were it not for the "registered mode" requirement that pin 11 serve as an output enable instead of an input, there would be a macrocell available. As it is, though, two of the macrocell pins end up getting used as input (one macrocell generates chip-select, one generates the timing-cap output, and four generate RA12-RA15).

[+batari]

I thought there might be a few free macrocells (though I haven't examined the PLD code too much.) Does your HDL compiler do automatic logic minimization?

 

Automatic logic minimization on a 16V8 What could one put in a 16V8 that would be complicated enough to require such a thing?

 

Actually, were it not for the "registered mode" requirement that pin 11 serve as an output enable instead of an input, there would be a macrocell available. As it is, though, two of the macrocell pins end up getting used as input (one macrocell generates chip-select, one generates the timing-cap output, and four generate RA12-RA15).

I don't recall how complicated the logic equations were, but I understand if you need more than a certain number of product terms, you can use up a macrocell. That, and the VHDL compiler always seems to produce shorter logic equations than I can do by hand, even on these small projects. That's all I meant to say.

[supercat]

I don't recall how complicated the logic equations were, but I understand if you need more than a certain number of product terms, you can use up a macrocell. That, and the VHDL compiler always seems to produce shorter logic equations than I can do by hand, even on these small projects. That's all I meant to say.

 

If a design is large enough to require the use of macrocells to generate intermediate results, then there will often be multiple ways of subdividing the problem, some of which will yield better results than others. An optimizer may be useful to try the different approaches and select the best. I suppose one might have such a project on a 16V8, though I've never seen one. Certainly when one gets into the realm of something like a 95C36XL such things become a much bigger issue.

 

In cases where one is simply trying to find the shortest set of product term equations corresponding to a known set of constraints, though, I don't think a particularly brilliant program is required. Simply determine all the different possible equations that fit within the solution space, eliminate any whose output is entirely a subset of another, and then find the smallest subset of those that fills the space.

 

If one is using non-synchronous logic and hazard avoidance becomes an issue, that may complicate things. Even on a 16V8, automated hazard-avoidance logic could be helpful if the automated tools were made aware of the possible switching sequences of the inputs.

[Mark2008]

What I think would be the ultimate 2600 hardware hack, would be to develop a cartridge that is using FPGA computer on a chip.

 

The 2600 then becomes nothing but a display driver and joystick reader...nothing else. The chronotech, really demonstrates how it would work. It would read from an area of the rom, display it. Read, display...thats all the real 2600 processor would ever do.

 

on a regular 4k rom, thats one screen, never changing...not much of a game. (not a game at all of course, I was being funny)

 

But on an fpga computer on a chip....that area would actually not be rom, even if it appeared to the atari that it was... it would be a ram buffer...it would be changing each update.

 

no math about how many frames you can get on a cart, would apply. the fpga computer would be actually calculating each frame based on its game logic, and putting out frames on the fly...the fpga comptuer being a considerably more powerful beastt than the 2600.

 

the somewhat flickery nature of the 2600's chrono tech display...can be forgiven with the right game...imagine if it was a fast paced 3d, somewhat dark shooter....

 

anyway...its a nice dream. I don't think 2600 programmers would care for it, because its really the FPGA computer, that is doing all the work...and therefore you aren't really programming for a 2600 at that point, but in actuality programming for whatever computer you are emulating in the fpga...with its 2600 interface, being the only relation to the actual 2600.

 

no emulator would automatically be ready to emulate that cart, for obvious reasons too.

 

But....from an end users perspective, it would rock....

 

I just thought I'd talk out loud about that pipe dream, since it seemed to relate to this thread.

 

I'm not a hardware guy, and never will be.....but its a nice thought.

[+grafixbmp]

I have been thinking about this concept for a while and I think I onlyneed 32K size for this. The full screen doesn't even cover all of it because the top edge and a portion of the bottom are used for a hud and basic game icons. the rest of the screen is broken up into 6 rows that are split down the middle. for a total of 12 sections or (big tiles). I can probably take enough space for 6 or 7 ful screen pics and get enough to create 25 pics. I was aldo thinking about hand drawing the hi color images myself. If I do it, there would be less noticable dithering and more color combinations.

[+grafixbmp]

I have refined my design a bit more for the screen fit and the data sizes. starting from the top, the first 8 rows are used for a simple hud and icon bar. from there there are 6 row groupings of 28 rows each with 6 of them down the screen. each complete section if any picture is 28 by 20. layed out as 6 x 2. the lowest part of the screen is a larger hud with some menu features that is 16 rows for a total of 192 scan lines.

 

So each section is 28 by 20 pixles.

 

that is at least 3 bytes unpacked by 28: 3 * 28 = 84

and then triple for R G B colors: 84 * 3 = 252

 

That is just the size of one large tile

Lets say you want to fit that size into a 32K space as many times as you can with enough left over fro game logic,etc.

 

114 individual tiles would take up almost 29K

but we didn't even pack these

if packed, we would use 2.5

that would be 2.5 * 28 = 70

70 * 3 = 210

210 divided into almost the same amount of space gets you around 136 tiles with just as much space for game logic.

 

I imagine that I won't even need this much. some scenes could possible repeat the left an right sides.the real deal I am wondering about is reloading the right hand side of the screen from a totaly diffrent part of memory quick enough.

 

 

I figured it would take up less space in the game logic if I didn't pack the main part at all. I din't even think I would even use 136 tiles let alone 114. you can get quite a few combinations with only 12 blocks on screen. and 114 possible ones to use. I will also have some small hi res ones too for some cut scenes where these would be packed for sure to save space. Imay have some text here and there too. I just need to work on the game layout/design to see if the numbers are good enough to pull something off.

[+grafixbmp]

What I think would be the ultimate 2600 hardware hack, would be to develop a cartridge that is using FPGA computer on a chip.

 

The 2600 then becomes nothing but a display driver and joystick reader...nothing else. The chronotech, really demonstrates how it would work. It would read from an area of the rom, display it. Read, display...thats all the real 2600 processor would ever do.

 

on a regular 4k rom, thats one screen, never changing...not much of a game. (not a game at all of course, I was being funny)

 

But on an fpga computer on a chip....that area would actually not be rom, even if it appeared to the atari that it was... it would be a ram buffer...it would be changing each update.

 

no math about how many frames you can get on a cart, would apply. the fpga computer would be actually calculating each frame based on its game logic, and putting out frames on the fly...the fpga comptuer being a considerably more powerful beastt than the 2600.

 

the somewhat flickery nature of the 2600's chrono tech display...can be forgiven with the right game...imagine if it was a fast paced 3d, somewhat dark shooter....

 

anyway...its a nice dream. I don't think 2600 programmers would care for it, because its really the FPGA computer, that is doing all the work...and therefore you aren't really programming for a 2600 at that point, but in actuality programming for whatever computer you are emulating in the fpga...with its 2600 interface, being the only relation to the actual 2600.

 

no emulator would automatically be ready to emulate that cart, for obvious reasons too.

 

But....from an end users perspective, it would rock....

 

I just thought I'd talk out loud about that pipe dream, since it seemed to relate to this thread.

 

I'm not a hardware guy, and never will be.....but its a nice thought.

 

Everything you are saying relates directly to a post I made a wile back and interestingly, there is such a device in the works now called the Chimera. Ituses an ARM7 processor that runs rather fast; 71.5 MHz. to be exact. Here is the post I made and the other stuff of the Chimera is there too by the creator.

 

http://www.atariage.com/forums/index.php?s...=116754&hl=