ColecoVision - The best is yet to come

[opcode]

If a picture is worth 1000 words, a movie is worth a million words.

 

Here is a link for Space Manbow, a MSX game using the V9958. The interesting thing about Space manbow is that it doesn't use any of the new framebuffered modes, but instead it uses graphics2, the same mode used by almost all CV games, but with the new features turned on, like hardware scrolling, the new sprite mode, programmable color palette and scanline interruption (used for creating that fixed score area).

It also uses the same WSG sound chip that we are using with the OM (and that I have already ordered a hundred units).

 

 

And here are two videos from the V9990 in action. Unfortunately the V9990 was never used with any commercially available product (since the MSX3 was cancelled), so the video came from a MSX with a V9990 expansion board (which I happen to have one, and have been playing with for a while). Also, the video was taken from a homebrew game, which is still in very early stages of development. A bit boring and generic so far, but I think it can demonstrate some of the V9990 capabilities.

 

http://www.youtube.com/watch?v=Rpn6BLU8Q4s...ted&search=

http://www.youtube.com/watch?v=c1uMIRVHxrA...ted&search=

 

Eduardo

[Pixelboy]

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.

So let me get this straight: You made the Castlevania Redux demo using one of the newer video modes of the V9958? Alright, so if we used the "enhanced" graphic mode 2 (used by Space Manbow) instead, we wouldn't have to bother ourselves with the blitter issues, which would make background animations (whatever those are...) more accessible?

 

 

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.

This is interesting... is this "vertical scroll drag idiosyncrasy" also present in "enhanced" graphic mode #2?

[opcode]

 

So let me get this straight: You made the Castlevania Redux demo using one of the newer video modes of the V9958? Alright, so if we used the "enhanced" graphic mode 2 (used by Space Manbow) instead, we wouldn't have to bother ourselves with the blitter issues, which would make background animations (whatever those are...) more accessible?

 

Yep, but in other hand you would be under the same limitations as mode2: only two colors per tile line, only 256 tiles, etc...

 

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.

This is interesting... is this "vertical scroll drag idiosyncrasy" also present in "enhanced" graphic mode #2?

 

Yep.

 

Eduardo

[Murph74]

While you guys talk tech (and over my head) I'm gonna clarify my DVD statement.

 

That was in reference to your spec of "Additional AV modes available with resolution up to 768x480 and 32K colors", most consumer DVD-Video disks utilize either 4:3 or 16:9 aspect ratio MPEG-2 video, stored at a resolution of 720x480 (NTSC) or 720x576 (PAL). So actually, it's 'above' most DVD spec.

 

it may or may not make a difference depending on whether it's true resolution, or simply a 384x240 doubled to fill that area. I've seen some emus like Atari 800Win use the 768x480resolution in fullscreen-- gives a more accurate 'emulated' display without showing the 'full' overscan area.

[opcode]

While you guys talk tech (and over my head) I'm gonna clarify my DVD statement.

 

That was in reference to your spec of "Additional AV modes available with resolution up to 768x480 and 32K colors", most consumer DVD-Video disks utilize either 4:3 or 16:9 aspect ratio MPEG-2 video, stored at a resolution of 720x480 (NTSC) or 720x576 (PAL). So actually, it's 'above' most DVD spec.

 

it may or may not make a difference depending on whether it's true resolution, or simply a 384x240 doubled to fill that area. I've seen some emus like Atari 800Win use the 768x480resolution in fullscreen-- gives a more accurate 'emulated' display without showing the 'full' overscan area.

 

I see. Well, anyway the 768x480 mode is an overscan mode with only 16 colors. 512x424 is the highest resolutin mode with 32K colors.

 

I have a V9990 board here, complete with VRAM and video encoder, so I could connect it to my prototype and play with it for a while... I will do that over the weekend and send pictures later. I also have several V9958s here, but I need a SDIP to DIP adapter first, which I can order once I am in the US.

 

Eduardo

[Pixelboy]

So let me get this straight: You made the Castlevania Redux demo using one of the newer video modes of the V9958? Alright, so if we used the "enhanced" graphic mode 2 (used by Space Manbow) instead, we wouldn't have to bother ourselves with the blitter issues, which would make background animations (whatever those are...) more accessible?

Yep, but in other hand you would be under the same limitations as mode2: only two colors per tile line, only 256 tiles, etc...

Frankly, I could live with that. Just having editable colors would be a wonderful improvement. I assume there's a VDP setting to hide the left-most column of tiles for scrolling purposes? What about vertical scrolling in enhanced mode 2? Can a row of tiles be blanketed out or must we resort to using a scanline interrupt to have a hidden area to update tiles cleanly?

 

 

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.

This is interesting... is this "vertical scroll drag idiosyncrasy" also present in "enhanced" graphic mode #2?

Yep.

You do realize the kind of implications that could have on BasicVision...

[opcode]

