Jump to content

Bmack36

Members
  • Posts

    1,133
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Bmack36

  1. 9 hours ago, JOD-I said:

    I just got a SGM off of ebay and at first everything was great.  I followed the instructions in the instruction manual when it started not to work.  I did a diagnostic and it tells me that ram 0000H-1FFFH: ERRORS FOUND.  Is there nothing I can do?

    Are you using the Atarimax when you get the errors? Double check that the BIOS bypass is turned off by pressing the * key in the atarimax menu. 

    • Like 3
  2. 8 minutes ago, Nateo said:

    A while ago I built my own Coleco stick out of some arcade parts and a wooden project box from Michael's. It works great, but it lacks a keypad, but it given that its rarely needed (and the player 2 keypad works the same way for most titles) I didn't worry about it too much,

    But now that I'm home a lot more often and with considerably less plans, I decided to try to hand wire one with some switching diodes and some tact switches. 

    The keypad doesn't work. I followed the attached schematic I found through Google. I decided to open up one of my original ColecoVision controllers to see if there was something I may have neglected, and it appears to my eye that the schematic I used is wrong. The diodes on the actual circuit board appear to be facing the opposite direction. Is this in fact my problem? I just want to make sure I'm not replacing 22 or so diodes for nothing. 

    ColecoController.jpg

    The diodes are backwards on this schematic. Here is another one from ChildOfCV:

    StandardController.pdf

     

    • Like 1
  3. 1 minute ago, Swami said:

    When you said you didn’t have the peripheral to investigate this pin 7 issue, was that the super action controller or the roller controller, as both have issues that require having pins 7 and 9 operational. 

    I have all the peripherals. I think what I was saying is that I don't have a peripheral that has the actual error. My SAC, EM2, and roller controller do not show the noise or jumping issues some people have had. If I can't reproduce the error it makes it tough to address.

  4. 2 minutes ago, doubledown said:

    So just to clarify...with pins 7 & 9 socketed & fully populated at the cable connector, jumper them together (shorting them together) inside/at the controller, so that when plugged into the Phoenix console it's controller port pins 7 & 9 would be connected via a 20' loop of wire (in the case of a 10' cordset)?  Would this cause any issue if said controller was then used on an actual ColecoVision or ADAM?  What if this controller was then used on an Atari 2600...where pin #7 is +5V?  Is this a more robust/bulletproof option than simply just not installing a socket/wire at pin 9?  

    7&9 being tied together on a real Adam or CV would not be an issue as both are inputs.

     

    I guess I wasn't thinking about plugging the controller into other systems and you are right that it could cause problems that way. Not populating pins 7 and 9 would be better. It is also possible there could be some kind of firmware switch to disable the encoder inputs, but that would have to be looked into.

  5. 6 hours ago, doubledown said:

    So I think I've pretty much kept up with this thread...but I can guarantee that I probably haven't read every post, and if info has been discussed/discovered/announced elsewhere (other sites/forums)...I don't know anything about those so forgive me if this has been solved, and I missed it. 

     

    My question is concerning games freezing and/or console lock-up, seemingly when using a SAC or an Edladdin based controller with the Phoenix.  By Edladdin based controllers, I mean any ColecoVision controllers Ed has built, or those built by others (myself included) using his Easy CV I/O Board + Keypad.  I have in the past, personally experienced game/console lock-up, when playing Pac-Man Collection off of my SD card, and Gauntlet played via cartridge.  Recently when I built one of my new controllers whereas I used an original Coleco Hand Controller PCB donor for the wiring (not an Edladdin PCB), I assumed I wouldn't have any issues playing these games...but they locked up too.  So then I grabbed an actual Hand Controller and it played fine.  Fast forward to today and I wanted to try something to check this out more, and here is what I found.  

     

    Coleco Hand Controllers - factory controller cable's are 7 conductors and the end is pinned at 1,2,3,4,5,6,8 (not pinned at 7 or 9)

    Coleco S.A.C. - factory controller cables are 9 conductors and the end is pinned at 1,2,3,4,5,6,7,8,9

     

    When I've built controllers using Ed's PCB, I fully populated the connector, and soldered wires to each of the 9 pads on the PCB (as the instructions tell you to do).  Upon further examination (and Ed can verify this) it appears that contacts #7 & #9 on Ed's PCB aren't connected to anything, I assume they're just there as a landing point so that the wires're aren't loose; I never really looked at this before today.  When I build a custom controller using a Coleco Hand Controller PCB, and a 9-conductor cable that I buy in bulk, I only solder 7 wires to the PCB, 1-Brown, 2-Red, 3-Orange, 4-Yellow, 5-Green, 6-Blue, 8-Grey, but I crimp sockets on all 9 wires when I assemble the cable end. I like to leave the extra conductors in the cable end so that if there is a failure with 1 or 2 other conductors...the cable can still be salvaged, and I crimp the sockets on and insert them into spots #7 & #9 so they're not simply loose in the hood.  Then in the controller itself, I stagger the cut length of these 2 wires (black and white), and heat shrink them so they can't contact each other, or short out on anything else.  So in a test, literally 15 minutes ago, here is what I did, and what happened with 2 of my custom controllers using a Coleco Hand Controller PCB:

     

    So both were wired/socket at all 9 positions in the cable end, but 7-black, and 9-white were not connected to anything inside the controller...so basically all the console could have seen/detected on these 2 pins is 10' of wire length on each...connected to nothing, not even each other.  When I tried Pac-Man Collection off of my SD card...I could get the game/console to freeze/lock-up/emit solid tone, within about 5-6 seconds once I started an actual game of Pac-Man with either controller.  I then opened both of their hoods, pulled out the sockets/wires from position 7-black and 9-white, and tried again...and now I cannot get it to lock up.  Obviously minimal testing done...but these results lead me to this conclusion:

     

    if anything (even just a length of wire) is connected to pins #7 and/or #9, this feezing/lock-up, can/may occur.  I haven't yet tested just removing one of these at a time 7 or 9, I've done both each time...but I can/will try re-inserting one of them, and leaving the other out to see the results.  (by-the-by...I've only ever noticed this with modern homebrew games...never with any original games)

     

    Please don't get me wrong, I'm not carving this in stone, and/or saying this is the gospel...this is just what I've seen with about 10-15 minutes worth of testing.  

     

    So with all that said...am I insane, or has this issue (which when searching through this topic there are several posts discussing exactly this) been solved and I just don't know about it?

     

    FYI, here are screenshots of my firmware/cores to verify that I'm using the latest/greatest:

     

    pnHVYfqmj

     

    Riptrg.jpg

     

    I'd appreciate any info/comments/thoughts about this.  Has this been fixed...have/are others also experiencing this issue...and the likes.  

     

    **UPDATE**

     

    So I just did some more testing...and I can attribute the issue to pin #9 specifically.  So assuming automatically that pins 1,2,3,4,5,6,8 are wired at both the connector end, and internally to a PCB for controls, then:

     

    7 & 9 - sockets are present at the cable end - lock up will occur playing Pac-Man Collection from my SD card

     

    only 9 - socket is present at the cable end (7 was removed) - lock up will occur playing Pac-Man Collection from my SD card

     

    only 7 - socket is present at the cable end (9 was removed) - lock up does not occur playing Pac-Man Collection from my SD card

     

    neither 7 or 9 - sockets not present at the cable end - lock up does not occur playing Pac-Man Collection from my SD card

    This is an issue. Easy way to fix is to jumper pins 7 and 9 in the controller, which should resolve the issue since those lines aren't being used anyways with that board (or any custom board like that which doesn't include spinner hardware).

  6. 3 hours ago, wileyc said:

    Hello Brian,

     

    I see that you've been active on AtariAge rather frequently in the past few days, and thus I assume that you've had time to read my response.

     

    Is the HDMI issue I reported considered valid?  If so, is it going to be investigated and (hopefully) fixed?  If not, why not?

     

    Thank you in advance for your response.

    Some changes were made in preparation for the next rev of the board, which shouldn't have an effect on the video output. Thank you for the report. There are still major changes to come with the video output and fixing the pixel clock so we will see what happens when those changes get implemented.

    • Like 3
  7. 2 hours ago, wileyc said:

    HDMI regression from version 6:

     

    * video no longer stable; vertical jitters and sporadic loss of video signal,

    * red pixels appear and disappear randomly on screen.

     

    Video signal from service menu is unaffected.  Reverting to version 6 fixes signal issue.

    What make and model tv are you using?

  8. 5 minutes ago, retrorgb said:

    Just updated that too.  It was never intentionally omitted...I remember writing the posts promoting your kickstarter and thinking I'd add it after it went on sale to the public, but then every time I went to the site, it was out of stock.  LOL, it still shows out of stock though...

    No worries, I was just messing around. Thanks for the update.

    Yeah we closed the last batch of pre-orders earlier this month for the next production run.

×
×
  • Create New...