Risky Rick in Dangerous Traps (June 25th)

[CPUWIZ]

5 minutes ago, Ritchy said:

I'm sorry to said that Risky Rick II was cancelled last year, since this topic turned wrong against our work and peoples prefered to not trust us. We are no more interrested to make ColecoVision games when so few peoples send feedbacks about their game experience and many more about this minor issue. I have only registered here during my vacation to try to explan that was not what you have though... Be free to continue to think what you want, I know that is not with a bunch of posts that I can change anything.

 

Welcome to the internet.

[Ritchy]

57 minutes ago, Swami said:

So, ArcadeVision seemed to dislike that I was trying to figure out why Risky Rick was giving me the dark start screen on two of my three ColecoVisions, rather than posting about gameplay on the one that worked.

Understand that is near to impossible to find a problem when you have a black screen and not able to reproduce it here.

[Swami]

22 minutes ago, Ritchy said:

Understand that is near to impossible to find a problem when you have a black screen and not able to reproduce it here.

BTW, I was not someone who asked to hack it, whatever that means, but, I have to admit it was informative as far as how it varies from typical carts.

[TPR]

It is almost a shame that ArcadeVision made such a decent game for the ColecoVision. Had they simply “played nicer” with the community they could have found themselves a nice niche of buyers who would have been happy to support their games. 

 

But playing the “blame game” as though it is somehow the members of the communities fault that their game doesn’t work on certain systems instead of offering refunds or a solution to make the game work, and then seeing the exchange in the past 24 hours is very disappointing. 

 

There were some very easy solutions here. None of which the publisher seems to be interested in. At least thanks to Kevtris, people who bought the game now have options to run it on previously non-working systems. 

 

I don’t think I’ve seen a scenario like this since Fred sold people faulty SGM knock-offs and tried to blame the customer for the issues they were having with his hardware. 

 

Its just not a good look for anyone wanting a community to support their projects. 

 

I wanted to be optimistic that the outcome of this would have been better because I’d like to see some new blood in the ColecoVision home brew community. 

 

Oh, well... 

[harlock76]

3 minutes ago, TPR said:

It is almost a shame that ArcadeVision made such a decent game for the ColecoVision. Had they simply “played nicer” with the community they could have found themselves a nice niche of buyers who would have been happy to support their games. 

 

But playing the “blame game” as though it is somehow the members of the communities fault that their game doesn’t work on certain systems instead of offering refunds or a solution to make the game work, and then seeing the exchange in the past 24 hours is very disappointing. 

 

There were some very easy solutions here. None of which the publisher seems to be interested in. At least thanks to Kevtris, people who bought the game now have options to run it on previously non-working systems. 

 

I don’t think I’ve seen a scenario like this since Fred sold people faulty SGM knock-offs and tried to blame the customer for the issues they were having with his hardware. 

 

Its just not a good look for anyone wanting a community to support their projects. 

 

I wanted to be optimistic that the outcome of this would have been better because I’d like to see some new blood in the ColecoVision home brew community. 

 

Oh, well... 

it's sad yes it is but don't take that too much at heart the community is still here yes things could have been better but as we says sh.. happens

there will always be new blood in the communiy as new hardwares and softwares will be created most of the times good blood  somes bad. coders will come and go that's how it is...

[kevtris]

2 hours ago, Ritchy said:

It is why I'm disapointed about kevtris do not contact us instead of thinking he his free to do what he wants with the work of others and saying we are lying is a public insult.

I have no reason to contact you about the game;  it was having issues on my hardware but turns out it wasn't my hardware after all, and was the game.  This means I have to debug it to find out why it happened.  I got interested when things didn't add up, and fell down the rabbit hole of figuring out exactly why it didn't work.   This is basically my job, to debug why videogames don't work on my hardware.   As such, this was just another thing to debug and I approached it like any other game that had problems.

 

That's when I discovered that the problem wasn't my fault.  The rest of the procedure was documented on my blog.  

 

I am free to explain what I found during the course of the investigation;  it was interesting and I figured others might want to see, too.   All I did was pull the curtain back a little on what was lurking inside when I discovered the cause of the failure was something more than a garden variety core bug of some kind.  I am not saying anyone is lying, but the functionality of those two checks is not in doubt.  They are defacto designed to stop it running in certain places.  There is literally no other purpose for it.  Sending the program counter into the weeds using a bogus PUSH BC : RET leaves no doubt why it was there.   This will do nothing but crash the CPU, since no valid address is ever put into BC, and the state of BC depends on what happens before.  The DJNZ before that point though will keep it looping through the checking routine for quite awhile and may never actually break out of it.

 

