CollectorVision Phoenix Release Thread

[Swami]

6 hours ago, doubledown said:

I have not yet tested a Roller Controller, S.A.C. or EM#2 on my Phoneix.  Maybe I'll try to test them this weekend to see what I find out with my unit.  As of now the issue I'm seeing is apparently something transient getting picked up on controller port pin 9, when a length of wire is connected to it, and said length of wire is seemingly acting as an antenna.  

I have mentioned this before so I’ll just briefly say that I saw the jumping once or twice a minute on slither, Armageddon and turbo with RC and EM2. However, I did not see the jumping with an Atari ST to USB mouse I rigged to be compatible. Removed due to less cord or Schmidt Triggers, etc in adapter?

5 hours ago, zaphro72 said:

Have you played centipede off SD card with roller controller? I tried but it kept freezing or resetting to skill level select screen on me.

 

I do see the jumping a bit even on the menu where I can pick games from sd card

Surprised there are issues in joystick mode, but maybe the fact the roller controller still requires pin 9 to be connected in joystick mode makes it act similar to the Edladdin devices/Super action controllers that require pin 9 to be connected. 

[doubledown]

31 minutes ago, Swami said:

Surprised there are issues in joystick mode, but maybe the fact the roller controller still requires pin 9 to be connected in joystick mode makes it act similar to the Edladdin devices/Super action controllers that require pin 9 to be connected. 

I believe it is having "something, anything" (a conductor/wire acting as an antenna) connected to pin 9 and nothing else that is a definite problem.  To make this clear, and Ed can verify his products better than I, but any "Edladdin" device, meaning a controller built by anybody with one of his boards...that has the 9th wire in the cable, connected at the socket end (at the console), this causes the problem, acting as an antenna or something (lack of better terminology).  While his PCB has connection points for all 9 wires...7 & 9 have no traces to anything on his board...simply a landing point via solder pad and a thru-hole solder point.  So it's not that his board is any sort of problem, its if the cable being used has wire/socket #9 connected at the connector.  Like I said, I build my own cables from bulk cable purchased, and then all of the end pieces with crimp on sockets...so I can simply choose to no longer crimp a socket on the white wire (#9), and anybody who has purchased a controller from me, who has experienced issues if used on their Phoenix, can open the hood, and cut the socket off...and it should take care of the problem.  Again this is all early in the testing phases...but it's all pretty repeatable/predictable with the testing I did last night.  

[Swami]

51 minutes ago, doubledown said:

I believe it is having "something, anything" (a conductor/wire acting as an antenna) connected to pin 9 and nothing else that is a definite problem.  To make this clear, and Ed can verify his products better than I, but any "Edladdin" device, meaning a controller built by anybody with one of his boards...that has the 9th wire in the cable, connected at the socket end (at the console), this causes the problem, acting as an antenna or something (lack of better terminology).  While his PCB has connection points for all 9 wires...7 & 9 have no traces to anything on his board...simply a landing point via solder pad and a thru-hole solder point.  So it's not that his board is any sort of problem, its if the cable being used has wire/socket #9 connected at the connector.  Like I said, I build my own cables from bulk cable purchased, and then all of the end pieces with crimp on sockets...so I can simply choose to no longer crimp a socket on the white wire (#9), and anybody who has purchased a controller from me, who has experienced issues if used on their Phoenix, can open the hood, and cut the socket off...and it should take care of the problem.  Again this is all early in the testing phases...but it's all pretty repeatable/predictable with the testing I did last night.  

Why does my rigged up Atari ST to USB mouse not show jumping? Either the 2 foot cable or noise filter in the adapter must fix it. Of course I can’t test PMC with this hooked up, just jumping in RC games. 

 

Also, some bought directly from Edladdin have the rotate buttons for pin 9 and 7, like the spinner on the super action controller, so that would provide a quandary. But that has nothing to do with the ones you build.  

 

I think i will see if ferrite clamps on the cable help. 

[doubledown]

Ok, so I just tested my Roller Controller, and Expansion Module #2 with my Phoenix:

 

With Expansion Module #2:

 

I played Turbo - from the SD card...and I saw no issues.  It played just fine, and just as it should.

 

I played Destructor - from the SD card...and I saw no issues.  It played just fine, and just as it should.

 

With Roller Controller:

 

