CollectorVision Phoenix Release Thread

[Keatah]

Wait what? Coleco is now controlling the Phoenix?

17 minutes ago, 128Kgames said:

So going forward, who's going to be supporting the Phoenix: CollectorVision or Coleco?  I'm guessing Coleco's involvement is why you guys are stopping your own production?

 

[retroillucid]

1 hour ago, 128Kgames said:

So going forward, who's going to be supporting the Phoenix: CollectorVision or Coleco?  I'm guessing Coleco's involvement is why you guys are stopping your own production?

 

44 minutes ago, Keatah said:

Wait what? Coleco is now controlling the Phoenix?

 

There's nothing like that!
It was mentioned they bought a couple of consoles, that's it, nothing more

Now, move on guys
Let's use this thread for the Phoenix only

[Bmack36]

New Firmware release for CV core (Rev7) in first post

 

-Re-written SN and AY sound modules

-Fix for early Opcode games (Magical Tree, Road Fighter, and sky jaguar)

[ten-four]

Thank you for the update.

 

I can confirm that MT -RF and SJ works on mine.

 

[doubledown]

1 minute ago, ten-four said:

Thank you for the update.

 

I can confirm that MT -RF and SJ works on mine.

 

I can also confirm these 3 working on mine too.

[Mr. John ColecoVision]

12 hours ago, Bmack36 said:

New Firmware release for CV core (Rev7) in first post

 

-Re-written SN and AY sound modules

-Fix for early Opcode games (Magical Tree, Road Fighter, and sky jaguar)

Awesome thanks!

[+davidcalgary29]

Do we have an ETA on the next run of Phoenixes (Phoenices?)

[Mr. John ColecoVision]

2 hours ago, davidcalgary29 said:

Do we have an ETA on the next run of Phoenixes (Phoenices?)

Nov-Dec I believe

[Swami]

On 7/22/2020 at 12:20 PM, davidcalgary29 said:

Do we have an ETA on the next run of Phoenixes (Phoenices?)

You peaked my interest. It seems the preferred form is Anglicized, like Hippopotamuses or Octopuses, as Phoenixes (Phoenices is listed as equivalent or rare, but is less common).

[wileyc]

On 7/22/2020 at 12:34 PM, Bmack36 said:

New Firmware release for CV core (Rev7) in first post

 

-Re-written SN and AY sound modules

-Fix for early Opcode games (Magical Tree, Road Fighter, and sky jaguar)

HDMI regression from version 6:

 

* video no longer stable; vertical jitters and sporadic loss of video signal,

* red pixels appear and disappear randomly on screen.

 

Video signal from service menu is unaffected.  Reverting to version 6 fixes signal issue.

[Bmack36]

2 hours ago, wileyc said:

HDMI regression from version 6:

 

* video no longer stable; vertical jitters and sporadic loss of video signal,

* red pixels appear and disappear randomly on screen.

 

Video signal from service menu is unaffected.  Reverting to version 6 fixes signal issue.

What make and model tv are you using?

[wileyc]

51 minutes ago, Bmack36 said:

What make and model tv are you using?

 

LG 60UK that has no issues with any other device attached to it.  Also tested on the 32-inch Toshiba upstairs, same problem.

 

What changed in the HDMI routines in the 07 core?

 

[wileyc]

Hello Brian,

 

I see that you've been active on AtariAge rather frequently in the past few days, and thus I assume that you've had time to read my response.

 

Is the HDMI issue I reported considered valid?  If so, is it going to be investigated and (hopefully) fixed?  If not, why not?

 

Thank you in advance for your response.

[Bmack36]

3 hours ago, wileyc said:

Hello Brian,

 

I see that you've been active on AtariAge rather frequently in the past few days, and thus I assume that you've had time to read my response.

 

Is the HDMI issue I reported considered valid?  If so, is it going to be investigated and (hopefully) fixed?  If not, why not?

 

Thank you in advance for your response.

Some changes were made in preparation for the next rev of the board, which shouldn't have an effect on the video output. Thank you for the report. There are still major changes to come with the video output and fixing the pixel clock so we will see what happens when those changes get implemented.

[zaphro72]

5 hours ago, wileyc said:

Hello Brian,

 

I see that you've been active on AtariAge rather frequently in the past few days, and thus I assume that you've had time to read my response.

 

Is the HDMI issue I reported considered valid?  If so, is it going to be investigated and (hopefully) fixed?  If not, why not?

 

Thank you in advance for your response.

It is also a good idea to put issues in the official GitHub issues section https://github.com/CollectorVision/Phoenix-Colecovision/issues

