CollectorVision Phoenix Release Thread

[nick3092]

36 minutes ago, Bmack36 said:

That is strange. My rom does not show that when run from the sd card.

I might not have been clear on how to reproduce it. It's not there from the beginning. It happens right after you select a skill. While it's waiting for input, the screen is normal. So it's only there for maybe a second or two after I press 1 to start the game before it actually starts. The rom is from the no intro set, so it should be a good copy. 

[nick3092]

Deleted, my phone somehow double posted. 

Edited January 21, 2020 by nick3092

[Ikrananka]

24 minutes ago, nick3092 said:

I might not have been clear on how to reproduce it. It's not there from the beginning. It happens right after you select a skill. While it's waiting for input, the screen is normal. So it's only there for maybe a second or two after I press 1 to start the game before it actually starts. The rom is from the no intro set, so it should be a good copy. 

Try the rom from here.  This is a known good rom.

[nick3092]

1 hour ago, Ikrananka said:

Try the rom from here.  This is a known good rom.

Same thing happens with the Comic Avenger rom from that collection as well.

 

Edit: No, this one seems fine. I think I selected the wrong one when I first tested it.

 

Really odd that the "bad" rom doesn't exhibit that behavior when used on the Atarimax with the Phoenix. Only when run directly from the Phoenix.

Edited January 21, 2020 by nick3092

[Lil Alien]

4 hours ago, nick3092 said:

I might not have been clear on how to reproduce it. It's not there from the beginning. It happens right after you select a skill. While it's waiting for input, the screen is normal. So it's only there for maybe a second or two after I press 1 to start the game before it actually starts. The rom is from the no intro set, so it should be a good copy. 

I've seen similar graphical anomalies like that go away after upgrading the firmware of the Atarimax Colecovision multicart...

[Swami]

3 hours ago, nick3092 said:

Same thing happens with the Comic Avenger rom from that collection as well.

 

Edit: No, this one seems fine. I think I selected the wrong one when I first tested it.

 

Really odd that the "bad" rom doesn't exhibit that behavior when used on the Atarimax with the Phoenix. Only when run directly from the Phoenix.

Different processes going on between cart load and sd card load. The FPGA has to try to replicate cartridge hardware. If the rom is made unusual by hacking it to remove the delay it could introduce errors in sd load vs loading from cart. 

[fiudr]

On 1/18/2020 at 3:52 AM, Tursi said:

"Even"? When the Phoenix release count matches the Flashback release count, let's revisit this point.

 

The resolution is 256x192. That's all the pixels that actually exist in the image. It's upscaled from that point with no interpolation, just pixel doubling. You're asking for a massively faster hardware clock and tighter HDMI timing so that the console does the doubling instead of your TV, which is what is designed to do it.

 

I don't make the decisions, but I've never understood this argument. You don't get any extra pixels, only bigger ones. There's no dropped detail.

There's a difference between outputting 256x192 and the TV upscaling it to 4k, and rendering it in the hardware at 720p and the TV upscaling the 720p image to 4k. There's a difference between upscaling and rendering.

 

Yes, to my knowledge the system would be using pixel doubling or whatever to render a larger image, but that would still be output at a super-sharp 720p. Because it's being rendered at 720p, the image the TV receives is much larger in resolution, and needs less upscaling. And the TV does a great job from there of upscaling 720p to 4k. But if the TV receives a measly 480p image, that's a very low resolution to upscale from. Like I said, it's better for the game system to render the images at a higher resolution first.

 

Edited January 23, 2020 by fiudr

[Ikrananka]

On 1/18/2020 at 7:58 AM, Bmack36 said:

That is strange. I wonder if your SAC is producing noise or inconsistent pulses. When I use that program on my SAC it does not generate any spurious pulses and always matches the speed and direction input. 

Even stranger.....I've just tested the three SACs that I have on a real CV.  On one of the controllers the spinner isn't operating correctly, but on the other two the spinner was registered perfectly in both directions using both the Nuvatec and Bruce Tomlin SAC test programs.  Nice and smooth in both directions regardless of how slow or fast the spin is.  However, while these register in both directions on a real CV, on my Phoenix they only register in one direction (spinning to the right).  The movement is still nice and smooth but when spinning left on my Phoenix it always moves to the right in the test programs.

 

I've also noticed that the Phoenix SAC keypad detection is not quite right.  Pressing the keypad buttons on a real CV the button presses are detected with a normal press of each button.  However, on the Phoenix I noticed that I would have to press harder on each button for the Phoenix to reliably detect the button presses.  I'll add this issue to the GitHib.

