Jump to content
IGNORED

The official "ColecoVision 2" thread


opcode

Recommended Posts

Running the spinner and VDP interrupts through some PLD logic sounds like a simple way. I'm sure you could get it out of "compatibility" mode through an address. It's not clear to me if using "Z80 interrupt Mode 2" would be compatible with the good ol' CV.

 

5-11under

 

"through some PLD logic"... to choose which interrupt sources will go to which interrupt lines... likely with an interrupt controller (maybe the CPLD can handle this?).

Edited by 5-11under
Link to comment
Share on other sites

Running the spinner and VDP interrupts through some PLD logic sounds like a simple way. I'm sure you could get it out of "compatibility" mode through an address. It's not clear to me if using "Z80 interrupt Mode 2" would be compatible with the good ol' CV.

 

5-11under

 

"through some PLD logic"... to choose which interrupt sources will go to which interrupt lines... likely with an interrupt controller (maybe the CPLD can handle this?).

 

The CV uses Mode 1 for the spinner (interrupts are handled at 0038H). Mode 2 is set by software, like "IM 2". You disable interrupts, "DI", then set "IM 2", then set the interrupt controller (thru I/O mapped ports), then set the I register "LD A,xx ; LD I,A", then enable interrupts "EI". Done.

Or you set IM 1 and then you will need to poll the controller or devices to find out who is generating the interrupt.

In compatibility mode the Z80 would be set in IM 1, and the controller would be disabled (so the spinner would be connected directly to the INT pin). Completely transparent I think, unless I am missing something.

Lets do an exercise: lets suppose you are doing a game that must run on a regular CV, but you want to add some FM music if the CV2 is used. Now lets suppose you want to use the FM timers for that. The YM2151 has a couple of timers that is useful for creating more complex music stuff. Now the timer generates an interrupt, and that is connected to the interrupt controller. So you will need to select the controller, and that means the spinner interrupt will also be detected thru the controller. Ok, now if you aren't using the spinner, then that would be easy, you activate the interrupt controller (PIC for short) and use IM 1 or 2, it doesn't matter, because the only interrupt connect to the PIC is the FM timer. Now supposing you also want to use the spinner. That is more complicated because you want your game to run on a regular CV. No matter what you will need to have separated INT routines, one for CV and other for CV2. The reason is, you have two INT signals, so you need the PIC, and you aren't going to determine what is generating the interrupt unless you poll the PIC or devices. But then you can use IM 2 if you are running on a CV2, and set the service routines to some other place than 0038H. That way, if you running on a CV1 you set IM 1 (you don't have another option actually), and your service routine will handle the spinner only. If it is a CV2, you set IM 2 and the I register, then the controller will send you the vectors for both the spinner and FM service routines, so you don't need to worry (the spinner routine can be simply a JUMP to 0038H. You know what, sounds pretty good to me. The only problem would be that in the CV1 case, DI will disable the spinner only, while for the CV2 it will disable the spinner and FM timer, so you need to be a little more careful, or use other methods to disable interrupts in the CV2 case (you can use the PIC for that). So yeah, I am still trying to come with a really bad case...

About implementation, I think we could create all of that using a big CPLD, or use an i8259.

Link to comment
Share on other sites

It's still not entirely clear to me how the software is supposed to detect the CV versus CV2.

 

Thinking about it, one possible way could be to do a write/read test on a high VRAM address (higher than 16K). The V9958 uses more VRAM than the TMS9928, so shouldn't this work?

Link to comment
Share on other sites

It's still not entirely clear to me how the software is supposed to detect the CV versus CV2.

 

Thinking about it, one possible way could be to do a write/read test on a high VRAM address (higher than 16K). The V9958 uses more VRAM than the TMS9928, so shouldn't this work?

 

How about simply checking the BIOS? ;)

Link to comment
Share on other sites

How about simply checking the BIOS? ;)

Is there a version string imbedded in the BIOS ROM?

No, but it has many unused bytes in the 0000-0038h range, so we can use that. Those bytes are usually FFh, but we can change one of them to something else to indicate the BIOS version.

Link to comment
Share on other sites

Any changes to the original BIOS would have some bad implications to existing games. So here is what I am planning to do (actually I had already done that with the SEM):

In case you're interested, I should post my optimized version of the ROM. I actually disasembled most of the game library to find out what addresses were used, then ended up with a nice large chunk of free space into which I dropped a controller tester.

 

Unfortunately, I didn't have access to any of the "official" CV/Adam documentation, so I came up with my own names for all the entry points.

 

The original CV has two sources of interrupts, the VDP and the spinner controller. The VDP is connected to the NMI pin in the Z80, while the spinner is connected to INT. First of all, I know a few people don't like the VDP generating NMI. Personally I have learned to live with that and how to manage that properly, but I understand why it is kind of annoying.

The problem is that this still won't help games that need to run on a genuine CV. There's always going to be a few more of those out there.