[willbilly]

On 6/23/2020 at 9:41 PM, Loafer said:

I have to admit considering the console race was a three way affair during the early 80's, it would be nice to see FPGA support for all 3.   I admit I'm very much a fan of expanding the ability of the Phoenix, but I'm also A-OK with what we've gotten so far.  If the current cores were the final updates to the console (and I'm sure it's not), I'd still be a happy camper.

I'd very much like to see an Intellivision FPGA system that fits the system specs for the proposed Intellivision IV.

[doubledown]

So I think I've pretty much kept up with this thread...but I can guarantee that I probably haven't read every post, and if info has been discussed/discovered/announced elsewhere (other sites/forums)...I don't know anything about those so forgive me if this has been solved, and I missed it. 

 

My question is concerning games freezing and/or console lock-up, seemingly when using a SAC or an Edladdin based controller with the Phoenix.  By Edladdin based controllers, I mean any ColecoVision controllers Ed has built, or those built by others (myself included) using his Easy CV I/O Board + Keypad.  I have in the past, personally experienced game/console lock-up, when playing Pac-Man Collection off of my SD card, and Gauntlet played via cartridge.  Recently when I built one of my new controllers whereas I used an original Coleco Hand Controller PCB donor for the wiring (not an Edladdin PCB), I assumed I wouldn't have any issues playing these games...but they locked up too.  So then I grabbed an actual Hand Controller and it played fine.  Fast forward to today and I wanted to try something to check this out more, and here is what I found.  

 

Coleco Hand Controllers - factory controller cable's are 7 conductors and the end is pinned at 1,2,3,4,5,6,8 (not pinned at 7 or 9)

Coleco S.A.C. - factory controller cables are 9 conductors and the end is pinned at 1,2,3,4,5,6,7,8,9

 

When I've built controllers using Ed's PCB, I fully populated the connector, and soldered wires to each of the 9 pads on the PCB (as the instructions tell you to do).  Upon further examination (and Ed can verify this) it appears that contacts #7 & #9 on Ed's PCB aren't connected to anything, I assume they're just there as a landing point so that the wires're aren't loose; I never really looked at this before today.  When I build a custom controller using a Coleco Hand Controller PCB, and a 9-conductor cable that I buy in bulk, I only solder 7 wires to the PCB, 1-Brown, 2-Red, 3-Orange, 4-Yellow, 5-Green, 6-Blue, 8-Grey, but I crimp sockets on all 9 wires when I assemble the cable end. I like to leave the extra conductors in the cable end so that if there is a failure with 1 or 2 other conductors...the cable can still be salvaged, and I crimp the sockets on and insert them into spots #7 & #9 so they're not simply loose in the hood.  Then in the controller itself, I stagger the cut length of these 2 wires (black and white), and heat shrink them so they can't contact each other, or short out on anything else.  So in a test, literally 15 minutes ago, here is what I did, and what happened with 2 of my custom controllers using a Coleco Hand Controller PCB:

 

So both were wired/socket at all 9 positions in the cable end, but 7-black, and 9-white were not connected to anything inside the controller...so basically all the console could have seen/detected on these 2 pins is 10' of wire length on each...connected to nothing, not even each other.  When I tried Pac-Man Collection off of my SD card...I could get the game/console to freeze/lock-up/emit solid tone, within about 5-6 seconds once I started an actual game of Pac-Man with either controller.  I then opened both of their hoods, pulled out the sockets/wires from position 7-black and 9-white, and tried again...and now I cannot get it to lock up.  Obviously minimal testing done...but these results lead me to this conclusion:

 

if anything (even just a length of wire) is connected to pins #7 and/or #9, this feezing/lock-up, can/may occur.  I haven't yet tested just removing one of these at a time 7 or 9, I've done both each time...but I can/will try re-inserting one of them, and leaving the other out to see the results.  (by-the-by...I've only ever noticed this with modern homebrew games...never with any original games)

 

Please don't get me wrong, I'm not carving this in stone, and/or saying this is the gospel...this is just what I've seen with about 10-15 minutes worth of testing.  

 

So with all that said...am I insane, or has this issue (which when searching through this topic there are several posts discussing exactly this) been solved and I just don't know about it?

 

FYI, here are screenshots of my firmware/cores to verify that I'm using the latest/greatest:

 

 

 

I'd appreciate any info/comments/thoughts about this.  Has this been fixed...have/are others also experiencing this issue...and the likes.  

 

**UPDATE**

 

