Jump to content
IGNORED

Cavern Fighter and Second Gen Phoenix issues


crisalan44

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.

 

Link to comment
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)

 

 :)

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

 

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

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

 

 

 

 

Link to comment
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.. :)

 

 

 

Link to comment
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 2
Link to comment
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...

 

 

 

Link to comment
Share on other sites

On 7/25/2021 at 12:58 AM, Tony Cruise said:

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.

No, there isn't. That is the point of random. It might be ANY value.

 

It is, and always has been, bad programming practice not to initialize your memory. This is called "uninitialized variables". Do you even know what value causes the effect you saw? Because only one bit is relevant there. Any one particular bit being set will be set for fully half the possible values - 128 out of 256 values in a byte!

 

As for CONTROLLER_INIT, the software needs to call it before using the functions that rely on it. Again, it is unreasonable to say "Hey, I don't have to initialize anything because I don't need to improve as a programmer." Your software landed in a new situation that it couldn't cope with because it took shortcuts. That's not my fault, but I not only had to spend hours figuring it out, now I have to argue with someone on the internet who is telling me, not once or twice, but over and over again, that his work is perfect and it's clearly my fault.

 

Your software failed to operate correctly due to uninitialized variables. This is not a new concept in software.

 

  • Like 1
Link to comment
Share on other sites

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

but setting the Ram to have all bits turned on; a real device would never be in that state.

You should stop saying that, because it's not true. All RAM is not set to 0xff.

 

The Phoenix BIOS code is fully open source. You could not only educate yourself before spreading untruths about what the BIOS does, you could submit the fix yourself.

 

  • Like 1
Link to comment
Share on other sites

On 7/25/2021 at 1:28 AM, youki said:

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.

Let's put it this way - when was the last time you saw a ColecoVision load software from an SD card (not counting add-on hardware). How many ColecoVisions output native HDMI audio and video? Can you plug a SNES controller into your ColecoVision? None of these things are even tangentially related to how the ColecoVision hardware works, yet they have to work on the Phoenix. This means that the memory system needs to be completely different, able to reconfigure itself to simulate different types of ROM cartridges. The video system operates at a completely different frequency and resolution, yet needs to appear to games to be completely original. And the SNES shift register needs to transparently look like two distinct banks of latched switches.

 

The Z80 and the SN are the closest to reproductions of the original hardware, since they don't need to do anything differently.

 

That said, the difference between emulation and simulation these days is pretty blurred. Emulators incorporate add-ons and need to interface with the host PC in order to function at all. Simulators need to emulate at least parts of the hardware. I already wrote a long blurb about this somewhere... ;)

 

  • Like 2
Link to comment
Share on other sites

8 minutes ago, Tursi said:

You should stop saying that, because it's not true. All RAM is not set to 0xff.

 

The Phoenix BIOS code is fully open source. You could not only educate yourself before spreading untruths about what the BIOS does, you could submit the fix yourself.

 

That is what Brian said it is doing.  But lets face it it is obviously doing something different from the previous firmware versions, as there are lots of games that have problems with it now.  All those games worked on the previous version.

Link to comment
Share on other sites

@Tony Cruise, let me offer one other suggestion as a peace offering.

 

Simply calling CONTROLLER_INIT doesn't guarantee that no other BIOS functions will fail due to uninitialized RAM. But the solution is simple - just zero all the RAM yourself in the CRT0. This guarantees that no matter the system, no matter if someone just pressed RESET (which of course otherwise leaves RAM how it was!), you always start with all the RAM zeroed. It only takes a few lines of assembly. Just put this as early as possible in your startup, before any C variable initialization (if your code does that):

	; clear RAM before starting
	ld hl,#0x7000			; set copy source
	ld de,#0x7001			; set copy dest
	ld bc,#0x03ff			; set bytes to copy (1 less than size)
	ld (hl),#0				; set initial value (this gets copied through)
	ldir					; do it

I think the odds are good this will cover it. For the Phoenix BIOS I had to trace all the initialization that the BIOS does when it's not skipped, since every byte mattered. It's not all zeros, but most of it is. That's in startTitle() in phoenixBoot.c, but the above should be sufficient for most cases, I would expect.

 

I see you've replied while I was typing this... :)

Link to comment
Share on other sites

16 minutes ago, Tursi said:

No, there isn't. That is the point of random. It might be ANY value.

 

It is, and always has been, bad programming practice not to initialize your memory. This is called "uninitialized variables". Do you even know what value causes the effect you saw? Because only one bit is relevant there. Any one particular bit being set will be set for fully half the possible values - 128 out of 256 values in a byte!

 

As for CONTROLLER_INIT, the software needs to call it before using the functions that rely on it. Again, it is unreasonable to say "Hey, I don't have to initialize anything because I don't need to improve as a programmer." Your software landed in a new situation that it couldn't cope with because it took shortcuts. That's not my fault, but I not only had to spend hours figuring it out, now I have to argue with someone on the internet who is telling me, not once or twice, but over and over again, that his work is perfect and it's clearly my fault.

 

