Jump to content
Bmack36

CollectorVision Phoenix Release Thread

Recommended Posts

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. 

Share this post


Link to post
Share on other sites
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.  

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites

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.  

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

  • Thanks 1

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

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

 

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

DSC04013.JPG

Share this post


Link to post
Share on other sites

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.   

Share this post


Link to post
Share on other sites

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.

 

DS1Z_QuickPrint1.thumb.png.597e5a4a35defeeb5810fd8c113f1b90.png     DS1Z_QuickPrint2.thumb.png.9c1f493b9499082f75418f78cc708626.png

 

Pin 7 ~3.25V with ~200mV magnitude noise

Pin 9 ~30mV with ~200mV magnitude noise

 

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

 

DS1Z_QuickPrint3.thumb.png.d0cc070aef51c55b41a4c05cd1f651b1.png   DS1Z_QuickPrint5.thumb.png.b61db0c7ee42fd41ac870f4826fd177b.png

 

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

 

DS1Z_QuickPrint4.thumb.png.0005fcf04cb1c8f072fab552806d03a8.png   DS1Z_QuickPrint6.thumb.png.8f6d3d97641714ef6b6f4fc1abeeadd3.png

 

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

 

 

  • Like 1

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