Jump to content
IGNORED

The official "ColecoVision 2" thread


opcode

Recommended Posts

Guys, I need some help here. Could some of you with a PAL CV system please verify if it uses a 10.738635MHz crystal or 10.6640625MHz.

 

Thanks!!

 

The NTSC uses a 7.15909 MHz crystal... times 1.5 to the VDP is 10.738635 MHz. The PAL colorburst is 4.43361875 MHz, but I don't think the VDP is running at 13.3... .

 

Sorry, not the full answer, but a step,

5-11under

Link to comment
Share on other sites

Guys, I need some help here. Could some of you with a PAL CV system please verify if it uses a 10.738635MHz crystal or 10.6640625MHz.

 

Thanks!!

 

The NTSC uses a 7.15909 MHz crystal... times 1.5 to the VDP is 10.738635 MHz. The PAL colorburst is 4.43361875 MHz, but I don't think the VDP is running at 13.3... .

 

Sorry, not the full answer, but a step,

5-11under

 

Right, I always forget that the CV crystal isn't directly connected to the VDP.

Actually the question should be, does the PAL CV have one or two system crystals? If it has a single crystal, then the VDP should run at exactly 3 times the CPU speed, just like a NTSC system, no matter what crystal frequency it uses, and that means I would need a single crystal for the CV2 too, as the V9958 will output 1/6 of its own clock to the system. If PAL systems use two crystals, then I would need to design the CV2 with two clock sources, one for the V9958 and one for the system (in addition to a crystal just for the CPU, at 28MHz (then divide by 2 and 8 to get 14Mhz and 3.58MHz)). I want to have a single board that can be used for both PAL and NTSC. BTW, do pleople in Europe still use PAL?

Ok, so the things I would like to know is if a PAL system uses one or two crystals (not counting the encoder crystal) and what is the exact crystal frequency.

Link to comment
Share on other sites

Ok guys, big deal, pun intended. We got a deal with RWB, we got the rights to officially use the ColecoVision name and logo with the proposed ColecoVision2.

Next step, check my source for obsolete ICs in China...

Fantastic - keeps any legal uncertainties out of the way. Will this bump up the cost of the unit by much to cover licensing fees?

 

I'm sure that having the highly desireable and recognisable ColecoVision brand on the CV2 will increase sales.

Link to comment
Share on other sites

Congratulation!!!

 

Just one thing i was thinking , even it is surely too early to think about that.

 

But it would be good to be able to know from a program if we are running on a CV or a CV2.

 

We could make cartridge that detect the type of the console and said run in "standard" mode on a CV and run an "enhanced" mode on a CV2.

 

May be using the PAL/NTSC (aka EUROPE/AMERICA) byte?

 

3CH -> CV NTSC

32H -> CV PAL

4CH -> CV2 NTSC

42H -> CV2 PAL

 

Just an idea. But i'm sure you already think about that.

Link to comment
Share on other sites

Guys, I need some help here. Could some of you with a PAL CV system please verify if it uses a 10.738635MHz crystal or 10.6640625MHz.

 

Thanks!!

 

The NTSC uses a 7.15909 MHz crystal... times 1.5 to the VDP is 10.738635 MHz. The PAL colorburst is 4.43361875 MHz, but I don't think the VDP is running at 13.3... .

 

Sorry, not the full answer, but a step,

5-11under

 

Hi :)

 

And congratulations again for authorization of the Coleco name. :D

 

I have opened 2 of my total 4 Colecovisions.

 

One board reads: Coleco 1982 75743 rev. H2. Has only 1 crystal with point 7.15909.

 

The second board says: Coleco 1983 91162 Rev.D. Have 2 crystals with No 7.15909 and 4.433619.

 

I do not know whether you can use these numbers. :)

Link to comment
Share on other sites

Congratulation!!!

 

Just one thing i was thinking , even it is surely too early to think about that.

 

But it would be good to be able to know from a program if we are running on a CV or a CV2.

 

We could make cartridge that detect the type of the console and said run in "standard" mode on a CV and run an "enhanced" mode on a CV2.

 

May be using the PAL/NTSC (aka EUROPE/AMERICA) byte?

 

