Will Chimera & bB be best friends?

[MausGames]

Do you think there will be a version of bB that takes advantage of all the cool new things introduced in the Chimera cart? Will it allow all of the features of the standard and multisprite kernel to work together, at the same time, in one kernel?

 

The main things I wonder about though are how many flicker-free sprites it will do, and if it will make possible pixel by pixel playfield and background color changes.

 

If so we'll be able to do cool stuff like these examples, using resolutions now available in the standard kernel with the superchip. Without line at a time coloring, bB games will no longer look like bB games at all, or even 2600 games for that matter. If this is easily possible, Chimera games are already guaranteed to be set apart in appearance and style.

 

[Gorf]

Do you think there will be a version of bB that takes advantage of all the cool new things introduced in the Chimera cart? Will it allow all of the features of the standard and multisprite kernel to work together, at the same time, in one kernel?

 

The main things I wonder about though are how many flicker-free sprites it will do, and if it will make possible pixel by pixel playfield and background color changes.

 

If so we'll be able to do cool stuff like these examples, using resolutions now available in the standard kernel with the superchip. Without line at a time coloring, bB games will no longer look like bB games at all, or even 2600 games for that matter. If this is easily possible, Chimera games are already guaranteed to be set apart in appearance and style.

 

 

What is this Chimera you speak of? Link?

[mimo]

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

 

in simple terms

[mos6507]

It's kind of early to be thinking about this. But I'd like someone to write an accelerated sprite multiplexing routine for Chimera that uses the ARM between frames to figure out the best strategy for the next frame. I just don't know how much better that will be than anything we've seen so far. Suffice to say, to whatever extent sprite flicker minizing and sprite numbers have been limited by VCS RAM and VCS speed, that would go away completely. It would all be up to what the TIA can perform during the kernel itself with repositioning sprites and juggling sprites with playfield duties.

 

BTW, Delicon had another break but as of last week he's been back to work designing what should be the final Chimera board design (knock on wood). We now have ample supply of ARM chips and can therefore offer more beta boards when the time comes.

[potatohead]

Was thinking of every other scanline multiplexing the other day. Simple flicker between two sprites means the whole sprite is essentially gone for one or more frames. If this were done with alternating scan lines, there would be some portion of the image displayed on every frame, in a lot of scenarios.

[Gorf]

It's kind of early to be thinking about this. But I'd like someone to write an accelerated sprite multiplexing routine for Chimera that uses the ARM between frames to figure out the best strategy for the next frame. I just don't know how much better that will be than anything we've seen so far. Suffice to say, to whatever extent sprite flicker minizing and sprite numbers have been limited by VCS RAM and VCS speed, that would go away completely. It would all be up to what the TIA can perform during the kernel itself with repositioning sprites and juggling sprites with playfield duties.

 

BTW, Delicon had another break but as of last week he's been back to work designing what should be the final Chimera board design (knock on wood). We now have ample supply of ARM chips and can therefore offer more beta boards when the time comes.

 

 

I think you would now only be limited by what the TIA can take off the ARM per frame.

Im no 2600 expert, but I imagine the ARM will be able to control the multiplexing duties

alot faster and allow the 6502 to do stuff like input at the same time. I think this will

greatly increase the sprites and lower the flicker to almost nothing. Shoot, I only wish

I knew more about the 2600 hardware than I do. I'd already be working on an app to do

just that.

 

 

And I think and updated version of bB for it would be swell. I think bB on all Atari systems

including my Jag would be sweet actually.

[Gorf]

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

 

in simple terms

 

 

Thanks mimo!

[MausGames]

That's all good to know, and I was hoping that maybe Batari will let us know if he has any plans for Chimera support, and if so what that would mean as far as added features.

 

The examples I posted are sample backgrounds that use the playfield, I hope there will eventually be a version of bB that allows the color of each playfield pixel to be read from tables.

Edited December 18, 2007 by MausGames

[Gorf]

That's all good to know, and I was hoping that maybe Batari will let us know if he has any plans for Chimera support, and if so what that would mean as far as added features.

 

The examples I posted are sample backgrounds that use the playfield, I hope there will eventually be a version of bB that allows the color of each playfield pixel to be read from tables.

 

 

I dont know so much about bB since it is a compiler and my guess is you certainly could add it

in and then like now using custom kernels that recognize and utilize the ARM. Not really knowing

how these 2600 kernel coding guru's even do what they do, I could imagine such a powerful

processor would enable some rather smoking displays.

 

My guess it with the right kernel, we'll see higher rez playfields too. I imagine so using some

wizardry like they do in a game like 2600 Battlezone or Beamrider which appear to have a

higher vertical and horizontal resolution (though Im sure there is some form of coding

hocus pocus to pull such feats off on the 2600. )

 

Normally I would be not to keen on such addons with a new processor, but the 2600 is so

well overworked as it is, I think it's time to give it a nice little helper. I would imagine a bB

that can take advantage of such new features will happen if the device draws enough interest.

 

It sounds to me from what I've read so far about it is that the intention of the ARM is to only

enhance the 2600 hardware and not take it over. If that is the case I would imagine it would

not be too terribly hard to hook in the new features of the Chimera into bB. I'll be keeping an

eye open for this one. I really dig the concept.

Edited December 19, 2007 by Gorf

[mos6507]

That's all good to know, and I was hoping that maybe Batari will let us know if he has any plans for Chimera support, and if so what that would mean as far as added features.

 

The examples I posted are sample backgrounds that use the playfield, I hope there will eventually be a version of bB that allows the color of each playfield pixel to be read from tables.

 

The 6507 still runs the show. Chimera can not completely take over the VCS and drive the TIA at 72mhz. (It's not technically possible to do do that without cracking open the case and replacing the CPU.) Chimera lets you load data faster for register stuffing, but not fast enough to change the playfield every single pixel. The 2600 can only change registers as fast as it takes the 6507 to read in a constant, which is 2 cycles. So the only way to use that method would be for Chimera to dynamically perform surgery on the code between frames or groups of scanlines. That's a measure of last resort because it would be tricky for the programmer to set up the target addresses for the surgery. Under normal circumstances you're talking about 4 cycle loads, maybe 3 in some cases.

 

But you'd be able to have very dynamic displays where every scanline can be utilized independently (because of no RAM limits) and the overall display changes a lot between frames (because the ARM does the rendering to RAM).

 

The ARM has two duty cycles, the kernel and vertical blank. During the kernel it will mostly be feeding data to the VCS. Between frames it will mostly be rendering the data for the next frame. In addition, the ARM will be constantly servicing peripherals so that pending input or output keeps moving at all times. The only time the ARM will be idle is after it loads a legacy game. In a Chimera game, it will be running in parallel with the VCS at all times. A multiprocessor, but one step removed from the bare metal. The only crossover point will be the cart RAM/hotspots.

Edited December 27, 2007 by mos6507

[mos6507]

not be too terribly hard to hook in the new features of the Chimera into bB.

 

bB would have to change a lot for Chimera. For instance, RAM writing would be done in a traditional manner. So you could have a more fully featured BASIC implementation.

 

Since so much of the actual hard work will be hidden behind Chimera library functions in the ARM, it may be just as easy to code in straight assembly and use code snippets and macros to call these functions. A lot of the abstraction that bB does is essentially a code wizard so for Chimera there is far less code generated since the meat is in the ARM.

Edited December 27, 2007 by mos6507