[Swami]

5 minutes ago, Ikrananka said:

Even stranger.....I've just tested the three SACs that I have on a real CV.  On one of the controllers the spinner isn't operating correctly, but on the other two the spinner was registered perfectly in both directions using both the Nuvatec and Bruce Tomlin SAC test programs.  Nice and smooth in both directions regardless of how slow or fast the spin is.  However, while these register in both directions on a real CV, on my Phoenix they only register in one direction (spinning to the right).  The movement is still nice and smooth but when spinning left on my Phoenix it always moves to the right in the test programs.

 

I've also noticed that the Phoenix SAC keypad detection is not quite right.  Pressing the keypad buttons on a real CV the button presses are detected with a normal press of each button.  However, on the Phoenix I noticed that I would have to press harder on each button for the Phoenix to reliably detect the button presses.  I'll add this issue to the GitHib.

How does the SAC spinner work, since the ColecoVision doesn't have a Vcc to power an optical encoder? Is it a mechanical rotary encoder or does it "steal" power from the small current from the normal five action pins?

[Ikrananka]

3 minutes ago, Swami said:

How does the SAC spinner work, since the ColecoVision doesn't have a Vcc to power an optical encoder? Is it a mechanical rotary encoder or does it "steal" power from the small current from the normal five action pins?

IIRC, the plastic spinner has two magnets in it that pass over two parallel (reed?) switches.  The magnets activate each switch in turn with two rapid pulses produced.  Depending upon the order of the pulses, i.e. Switch 1 then Switch 2 or Switch 2 then Switch 1 dictates how the CV determines the direction the spinner is turning.  As these are simply switches like all other controller actions (not optical) I believe they do not require any power.  Attached are the controller schematic and PCB layout, courtesy of ChildofCV.

 

Perhaps the Phoenix's tolerance of how close together the two pulses are for direction detection needs adjusting?

SuperActionController-PCB.pdf SuperActionController-Schematic.pdf

[Swami]

1 minute ago, Ikrananka said:

IIRC, the plastic spinner has two magnets in it that pass over two parallel (reed?) switches.  The magnets activate each switch in turn with two rapid pulses produced.  Depending upon the order of the pulses, i.e. Switch 1 then Switch 2 or Switch 2 then Switch 1 dictates how the CV determines the direction the spinner is turning.  As these are simply switches like all other controller actions (not optical) I believe they do not require any power.  Attached are the controller schematic and PCB layout, courtesy of ChildofCV.

 

Perhaps the Phoenix's tolerance of how close together the two pulses are for direction detection needs adjusting?

SuperActionController-PCB.pdf 27.78 kB · 0 downloads SuperActionController-Schematic.pdf 55.21 kB · 0 downloads

There is something in the original ColecoVision that deals with signal artifacts that is different from the Phoenix. I've also seen the Atari 2600 able to correctly interpret optical quadrature from an adapter that the ColecoVision did not, resulting in the one-direction only movement. However, I have found the Smallymouse2 quadrature adapter (USB mouse to bus mouse) to work flawlessly on Atari 2600, ColecoVision and Phoenix, so I think it must put out a very high quality quadrature signal that the Roller Controller, 3rd party adapter and SAC do not. I can't remember the name of the guy who made the 3rd party adapter I got off eBay, but its not really important).

[Ikrananka]

1 hour ago, Swami said:

There is something in the original ColecoVision that deals with signal artifacts that is different from the Phoenix.

As the Phoenix is an FPGA then shouldn't the Phoenix replicate this?  Or is it perhaps down to the tolerances of the components of that era that aren't directly replicated in an FPGA unless explicitly tuned?

[Swami]

7 minutes ago, Ikrananka said:

As the Phoenix is an FPGA then shouldn't the Phoenix replicate this?  Or is it perhaps down to the tolerances of the components of that era that aren't directly replicated in an FPGA unless explicitly tuned?

Tuned or left out, not sure. I think its clear from several shortfalls in the Phoenix that FPGA being 100% accurate replication can't be taken for granted, despite commonly advertised as such, although, hopefully, it can be achieved in the near future. That's not to say there isn't a lot that is great about it. 

[Ikrananka]

36 minutes ago, Swami said:

Tuned or left out, not sure. I think its clear from several shortfalls in the Phoenix that FPGA being 100% accurate replication can't be taken for granted, despite commonly advertised as such, although, hopefully, it can be achieved in the near future. That's not to say there isn't a lot that is great about it. 

