ColecoVision - The best is yet to come

[Murph74]

 

That job is not as cool as you may think. When you find yourself bring checks home to review at 9:00 at night, sitting in front of the tv watching reruns of The A-Team, call me. Got some work to do now.

 

Hell, I don't want the job-- just the title.

Edited November 23, 2006 by Murph74

[Murph74]

Ok, here's an idea of what I have in mind fo rhte fund meter, without the direct paypal link just yet...

 

http://www.lupusx.com/index.php?option=com...r&Itemid=26

 

The script comes from http://donationbooster.com but they want to own the info they collect, and charge to use their stuff.

 

Anyone good at changing things around in scripts or writing something similar from scratch?

 

I'm thinking 2 scripts would be ideal-- One is a pledge meter, just for listing commitments of money. The second is the collection meter with the paypal link to actually keep track of monies invested already.

 

And Eduardo, hosting it on your site is as good of a place as any. Matter of fact, if you're ok wit it, I might just redirect or at least link my domain to your site. I just haven't had time to do anything with "colecocollector.com" other than post an outdated list of games for a checklist.

[MausBoy]

The BasicVision IDE sounds completely awesome too. I think it adds a lot of value to this project that it includes tools to encourage a bunch of 3rd party games being made for it.

[opcode]

Ok, here's an idea of what I have in mind fo rhte fund meter, without the direct paypal link just yet...

 

http://www.lupusx.com/index.php?option=com...r&Itemid=26

 

The script comes from http://donationbooster.com but they want to own the info they collect, and charge to use their stuff.

 

Anyone good at changing things around in scripts or writing something similar from scratch?

 

I'm thinking 2 scripts would be ideal-- One is a pledge meter, just for listing commitments of money. The second is the collection meter with the paypal link to actually keep track of monies invested already.

 

And Eduardo, hosting it on your site is as good of a place as any. Matter of fact, if you're ok wit it, I might just redirect or at least link my domain to your site. I just haven't had time to do anything with "colecocollector.com" other than post an outdated list of games for a checklist.

 

Seems good, please go ahead.

 

I had some free time today and started implementing the sound CPU. So far I have the sound CPU, sound memory and memory decoding, as well as our first sound chip. The electric part is ok, but now we need to exercise the sound CPU. Propably I will replace the sound RAM with an EPROM and will program the sound CPU to generate some tones with the sound chip. Next I will add the sound latch, so the sound CPU can receive commands from the main CPU. The last stage will be to add the bus driver circuitry, so the main CPU can load a program into the sound RAM.

 

Eduardo

[opcode]

We got 20 names!

 

Eduardo

[Troy_Whelan]

We got 20 names!

 

Eduardo

Make that 21, you know I am in!

 

Troy

[ten-four]

We got 20 names!

 

Eduardo

 

If it works fine with a PAL version...I'm in too.

 

Can PacMan Collection and the forthcomming Donkey Kong Arcade run without your OpModule ?.

 

Do OpCode have a pic. of Opcontroller ?.

[AussieAtari]

Guys, would it be possible to PM each member who has pledged support once the register is up and running on the Opcode site so we can get in and "put our money where our mouths are" and secure our "shares"?

Edited November 28, 2006 by AussieAtari

[Pixelboy]

If it works fine with a PAL version...I'm in too.

 

Can PacMan Collection and the forthcomming Donkey Kong Arcade run without your OpModule ?.

 

Do OpCode have a pic. of Opcontroller ?.

Since Eduardo is busy preparing for his move to the US, I guess I can try to answer those questions on his behalf. Of course, he might show up at any time and correct me.

 

Whether or not the Opgrade Module will work on a PAL CV is up in the air right now, because we're still not sure which video chip we'll be using. I don't know all that much about PAL versus NTSC, but I do know that Eduardo is planning to add A/V and S-Video outputs to the OM. (I don't know if old CV carts will be able to use the A/V or S-Video instead of the standard RF output, BTW).

 

Pac-Man Collection doesn't require the OM, but I believe once the OM prototype is built, Eduardo will want to add some OM-centric features, like better sounds and better colors. But it will be completely optional, so if the PMC cart doesn't detect the OM plugged into the expansion port, it will run in "vanilla mode".

 

