Cavern Fighter and Second Gen Phoenix issues

[sn8k]

On 7/24/2021 at 3:43 PM, retroillucid said:

No, it is Hardware simulation 
Big difference

You're supposed to be working on Yucatan Jungle!!

[Tursi]

5 hours ago, youki said:

I don't consider that as "bug". In another context, it was very common to use tricks on computer and exploit some non documented hardware behavior to obtain special effect or else.  It is not bug.  Then when new hardware comes , some incompatibility may exists ok... but the tricks used were  not bugs.  

then it is up to you to see if you want your hardware is fully backward compatible or not. 

 

I didn't use the word bug. I used "issue"... because I agree with you. This is not a bug on the Phoenix side.

 

Whether use of undocumented features counts as a bug in my eyes depends on the system and the trick. I've seen some over the years that were just unfortunate incompatibilities, and some that were silly ideas in the first place and deserved a smack. 

 

[Tursi]

22 minutes ago, sn8k said:

I have encountered 2 issues.

 

Wizard of Wor will not play from SD card directly through the Phoenix. But works if I play it through the AtariMax Coleco flashcart on said Phoenix.

 

Ninja Princess does not work for me either directly through the Phoenix or using the AtariMax. It just freezes after 2 seconds of gameplay. Does the same thing on both

 

I dont have the actual carts to test.

 

These are the only 2 games I can't get working on Phoenix.

Wizard of Wor is a 512k cart, and the Phoenix can only load up to 512k minus 32k (for SGM) carts. I made a patch for it that moves some data out of the critical area so that it will run on Phoenix, I believe that was approved by the author and that it is here on AA somewhere. It will try to load them, but it can't determine in advance if that last 32k is actually used by the game.

 

Ninja Princess I don't know anything about.

 

[Ikrananka]

4 minutes ago, Tursi said:

Wizard of Wor is a 512k cart, and the Phoenix can only load up to 512k minus 32k (for SGM) carts. I made a patch for it that moves some data out of the critical area so that it will run on Phoenix, I believe that was approved by the author and that it is here on AA somewhere. It will try to load them, but it can't determine in advance if that last 32k is actually used by the game.

Here's the post with the patched Wizard of Wor rom:

 

 

[retroillucid]

30 minutes ago, sn8k said:

You're supposed to be working on Yucatan Jungle!!

Hahahaha! 

Yeah, I took a pause to work on Turbo SuperGame

[sn8k]

43 minutes ago, Ikrananka said:

Here's the post with the patched Wizard of Wor rom:

 

 

Thank you!

[matthew180]

On 7/25/2021 at 3:26 AM, Tony Cruise said:

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.

This has already been discussed, so I will only touch on it.  The Phoenix does not fill RAM with 0xFF.  It *used* to clear RAM to 0x00, since this is what most programmers seem to think happens with RAM at power-on and reset, and this is what most software emulators do as well (so I have been told).

 

However, along comes a new game and checks for this pristine zeroed RAM and won't start if it finds such a situation.  The author was relying on the actual random nature of RAM to try and detect when it was running on emulation, and would shut itself down (even though it is possible to have zeroed RAM after a warm-reset).  In response, the Phoenix HDL was modified to write a pattern to RAM.

 

On 7/25/2021 at 3:26 AM, Tony Cruise said:

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.

Please provide a detailed algorithm for this "random bits set here and there" that you speak of, that will not interfere with *any* software written in the past, or *any* software that will be written in the future.  Random is random, and all zero or all ones is valid, and anything in between.  Maybe you could spend a few hundred hours characterizing RAM power-on and thermal dynamics and let us know how we can make a perfect emulation of the power-on state of the CV RAM?

 

