Jump to content
crisalan44

Cavern Fighter and Second Gen Phoenix issues

Recommended Posts

13 hours ago, Tony Cruise said:

Rather than break your emulation...

It is not emulation.

13 hours ago, Tony Cruise said:

... to make one cartridge work (that is actively trying to detect emulation) and stop probably quite a few other games from working (that work fine on all versions of real hardware and all the emulators) ...

That's a very bold, yet vague, statement.  Have *you* tested "quite a few other games" on *all* real hardware and emulators?  I can tell you this much, the people working on Phoenix have at least tried, and spent many hundreds of hours testing.  The author of Risky Rick also blamed the Phoenix and emulators for getting something wrong, and low, it turned out they lied and were wrong.

13 hours ago, Tony Cruise said:

I think it would be better to go back to your memory initialisation used in version 7

And what initialization was that, exactly?  See, real RAM does not "initialize", so if you did not write a value to a RAM location, you should never "assume" it contains any specific value.  Any initialization that emulators or the Phoenix does is an attempt to try to keep software working that does not do proper initialization.

13 hours ago, Tony Cruise said:

... and it would probably be better to figure out which addresses Risky Rick checks to add some values ...

Are you volunteering?  Never mind, that was a rhetorical question.  Someone was nice enough to reverse it already and do a write-up.  What R.R. does is stupid, and it will also fail on a real CV (and has been reported to do so).  The Phoenix did "add some values", and see, it breaks your game now because you did not initialize RAM before using it, and you blame the Phoenix for getting something wrong.  That is just not right.

13 hours ago, Tony Cruise said:

or even detect that it is a Risky Rick cartridge and only do your changed behavior for that cartridge/rom.

Really?  Seriously?  First of all, the Phoenix is *NOT* MAME.  Changing behavior for crappy software is not going to happen.  If devs want to leave having their software work to "random chance", so be it.  The CV barely works as it is (the hardware implementation is awful).

13 hours ago, Tony Cruise said:

And look I'm happy to add a call to CONTROLLER_INIT in future titles to make sure, ...

As you should have done to begin with.  What did you expect to happen using uninitialized RAM and I/O ports?

13 hours ago, Tony Cruise said:

but it's not going to fix existing ones that have an issue (and there will probably be more titles than have been listed so far that will have issues).

Nope, it won't fix any existing bad code.  If people continue to not understand hardware and make wrong assumptions, there will continue to be broken software.

13 hours ago, Tony Cruise said:

The Phoenix Coleco core is supposed to emulate a Coleco after all.

The Phoenix is not emulation.

 

It is a completely unrealistic expectation that *any* software emulation or hardware reproduction of a retro-computer is going to implement the thermal and transient response of the transistors used in legacy memory chips.  The power-on or reset state of a RAM chip is *RANDOM*!  I/O ports are the same deal, ESPECIALLY the seriously crappy CV ports.  If you did not initialize the RAM or ports, then you should NEVER expect them to be set to any known value.

 

Share this post


Link to post
Share on other sites
11 hours ago, matthew180 said:

It is not emulation.

It is Hardware Emulation.

 

"hardware emulation is the process of imitating the behavior of one or more pieces of hardware with another piece of hardware, typically a special purpose emulation system."

(wikipedia)

 

 :)

Share this post


Link to post
Share on other sites
6 hours ago, youki said:

It is Hardware Emulation.

 

"hardware emulation is the process of imitating the behavior of one or more pieces of hardware with another piece of hardware, typically a special purpose emulation system."

(wikipedia)

 

 :)

No, it is Hardware simulation 
Big difference

Share this post


Link to post
Share on other sites
24 minutes ago, retroillucid said:

No, it is Hardware simulation 
Big difference

Not at all, i encourage you to check the definition what a hardware Simulation is.   I hope the Phoenix is not a simulation! :)

 

But anyway, it makes no difference in the fact that the Phoenix is a great system whatever you name it.

 

Share this post


Link to post
Share on other sites
10 minutes ago, youki said:

Not at all, i encourage you to check the definition what a hardware Simulation is.   I hope the Phoenix is not a simulation! :)

 

But anyway, it makes no difference in the fact that the Phoenix is a great system whatever you name it.

 

A simulator creates an environment that mimics the behavior and configurations of a real device.

On the other hand, an emulator duplicates all the hardware and software features of a real device

  • Like 1

Share this post


Link to post
Share on other sites
On 7/24/2021 at 8:39 AM, Tursi said:

RAM powerup is random, you should not be relying on it to be any specific value when your software starts, ESPECIALLY when your software specifically skips the BIOS initialization code, which actually DOES init all that for you.

 

Init your hardware, people.

 

But there is a difference between some random bit data and filling the RAM with 0xFF.  It doesn't look like CONTROLLER_INIT is called even if you don't skip the BIOS screen either.  It's only called when no cartridge is detected.

Share this post


Link to post
Share on other sites
On 7/24/2021 at 11:23 AM, matthew180 said:

It is not emulation.

That's a very bold, yet vague, statement.  Have *you* tested "quite a few other games" on *all* real hardware and emulators?  I can tell you this much, the people working on Phoenix have at least tried, and spent many hundreds of hours testing.  The author of Risky Rick also blamed the Phoenix and emulators for getting something wrong, and low, it turned out they lied and were wrong.

