Why does Penguin Adventure not work on some CV systems?

[Ikrananka]

Ok, let me get this behind me too. I have scheduled 3 days during the week to check the code first. First I have to isolate which part of the code is causing the crash in the affected systems. It is easier now since I have one such board. I get back to you ASAP.

 

Any update?

[ChildOfCv]

Just a general note about capacitance, which may not be all that helpful

 

When testing whether power is any good, you should put the voltmeter on AC and check the voltage at the chip power supply pins. If the power is good and filtered, you'll see little to no reading on the meter. When electrolytic capacitors begin to fail, they will begin to leech at the power supply's capabilities, and that will be evident with ripple voltage.

 

I've only recently heard about the SGM (basically since I started browsing this board), so I have no idea what its internals look like, so hopefully I don't come off as sounding like I know everything in the following points. I also can't guarantee complete accuracy, only having an associates degree in electronics troubleshooting from the local community college--obviously I'm only vaguely aware of design issues and not an authority on how to mitigate signal integrity issues. Now, disclaimer aside:

 

Even if all of your caps are good, there could even be a design flaw in the SGM itself that makes it vulnerable to odd situations such as static electricity, certain bit patterns, phase of the moon, etc. At its core, a capacitor is just two metal plates in proximity that are not touching. Well, board traces match that description too. There will be some crosstalk between traces, and if it's bad enough, your signal degrades. So running traces in high-frequency applications can be as much black magic as it is science. If the SGM employs high-frequency components such as an on-board microprocessor, that's a definite concern. At Colecovision's 3.58MHz, you're still pretty safe from that. But at 50MHz or better, that's in the fun zone.

 

It could be that if you left the board as dirty as was shipped, the game would have worked. The accumulated corrosion could have been fortuitous in providing just enough resistance to maintain adequate signal quality, and cleaning is actually what did it in. As that affects the SGM, perhaps adding a few low-ohm resistors on the signal lines would be enough to fix its issues.

 

It could well be that the cleanness of the CV board may be the deciding factor in what works vs what doesn't.

 

But again, just spitballing here.

[imstarryeyed]

I will be very keen to see a cart that is broken to see if it works on the Collectorvision system. I think if it works on that system it may help rule out the cart from system differences?

[Ikrananka]

Wow, I can’t believe I’m writing this, but I have a solution to the Penguin Adventure problem. It turns out that I was not getting good ground continuity on my system, specifically this meant that pin 13 on the cartridge connector was not getting a connection to the RF shield and therefore was not grounded. This was identified by @ArcadeVision as this was what was causing problems on some systems with their Risky Rick game. Specifically the problem with their game seemed to occur on systems that had been disassembled and reassembled for modding but somehow the bottom RF shield did not make a good connection with the motherboard. Initially the mods were blamed but then ArcadeVision determined that it was a grounding issue.

 

So, I fixed my system by doing some bending and cleaning of the bottom RF shield and now pin 13 on the cart connector has good continuity with the RF shield and the ground plane. I wondered if this might have also been the problem with Penguin Adventure and it was. The game now works perfectly. I tested this again by intentionally removing the bottom RF shield and the resetting problem returned. When I put the RF shield back and ensured pin 13 was grounded, the game worked perfectly again.

This makes sense as NIAD reported that on one of his systems pressing down on the cartridge would get it working. What was probably happening was that this was pressing the motherboard against the bottom RF shield at the screw by the cart connector, thereby grounding pin 13.

Details on how to test for the problem and how to fix it can be found here.

 

[+evg2000]

@Ikrananka, interesting find. The strange thing is that on my system if I remove the SMG and use a JB it works, put the SGM back in and it's broken again. I wonder if the SGM is pushing the RF shielding somehow?

[Ikrananka]

@Ikrananka, interesting find. The strange thing is that on my system if I remove the SMG and use a JB it works, put the SGM back in and it's broken again. I wonder if the SGM is pushing the RF shielding somehow?

 