In Joystick Mode - in the SD card menu, when using controller 1's joystick to navigate through the SD card menu...I would press down once, and that moved me down 1 game in the list.  But then maybe the next time I press down once...it jumped down 3 lines.  Then 1 line, 1 line, then 3 lines again, so on, and so forth.

 

...but when in Roller Mode - this line-jumping phenomenon does not happen...press down once on the controller's joystick, and I move down 1 game in the list, repeatably.

 

Playing Centipede from SD card - in Joystick Mode...I saw no issues.  It played just fine, and just as it should.

 

Playing Armageddon from SD card - in Roller Mode...my on-screen cursor would, every so often...just jump across the screen.  

 

Playing Slither from SD card - in Roller Mode...my on-screen character would, every so often...just jump across the screen.

 

Also remember...I'm wasn't saying this Pin 9 issue I'm looking at is causing "jumping" with a non-joystick controller...I'm seeing the problem of the Phoenix console flat out locking up and emitting a solid steady tone...to where it has to be reset.  Not to say they're not related, but I didn't know anything about this jumping until now...as I hadn't used any type of specialty controller with my Phonenix until tonight.  

[Swami]

On 8/7/2020 at 7:09 PM, doubledown said:

Ok, so I just tested my Roller Controller, and Expansion Module #2 with my Phoenix:

 

With Expansion Module #2:

 

I played Turbo - from the SD card...and I saw no issues.  It played just fine, and just as it should.

 

I played Destructor - from the SD card...and I saw no issues.  It played just fine, and just as it should.

 

With Roller Controller:

 

In Joystick Mode - in the SD card menu, when using controller 1's joystick to navigate through the SD card menu...I would press down once, and that moved me down 1 game in the list.  But then maybe the next time I press down once...it jumped down 3 lines.  Then 1 line, 1 line, then 3 lines again, so on, and so forth.

 

...but when in Roller Mode - this line-jumping phenomenon does not happen...press down once on the controller's joystick, and I move down 1 game in the list, repeatably.

 

Playing Centipede from SD card - in Joystick Mode...I saw no issues.  It played just fine, and just as it should.

 

Playing Armageddon from SD card - in Roller Mode...my on-screen cursor would, every so often...just jump across the screen.  

 

Playing Slither from SD card - in Roller Mode...my on-screen character would, every so often...just jump across the screen.

 

Also remember...I'm wasn't saying this Pin 9 issue I'm looking at is causing "jumping" with a non-joystick controller...I'm seeing the problem of the Phoenix console flat out locking up and emitting a solid steady tone...to where it has to be reset.  Not to say they're not related, but I didn't know anything about this jumping until now...as I hadn't used any type of specialty controller with my Phonenix until tonight.  

I tried the ferrite bead clamps on the roller controller cable tonight for the Phoenix. I put one (5mm) next to each port connector, one each a little farther up near the joint, one larger one (11mm) next to the joint and where it leaves the roller controller...and...no difference. Still get a hyperspace like jump in Slither and Armageddon every 1 to 2 1/2  min. Also, spinning the trackball very fast will frequently do it as well. I get the feeling it may be mistaking noise spikes for signal and a low pas filter or Schmitt trigger may fix it, but I don't know how to make one specifically for this. I'll try the Edladdin SAC+ this weekend with the ferrite beads on early Opcode games just to be thorough.

[Swami]

So, my next attempt with the Roller Controller/Super Action Controller issue will be to try a DB9 EMC filter from 

https://www.camiresearch.com/connector-protector.html

 

i tried talking to tech support there but the guy seemed to think it was a bad cable or connector or needed a gold plated pin connector, but that doesn’t really add up since it works with a standard ColecoVision. 

[Bill Loguidice]

5 minutes ago, Swami said:

So, my next attempt with the Roller Controller/Super Action Controller issue will be to try a DB9 EMC filter from 

https://www.camiresearch.com/connector-protector.html

 

i tried talking to tech support there but the guy seemed to think it was a bad cable or connector or needed a gold plated pin connector, but that doesn’t really add up since it works with a standard ColecoVision. 

It's definitely not your controllers as it happens to others of us with controllers that work perfectly on original ColecoVision/Adam hardware. I'll be interested to hear your results with the filter.

[doubledown]

2 hours ago, Swami said:

So, my next attempt with the Roller Controller/Super Action Controller issue will be to try a DB9 EMC filter from 

https://www.camiresearch.com/connector-protector.html

 

i tried talking to tech support there but the guy seemed to think it was a bad cable or connector or needed a gold plated pin connector, but that doesn’t really add up since it works with a standard ColecoVision. 

I'd be skeptical of this helping at all with the problem, but give it a shot and let us know.

[zaphro72]

The Hanimex Pencil II core for the Phoenix was posted on Facebook Collectorvision Phoenix page. I assume eventually it will make it's way here too.

[Swami]

On 8/28/2020 at 3:22 PM, doubledown said:

I'd be skeptical of this helping at all with the problem, but give it a shot and let us know.

Well, no effect from the filters, but I don't have an oscilloscope, ect, to analyze what is going on as the difference between the Roller Controller and the SmalleyMouse2 adapter, so figured it was better than nothing. Here is what Waiting For Friday, creator of the Smalleymouse2 adapter has to say on the subject.

 

Limiting the quadrature rate

With 8-bit retro computers it was possible to move the mouse faster than the host computer could detect – this would cause spurious updates with the mouse pointer seeming to bounce around the display.  SmallyMouse2 contains a rate limiting algorithm that prevents the device from overrunning the host computer.  Two definitions in the firmware control this, namely Q_RATELIMIT and Q_BUFFERLIMIT.  The rate limit sets the maximum frequency of the quadrature output generated by SmallyMouse2 and is specified in Hertz (i.e. the number of quadrature signals per second).  This prevents the device from outputting faster than the 8-bit host can count.  Since there is only a limited time between USB reports, any extra position updates that cannot be sent to the host will be lost.  The buffer limit parameter specifies how much overrun should be allowed before updates are disregarded.  By altering these two parameters it is possible to tune the quadrature output for a specific computer.  By default, the firmware provides a ‘safe’ value that should work with a wide-range of machines.

The Q_RATELIMIT is only applied to the output when the ‘slow’ configuration header is shorted (i.e. a jumper is placed on the 2 pin header).  The Q_BUFFERLIMIT is always applied; however, this should have no effect if the slow configuration header is open (as the normal output rate should allow the output to keep up with the USB reports).

[zaphro72]

Has anybody else tried Chuck Norris Super Kicks on your Phoenix? All I am getting is a black screen off the Phoenix SD card, but it works off AtariMax? It works for @Bmack36 and he tried to help me but we had no luck on Rev 7 or Rev 6. Wondering if anyone else is having the issue.

[Ikrananka]

3 minutes ago, zaphro72 said:

Has anybody else tried Chuck Norris Super Kicks on your Phoenix? All I am getting is a black screen off the Phoenix SD card, but it works off AtariMax? It works for @Bmack36 and he tried to help me but we had no luck on Rev 7 or Rev 6. Wondering if anyone else is having the issue.

Works fine for me both from the SD card and also with an original cart.  Tried it with both Rev 6 and 7 cores.  Try the attached rom as this is the one from my rom dumping project and works for me.

Chuck Norris Superkicks.rom

[Ikrananka]

On 7/21/2020 at 9:34 PM, Bmack36 said:

New Firmware release for CV core (Rev7) in first post

 

-Re-written SN and AY sound modules

-Fix for early Opcode games (Magical Tree, Road Fighter, and sky jaguar)

I finally got time to update my Phoenix and try out MT, RF and SJ and they work great - thank you ?

 