And what initialization was that, exactly?  See, real RAM does not "initialize", so if you did not write a value to a RAM location, you should never "assume" it contains any specific value.  Any initialization that emulators or the Phoenix does is an attempt to try to keep software working that does not do proper initialization.

Are you volunteering?  Never mind, that was a rhetorical question.  Someone was nice enough to reverse it already and do a write-up.  What R.R. does is stupid, and it will also fail on a real CV (and has been reported to do so).  The Phoenix did "add some values", and see, it breaks your game now because you did not initialize RAM before using it, and you blame the Phoenix for getting something wrong.  That is just not right.

Really?  Seriously?  First of all, the Phoenix is *NOT* MAME.  Changing behavior for crappy software is not going to happen.  If devs want to leave having their software work to "random chance", so be it.  The CV barely works as it is (the hardware implementation is awful).

As you should have done to begin with.  What did you expect to happen using uninitialized RAM and I/O ports?

Nope, it won't fix any existing bad code.  If people continue to not understand hardware and make wrong assumptions, there will continue to be broken software.

The Phoenix is not emulation.

 

It is a completely unrealistic expectation that *any* software emulation or hardware reproduction of a retro-computer is going to implement the thermal and transient response of the transistors used in legacy memory chips.  The power-on or reset state of a RAM chip is *RANDOM*!  I/O ports are the same deal, ESPECIALLY the seriously crappy CV ports.  If you did not initialize the RAM or ports, then you should NEVER expect them to be set to any known value.

 

But the change made to the latest firmware is specifically filling RAM with 0xFF, not random bits being set which may on the odd chance cause issues. And yes it is an emulator, just FPGA emulation rather than software emulation, so it needs to emulate what the original hardware does.  So Ram should be cleared and maybe some random bits (not bytes) set here and there to simulate fluctuating.  Had any other value than 0xFF been chosen to fill ram with, then there would not actually have been a problem.  This change in behavior has also caused issues with other titles not just mine.

 

I do clear all Ram my titles use, but this is Ram used by a BIOS routine.  The start-up code in the BIOS is a little hard to follow, on further analysis it looks to only call controller init when no cartridge is found.  Something that was there but no one specifically noticed, now we do, so future titles will be better for it.

 

And the older version of the Phoenix firmware worked fine for all of the existing games, so this change has actually made it less compatible, so it is a regression i.e. it supports less titles than it did for the last version, it makes it perform less like real hard so thus it needs to be fixed.

 

On my side of things I have added the call to all existing titles in development, and will change the free libraries I share with the community i.e. to make things better in the future.  But we can't do anything about all the physical cartridges out there with that will not work on this Phoenix firmware version.

 

And yes I agree with your very last statement, emulators being made to try and emulate the thermal and transient response etc is too much to ask, but setting the Ram to have all bits turned on; a real device would never be in that state. When it has no power, all the bits would be zero, it's only when powered on that there would be a very small chance that some bits (not bytes) would be turned on.

 

Although I do take a bit of offense at calling my original, written from scratch games, crappy ports.  I am one of the few people who truly write to the hardware, have taken the trouble to create both a video series and write a book, to help more people create original titles for the system we love.  Plus quite a few people tested the title extensively, on every hardware iteration and all of the emulators, including the Phoenix - are you disparaging their efforts as well?  The testing of the game was completed in November last year, well before the 2nd run of the Phoenix was in progress.

Have you actually tried writing an original game yourself, completing it including the work it takes to test it?  I seriously doubt it.

 

And I want to be very clear, the Phoenix is a fantastic piece of hardware, put together at great effort by a team of people, and it is allowing a lot more people to experience the wonder that is the Colecovision.  But we don't want it to regress and provide a bad experience, so just like software titles need to be tested so do firmware upgrades.  And this change made to support (as you said a piece of bad programming) perhaps wasn't such a good idea considering how many titles it has knocked off the capability list.

 

 

 

 

Share this post


Link to post
Share on other sites
11 hours ago, retroillucid said:

A simulator creates an environment that mimics the behavior and configurations of a real device.

On the other hand, an emulator duplicates all the hardware and software features of a real device

So you mean the Phoenix just mimics the behavior and configuration of a colecovision?    I'm disapointed. :(

 

I thought the Phoenix duplicated in a FPGA all the hardware and software features of the colecovision.

 

Ok so , if you say , the Phoenix is a colecovision simulator.

 

In fact it is like when your wife is simulating ...  🤣   sorry.. :)

 

 

 

Share this post


Link to post
Share on other sites
11 minutes ago, Tony Cruise said:

Although I do take a bit of offense at calling my original, written from scratch games, crappy ports.  

Tony, i don't think the scratch games and  crappy ports was targeted to your games , i think he was talking about game like Risky Risk.

  • Like 1

Share this post


Link to post
Share on other sites

My first job out of college was component level repair of PCB's for a multitude of devices.

Printers, Laser Scanners etc.

 

The test beds were all SIMULATORS. 

So, you could replace various boards from a device and plug it into the simulator and would ACT like it was in the actual device.

This was nice because you could easily apply heat or cooling to the board or a single component without having daughter boards or chassis in the way etc.

 

When you "printed" it did not fire a print head, it strobes LED's  etc.

 

I have had boards so bad, that I would fry the test bed and I would spend an hour or two fixing that! :(

I was using up to 95% actual hardware of a device and it was still a simulation of the device.

 

I can't imagine what test beds look like today? If they even exist?  Don't we just throw it away if it doesn't work now...

 

 

 

Share this post


Link to post
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.

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