3CH -> CV NTSC

32H -> CV PAL

4CH -> CV2 NTSC

42H -> CV2 PAL

 

Just an idea. But i'm sure you already think about that.

 

oups, my idea of using this byte is stupid in fact.

 

Because if an existing game already test this byte, it won't work on the CV2.

Link to comment
Share on other sites

Congratulation!!!

 

Just one thing i was thinking , even it is surely too early to think about that.

 

But it would be good to be able to know from a program if we are running on a CV or a CV2.

 

We could make cartridge that detect the type of the console and said run in "standard" mode on a CV and run an "enhanced" mode on a CV2.

 

May be using the PAL/NTSC (aka EUROPE/AMERICA) byte?

 

3CH -> CV NTSC

32H -> CV PAL

4CH -> CV2 NTSC

42H -> CV2 PAL

 

Just an idea. But i'm sure you already think about that.

 

oups, my idea of using this byte is stupid in fact.

 

Because if an existing game already test this byte, it won't work on the CV2.

If the CV2 runs by default in the standard CV mode and it is the responsibility of the game to trigger "enhanced" mode somehow after detecting that it's running in a CV2, it seems like your idea might be possible.

Link to comment
Share on other sites

Congratulation!!!

 

Just one thing i was thinking , even it is surely too early to think about that.

 

But it would be good to be able to know from a program if we are running on a CV or a CV2.

 

We could make cartridge that detect the type of the console and said run in "standard" mode on a CV and run an "enhanced" mode on a CV2.

 

May be using the PAL/NTSC (aka EUROPE/AMERICA) byte?

 

3CH -> CV NTSC

32H -> CV PAL

4CH -> CV2 NTSC

42H -> CV2 PAL

 

Just an idea. But i'm sure you already think about that.

 

oups, my idea of using this byte is stupid in fact.

 

Because if an existing game already test this byte, it won't work on the CV2.

If the CV2 runs by default in the standard CV mode and it is the responsibility of the game to trigger "enhanced" mode somehow after detecting that it's running in a CV2, it seems like your idea might be possible.

Isn't there something that could be added to the CV2 BIOS for that? Some kind of bogus BIOS call that doesn't do anything on an original ColecoVision console, but triggers a response on the CV2?

Link to comment
Share on other sites

But it would be good to be able to know from a program if we are running on a CV or a CV2.

 

We could make cartridge that detect the type of the console and said run in "standard" mode on a CV and run an "enhanced" mode on a CV2.

 

May be using the PAL/NTSC (aka EUROPE/AMERICA) byte?

 

3CH -> CV NTSC

32H -> CV PAL

4CH -> CV2 NTSC

42H -> CV2 PAL

 

Just an idea. But i'm sure you already think about that.

 

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):

We will have a different game header for CV2 games. During boot-up the BIOS will check for the header and the system will be set accordingly (Z80 speed, I/O mapping, VDP mode, etc). Also, the BIOS will check for the color system, then set the VDP accordingly. The original CV had different versions of the VDP for NTSC and PAL. The V9958/V9990 use a different approach, they have a register setting to select between NTSC/PAL, so the BIOS should be responsible for that.

However you should be able create a game using the old header and still use the new features. For example, you can create a game that runs on a regular CV and activate certain features if the CV2 is detected. You can use a custom color palette, more sprites per scanline, faster CPU, FM music, create a special bitmapped intro screen, etc. All of that can be activated by software anytime, even in legacy mode.

Link to comment
Share on other sites

However you should be able create a game using the old header and still use the new features. For example, you can create a game that runs on a regular CV and activate certain features if the CV2 is detected. You can use a custom color palette, more sprites per scanline, faster CPU, FM music, create a special bitmapped intro screen, etc. All of that can be activated by software anytime, even in legacy mode.

 

It is exactly what i would like. :)

Link to comment
Share on other sites

Hi :)

 

And congratulations again for authorization of the Coleco name. :D

 

I have opened 2 of my total 4 Colecovisions.

 

One board reads: Coleco 1982 75743 rev. H2. Has only 1 crystal with point 7.15909.

 