As for Donkey Kong, Eduardo told me he wants to port the actual arcade ROM (as much of it as possible, anyhow), and the arcade game requires 4K of RAM, so unless he does things differently, the Opgrade Module will be required to play Donkey Kong Arcade (since the CV has only 1K of RAM).

 

I believe Opcode built a prototype of his Opcontroller, but I've never seen any picture of it. I seem to recall Eduardo mentionning that his prototype was pretty bulky. That's pretty much all I know about it.

[opcode]

Since Eduardo is busy preparing for his move to the US, I guess I can try to answer those questions on his behalf. Of course, he might show up at any time and correct me.

 

Whether or not the Opgrade Module will work on a PAL CV is up in the air right now, because we're still not sure which video chip we'll be using. I don't know all that much about PAL versus NTSC, but I do know that Eduardo is planning to add A/V and S-Video outputs to the OM. (I don't know if old CV carts will be able to use the A/V or S-Video instead of the standard RF output, BTW).

 

About PAL, no matter which video chip we end using, both are PAL-ready, no problem. The same is true for the video encoder, which can output composite, S-video and RGB.

And, yes, legacy games will be able to use all the new outputs.

 

Eduardo

[moonpatrol]

Count me in for $100.

[MegaManFan]

You can put me down as a supporter too (in all uses of the word).

[misspent_youth]

even an athletic supporter?

 

 

 

OK sorry that was bad...

[opcode]

Hi!

 

Thanks for all the support!

We are now 25. I will start to contact you guys once I am settled in my new home.

 

In the meantime, I have a question for you guys: between a backward compatible video processor and a more powerful, albeit not backward compatible video processor, which one would you prefer?

Being backward compatible has the advantage that the new video outputs could be used by any legacy game (not requering you to use the RF output anymore).

In the other hand, the non backward compatible solutions is at least four times as powerful. To make things not so abstract, consider the specs bellow:

 

Compatible VDP (specs are for new video mode):

 

- 256x224 resolution

- 500 tiles max, 4 bits per pixel

- 1 background plane

- 32 colors selectable from 64

- 64 sprites, 8x16 pixels

- 8 sprites per scanline

 

Non-compatible VDP:

 

- 256x212 or 512x212 resolution

- 16K tiles max, 4 bits per pixel

- 2 independent background planes

- 64 colors selectable from 32K

- 128 sprites, 16x16 pixels

- 16 sprites per scanline

- Additional AV modes available with resolution up to 768x480 and 32K colors

 

Supposing both would cost the same, which one would you prefer?

 

Eduardo

[Murph74]

My quick response is 'more is better', and like the numbers on the non compatible chip. But I also wonder right away how 'colecovision' it would be to have DVD quality gaming graphics coming from that machine.

 

So in less than 15 seconds, I vote for compatible-- it will help keep the colecovision vibe, and allow the outputs to be used for legacy titles it sounds like. My thinking against hte newer chip is simply it makes a different system-- if you're going to do that, why bother with the colecovision as a core, and just build a standalone?

[Pixelboy]

In the meantime, I have a question for you guys: between a backward compatible video processor and a more powerful, albeit not backward compatible video processor, which one would you prefer?

Being backward compatible has the advantage that the new video outputs could be used by any legacy game (not requering you to use the RF output anymore).

In the other hand, the non backward compatible solutions is at least four times as powerful. To make things not so abstract, consider the specs bellow:

 

Compatible VDP (specs are for new video mode):

 

- 256x224 resolution

- 500 tiles max, 4 bits per pixel

- 1 background plane

- 32 colors selectable from 64

- 64 sprites, 8x16 pixels

- 8 sprites per scanline

 

Non-compatible VDP:

 

- 256x212 or 512x212 resolution

- 16K tiles max, 4 bits per pixel

- 2 independent background planes

- 64 colors selectable from 32K

- 128 sprites, 16x16 pixels

- 16 sprites per scanline

- Additional AV modes available with resolution up to 768x480 and 32K colors

 

Supposing both would cost the same, which one would you prefer?

There are several issues to examine aside from cost. A non-compatible VDP means that certain old CV games might not run correctly, which means the user would need to unplug the Opgrade Module to play those games, and so the ability to use something else than RF output would be lost. It's not that big a deal, but still annoying because we're not sure yet which legacy games will run and which games will have problems with the OM.

 