So I just did some more testing...and I can attribute the issue to pin #9 specifically.  So assuming automatically that pins 1,2,3,4,5,6,8 are wired at both the connector end, and internally to a PCB for controls, then:

 

7 & 9 - sockets are present at the cable end - lock up will occur playing Pac-Man Collection from my SD card

 

only 9 - socket is present at the cable end (7 was removed) - lock up will occur playing Pac-Man Collection from my SD card

 

only 7 - socket is present at the cable end (9 was removed) - lock up does not occur playing Pac-Man Collection from my SD card

 

neither 7 or 9 - sockets not present at the cable end - lock up does not occur playing Pac-Man Collection from my SD card

Edited August 7, 2020 by doubledown

[Bmack36]

6 hours ago, doubledown said:

So I think I've pretty much kept up with this thread...but I can guarantee that I probably haven't read every post, and if info has been discussed/discovered/announced elsewhere (other sites/forums)...I don't know anything about those so forgive me if this has been solved, and I missed it. 

 

My question is concerning games freezing and/or console lock-up, seemingly when using a SAC or an Edladdin based controller with the Phoenix.  By Edladdin based controllers, I mean any ColecoVision controllers Ed has built, or those built by others (myself included) using his Easy CV I/O Board + Keypad.  I have in the past, personally experienced game/console lock-up, when playing Pac-Man Collection off of my SD card, and Gauntlet played via cartridge.  Recently when I built one of my new controllers whereas I used an original Coleco Hand Controller PCB donor for the wiring (not an Edladdin PCB), I assumed I wouldn't have any issues playing these games...but they locked up too.  So then I grabbed an actual Hand Controller and it played fine.  Fast forward to today and I wanted to try something to check this out more, and here is what I found.  

 

Coleco Hand Controllers - factory controller cable's are 7 conductors and the end is pinned at 1,2,3,4,5,6,8 (not pinned at 7 or 9)

Coleco S.A.C. - factory controller cables are 9 conductors and the end is pinned at 1,2,3,4,5,6,7,8,9

 

When I've built controllers using Ed's PCB, I fully populated the connector, and soldered wires to each of the 9 pads on the PCB (as the instructions tell you to do).  Upon further examination (and Ed can verify this) it appears that contacts #7 & #9 on Ed's PCB aren't connected to anything, I assume they're just there as a landing point so that the wires're aren't loose; I never really looked at this before today.  When I build a custom controller using a Coleco Hand Controller PCB, and a 9-conductor cable that I buy in bulk, I only solder 7 wires to the PCB, 1-Brown, 2-Red, 3-Orange, 4-Yellow, 5-Green, 6-Blue, 8-Grey, but I crimp sockets on all 9 wires when I assemble the cable end. I like to leave the extra conductors in the cable end so that if there is a failure with 1 or 2 other conductors...the cable can still be salvaged, and I crimp the sockets on and insert them into spots #7 & #9 so they're not simply loose in the hood.  Then in the controller itself, I stagger the cut length of these 2 wires (black and white), and heat shrink them so they can't contact each other, or short out on anything else.  So in a test, literally 15 minutes ago, here is what I did, and what happened with 2 of my custom controllers using a Coleco Hand Controller PCB:

 

So both were wired/socket at all 9 positions in the cable end, but 7-black, and 9-white were not connected to anything inside the controller...so basically all the console could have seen/detected on these 2 pins is 10' of wire length on each...connected to nothing, not even each other.  When I tried Pac-Man Collection off of my SD card...I could get the game/console to freeze/lock-up/emit solid tone, within about 5-6 seconds once I started an actual game of Pac-Man with either controller.  I then opened both of their hoods, pulled out the sockets/wires from position 7-black and 9-white, and tried again...and now I cannot get it to lock up.  Obviously minimal testing done...but these results lead me to this conclusion:

 

if anything (even just a length of wire) is connected to pins #7 and/or #9, this feezing/lock-up, can/may occur.  I haven't yet tested just removing one of these at a time 7 or 9, I've done both each time...but I can/will try re-inserting one of them, and leaving the other out to see the results.  (by-the-by...I've only ever noticed this with modern homebrew games...never with any original games)

 

Please don't get me wrong, I'm not carving this in stone, and/or saying this is the gospel...this is just what I've seen with about 10-15 minutes worth of testing.  

 

So with all that said...am I insane, or has this issue (which when searching through this topic there are several posts discussing exactly this) been solved and I just don't know about it?

 

FYI, here are screenshots of my firmware/cores to verify that I'm using the latest/greatest:

 

 

 