Your software failed to operate correctly due to uninitialized variables. This is not a new concept in software.

 

Look mate I have already said, the not calling of that function was a misunderstanding of what was being called during BIOS start-up and it will be corrected in future titles and the downloadable content for my book and video series.  I am happy to learn and improve.

 

As I said in the other post it doesn't change the fact that my software (and quite a few others) worked on the version 7 firmware and don't now work on the version 8 firmware, so that is a reversion in the code i.e. it is a bug in the firmware compared to previous.

 

Almost every piece of software released has bugs, where things are missed, as it is simply not possible to test every scenario.  All we can do is learn and move on.

 

I will correct mine, but the firmware also needs to be corrected as well.  Every time I try to suggest that the answer is someone attacking back.

Link to comment
Share on other sites

3 minutes ago, Tony Cruise said:

Look mate I have already said, the not calling of that function was a misunderstanding of what was being called during BIOS start-up and it will be corrected in future titles and the downloadable content for my book and video series.  I am happy to learn and improve.

 

As I said in the other post it doesn't change the fact that my software (and quite a few others) worked on the version 7 firmware and don't now work on the version 8 firmware, so that is a reversion in the code i.e. it is a bug in the firmware compared to previous.

 

Almost every piece of software released has bugs, where things are missed, as it is simply not possible to test every scenario.  All we can do is learn and move on.

 

I will correct mine, but the firmware also needs to be corrected as well.  Every time I try to suggest that the answer is someone attacking back.

The issue is identified. Are we supposed to drop everything we're doing and run off to change our software to work around the bugs? %$@#%@#$ give it some time, man! ;)

 

Not all the attacks were aimed at you, as Youki suggested. There's a lot of software for the ColecoVision that seems rushed or has poor practices. They work, most of the time, but when you get to a system that's a little less random, if the init doesn't fit that "most" then it's an issue. Attacking Matt's skills is a bit out of line - I think developing a hardware VDP is at least as skilled as coding an 8-bit game. As a result of that sort of thing, emotions have run high. ;)

 

One other suggestion, if you really want to control the machine -- my personal suggestion is to move away from the BIOS. It's not very good code either, and you'll gain back some performance plus the freedom to use ALL the RAM however you want. None of the hardware in there is very complex, you can find examples of how to access everything* directly in my library here (and it's PD, so you can steal any parts you like): https://github.com/tursilion/libti99coleco

 

(* - everything stock, I haven't coded roller controller/spinner support or any add-ons there).

 

I hope at this point at least we understand each other! :)

 

Link to comment
Share on other sites

1 minute ago, Tursi said:

The issue is identified. Are we supposed to drop everything we're doing and run off to change our software to work around the bugs? %$@#%@#$ give it some time, man! ;)

 

Not all the attacks were aimed at you, as Youki suggested. There's a lot of software for the ColecoVision that seems rushed or has poor practices. They work, most of the time, but when you get to a system that's a little less random, if the init doesn't fit that "most" then it's an issue. Attacking Matt's skills is a bit out of line - I think developing a hardware VDP is at least as skilled as coding an 8-bit game. As a result of that sort of thing, emotions have run high. ;)

 

One other suggestion, if you really want to control the machine -- my personal suggestion is to move away from the BIOS. It's not very good code either, and you'll gain back some performance plus the freedom to use ALL the RAM however you want. None of the hardware in there is very complex, you can find examples of how to access everything* directly in my library here (and it's PD, so you can steal any parts you like): https://github.com/tursilion/libti99coleco

 

(* - everything stock, I haven't coded roller controller/spinner support or any add-ons there).

 

I hope at this point at least we understand each other! :)

 

Yep all good, no rush on the fix for the firmware, just some acknowledgement that there is an issue and it needs to be fixed (which you have now said is in progress) was all that seemed to be missing (and caused others to jump on the defensive).

 

I actually mostly use my own routines already, I only use the BIOS for controllers, the timer code (as it's not that bad) and the sound engine (they are alright, and a lot of the other engines use more ram - bar Berzerk that has it's own engine).  And I haven't run out of room in a 32k Rom yet.  I really need to think of game that needs a Super Game Rom, that would be cool.

 

While I have you what are your thoughts on the current accuracy of the sound emulation?  The only reason I mention this is the current voice samples in Berzerk (Note: same voice engine as used in Uridium) although by no means perfect, are understandable on real hardware and Blue MSX, but no were near as clear on CoolCV and the Phoenix.  This is only subjective, not totally evidence based at the moment (maybe some of us are getting old and a little deaf ;)).

On the original release firmware, only squealing seemed to be played, that has been fixed since, but do you think there is anything else that could be improved?

Link to comment
Share on other sites

3 minutes ago, Tony Cruise said:

While I have you what are your thoughts on the current accuracy of the sound emulation?  The only reason I mention this is the current voice samples in Berzerk (Note: same voice engine as used in Uridium) although by no means perfect, are understandable on real hardware and Blue MSX, but no were near as clear on CoolCV and the Phoenix.  This is only subjective, not totally evidence based at the moment (maybe some of us are getting old and a little deaf ;)).