There's also the game-dev point of view to consider. The larger tile tables and the new resolutions offered by the non-compatible VDP seem preferable in theory, but are they more trouble to program for? The same question applies to sprites, but it's even more important, because the programmer will manage sprites constantly, no matter what the game is. 8x16 sprites are bothersome when your sprite graphics are made to fit in 16x16, but it's far from being unmanageable.

 

Also, in either case, using 4 bits per pixel means the graphic data will require roughly twice as much more ROM space on the cart. Keeping this in mind, will the MegaCart be required for any game tailored for the OM? If yes, then this probably means that Opcode Games will be releasing all the OM-centric games, and in the end, we have to ask ourselves if we really need the extra power of the non-compatible VDP. Seems to me like we little people could live with the compatible VDP if it's less trouble to program for.

 

BTW, Eduardo, you didn't mention the static areas definable with the compatible VDP. Are they also available in the non-compatible VDP?

[NightSprinter]

Regardless of what, count me in. I would most certainly like to see my old CV get more use. If it isn't too late yet, also put me in for a copy of PMC as well for both CV and MSX2.

[opcode]

My quick response is 'more is better', and like the numbers on the non compatible chip. But I also wonder right away how 'colecovision' it would be to have DVD quality gaming graphics coming from that machine.

 

So in less than 15 seconds, I vote for compatible-- it will help keep the colecovision vibe, and allow the outputs to be used for legacy titles it sounds like. My thinking against hte newer chip is simply it makes a different system-- if you're going to do that, why bother with the colecovision as a core, and just build a standalone?

 

Well, you know, in the end any improvement would result in a different system.

To put it more in perspective, the compatible chip is from mid 80s, while the non-compatible is from late 80s. The non-compatible, while obviously non-compatible, derivate from a compatible family, the V99XX, and was created for use with the MSX3 computer family (which, btw, was canned before release). For the MSX experts here, yes, I am talking about the V9990.

And finally, I wouldn’t say that the V9990 is "DVD quality". In tile mode it can display "only" 64 colors, so it is more in the Genesis/SNES class...

The reason I am asking the question about compatibility/not compatibility here was that I am not being able to find the compatible solution at a reasonable price, so I started to wonder what you guys would think if we used a non-compatible solution.

But ok, please keep posting your comments.

 

Eduardo

[opcode]

There are several issues to examine aside from cost. A non-compatible VDP means that certain old CV games might not run correctly, which means the user would need to unplug the Opgrade Module to play those games, and so the ability to use something else than RF output would be lost. It's not that big a deal, but still annoying because we're not sure yet which legacy games will run and which games will have problems with the OM.

 

Not really. The new video chip would be simply another device, and it would even work in parallel with the old video (though I can't see any practical use for it). In fact the new video would be able to output to both the new output jacks and CV RF, while the old video could output only to the RF.

The compatible option, in other hand, should replace the CV video, meaning that only the new video could be active while the OM was plugged in.

 

There's also the game-dev point of view to consider. The larger tile tables and the new resolutions offered by the non-compatible VDP seem preferable in theory, but are they more trouble to program for? The same question applies to sprites, but it's even more important, because the programmer will manage sprites constantly, no matter what the game is. 8x16 sprites are bothersome when your sprite graphics are made to fit in 16x16, but it's far from being unmanageable.

 

I can't see the difference. Both are 4 bits per pixel, so the necessary work to produce graphics is the same for both chips. More sprites and tiles doesn't mean more work, since you don't need to use them all. Instead, more sprites means you can place more objects on screen and don't worry about flickering.

 

Also, in either case, using 4 bits per pixel means the graphic data will require roughly twice as much more ROM space on the cart. Keeping this in mind, will the MegaCart be required for any game tailored for the OM? If yes, then this probably means that Opcode Games will be releasing all the OM-centric games, and in the end, we have to ask ourselves if we really need the extra power of the non-compatible VDP. Seems to me like we little people could live with the compatible VDP if it's less trouble to program for.

 

Ok, maybe you are assuming that Genesis-class graphics means Genesis-class games. Well, it isn't necessarily true. I can have all this graphic power and use it just to make a better port of Donkey Kong. The CV uses 2 bits per pixel (1 for pattern and 1 for color), so yes, graphics will take more cartridge space. But it doesn't mean that OM games would always require a MegaCart. I would say that a 24KB CV game would be updated with new graphics and still fit inside standard CV carts.

About extra power, there is two points to consider:

1) Will the extra power mean more cartridge space: no, since both solutions use 4 bits per pixel.