Frankly, I could live with that. Just having editable colors would be a wonderful improvement. I assume there's a VDP setting to hide the left-most column of tiles for scrolling purposes?

 

Yes, there is.

 

What about vertical scrolling in enhanced mode 2? Can a row of tiles be blanketed out or must we resort to using a scanline interrupt to have a hidden area to update tiles cleanly?

 

Nice question. You need to use line interruption and blank one or more rows. In fact, you can simply use a fixed score area to that purpose. A nice thing about the V9958 is the generous amount of VRAM (192KB). So you have many "pages" to work with. Instead having a single pattern table, a single color table, a single sprite table, etc, you can have as many as 8 tables of each type which you can make visible any time, plus 4 tables of each type which you cannot make visible but can use to store data. All table base registers has been updated to support 17 bits addressing (128KB).

 

 

This is interesting... is this "vertical scroll drag idiosyncrasy" also present in "enhanced" graphic mode #2?

Yep.

You do realize the kind of implications that could have on BasicVision...

 

Yes, I do. The problem with the V9958 is exactly all the extra overhead you need to deal with. As I told you, that one-color-per-scanline was a bad design idea. Not because it is limited, but because it demanded the creation of a new table, the sprite color table. Any sprite flickering routine must move sprite data around, so sprites which were lower priority can become higher priority. It wasn't very CPU intensive before, because each sprite had only 4 bytes of attributes. Now sprites have 20 bytes of attributes! So before the whole sprite attribute set was 128 bytes max, now it's 640 bytes! Can you imagine how many CPU cycles are necessary to move this amount of data to the VRAM?

Of course you don't need to use the new sprite mode, but then you are back to 4 sprites per scanline, and no sprite color OR-ering.

See, I am just trying to show you all the pros and cons of the V9958...

 

Eduardo

[Pixelboy]

You do realize the kind of implications that could have on BasicVision...

Yes, I do. The problem with the V9958 is exactly all the extra overhead you need to deal with. As I told you, that one-color-per-scanline was a bad design idea. Not because it is limited, but because it demanded the creation of a new table, the sprite color table. Any sprite flickering routine must move sprite data around, so sprites which were lower priority can become higher priority. It wasn't very CPU intensive before, because each sprite had only 4 bytes of attributes. Now sprites have 20 bytes of attributes! So before the whole sprite attribute set was 128 bytes max, now it's 640 bytes! Can you imagine how many CPU cycles are necessary to move this amount of data to the VRAM?

Of course you don't need to use the new sprite mode, but then you are back to 4 sprites per scanline, and no sprite color OR-ering.

See, I am just trying to show you all the pros and cons of the V9958...

They all have pros and cons, as far as I can tell. I figure if the new sprite mode is too much trouble for a particular game, the programmer can always revert to the old sprite mode and make the most of it by editing the color palette. Besides, I'm sure OR-eing sprites is not all it's cracked up to be, especially when you take flicker into account.

 

So in the end, the V9958 does look better and better to me... What can I say, only fools never change their minds.

[opcode]

They all have pros and cons, as far as I can tell. I figure if the new sprite mode is too much trouble for a particular game, the programmer can always revert to the old sprite mode and make the most of it by editing the color palette. Besides, I'm sure OR-eing sprites is not all it's cracked up to be, especially when you take flicker into account.

 

So in the end, the V9958 does look better and better to me... What can I say, only fools never change their minds.

 

Ok, looks like the V9990 doesn't stand a chance here.... <sigh>.... Ok, lets go with the V9958 then. Maybe we could still use the V9990 when we make OM#2...

Since the V9990 is ruled out now, here are some mockup screens I had created for Castlevania Redux, based on the X68K version graphics.

 

Eduardo

[opcode]

I added the sound latch port to the prototype today. Pictures and test tomorrow...

Everytime the main CPU places data into the sound latch, the sounds CPU receives an interruption signal, which is cleared once the sound CPU has read the sound latch data.

 

Eduardo

Edited December 3, 2006 by opcode

[AussieAtari]

They are amazing images from a CV!!

[NinjaWarrior]

How does the Atari 2600 Adapter go in the CV

[Pixelboy]

How does the Atari 2600 Adapter go in the CV

Through the CV's front expansion port, as always. You won't be able to use the Expansion Module #1 when the Opgrade Module is plugged in.

 

So go get yourself a heavy sixer, if you haven't already. Or better yet, a Gemini, since the controllers are much better.

[NinjaWarrior]

Do you have any pics of the adapter pluged in..I thought it would go in the Cart Slot

[Pixelboy]

Do you have any pics of the adapter pluged in..I thought it would go in the Cart Slot

Check post #131 in this thread. It will give you a general idea of what the final unit will look like.

[pusco]

Hi Eduardo,

 

please count me in for your expansion board, too.

 

Thanks,

 

Oliver

[Pixelboy]