Unfortunately, I found another issue with one of Opcode's early games, namely Space Invaders Collection.  I hadn't play tested this on the Phoenix before other than to check the attract mode and menu worked - which they do.  However, if one tries to start a one player game (after pressing # to add credits) it either immediately freezes or just resets after pressing 1 on the keypad.  If you try and play a two player game the game will start but if one presses * to pause the game and then * to unpause the game it then immediately either freezes or resets.  This behaviour occurs with both the original cart and the game rom from the SD card.  The issues are the same with core Rev 6 and Rev 7.  I'll add this to the GitHub as an issue shortly.

[Bmack36]

8 minutes ago, Ikrananka said:

I finally got time to update my Phoenix and try out MT, RF and SJ and they work great - thank you ?

 

Unfortunately, I found another issue with one of Opcode's early games, namely Space Invaders Collection.  I hadn't play tested this on the Phoenix before other than to check the attract mode and menu worked - which they do.  However, if one tries to start a one player game (after pressing # to add credits) it either immediately freezes or just resets after pressing 1 on the keypad.  If you try and play a two player game the game will start but if one presses * to pause the game and then * to unpause the game it then immediately either freezes or resets.  This behaviour occurs with both the original cart and the game rom from the SD card.  The issues are the same with core Rev 6 and Rev 7.  I'll add this to the GitHub as an issue shortly.

It seems to run fine on mine with Rev7. Which controller are you using?

[zaphro72]

48 minutes ago, Ikrananka said:

I finally got time to update my Phoenix and try out MT, RF and SJ and they work great - thank you ?

 

Unfortunately, I found another issue with one of Opcode's early games, namely Space Invaders Collection.  I hadn't play tested this on the Phoenix before other than to check the attract mode and menu worked - which they do.  However, if one tries to start a one player game (after pressing # to add credits) it either immediately freezes or just resets after pressing 1 on the keypad.  If you try and play a two player game the game will start but if one presses * to pause the game and then * to unpause the game it then immediately either freezes or resets.  This behaviour occurs with both the original cart and the game rom from the SD card.  The issues are the same with core Rev 6 and Rev 7.  I'll add this to the GitHub as an issue shortly.

Ya no issues with this on my side

[zaphro72]

2 hours ago, Ikrananka said:

Works fine for me both from the SD card and also with an original cart.  Tried it with both Rev 6 and 7 cores.  Try the attached rom as this is the one from my rom dumping project and works for me.

Chuck Norris Superkicks.rom 16 kB · 2 downloads

In an interesting turn of events Chuck is now working on my Phoenix off SD with rom’s it didn’t work with earlier with me doing nothing different other than playing games off the atarimax in between

[Ikrananka]

1 hour ago, Bmack36 said:

It seems to run fine on mine with Rev7. Which controller are you using?

Now this is interesting.  I was using a standard ColecoVision controller and this works fine with other games I have been playing/testing.  Seeing as you mentioned the controller I tried a different standard CV one and with this Space Invaders works fine - none of the issues I listed.  However, switching back to the other controller and I get the issues with Space Invaders again.  So, does this mean that the Phoenix is more sensitive to controller response/timing than an original CV?

[Bmack36]

The Phoenix appears to be more sensitive to noise on the encoder lines. Was the standard cv controller that is messing up a SAC. If the spinner is in a particular orientation it can cause issues in some games. Has the cable been replaced on the one that is messing up? It could be that that controller has all 9 wires running through it with pin 9 not hooked up to anything and it is picking up noise.

[Ikrananka]

11 hours ago, Bmack36 said:

The Phoenix appears to be more sensitive to noise on the encoder lines. Was the standard cv controller that is messing up a SAC. If the spinner is in a particular orientation it can cause issues in some games. Has the cable been replaced on the one that is messing up? It could be that that controller has all 9 wires running through it with pin 9 not hooked up to anything and it is picking up noise.

It's just a standard stock black CV controller, not a SAC.  I've had this one for decades and when I got it someone had replaced the joystick with one of the aftermarket ball tops from back in the day - not one of the more recent mods.  So, while it has been meddled with at some point many years ago, it has been my main CV controller and has worked flawlessly.  That said, it is starting to become a little unresponsive so I'll throw that out there.  The problem with this controller and the Phoenix seems to be when using the keypad.  I'll do some more testing of the keypad specifically both with a ColecoVision and my Phoenix and will report back.

 

I could takes some oscilloscope readings of the keypad presses if that helps.  Perhaps this is related to the early Phoenix CV core keypad bounce issue that was later fixed.

[Ikrananka]

4 hours ago, Ikrananka said:

It's just a standard stock black CV controller, not a SAC.  I've had this one for decades and when I got it someone had replaced the joystick with one of the aftermarket ball tops from back in the day - not one of the more recent mods.  So, while it has been meddled with at some point many years ago, it has been my main CV controller and has worked flawlessly.  That said, it is starting to become a little unresponsive so I'll throw that out there.  The problem with this controller and the Phoenix seems to be when using the keypad.  I'll do some more testing of the keypad specifically both with a ColecoVision and my Phoenix and will report back.

 

I could takes some oscilloscope readings of the keypad presses if that helps.  Perhaps this is related to the early Phoenix CV core keypad bounce issue that was later fixed.

Okay, I did a bit more testing with two different controllers (i) the one that the Phoenix doesn't like with Space Invaders (let's call this the "wonky" one) and (ii) one that works with the Phoenix and Space Invaders (let's call this the "good" one).  This is what I'm observing:

 

Original CV

 

Space Invaders - both controllers and their keypads work perfectly with the game.  No issues.

 

Nuvatec Super Action Joystick Test program - both controllers respond perfectly including the fire buttons and all keypad buttons.  Spinner indications stay at 000.

 

Phoenix

 

Space Invaders - as reported previously the "wonky" joystick causes one player games to either freeze or the game to reset.

 

Nuvatec Super Action Joystick Test program:

1. As soon as the program starts it registers that both left and right fire buttons, for the joystick in port 1, have been pressed even though they haven't, i.e. the symbols for F1 and F2 disappear.  This happens for both of the controllers I tested and does NOT occur on a real CV.
2. Pressing the keypad buttons on the "wonky" joystick (in both port 1 and port 2) shows that they are registered correctly.  However, and this is I suspect the problem when pressing the keypad buttons, occasionally the Spinner indication registers a value.  This does NOT happen with this joystick on a real CV.  This also does not happen with the "good" joystick on the Phoenix.

Could the above be related to the keypad debounce code that was introduced a while ago and not necessarily noise?  I'd be happy to test some variations of the core if that would help.

 

[Tursi]

The issue is likely the spinner hits, you want to try and figure out why those are happening. While Phoenix seems more sensitive there than a real CV, since you have a reproducible case with two controllers - one that works as expected and one that doesn't - any data specific to differences there would be helpful.

 

The reason it's a problem is that the spinner causes interrupts to the CPU. If the cartridge doesn't define a valid vector to handle that interrupt, and interrupts are enabled (a combination of cases that is true on a lot of titles), then on an input pulse the software will jump to a (pseudo-) random vector, and more often than not crash. With a real spinner this can happen even if you don't spin the wheel, depending on the position it's in (the interrupt can be triggered by switching to keypad in that case). On some titles simply having the spinner in the right place will cause the software to think a key is held down and leave you stuck on the title page. This /is/ visible on a real Coleco with the Super Action Controller (I think it was Centipede we reproduced it on).

 

What shouldn't happen are SAC pulses when nothing is wired up to those pins, so it'd be interesting to see whether your "wonky" joystick is doing something interesting there. We're looking at pins 7 and 9, with particular interest to anything on pin 9, which triggers the interrupt. For data's sake, anything from "is it connected in the cable?", which would suggest an antenna-like run, to "is it shorting to something in the controller?" (Though I'd expect a short to affect the real Coleco too...). If your test software there shows the 8 bits back from the controller, you want to be watching the bits for 0x80 (which is the opposite end of the byte from stick UP), and 0x20. (All based on my notes anyway...)

 

If you have a real SAC, you can also try Space Invaders on real hardware with that, and give the spinner a spin to see if it's tolerant. I don't have that software to test.

 

[Ikrananka]

1 hour ago, Tursi said:

The reason it's a problem is that the spinner causes interrupts to the CPU. If the cartridge doesn't define a valid vector to handle that interrupt, and interrupts are enabled (a combination of cases that is true on a lot of titles), then on an input pulse the software will jump to a (pseudo-) random vector, and more often than not crash. With a real spinner this can happen even if you don't spin the wheel, depending on the position it's in (the interrupt can be triggered by switching to keypad in that case). On some titles simply having the spinner in the right place will cause the software to think a key is held down and leave you stuck on the title page. This /is/ visible on a real Coleco with the Super Action Controller (I think it was Centipede we reproduced it on).

 

If you have a real SAC, you can also try Space Invaders on real hardware with that, and give the spinner a spin to see if it's tolerant. I don't have that software to test.

Thanks for the explanation, I'm trying to learn more about this kind of thing so that information is really appreciated.  So, I tried a real SAC on real hardware with Space Invaders.  When I spin the spinner the game does indeed freeze or causes other odd behaviour so the game is definitely not tolerant of the spinner.  As you suspected this is the most likely explanation as to why my "wonky" controller has a similar effect with Space Invaders on the Phoenix.

 

1 hour ago, Tursi said:

What shouldn't happen are SAC pulses when nothing is wired up to those pins, so it'd be interesting to see whether your "wonky" joystick is doing something interesting there. We're looking at pins 7 and 9, with particular interest to anything on pin 9, which triggers the interrupt. For data's sake, anything from "is it connected in the cable?", which would suggest an antenna-like run, to "is it shorting to something in the controller?" (Though I'd expect a short to affect the real Coleco too...). If your test software there shows the 8 bits back from the controller, you want to be watching the bits for 0x80 (which is the opposite end of the byte from stick UP), and 0x20. (All based on my notes anyway...)

Unfortunately, I don't have any test software that shows the 8 bits back from the controller.  What I will do is dismantle the joystick and check the wiring to verify if anything is directly connected to, or shorted to, pins 7 or 9.  I'll report back soon.

[Ikrananka]

1 hour ago, Ikrananka said:

Unfortunately, I don't have any test software that shows the 8 bits back from the controller.  What I will do is dismantle the joystick and check the wiring to verify if anything is directly connected to, or shorted to, pins 7 or 9.  I'll report back soon.

Okay, looks like we've got some answers.  The "wonky" joystick has 9 wires in the cable and has 9 female metal connections in the DB9 jack.  There are two wires installed, and soldered to the PCB, for the non-existent spinner.  In this case they are white and violet wires.  I wondered if desoldering them would help so I did this and tested the joystick on my Phoenix but the problem with Space Invaders persists.  So, it must be as you suggested, an antenna (inductance?) effect.  Is there a way to eliminate the Phoenix's sensitivity to these effects?  I suspect the only solution from a joystick perspective is to replace the entire cable and DB9 with one that only contains the required 7 wires and connections.

 

The "wonky" one looks to be an older joystick as the PCB is Rev. E compared to the Rev. G of the "good" 7 wire joystick.  Strangely they both have the traces and markings for the non-existent spinner!

[HDTV1080P]

With a firmware update the DB9 jack can be disabled or re-enabled, wouldn’t it be possible to disable individual pins on the DB9 jack with a firmware update? Just disable the pins on the DB9 jack that are causing the problem and re-enable all pins on the DB9 when used with other controllers. Make a menu option in the BIOS to turn off certain pin numbers when used with certain controllers.   

[Ikrananka]

Thought it might be useful to illustrate the magnitude of the noise on pins 7 and 9 that is induced when a keypad button is pressed on my 9 wire "wonky" joystick (white and violet wires still desoldered from the controller PCB). 

 

"Good" Controller - Pins 7 & 9 (respectively)

 

First, here are baseline readings for pins 7 and 9 with my "good" 7 wire controller connected, i.e. absolutely nothing connected to pins 7 and 9 on the Phoenix so the noise here must be from the Phoenix.

 

     

 

Pin 7 ~3.25V with ~200mV magnitude noise

Pin 9 ~30mV with ~200mV magnitude noise

 

"Wonky" Controller - Pins 7 & 9 (respectively) - Joystick/Keypad Inactive

 

   

 

Pin 7 ~3.3V with ~2V magnitude noise (so noise magnitude is MUCH greater and shape and nature of the noise is distinctly)

Pin 9 ~400mV (but with a curious shape) with ~1.5 to 2V noise (so noise magnitude is MUCH greater and shape and nature of the noise is different)

 

"Wonky" Controller - Pins 7 & 9 (respectively) - Keypad Button Pressed

 

   

 

Pin 7 ~3.3V with ~2.5V magnitude noise (pressing the keypad the magnitude of the noise increases which I guess confirms inductance from the other wires)

Pin 9 ~850mV(avg) with ~2.5V noise (pressing the keypad the magnitude of the noise increases and the nature/shape of the waveform changes - again I guess confirms inductance from the other wires)

 

Conclusion

 

I can clearly see an effect on the noise and it's magnitude when I press a keypad button with my 9 wire "wonky" controller.  In fact just plugging this in dramatically changes the waveform and noise on pins 7 and 9 and also increases the voltage level of pin 9 before a keypad is even pressed (compared to my 7 wire "good" joystick).