Obvious obfuscation was obvious at the very start of code too.  Adding 0x2a to HL and pushing it onto the stack to build a jump address was pretty humorous, and was a giant screaming red flag that I was about to find something really good a bit farther in, and I sure wasn't disappointed.  Adding something to HL before setting it up wasn't the smartest way to hide it- I just had to look at what the BIOS did after reset, which is load the start address into HL and jump to (HL).  

 

If you want to really learn how to obfuscate, I did a nice writeup on how I reverse engineered the Famicom "pirate original" Earthworm Jim 2 game.  It used some truly insane things like strings of seemingly random code that actually manufactured critical routines in RAM, and writing to bank select registers in the "middle" of what looked like a function, but if the bankswitch doesn't take place the code will eventually crash.  They hid the bankswitch register using mirrors of it and long strings of what looked like mapper initialization code which really didn't do anything of the sort.  They also hid code in what looked like data tables. 

 

The link to that is here: http://blog.kevtris.org/blogfiles/EWJ2PROT.TXT

 

 

[Ritchy]

1 hour ago, TPR said:

But playing the “blame game” as though it is somehow the members of the communities fault that their game doesn’t work on certain systems instead of offering refunds or a solution to make the game work, and then seeing the exchange in the past 24 hours is very disappointing. 

We have offered exchange and refund options to any peoples having a problem with the game, with the delivering service or simply changing their minds.

In this two cases, it was declined because the game was working on one of the ColecoVision. We have offered to fix the moded consoles too.

 

Edited August 6, 2019 by Ritchy

[Ritchy]

2 hours ago, kevtris said:

 it was having issues on my hardware but turns out it wasn't my hardware after all, and was the game. 

You can't said that after writing: "One good thing is this highlights how important it is in emulators and FPGA systems to initialize RAM to a state similar to how uninitialized RAM manifests to get around these tests.  As a bonus, at least on Coleco, it fixes two games that rely on randomness in RAM."

 

Nice to know that you learn it... Because our memory check highlight you the fact that some things you don't know/took care around the RAM initialisation state have to be and can allows to fix some issues with games. The way to do is not a problem (but a game into the game). Only the result it important. Removing it is just a door for potential bugs into emulators and FPGA systems, like I said since the began.

Edited August 6, 2019 by Ritchy

[Bmack36]

1 hour ago, Ritchy said:

You can't said that after writing: "One good thing is this highlights how important it is in emulators and FPGA systems to initialize RAM to a state similar to how uninitialized RAM manifests to get around these tests.  As a bonus, at least on Coleco, it fixes two games that rely on randomness in RAM."

 

Nice to know that you learn it... Because our memory check highlight you the fact that some things you don't know/took care around the RAM initialisation state have to be and can allows to fix some issues with games. The way to do is not a problem (but a game into the game). Only the result it important. Removing it is just a door for potential bugs into emulators and FPGA systems, like I said since the began.

Kevtris was referring to the fact that he was not able to get the game to fully run on his system without the pin 13 issue (getting the full game).  Once he had the full game, it would have worked just fine on his system due to the accuracy of his FPGA implementation and what you quoted above about the accuracy in the RAM initialization. He did notice that it still didn't work on the Atarimax or emulators, which prompted him to dig into it further.

Edited August 6, 2019 by Bmack36
typo

[kevtris]

1 hour ago, Ritchy said:

You can't said that after writing: "One good thing is this highlights how important it is in emulators and FPGA systems to initialize RAM to a state similar to how uninitialized RAM manifests to get around these tests.  As a bonus, at least on Coleco, it fixes two games that rely on randomness in RAM."

 

Nice to know that you learn it... Because our memory check highlight you the fact that some things you don't know/took care around the RAM initialisation state have to be and can allows to fix some issues with games. The way to do is not a problem (but a game into the game). Only the result it important. Removing it is just a door for potential bugs into emulators and FPGA systems, like I said since the began.

I was talking about how the demo version won't let you proceed.  I didn't find the RAM test stuff until later when I got the full version.

 