Hi Eduardo,

 

please count me in for your expansion board, too.

 

Thanks,

 

Oliver

We appreciate everyone's contribution.

 

Just wanted to let everyone know that Eduardo is currently getting settled in the US, and I haven't heard from him since December 7th. I assume it will be a while before he gets himself an internet connection for his personal use. It's probably at the bottom of his list of priorities right now, but I'm sure he'll be back as soon as he can.

[Atari Dogs]

Just wondering the status of this project.

[Pixelboy]

Just wondering the status of this project.

Nothing new to report, except perhaps that the Opgrade Module will be required for all the other games we want to release after Pac-Man Collection, Road Fighter and Konami Sports Collection, so Opcode will necessarily have to finish the OM prototype by the end of this year if we want to release anything in 2008 and beyond.

[ApolloBoy]

I'm definetly up for getting the Opgrade Module. I can't wait to play some Gradius or Castlevania on the CV!

[Metal Ghost]

Hey crew....any update on this? From one of the last informative posts, it appeared as though something would have to happen (a working prototype at least) by the end of the year, but haven't seen anything since April (gulp!).

 

Any news????

[Pixelboy]

Hey crew....any update on this? From one of the last informative posts, it appeared as though something would have to happen (a working prototype at least) by the end of the year, but haven't seen anything since April (gulp!).

 

Any news????

The Opgrade Module has become a very long-term project for Eduardo. After Road Fighter and Pac-Man Collection, we'll be putting our efforts into the Memory Pack, which offers one (perhaps even two, not settled on that yet) of the Opgrade Module's features. With 16K of extra RAM, we can already release a string of new CV games, namely Goonies, Knightmare, Zanac, Yie Ar Kung Fu II, King's Valley, and also Donkey Kong Arcade (which Eduardo worked on a little bit recently but is still very far from completion software-wise).

 

With all these potential titles in the pipeline already (some of which are currently 100% functional with a Memory Pack prototype plugged into the CV's expansion port), it makes little sense to put any effort in the Opgrade Module at this point. Both Eduardo and I are fairly certain that CV fans would rather have the cheaper Memory Pack with lots of new games to play instead of a bulkier and more expensive Opgrade Module that plays the same upcoming games and some bigger games (like Castlevania Redux) that could possibly turn out to be vaporware if they get stuck in long-term development hell.

 

I'll let you in on a little secret, which I'm sure Eduardo won't mind me sharing with the rest of you: Aside from the games listed as current and future projects on the Opcode Games web site, there are a couple of other MSX games that Eduardo would love to port to the CV, such as Maze of Galious and Penguin Adventure (I'd love to see Dragon Slayer IV added to that list, but Eduardo doesn't seem interested, sadly). The point is that those cool games could be made to run on the CV as MegaCarts with only the Memory Pack as requirement. So again, the Opgrade Module clearly doesn't need to be part of the picture anytime soon. Opcode Games can do a LOT of mileage with only 16K of extra RAM.

[Mark2008]

I cannot speak for anyone but myself, but this CV fan liked the idea of the opgrade module, in theory anyway.

 

Although my favorite hardware project, would be a new cv clone... and one with 16k would be mighty fine. It's interesting to read that they have put a colecovision on verilog...but who would have the resources to put out actual hardware....I certainly dont' have that kind of skill.

 

Well, looking forward to reading about your new products, as always.

[ApolloBoy]

Although my favorite hardware project, would be a new cv clone... and one with 16k would be mighty fine.

 

That'd be nice, albeit expensive (both to build and to buy). What I'd really like is a Colecovision Jr. shell so you don't have to go through the trouble of cutting apart a case and what not. All you'd have to do is drop in your Colecovision's motherboard and close it up. Boom, instant Colecovision Jr.

[Mark2008]

http://www.digilentinc.com/Products/Detail.cfm?Prod=NEXYS2

 

I'm not breaking any news here, I'm sure. But this board is capable of being a colecovision, and is $99.

 

I don't know what price point it needs to get at, with other parts added, I know its a bit expensive, but I would pay it. It's not that much for a really fun hobby, if you look at it that way...

 

as these boards get cheaper, and people already sell cases and memory chip readers for them....I feel we will have a new colecovision soon.

 

Whether a company picks it up to sell...I don't know, but I mean a hobbyist can slap it together...

o a colecovision with a vga monitor out, is a great improvement...changing it from 1k to 16k, should be trivial.

 

Even a cartridge port wouldn't be that hard for a hardware hobbyist....unfortunately that is the one thing I cannot do.

I could slap together the rest with my programming skills, but I almost never pick up a soldering iron.

 

So I will have to wait for one of the geniuses in the community to do it...but it will be sweet!

 

I like your case idea too....but a new CV solves many hardware problems, and with the reconfigurable nature of these machines, enhanced graphics modes are a natural result!

 

Just give me a real cartridge port!