Link to comment
Share on other sites

I ordered 100 YM2151 sound ICs from a distributor in China, just to check if they are really trustable. The tracking system in the TNT website says that something is coming, not sure if it is 100 chips or a rock, but we will find out soon. :)

Link to comment
Share on other sites

Just found this thread very excited, as for Pal most newer TV's can auto switch to NTSC even my 15 year old CRT dose it. I have changed all my older systems to NTSC Once I sour the difference in the squashed picture and slow picture and sound I could not go back. So if it did do Pal would the screen be squashed an run about 15% slower.

 

But you would have to ask everyone ells I'm just saying if it is hard to do and costs more I personally do not need Pal mode.

Link to comment
Share on other sites

Excellent news:

First, check what I got in the mail today. Yep, that is right, 100 YM2151, aka the Yamaha OPM FM sound chip. Little background on the OPM: in 1983 Yamaha released the DX7 music keyboard, the world's first fully digital synthesizer (the DX7 eventually became the best seller keyboard ever). However the DX7 required two chips for FM synthesis, and Yamaha wanted to have a single chip solution for the home market. In 1984 they create the YM2151, aka FM Operator Type M (therefore OPM). They first used it with their line of MSX computers aimed on musicians, then created some standalone keyboards around it, the DX100 probably being the most famous. Finally OPMs were used in arcade games (I think Atari was the first to use it, though their games were far of showcase material), in fact they were probably the most used sound chip in arcade games during the late 80s, and the only other "home" device that used the OPM was the X68000 computers. Other two lines of FM chips were create, OPL and OPN, the former being the Sound Blaster line, the later being the MegaDrive line, but the OPM stayed the top FM chip until sometime during the 90s.

The OPM lacked the DX7 6 operators per channel (it had 4 instead), but on the other hand it offered several different waveforms, while the original DX7 only had sine. The OPN was similar but had fewer channels, while the OPL was a very striped down version, with only 2 operators per channel and many missing features.

So there you have it, the OPM, king of arcades during the 80s and previously used only in the Yamaha MSX music computers and X68000 (a $3K+ Japanese computer) will appear in the ColecoVision 2.

The other news is that I started assembling the first prototype, and I hope to have some "sounding" news soon...

Here are some linking for YM2151 music..

http://www.youtube.com/watch?v=c0Jj-andLxA&feature=related

http://www.youtube.com/watch?v=QSHAE63Z7_U&NR=1

 

[EDIT:] For those who want to create music using the YM2151, there is a powerful emulator evailable, VOPM.

http://www.kvraudio.com/get/228.html

post-1432-126383664344_thumb.jpg

Edited by opcode
Link to comment
Share on other sites

The other news is that I started assembling the first prototype, and I hope to have some "sounding" news soon...

The first prototype of the CV2? What are you looking to implement in this first prototype? :)

 

A CV1, but using a V9958. We should see soon. ;)

Link to comment
Share on other sites

This is awesome. I can't wait to buy one. :D

 

New games from Opcode: Count me in for an RPG, maybe do a Tunnel and Trolls or Apshai type "Diablo" game. I wish Tunnels and Trolls didn't die out, the only thing out there is a splash screen rom I think.

I wound't mind a port of something like Ultima which may be impossible. I'm all for complex RPG's but I'm not sure it can be done so I'm happy with an Apshai type hack n slash game.

Link to comment
Share on other sites

Will the V9958 be a separate chip or is it part of the V9990.

 

They were created to be used as a dual chipeset solution. The V9990 was called the V9978 in the preliminary docs, but was later renamed once the MSX3 got cancelled. The reason why it is a separate chip is because the V9958 had reached the limits of what could be done with its current memory architecture. The V9990 replaces the DRAM video memory scheme used since the TMS9928 days with dual-ported VRAM. That is why it can be so fast, even though both it and the V9958 are running at the same clock. The V9990 blitter is up to 20 times faster than the V9958.

Anyway, with the V9958+V9990 you get full backward compatibility and 16-bit quality graphics. In order to be able to use both chips together, ASCII (the MSX standard owner) created the V7040 video encoder together with Sony. The V7040 can do superimposing of both chips, or select just one of them.