Personally, I'm loving my Phoenix.  I'm just testing it as much as possible to identify any wrinkles to give the devs something to do ?  Seriously though, I'm hoping that identifying niggles such as these will end up making it as good as the real thing (but with HDMI). 

[Keatah]

6 hours ago, Ikrananka said:

As the Phoenix is an FPGA then shouldn't the Phoenix replicate this?

Common wisdom would have you think so. But FPGA's are not an exact replication of transistors, resistors, diodes, capacitors, inductors, and so on. At the component level, the IC's and discrete parts in a real ColecoVision console have all kinds of nuances that are digested down (through observation) by the developer and then translated into series of Truth Tables or bitstream by the developer and his toolkit. Every time you turn on the Phoenix it's uploaded to the FPGA. Now you have a chip that is programmed to be a ColecoVision.

 

6 hours ago, Ikrananka said:

  Or is it perhaps down to the tolerances of the components of that era that aren't directly replicated in an FPGA unless explicitly tuned?

Partly yes. You can't really "tune" anything in an FPGA like you would an AM/FM radio or other analog style equipment. You can adjust values in the Truth Tables and DACs or ADCs. Or build new ones, or build more of them, to look at incoming signals in more detail or differently. But that also costs valuable fabric space. This is a sub-$100 FPGA here, it isn't a "communications" grade FPGA like used in radar systems or soft radios.

 

6 hours ago, Swami said:

Tuned or left out, not sure. I think its clear from several shortfalls in the Phoenix that FPGA being 100% accurate replication can't be taken for granted, despite commonly advertised as such, although, hopefully, it can be achieved in the near future. That's not to say there isn't a lot that is great about it. 

It's commonly advertised as such (all FPGA consoles are) because, Hardware = Hardware. And that instills "exact replication" in the mind of the gamer who wants to believe. All without guaranteeing anything. The harsh reality is that FPGA is no more or less accurate than Software Emulation. And few people like SE to begin with. Especially the press. They downplay it at every opportunity. They call it cheap, shoddy, inaccurate.. you name it.

 

Besides you can't really sell Software Emulation, aside from like compilations to play online. Can't sell the good stuff like MAME or Altirra. But a hardware box with FPGA in it? You can market it all day long.

 

FPGA or SE is only as accurate as their respective developers make them. Both camps come close to doing a passable simulation of their target consoles. But I believe SE has a huge advantage because there are more C devs than FPGA devs, and this creates a knowledge base and provides for easy passing of the torch should a dev decide to retire from a project. SE has a better chance of being picked up and continued on compared to FPGA. MAME and Stella are just two examples.

 

6 hours ago, Ikrananka said:

Personally, I'm loving my Phoenix.  I'm just testing it as much as possible to identify any wrinkles to give the devs something to do ?  Seriously though, I'm hoping that identifying niggles such as these will end up making it as good as the real thing (but with HDMI). 

Yes. That's how it goes for these kinds of things, Software Emulators or FPGA Emulators. It's just natural evolution. MAME has been doing it for 20+ years now.

[Tursi]

10 hours ago, Ikrananka said:

I've also noticed that the Phoenix SAC keypad detection is not quite right.  Pressing the keypad buttons on a real CV the button presses are detected with a normal press of each button.  However, on the Phoenix I noticed that I would have to press harder on each button for the Phoenix to reliably detect the button presses.  I'll add this issue to the GitHib.

This is interesting, since the buttons are not analog. I wonder if they are just dirty, and the Coleco is more sensitive to the reduced current?

10 hours ago, Ikrananka said:

Perhaps the Phoenix's tolerance of how close together the two pulses are for direction detection needs adjusting?

Interpretation of the reed switches is done in the game software, not in the hardware. MattH can give you a good long rant about the circuitry on the ColecoVision input port, though... it's a bit odd and doesn't reproduce in a straight-forward manner.

 

[Ikrananka]

6 hours ago, Tursi said:

This is interesting, since the buttons are not analog. I wonder if they are just dirty, and the Coleco is more sensitive to the reduced current?

Not sure about dirty, but certainly the materials involved at the keypad contacts could easily have deteriorated and are less effective.  My point of posting this was to highlight the difference in behaviour between a real CV and the Phoenix in the hope that you may be able to reduce the differences.  Personally I hate the SAC keypads - at this age they can be as flaky as the spinners.

 

6 hours ago, Tursi said:

Interpretation of the reed switches is done in the game software, not in the hardware. MattH can give you a good long rant about the circuitry on the ColecoVision input port, though... it's a bit odd and doesn't reproduce in a straight-forward manner.

But there is definitely an issue here with the Phoenix.  My two good SACs work smoothly in both directions on a real CV but on the Phoenix it is always to the right.  Testing with both the old Nuvatec program and the much newer Bruce Tomlin program.

[Bill Loguidice]

30 minutes ago, Ikrananka said:

But there is definitely an issue here with the Phoenix.  My two good SACs work smoothly in both directions on a real CV but on the Phoenix it is always to the right.  Testing with both the old Nuvatec program and the much newer Bruce Tomlin program.

Perhaps it's related to the same issues with the Steering Wheel and Roller Controller?

[+evg2000]

3 hours ago, Bill Loguidice said:

Perhaps it's related to the same issues with the Steering Wheel and Roller Controller?

what issues are they having?  My paddle seems to work fine on the phoenix.  Though total different implementation than the steering whee, roller controller, or SAC.  

[Bill Loguidice]

3 minutes ago, evg2000 said:

what issues are they having?  My paddle seems to work fine on the phoenix.  Though total different implementation than the steering whee, roller controller, or SAC.  

One example is jumping/warping in Slither and drift in Turbo. 

[+evg2000]

Bill, thanks for the info. 

[Swami]

22 hours ago, Keatah said:

Common wisdom would have you think so. But FPGA's are not an exact replication of transistors, resistors, diodes, capacitors, inductors, and so on. At the component level, the IC's and discrete parts in a real ColecoVision console have all kinds of nuances that are digested down (through observation) by the developer and then translated into series of Truth Tables or bitstream by the developer and his toolkit. Every time you turn on the Phoenix it's uploaded to the FPGA. Now you have a chip that is programmed to be a ColecoVision.

 

Partly yes. You can't really "tune" anything in an FPGA like you would an AM/FM radio or other analog style equipment. You can adjust values in the Truth Tables and DACs or ADCs. Or build new ones, or build more of them, to look at incoming signals in more detail or differently. But that also costs valuable fabric space. This is a sub-$100 FPGA here, it isn't a "communications" grade FPGA like used in radar systems or soft radios.

 

It's commonly advertised as such (all FPGA consoles are) because, Hardware = Hardware. And that instills "exact replication" in the mind of the gamer who wants to believe. All without guaranteeing anything. The harsh reality is that FPGA is no more or less accurate than Software Emulation. And few people like SE to begin with. Especially the press. They downplay it at every opportunity. They call it cheap, shoddy, inaccurate.. you name it.

 

Besides you can't really sell Software Emulation, aside from like compilations to play online. Can't sell the good stuff like MAME or Altirra. But a hardware box with FPGA in it? You can market it all day long.

 

FPGA or SE is only as accurate as their respective developers make them. Both camps come close to doing a passable simulation of their target consoles. But I believe SE has a huge advantage because there are more C devs than FPGA devs, and this creates a knowledge base and provides for easy passing of the torch should a dev decide to retire from a project. SE has a better chance of being picked up and continued on compared to FPGA. MAME and Stella are just two examples.

 

Yes. That's how it goes for these kinds of things, Software Emulators or FPGA Emulators. It's just natural evolution. MAME has been doing it for 20+ years now.

The main shortfall of emulation is it is not very compatible with carts, many of which cannot be dumped.

[Tursi]

On 1/26/2020 at 9:11 PM, Swami said:

The main shortfall of emulation is it is not very compatible with carts, many of which cannot be dumped.

There are still legacy carts that can't be dumped, or is this newer carts for respect reasons?

 

[Swami]

On 1/29/2020 at 1:30 AM, Tursi said:

There are still legacy carts that can't be dumped, or is this newer carts for respect reasons?

 

I’m referring mainly to some homebrews when it comes to ColecoVision. Also, I am referring to personal copies, so the respect issue is not in play. There are a few homebrew carts that cannot currently be dumped and used on an emulator for physical reasons. There are about 5 to 7 such ColecoVision Homebrews. In general for all 8-bits, some have DRM that prevents dumping. Intellivision has several. As far as legacy carts, Pink Panther prototype for the 2600 was such a cart due to the electronics in the cart, but it was recently dumped using a savekey. I can’t think of any other legacy carts but there might be a couple. 

[Mika73]

How many orders are still missing before more Phoenix can be shipped?


Sent from my iPhone using Tapatalk