Interestingly, most games clear RAM out to a known state (all 0's for example) so this isn't a problem.  Only a poorly coded game or piece of software relies on the random RAM contents on initialization, because it cannot be relied upon to be in a usable, workable state when the software runs.   I highlighted two other Coleco titles with a random number problem because of this earlier, and have found others on other systems.

 

I consider a piece of software broken if changing ram contents causes the game to crash or fail in some way; because this can happen on real hardware by chance.  There is no guarantee that say, my Coleco will have compatible RAM trash to your Coleco.  Coleco could've used different manufacturers for the RAM in the systems depending on date of manufacture, or simply whatever they could buy cheapest that month for production.   It's very possible some brands or revisions of RAM produce all 0's or FFs, or some other static pattern.  I have some Motorola 8K SRAM chips that output 0xAA for every location on powerup.  Granted, these are military rated parts, so this could be in their spec to prevent problems like this.

 

(For those that are curious)

 

I have actually researched RAM power up values for different kind of SRAMs;  specifically 6116 and 6264 and 62256 style SRAMs (2K, 8K, and 32K static RAMs such that are found in many NES era to SNES/genesis/gameboy era systems and carts).   Their powerup patterns tend to be repeating blocks of mostly 00 and FF, with the spacing of each run determined by manufacturer and chip size.

 

While the data is mostly 00's the FF's,  it is more complex and there will be plenty of single bit flips. These can be static, or change on every powerup, or only sometimes on subsequent powerups.  The exact behavior is determined by voltage, temperature, the silicon process itself, and tiny imperfections.  It is very possible that some RAMs have a lot of these single bit flips, and others will have very few.  The latter will trigger on the first memory test as a failure and the game won't run.   It is acceptable to hash the entire contents of RAM (or some portion of it) to generate some entropy for a random number generator, but that is the only valid use of checking uninitialized RAM.  On several NES games, they will use two bytes for random number generation.  They use whatever value was in RAM as the starting seed but are safe about it.  If for some reason, the 16 bits hold 0, it will write a fixed seed into RAM so that the game will function even in this case.   Coleco could've learned a thing or two about this for THEIR random number generator!  They do not do the test.

 

Also, reading uninitialized RAM is such a problem for current day developers, that many emulators will actually throw a warning if you do it.  The easy solution is to simply clear RAM out when your code starts.

 

[+-^CrossBow^-]

8 hours ago, Ritchy said:

After that, only two guys with defective consoles that not run the game ask to hack our work without contacting us. Hey! It was offered to fix console on my free time (but shipping was too expensives) or to refund the game, despite the fact they was informed they should have problems before ordering.

I'm not sure where you are getting your information. But I never requested anyone to look into this issue and would never ask anyone to 'hack' a game so that I can play it outside of the normal means. 

 

Fact is Kevtris contacted me to help him get some measurements off my Colecovision while I had it opened up to recap it since he wasn't able to get the game physically and he knew I had the game and was experiencing issues that he felt was related to what he was working on.

 

As for offering to fix my console. Yes you did offer. I declined because I knew there wasn't really anything wrong with my console because I have quite a lot of other games for this system that do not give me any issues. So I apologize if I wasn't okay with sending my CV to unknown persons across the ocean to France to 'fix' what I knew wasn't broken to begin with. Again I can appreciate that gesture but it wasn't a risk that was worth taking for a single game that didn't want to work right in my CV.

 

@kevtris has already shown that the game isn't doing anything special that requires these ram checks. The Pin 13 bit was implemented to prevent dumping the game and for that no one faults you for doing that. In fact, it was incredibly creative. But stating that the RAM checks were needed for the game to operate properly is simply not a true statement as again, the game with those checks removed, works 100% on the same CV that your original cart does NOT work all the time on. So again your statements about these RAM checks being required are just not true and were put in place to prevent the game from booting properly under certain conditions. Conditions that Kevtris has stated can happen on actual hardware (And apparently there are at least 2 of us that are demonstrating this). Again, if it is only the two of us having this issue, then fine we live with it and move on but you need to call you code on this for what it is.

[Ritchy]

1 minute ago, -^Cro§Bow^- said:

I'm not sure where you are getting your information. But I never requested anyone to look into this issue and would never ask anyone to 'hack' a game so that I can play it outside of the normal means. 

I beg your pardon, may be I have misunderstood a sentence as it was really late here and I can't found again that information. So, please, don't care.

[Swami]

I suppose it’s a futile question now, but apparently he is saying pin 13 was there because of two full games and two demos (NTSC and PAL) on the 128k chip. But I don’t think it was ever understood why there are demo versions on the cart to begin with, that you only go to without ground.

 

I suppose maybe they are remnants from testing, but I’m not sure what purpose they would serve and it seems like a poor trade off to leave them on there and have the strict grounding issues of pin 13 not seen by any other cart and all kinds of people having to open their console up to fix it.

 

It it just seems strange to me to have these demos on the cart that normally wouldn’t be accessible anyway and just complicating things.  

[Ritchy]

Swami, all if futile as I try to explain something and my words are not properly understood (looks to be my fault). I have contacted Loafer by PM, as offered, and I'm waiting to see if it is possible to speak in french with him instead. I really hope that will help to not denny explanations after that.

 

Please, wait.

Edited August 6, 2019 by Ritchy

[Loafer]

Hi Ritchy

 

I have received your PM.  I am at work presently and will review and comment this evening

 

J'ai reçu ton message, Je travail présentement.  Je le lirai ce soir et te donnera mes commentaires ensuite 

 

[MegaManFan]

4 hours ago, -^Cro§Bow^- said:

Again, if it is only the two of us having this issue, then fine we live with it and move on but you need to call you code on this for what it is.

THIS.

[Ritchy]

-^Cro§Bow^- and Swami, we have never exclude to release a ROM version for peoples buying the game, but as we said it require some works and we are working on the MSX versions. Now, if you think that a hacked version should do the job for you, and you will not complain if any random bugs occurs with it, I can send to you an upgrate kit for your game cartridges. (please contact ArcadeVision by email)

Edited August 6, 2019 by Ritchy

[JT Cook]

If nothing else, this thread can be seen as a good case study of a company(big or small)/customer expectations and relations and product and support after issues arise. It also makes a good case study of the advantages and pitfalls of using DRM in software, and maybe to have a plan if that DRM cripples the rightful use of the software it was intended to protect. If there are any inspiring or active indie developers looking to sell their game (retro or even current PC) this thread is a good read through.

Also it is promising at the end of the day it looks like Ritchy is trying to make things right with the people who are having issues.

Edited August 6, 2019 by JT Cook
Typos

[Ritchy]

43 minutes ago, JT Cook said:

If nothing else, this thread can be seen as a good case study of company(big or small)/customer expectations and relations and product and support after issues arrise. It also makes a good case study of the advantages and pitfalls of using DRM in software, and maybe to have a plan if that DRM cripples the software it was intended to protect. If there are any inspiring or active indie developers looking to sell their game (retro or even current PC) this thread is a good read through.

Also it is promising at the end of the day it looks like Ritchy is trying to make things right with the people who are having issues.

You know JT Cook, we does all for the Risky Rick players since one year through the ArcadeVision website, retro event contest and email support.

This forum is an exception around the world as peoples prefered to post on the topic instead of contacting the support about any requests with our game.

 

I'm sure that we will find a deal with them because we have developed Risky Rick to have fun and to show what can technicaly does a stock ColecoVision.

Probably my approtch to try to explain our choices was wrong and I understant that you do not wanted to ear it. Better to focus on the solution for them.

 

I will work on a replacement kit if they agree with that.

 

[Albert]

1 minute ago, Ritchy said:

This forum is an exception around the world as peoples prefered to post on the topic instead of contacting the support about any requests with our game.

I'm getting really tired of seeing you put this forum down.  This is one of the largest classic gaming forums on the net, and it has a large number of active and enthusiastic ColecoVision owners.  People are going to be critical of issues such as what has been described in this thread, especially when the developers are being dodgy with their answers.  To say nothing of trying to squelch discussion of what you claim is not DRM/copy protection, although the code doesn't seem to serve any other useful purpose.  Please accept that people have not been happy with your handling of this situation, and stop trying to paint AtariAge in a negative light.

 

 ..Al

[Ritchy]

26 minutes ago, Albert said:

I'm getting really tired of seeing you put this forum down. 

Albert, I think that you misunderstand what I said. It is not puting the forum down to said that peoples prefered to ask support on a topic here instead.

And when I said this forum is an exception, it is not into a negative way. About the others points, if you don't agree with us it is not a problem at all. You don't know the game development history and the required choices to have a safe scope of usage for this game. Thank you.

Edited August 6, 2019 by Ritchy

[VectorGamer]

47 minutes ago, Albert said:

This is one of the largest classic gaming forums on the net

 

Behind CAGDC

[Albert]

2 minutes ago, VectorGamer said:

Behind CAGDC

What?

[TPR]

2 minutes ago, VectorGamer said:

Behind CAGDC

Well he did say "one of" the largest... 

[Albert]

Just now, TPR said:

Well he did say "one of" the largest... 

That forum only has 78,000 posts and looks somewhat dead in terms of activity.

 

 ..Al