The second board says: Coleco 1983 91162 Rev.D. Have 2 crystals with No 7.15909 and 4.433619.

 

I do not know whether you can use these numbers. :)

 

Hi Ole,

 

Thanks, that is exactly the info I needed. Your 2nd board is definitively a PAL system, because the 4.43 crystal, which is the frequency of the PAL subcarrier. But the interesting part is the main crystal, exactly the same value as the NTSC system. That means the system clocks was exactly the same too. That makes things easier. So I have the option to use the same crystal for both my NTSC and PAL systems too, tough in the CV2's case it should be 21.47727MHz, connected to the VDPs. The V9958 will then produce the system clock (3.58MHz) for the PSG, FM and others. The CPU will have its own oscillator, at 28.63636MHz (then divided by 2 and 8 ). Fantastic, so I will need two oscillators and a crystal.

Edited by opcode
Link to comment
Share on other sites

Ok guys, big deal, pun intended. We got a deal with RWB, we got the rights to officially use the ColecoVision name and logo with the proposed ColecoVision2.

Next step, check my source for obsolete ICs in China...

 

Sound great! It just keeps getting better and better!

:D

 

(dreaming about a colecovision2....)

Link to comment
Share on other sites

Ok, so I talked to Andre' last night and while we were discussing about oscillators and stuff he told me to start using PLDs already, so probably we will be skipping a few steps.

On the other hand that means I need to sit down and design the whole CV2 in every detail before I can start creating the new schematics. It seems simple at first, but actually there is some stuff that still needs to be figured out, like the interrupt controller. Since that has a software size, perhaps we could discuss some of that here, so we can try to reach a solution that is to everyone's liking.

In fact why don’t we start right now... :)

Let's discuss interrupts management first...

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. Anyways, here is the problem with the CV2:

The CV2 will have 5 sources of interrupts: V9958, V9990 (x2), YM2151, spinner. The V9958 uses interrupts for the same thing the TMS9928 does, to let the CPU knows that a frame is complete (during vblank), but it has an additional function: to let the CPU knows that a certain scanline has been reached.

The V9990 has two interrupt lines, INT0 is for vblank and also for blitter command end, and INT1 is for scanline reached.

The YM2151 uses interrupts for its timers.

So the problem now is how to manage that, considering that the Z80 has only two interrupt pins. If we connect everything to those two pins, we would need to poll all the devices in order to determine who generated the interrupt. And that isn't very efficient.

So my idea is to have an interrupt controller. All those interrupt lines would be connected to the interrupt controller, and the interrupt controller would be connected to the Z80 INT line. The interrupt controller would be programmable in terms of interrupt priority and mask, so we could set which interrupts can be accepted and what is the priority between them. Once the controller receives an interrupt it will generate an interrupt to the Z80. Now here is the tricky part, the Z80 needs to determine who generated the interrupt, and there are a couple of ways to do that. The simplest would be to poll the controller and get a status byte showing the active interrupts. Some software logic would still be required though (because you need to check the bits and then jump to the corresponding service routine). The alternative would be more elegant: to use the Z80 interrupt Mode 2. When the controller receives an interrupt, it puts an eight bit vector on the data bus. The Z80 forms a pointer using this byte as the lower 8 bits and the content of the “I” register as the upper 8 bits. That will give you the pointer to the service routine for that interrupt, so no time is lost polling anything. How about that? I still need to come with the details though.

A thing I haven't decided yet, because I still need to think about all the implications, is to remove the V9958 from the NMI line when this advanced mode is used, and treat everything as INT (maskable). The only problem I see right now is that if you making a game that runs in the original hardware, but want to use some of the advanced features, you would need to handle interrupts differently if this advanced interrupt mode is used. Unless we have two settings here: "interrupt controller enable" and "VDP interrupt more". First setting would define if the INT line will see the spinner or the controller. Set to 0 (spinner only), and you get compatibility mode. Set to 1 to get the controller (and that includes the spinner). The second setting would define how the system routes the VDP interrupt line. Set to 0 to send it to the Z80 NMI (compatibility mode), set to 1 to send it to the interrupt controller (so VDP is now maskable).

So how about that? Anyone sees any problem with this approach?

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...