And since we are talking about video here, the only device that used the V9990 up to this day was a homebrew expansion board for the MSX called the GFX9000. However the GFX9000 cannot superimpose both videos as they were supposed to be, neither does it use one of the V9990 coolest features, direct access from the CPU to the VRAM. However, since the V9990 is so fast (you don't need to wait between memory accesses like the TMS9928), accessing the VRAM directly isn't really an improvement, because the Z80 is as fast accessing I/O as it is accessing memory (or as slow, because it needs 21 cycles to transfer a byte in block mode). However if you use a dedicate DMA solution to do the transfer, then you start to see some really impressive speed improvements. The Z80 in the CV2 should run at 4 times the original speed, however the V9990 adds an extra burden on the CPU, because the sprite table is 4 times the original size, as is the name table. With DMA transfer you can take the Z80 out of the bus, give control to the DMA controller, transfer the data from RAM to VRAM in very high speed (up to 10MB/s), then return the bus to the Z80.

Link to comment
Share on other sites

How hard or expensive/practical would it be to add MSX 1 & 2 compatibility, if you wanted to sell more units you could make it compatible with the MSX and bring that community into it as well, as that community seems to be quite active.

 

Then when the unit ships you could sell it with two stickers, one that says Colecovision 2 and one that says MSX 3. There would be many great Japanese MSX games that could be translated into English. Although that could still be done anyway, but it would be great to play some of the MSX 1 and MSX 2 games.

Link to comment
Share on other sites

It could break the business that consist to port MSX Game to CV... :D

 

More seriously , i would love also to have an MSX direct compatibility on the CV2.

 

But lot of MSX games requires Keyboard afaik.

 

What about changing the CV2 project to a MSX 3 project that would be compatible with CV ?

 

You could put USB port and manage mouse and keyboard.

 

Anyway CV, CV2 or MSX 3 , i will buy. But that's try that the MSX part could generate lot of more sells IMHO.

Link to comment
Share on other sites

It could break the business that consist to port MSX Game to CV... :D

 

More seriously , i would love also to have an MSX direct compatibility on the CV2.

 

But lot of MSX games requires Keyboard afaik.

 

What about changing the CV2 project to a MSX 3 project that would be compatible with CV ?

 

You could put USB port and manage mouse and keyboard.

 

Anyway CV, CV2 or MSX 3 , i will buy. But that's try that the MSX part could generate lot of more sells IMHO.

You think so? The ColecoVision is mostly an american system, while the MSX was big mostly in Japan only. Why support both interrupt systems (and all other differences between the two machines) and make a keyboard practically mandatory with the CV2?

 

Some may like the idea, but I don't. What we all really want to do with this console is play games, and the MegaRAM component of the CV2 will already be a big help in porting the bigger MSX games (especially if it's bumped up to 1 megabyte) because it will accomodate all types of MSX MegaROM configurations with minimal reprogramming effort.

 

I have to wonder how well the YM2151 will accomodate MSX games that use the SCC however, but that's a discussion for another day. The point is, porting MSX games will be easier than ever before, so why bother to make this console a "two-gaming-systems-in-one" machine? We'd be adding complexity for no good reason.

Link to comment
Share on other sites

There is also a business reason for that.

 

MSX port will be lot of easier , could even been done automatically. So easy to produce "low cost" (considering time as cost) cartridge for CV2 , more cartriges to sell , more potential money to receive.

 

If you create a console with direct MSX compatibility , you can just buy directly existing MSX cartridge on ebay or elsewhere => no "easy" money to take from MSX port.

 

Another point, is that if i were you , i would target a world wide market. Not only U.S . MSX are very popular in others part of the world lot of more than the C.V.

 

The risk i see, is that man could prefer to go the "easy" way and produce only direct MSX port for the CV 2. And we could have mainly this kind of port on the console. That would be , IMHO, very disapointing.

 

If you integrate built'n Msx compatibility , they will be no interrest for developper to port an MSX game, so it will force the developper to create original game or port arcade games using enhanced CV2 features.

 

Just my 2 cents. As i said , anyway i will buy that console.

Link to comment
Share on other sites

While I think it is a reasonable proposition, here is why I don't want to pursue the MSX idea:

- Technical reasons, implementing MSX compatibility would be very complicated and expensive. Even though we use the same Z80 and VDP, MSX compatibility would require plenty of different chips, like two extra sound generators, an 8255, lots and lots of glue logic, different interfaces, a keyboard, two extra cartridge slots, etc. And we have the problem with the BIOS and BASIC. MSX Association is still active, using their BIOS and BASIC would be a copyright infringement. While I usually don't care about that, I am sure RWB does care, since they are giving us their name to use here.

- Let me ask you something (youki): have you checked the MSX scene recently? It's a mess... We (the CV community) pale next to them in number of users, the One-chip-MSX managed to sell 5K units in Japan recently, costing $200. And there are hundreds of users outside Japan too. Perhaps because they are so many, they seem to be unable to coordinate any effort in terms of keeping the standard alive and evolving. You come with an idea and you are quickly disqualified by hundreds of other users. A few worthwhile efforts failed because of the complete lack of support from the community, like the GFX9000 video board using the V9990 (not a single game was ever created). Finally, have you ever tried to do business with Japan? It’s almost impossible. They don’t mix with outsiders…

Honestly I don't want to be part of that. The MSX standard is very dear to me, as it was the computer I was using during most of the 80s and part of the 90s, but I must say that the scene is just sad. My business is exclusively with the ColecoVision now.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...