2) Do we need the extra power: maybe not, but if we can pay the same for both, what's the problem?

The only real question, as I mentioned before is, how important is to have the new video outputs working with legacy games?

 

BTW, Eduardo, you didn't mention the static areas definable with the compatible VDP. Are they also available in the non-compatible VDP?

 

Static areas? Oh, yeah, right! The V9990 can do a lot better. First because scrolling can be changed on the fly, allowing any kind of split screens. 2nd because the V9990 has two independent background planes. And 3rd, because the planes can have different priorities for each 64x64 area. Rally-X or Bosconian could be done with no trouble on the V9990.

 

Eduardo

[Pixelboy]

The non-compatible, while obviously non-compatible, derivate from a compatible family, the V99XX, and was created for use with the MSX3 computer family (which, btw, was canned before release). For the MSX experts here, yes, I am talking about the V9990.

Oh! I thought you were comparing the 315-5146 to the V9958, but you're actually comparing it to the V9990. My mistake.

[misspent_youth]

I vote for backward compatibility, solely for the ability to use the modern connections to play original games. Then again, i guess I could always just mod a CV for component output and use that for the legacy games, but then I need to make yet more room at my gaming rig.

[opcode]

The non-compatible, while obviously non-compatible, derivate from a compatible family, the V99XX, and was created for use with the MSX3 computer family (which, btw, was canned before release). For the MSX experts here, yes, I am talking about the V9990.

Oh! I thought you were comparing the 315-5146 to the V9958, but you're actually comparing it to the V9990. My mistake.

 

Ok.... since you have now reveled our options, let explain here what are the pros and cons of each solution...

 

V9958:

(Created by ASCII for the MSX computers)

New modes use linear framebuffer scheme, so it isn't exactly a game centric VDP

256x212 or 512x212 modes, 16 colors from 512 (four bits per pixel). Graphics7 mode can display 256 or 19K colors simultaneously (8 bits per pixel).

Blitter helps CPU with graphic transfers.

32 sprites on screen, 8 sprites per scanline. 16x16 pixels, 1 color per scanline (!). However sprites can be superimposed and OR-ed to produce more colors per scanline.

Hardware scroll, programmable scanline interruption

pros:

- the best TMS9928 compatible solution available

- color emulation is very good

- general emulation is almost 100% perfect. No import feature was left un-emulated

- new features (color palette, hardware scroll, etc) can be used with legacy modes

- though it isn't a tile based solution, there is enough space in VRAM for more than 4K "virtual" tiles

cons:

- sprites weren't improved that much

- background animation is usually slow, since it is a frame buffered solution

- fairly complex to program

 

315-5246:

(created by Sega for the SMS) <Eduardo takes shelter...>

New mode is tile based.

256x224, 32 colors from 64.

Sprites are 8x16, four bits per pixel, 64 sprites on screen, 8 sprites per scanline.

Hardware scroll, programmable scanline interruption (though vertical scrolling can not be changed mid screen) (go figure)...

pros:

- good VDP for games

- sprites are better than V9958

- animation is fast, since it is a tile solution

- easy to program

cons:

- not 100% compatible. AND masking with base table registers wasn't emulated.

- bad color emulation

- small VRAM means fewer tiles available (around 500)

 

V9990:

(created by ASCII/Yamaha for the MSX3)

Not compatible with TMS9928

It has two game modes (tile based). Mode1: 256x212, 4 bits per pixel, 2 planes, 64 colors from 32K. Mode2: 512x212, same as mode1, but with a single plane.

Sprites are 16x16, four bits per pixel, 128 sprites on screen, 16 sprites per scanline.

Hardware scroll, programmable vertical and horizontal interruption, programmable plane and sprite priority.

Additional modes are framebuffer based, with no sprite, but good for animations, as the V9990 has a incredibly fast blitter coprocessor, up to 20 times faster than the V9958 blitter. Up to 512x424 with 32K colors, or 768x480 with 16 colors.

pros:

- good for games

- really powerful

- 16K tiles

- easy to program

cons:

- not backward compatible

 

Eduardo

[Pixelboy]

Ok.... since you have now reveled our options, let explain here what are the pros and cons of each solution...

 

Yeah, we might as well lay it all out on the table, because our contributors should know the dilemma we're facing. There's no perfect solution here:

 