In the mean time, it does not matter what "pattern" or "random setting of bits" the Phoenix uses, any randomness could affect software that does not do proper initialization of memory or hardware ports.  This is also true of real hardware, and it was reported (so I have heard) that R.R. fails from time to time on real hardware too (yet somehow never on the author's system during testing...)

 

On 7/25/2021 at 3:26 AM, Tony Cruise said:

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.

Do you know this for a fact, or are you speculating again?  Have you tested the different firmware versions of the Phoenix against *all* CV games?  It did not work for R.R.  I can tell you this, Brian (BMack) and others try to test every CV game on the Phoenix, and when there is a problem getting one to run, we hear about it.  There is nothing to fix related to RAM, until we get your algorithm for making it match the real CV.

 

Sarcasm aside (but I'm only being slightly sarcastic to begin with, I'm serious about you writing that algorithm), I'm sure this issue will mean more HDL changes to make concessions for games.

 

On 7/25/2021 at 3:26 AM, Tony Cruise said:

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.

No, sorry, that's not how hardware works.  And if it was, what exactly would the "chance" of some bits being turned on?  You are making speculative statements as if they are fact.

 

If you read a powered-off RAM chip, you will get random data.  Powered off devices have no state.  Logic zero in a RAM chip is an "active" (powered) function of the chip and only exists when power is on.  Thinking that RAM somehow "powers on" as all zero, because without power the bits must somehow be "zero", is such a programmer's perspective about how hardware works.  And applying the idea that then, after power is applied, some of them "jump" to a one bit...  uh, no.

 

You need to go get yourself a solderless breadboard and a bunch of TTL logic ICs, and build a computer from scratch.  I think you might find the knowledge gained enlightening.

 

On 7/25/2021 at 3:26 AM, Tony Cruise said:

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

As others have pointed out, I was not talking about your software, I would not say such things.  It was mostly a dig at MAME and how it "patches" itself to work with various games instead of getting the emulation correct, but also at a lot of the legacy CV software that is really poorly written.

 

On 7/25/2021 at 3:26 AM, Tony Cruise said:

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.

I applaud your efforts, seriously, it is a lot of work.

 

But you are speculating again, somehow "knowing" that you are in a group of "one of the few people" doing this kind of work.  Do you know how many people are doing similar things?  Does it only have to be the CV community?  There are a lot of people making a lot of hardware and software for these systems we love.

 

While I do agree that, compared to the number of people *using* the systems, the number of people authoring new software or making new hardware is probably a small percent.  But even a small percent in a big community can be a large number of people.  No one asked us to make these new things, so IMO it is wrong the put yourself into some "better than others" status just because you have chosen to make something for an old system.  Most people outside of the retro-computer communities would probably consider it a waste of time and life (clearly I am not of that opinion).

 

On 7/25/2021 at 3:26 AM, Tony Cruise said:

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.

Of course I am not putting down anyone's efforts, especially testers.  But software releases all the time that was tested, yet bugs are still found later.  There are all kinds of bugs in existing CV software too, yet somehow it *seems* to work just fine, when the truth is it works out of pure chance, dumb luck, and sometimes randomness.

 

You tend to find a lot of software bugs when you are making hardware, because you assume software was written correctly.

 

On 7/25/2021 at 3:26 AM, Tony Cruise said:

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

Yes, actually, I have.  But, you decided to speculate again and answer the question rhetorically before waiting for an answer.

 

Have you tried building a piece of hardware for a retro computer, trying to make it work with an existing library of legacy software?

 

On 7/25/2021 at 3:26 AM, Tony Cruise said:

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.

How many titles is that, exactly?  Enumerate the list of broken games due to the last firmware release, and I'm sure Bmack will get things sorted out, including a firmware fix if necessary.

 

[matthew180]

On 7/24/2021 at 4:23 PM, 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

Based on those definitions I would say there are no retro-computer "emulators", only simulators.

 

I have also never found consistent definitions for the terms.  It is not black and white, and you can always come up with scenarios that will cause disagreement.

 

To me you have to include the medium, i.e. are you working with chips and electronics, or are you working purely in software?  Once you establish that, you then apply the word "software" or "hardware" as a prefix to "emulation" or "simulation".

 

In the case of the Phoenix, IMO, it falls into the "hardware emulation" category.  And, AFAIK there are no "software emulators" for the CV, although I have not done a code-review of any, I am making an assumption on how they are structured based on the code implementation of the "emulators" I have looked at.

 

Oh, and you also have to define "hardware", unfortunately.  There are transistors inside the chips, there are functional blocks inside the chips (the larger functionality created by the transistors), and there is the external functionality of the chip (i.e. a CPU ISA, external bus, etc.)

 

When talking about a CPU, every "emulator" I have looked at code for is actually "simulating" the ISA and external functional interface.  The only true software emulator I know of is the Visual6502 project, and I do not know of any software emulators written at the internal hardware functional-block level.

 

When working with something like an FPGA, you are emulating the internal functional blocks at a hardware level, using real chips with real transistors in them.  There is no "code execution" going on with an FPGA emulation...  And let's not blur the line where a soft-core CPU is put on an FPGA, and then a "simulator" is run on that soft-core.

 

[zaphro72]

On 7/21/2021 at 5:54 AM, Bmack36 said:

You can install core 8 on an old Phoenix, but there is potential that your TV might not like it. Worst case is you revert to 7 if it doesn't work. Just don't mess with the service core and it will be fine.

 

Not saying this is the case for cavern fighter but lots of CV games (even official ones) have issues that really shouldn't work or rely on dumb luck to work. One example is the Heist where it is reading in uninitialized ram and acting upon it when starting the game. Another example is Centipede where it is acting on the spinner input and the controller gets locked out of menu input due to the spinner being in a specific location (with stock CV and stock Super Action Controller)

@Milli Vee this briefly mentions what I was talking about on Facebook.