Yeah, no idea what's making that happen. Could be that something about their dimensions is causing the motherboard to be pressed in a certain direction and that this is causing ground to become problematic. I'd really suggest doing the ground continuity test (which can be done without disassembly). If that shows good ground continuity then I'd remove the top of your CV and that way you'll be able to physically see what's going on when the two different boxes are connected to the expansion slot. If you do disassemble it's then a good idea to lift the motherboard and clean all of the ground plane and shield contacts to make sure you've got as good ground continuity as possible. In fact you could also solder a wire between the main ground plane and the area next to the cartridge connector (the area with the screw).

[opcode]

This is very interesting. Now, I am not sure that I understand the VDP clock issue. If that is the case, then those CVs with shielding issues would stop working with any game.

I think it is more probable that you are getting noise from pin13, and that is interfering with the SGC mapper. That is something we could check before designing the next board. Maybe there is a way to make it less vulnerable to such noise. I wonder if we leave pin 13 unconnected if that would help. In theory the cartridge should work just fine. We connect pin 13 because Coleco did that with their cartridges.

But thanks a lot for sharing the solution.

 

 

Sent from my iPhone using Tapatalk

[Tony Cruise]

Any updates on fixes for Penguin Adventure, it's been over 18 months since I got my copy and I am still unable to play it, and very little communication on updates and progress???

[Ikrananka]

5 hours ago, Tony Cruise said:

Any updates on fixes for Penguin Adventure, it's been over 18 months since I got my copy and I am still unable to play it, and very little communication on updates and progress???

Hi Tony, this problem was found to be down to poor grounding on certain ColecoVision systems.  Check out my posts here and here for the solution.

[Bmack36]

6 hours ago, Tony Cruise said:

Any updates on fixes for Penguin Adventure, it's been over 18 months since I got my copy and I am still unable to play it, and very little communication on updates and progress???

Did you try it on your Phoenix? It should work fine on that.

[Ikrananka]

2 minutes ago, Bmack36 said:

Did you try it on your Phoenix? It should work fine on that.

I can also confirm that it works fine on a Phoenix.

[Kiwi]

23 hours ago, Tony Cruise said:

Any updates on fixes for Penguin Adventure, it's been over 18 months since I got my copy and I am still unable to play it, and very little communication on updates and progress???

I did notice that the games were running slower on your system from the Vanguard/Challenger video.  I think it is a PAL system, running at 50fps instead of 60.  I'm not sure if Penguin Adventure would work on PAL system or not.  You do have the Phoenix, you may want to try the cart on that system to see if it works. 

[Tony Cruise]

Good point I do now have a Pheonix so will try it on that over the weekend.  And yes I listed myself as having a Pal system in the earlier parts of this post.  That shouldn't generally be a problem.

Would have been nice to have actually received support from OpCode though, especially as this was sold as a premium product.

Perhaps a lesson to OpCode that maybe working on writing titles from scratch might be a better strategy, rather than just porting other peoples code with a tool set and having issues like this.

[opcode]

Just now, Tony Cruise said:

Good point I do now have a Pheonix so will try it on that over the weekend.  And yes I listed myself as having a Pal system in the earlier parts of this post.  That shouldn't generally be a problem.

Would have been nice to have actually received support from OpCode though, especially as this was sold as a premium product.

Perhaps a lesson to OpCode that maybe working on writing titles from scratch might be a better strategy, rather than just porting other peoples code with a tool set and having issues like this.

I don’t port with a tool set, and the reason for the problem was mentioned above. It isn’t software related otherwise everybody would be experiencing the same issues.

I understand your frustration, just please don’t say things that aren’t true.  
We have been working on a new cartridge PCB to eliminate the issue, but we aren’t there just yet. 

[Tony Cruise]

30 minutes ago, opcode said:

I don’t port with a tool set, and the reason for the problem was mentioned above. It isn’t software related otherwise everybody would be experiencing the same issues.

I understand your frustration, just please don’t say things that aren’t true.  
We have been working on a new cartridge PCB to eliminate the issue, but we aren’t there just yet. 

Communication is key, plus I don't like to see someones talents wasted, you are far too good a programmer to just churn out ports (especially ones that would not pass both a percentage original code test and especially branded character/symbol tests in a copyright dispute).  I know you mean well and have been a long term supporter of the Colecovision, so don't take my words to heart too much (grumpy old person mode off).