- The V9958 has a lot of desirable features (like the abillity to use hardware scrolling and palette editing with the original CV display modes) but it's "fairly complex to program". I don't know how widely available the chip is, BTW, so long-term supply remains with a question mark.

 

- The 315-5246 is a nice middle-ground for game programming, but the chip is rare, hard to find, and therefore more expensive. Long-term supply is uncertain at best. The colors are less than ideal when used with original CV games, and you can't use advanced features like hardware scrolling with the original CV display modes.

 

- The V9990 is very powerful, but not backward compatible, so old CV games could not use the new video outputs on the OM.

 

From the few responses I've seen here so far, backward compatibility to the new video output jacks seems to be important, which is not surprising, as many people want something better than the crummy RF output. With the OM, people could play all their CV games on modern TVs without having to mod their CV consoles. It's a potent selling point to end consumers, and since the 315-5246 is hard to find and technically not as ideal as we'd like it to be, the good ol' V9958 seems like the best option, even though it's more of a chore to work with at the programming level...

 

BTW, Eduardo, when you say "background animation is slow", do you mean the hardware scrolling is slow, or are you talking about something else?

[opcode]

Ok.... since you have now reveled our options, let explain here what are the pros and cons of each solution...

 

Yeah, we might as well lay it all out on the table, because our contributors should know the dilemma we're facing. There's no perfect solution here:

 

- The V9958 has a lot of desirable features (like the abillity to use hardware scrolling and palette editing with the original CV display modes) but it's "fairly complex to program". I don't know how widely available the chip is, BTW, so long-term supply remains with a question mark.

 

- The 315-5246 is a nice middle-ground for game programming, but the chip is rare, hard to find, and therefore more expensive. Long-term supply is uncertain at best. The colors are less than ideal when used with original CV games, and you can't use advanced features like hardware scrolling with the original CV display modes.

 

- The V9990 is very powerful, but not backward compatible, so old CV games could not use the new video outputs on the OM.

 

From the few responses I've seen here so far, backward compatibility to the new video output jacks seems to be important, which is not surprising, as many people want something better than the crummy RF output. With the OM, people could play all their CV games on modern TVs without having to mod their CV consoles. It's a potent selling point to end consumers, and since the 315-5246 is hard to find and technically not as ideal as we'd like it to be, the good ol' V9958 seems like the best option, even though it's more of a chore to work with at the programming level...

 

BTW, Eduardo, when you say "background animation is slow", do you mean the hardware scrolling is slow, or are you talking about something else?

 

Hi Luc,

 

The V9958 is still easy to find. I have checked a few IC search services and the V9958 is available in ten of thousands, as is the V9990. In other hand, the 315-5246 seems to be very rare, and some IC search services don't even list it.

 

The problem with the V9958 is that it isn't a game-centric IC. A framebuffered mode doesn't use tiles, so it doesn't have a tile map. Thus, if you want to place tile #10 into screen position #100, it isn't like simply copying the tile code to the tile map position 100, but instead you need to copy the whole tile data to that screen position (32 bytes). The blitter can do that for you, but first you need to program the blitter, which is fairly complex. And to be honest the V9958 blitter isn't the fastest thing on Earth, so while it can keep with the scrolling pace, there won't be much blitter time left for background animation. I created that Castlevania demo using the V9958, but I don't think there would be enough time to animate a lot of stuff in the background. So the V9958 can scroll screens as smoothly as any of the other chips, but it cannot compete in the background animation area.

In the other hand, the V9990 has the advantage of having two dedicated game modes (tile modes), while still offering a blitter, which can be used to produce even more complex animations while the CPU is busy with something else.

I will be honest with you: I am used to the V9958, because I have been programming for the MSX for so long, but it is a frightening chip for newcomers.

And there are other idiosyncrasies, like the vertical scroll dragging sprites with it (so you need to compensate moving all sprites up or down) and the sprite color table being too large (128 bytes) and requiring you to move it around when creating sprite flickering.

Probably that's the reason that ASCII created the V9990 incompatible, so they could remake it from scratch.

 

Eduardo

[AussieAtari]

MY CV already has an A/V mod so personally I'd go for the non-backwards compatible way and enjoy the benefits.

 

However, I'd support a general view that backwards compatible would be better, that way everyone can enjoy every CV game on their consoles using the OM.