I'd appreciate any info/comments/thoughts about this.  Has this been fixed...have/are others also experiencing this issue...and the likes.  

 

**UPDATE**

 

So I just did some more testing...and I can attribute the issue to pin #9 specifically.  So assuming automatically that pins 1,2,3,4,5,6,8 are wired at both the connector end, and internally to a PCB for controls, then:

 

7 & 9 - sockets are present at the cable end - lock up will occur playing Pac-Man Collection from my SD card

 

only 9 - socket is present at the cable end (7 was removed) - lock up will occur playing Pac-Man Collection from my SD card

 

only 7 - socket is present at the cable end (9 was removed) - lock up does not occur playing Pac-Man Collection from my SD card

 

neither 7 or 9 - sockets not present at the cable end - lock up does not occur playing Pac-Man Collection from my SD card

This is an issue. Easy way to fix is to jumper pins 7 and 9 in the controller, which should resolve the issue since those lines aren't being used anyways with that board (or any custom board like that which doesn't include spinner hardware).

[doubledown]

43 minutes ago, Bmack36 said:

This is an issue. Easy way to fix is to jumper pins 7 and 9 in the controller, which should resolve the issue since those lines aren't being used anyways with that board (or any custom board like that which doesn't include spinner hardware).

So just to clarify...with pins 7 & 9 socketed & fully populated at the cable connector, jumper them together (shorting them together) inside/at the controller, so that when plugged into the Phoenix console it's controller port pins 7 & 9 would be connected via a 20' loop of wire (in the case of a 10' cordset)?  Would this cause any issue if said controller was then used on an actual ColecoVision or ADAM?  What if this controller was then used on an Atari 2600...where pin #7 is +5V?  Is this a more robust/bulletproof option than simply just not installing a socket/wire at pin 9?  

[Bmack36]

2 minutes ago, doubledown said:

So just to clarify...with pins 7 & 9 socketed & fully populated at the cable connector, jumper them together (shorting them together) inside/at the controller, so that when plugged into the Phoenix console it's controller port pins 7 & 9 would be connected via a 20' loop of wire (in the case of a 10' cordset)?  Would this cause any issue if said controller was then used on an actual ColecoVision or ADAM?  What if this controller was then used on an Atari 2600...where pin #7 is +5V?  Is this a more robust/bulletproof option than simply just not installing a socket/wire at pin 9?  

7&9 being tied together on a real Adam or CV would not be an issue as both are inputs.

 

I guess I wasn't thinking about plugging the controller into other systems and you are right that it could cause problems that way. Not populating pins 7 and 9 would be better. It is also possible there could be some kind of firmware switch to disable the encoder inputs, but that would have to be looked into.

[doubledown]

Thanks for the info.  

[Swami]

1 hour ago, Bmack36 said:

7&9 being tied together on a real Adam or CV would not be an issue as both are inputs.

 

I guess I wasn't thinking about plugging the controller into other systems and you are right that it could cause problems that way. Not populating pins 7 and 9 would be better. It is also possible there could be some kind of firmware switch to disable the encoder inputs, but that would have to be looked into.

When you said you didn’t have the peripheral to investigate this pin 7 issue, was that the super action controller or the roller controller, as both have issues that require having pins 7 and 9 operational. 

[Bmack36]

1 minute ago, Swami said:

When you said you didn’t have the peripheral to investigate this pin 7 issue, was that the super action controller or the roller controller, as both have issues that require having pins 7 and 9 operational. 

I have all the peripherals. I think what I was saying is that I don't have a peripheral that has the actual error. My SAC, EM2, and roller controller do not show the noise or jumping issues some people have had. If I can't reproduce the error it makes it tough to address.

[doubledown]

I have not yet tested a Roller Controller, S.A.C. or EM#2 on my Phoneix.  Maybe I'll try to test them this weekend to see what I find out with my unit.  As of now the issue I'm seeing is apparently something transient getting picked up on controller port pin 9, when a length of wire is connected to it, and said length of wire is seemingly acting as an antenna.  

[zaphro72]

2 hours ago, Bmack36 said:

I have all the peripherals. I think what I was saying is that I don't have a peripheral that has the actual error. My SAC, EM2, and roller controller do not show the noise or jumping issues some people have had. If I can't reproduce the error it makes it tough to address.

Have you played centipede off SD card with roller controller? I tried but it kept freezing or resetting to skill level select screen on me.

 

I do see the jumping a bit even on the menu where I can pick games from sd card

Edited August 7, 2020 by zaphro72
Clarity