On the original release firmware, only squealing seemed to be played, that has been fixed since, but do you think there is anything else that could be improved?

I haven't played Berzerk, but I thought it used the pitch-based playback system? It depends on which one it's doing. The pitch based system uses Artrag's system to convert speech data into 3 pitch channels for playback at 60hz or 120hz, allowing other gameplay at the same time. That should in theory "just work" as long as all the updates make it out in real time.

 

From your comment that it was squealing on the first release, that sounds like it uses the other method of setting a high frequency and modulating volume (which usually freezes other action to let the CPU dedicate itself to audio). I'm just going to straight up say that this is really hard for any reproduction to get right - hardware or software. The maximum output frequency of the SN sound chip in there is over 50Khz. The average sample rate of a software emulator is 44.1Khz (or maybe 48khz if it's more modern). The HDMI sample frequency I don't know offhand, I think it's one of those two as well. As you can see - neither of those is 50. To accurately reproduce a waveform digitally, your sample rate needs to be double the frequency you are sampling - so we'd need over 110Khz output to accurately reproduce this.

 

I'm not sure what CoolCV does. For Phoenix I believe they ('they' because I didn't do the HDMI) implemented the same system I put in Classic99 - that over a certain output frequency it fakes a DAC output instead. This removes the aliasing which is what causes the squeals, but of course it's not quite accurate (although it can sound quite good, since it also loses the carrier frequency). I remember we had to do that for Sewer Sam. The second issue is how well the volume modulation makes it into the output stream - that I don't know for either system.

 

I can't help much there though, I'm a software guy and not a FPGA guy, plus the output is limited to what the HDMI will carry, so it all has to play nice.

Link to comment
Share on other sites

1 hour ago, Tursi said:

Let's put it this way - when was the last time you saw a ColecoVision load software from an SD card (not counting add-on hardware). How many ColecoVisions output native HDMI audio and video? Can you plug a SNES controller into your ColecoVision? None of these things are even tangentially related to how the ColecoVision hardware works, yet they have to work on the Phoenix. This means that the memory system needs to be completely different, able to reconfigure itself to simulate different types of ROM cartridges. The video system operates at a completely different frequency and resolution, yet needs to appear to games to be completely original. And the SNES shift register needs to transparently look like two distinct banks of latched switches.

 

The Z80 and the SN are the closest to reproductions of the original hardware, since they don't need to do anything differently.

 

That said, the difference between emulation and simulation these days is pretty blurred. Emulators incorporate add-ons and need to interface with the host PC in order to function at all. Simulators need to emulate at least parts of the hardware. I already wrote a long blurb about this somewhere... ;)

 

i would have seen  HDMI support  , SNES Controller support more  or SD Card reader  more as an extension on the original hardware.  It is perfectly possible to build such of "extension" that would work on a real CV.

 

Link to comment
Share on other sites

55 minutes ago, Tursi said:

The issue is identified. Are we supposed to drop everything we're doing and run off to change our software to work around the bugs? %$@#%@#$ give it some time, man! ;)

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. 

 

Link to comment
Share on other sites

1 hour ago, Tony Cruise said:

The only reason I mention this is the current voice samples in Berzerk (Note: same voice engine as used in Uridium) although by no means perfect, are understandable on real hardware and Blue MSX, but no were near as clear on CoolCV and the Phoenix. 

From your Youtube videos, your Colecovision runs at 50hz.  Phoenix runs at 60hz(I not 100% sure if it can run at 50hz.).  So the voice sample play a bit quicker on the 60hz console.  I did use the freeze voice command for Vanguard because I wanted to have fun adding the voices to the game and the attempt to fill up 128KB cartridge, however I wasn't aware of Artrag's voice routine at the time. 

I think when he meant update fireware, I've wondered if it can patch individual game like init his games to 0x00.
 

1 hour ago, Tony Cruise said:

(maybe some of us are getting old and a little deaf ;)).

Oh I already got the hard of hearing thing when I was borned. ;)  

Link to comment
Share on other sites

7 minutes ago, Kiwi said:

From your Youtube videos, your Colecovision runs at 50hz.  Phoenix runs at 60hz(I not 100% sure if it can run at 50hz.).  So the voice sample play a bit quicker on the 60hz console.  I did use the freeze voice command for Vanguard because I wanted to have fun adding the voices to the game and the attempt to fill up 128KB cartridge, however I wasn't aware of Artrag's voice routine at the time. 

I think when he meant update fireware, I've wondered if it can patch individual game like init his games to 0x00.
 

Oh I already got the hard of hearing thing when I was borned. ;)  

Yeah my physical Colecovision is 50Hz, BlueMSX defaults to 60Hz.  The samples play well and don't slow the gameplay down.  I can hear the voices, but others can't understand them.

 

I have compressed everything in Berzerk down to 17.7k with the existing samples, so I was thinking of also including samples for the MSX/SGM graphics chip, if detected and they will be able to use the larger number of volume graduations and it will still fit in a 32k ROM.

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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