Jump to content

Stephen Moss

Members
  • Content Count

    1,185
  • Joined

  • Last visited

Community Reputation

186 Excellent

About Stephen Moss

  • Rank
    Stargunner
  • Birthday 12/20/1970

Profile Information

  • Gender
    Male
  • Location
    Cambridge, United Kingdom
  • Interests
    American Football, Golf, Electronics, Programming, Sci-Fi, Indoor Climbing
  1. Seem to me to be a lot of engineering overkill for something that is just a potentiomer and a switch and I don't think that what you want to do is possible, at best it is very difficult as it is an entirely different proposition to your MAME/Stella controller which is still just reading a USB mouse and is already coded to convert the mouse data to a relevant value using the PC's native USB host controller, OS host software and Mouse Driver. You may find examples of using the Arduino's & Pi's as USB slave devices but finding examples of USB host probably don't exist as making a host in much harder than a slave so not many (if anyone) makes DIY USB host devices. 1) I think you will need to write your own USB host controller code & mouse driver (which is where the difficulty lies), certainly for the Arduino as the Pi must already have that for using keyboard & mouse but I don't know how you would tap into the data on the Pi as it may only be accessible by the OS. 2) There is no USB A port to plug the mouse into on the Arduino, only a USB B as it is a slave device. You can add one but being more of a children's toy rather then something for real engineering to my I don't think the micro-controller devices on the Arduino have USB OTG capabilities and the on board USB interface chip is configured to make the Arduino appear to the PC as a serial port slave. Even if you could reprogram the on board USB interface device to host you then would not be able to program the Arduino so you would need a USB OTG device for the mouse. 3) As I recall USB mice provide relative data, i.e. how far it was moved in the X & Y directions as a signed 8 bit integer which would be difficult to convert to a relative value. I would assume that you would need to divide the mouse value by say 10 to get a usable scale otherwise you would only get max L & R, use the sign as direction (L or R) relative to current position. 4) If you could do all the above there is no simple way to recreate a potentiometer. There are digital pots but they tend to be double ended (5 & 0V) and you need single ended (just 5V), you could use a motor to turn an physical pot but then why not just do that to begin with as it is much simpler than faffing about with Arduino's & Pi's. But if you did get this far the better options would probably be to convert the position value to an analogue voltage & either feed it in via a fixed resistor or to the GATE of an FET (source to 2600 input, Drain to 5V) so the varying voltage (instead of varying resistor) adjusts the current charging the capacitor.
  2. Albert & Tempest... Did you try slowly flexing the output cable? If you keep folding it in the same way when you pack it away the constant flexing at the same point can break the cables creating an open circuit, resulting in either no voltage if either power or power and ground have gone or result in an odd voltage reading if just ground has gone or a power ground short has occured. If that is the problem slowly flexing the cable may reveal that as the problem as power suddenly returns and also enable you to identify the location of the break which if not right at the connector or strain relief should allow you to cut out the damaged section and reconnect the two pieces to get it working again (just make sure you connect them with the correct polarity). Sometimes rechargeable batteries are a little shorter than standard alkaline's in the same way the Duracell are generally a little larger them other alkaline's, if you have a good spiral spring at the ground connection it can push them forward enough to ensure correct contact. if not you might find that it looks OK but there is actually is a small gap, measuring across the batter holder contacts should tell you if that is the case as if they are making contact you should be able to measure voltage there.
  3. There are others here who know more about how the Jaguar operates than I, however as I understand it the BIOS checks the cartridge encryption and if it passes you get the standard boot screen with the tumbling letters and if not the RSOD with just the growl. If you are just getting the growl without the tumbling letter sounds it's possible you are getting the RSOD you just can't see it because there is not video output. I assume you have tried cleaning the cartridge contacts as well as those of the cartridge socket, Make sure the cartridge it seated level, when I first got my Jag it did not work and think it was because I was using one hand to insert the cartridges, getting them on a slight angle that may have been enough to prevent contact on a couple of pins and loss of data but it has been fine ever since. And make sure to insert it past the bump. It probably won't make any difference but try it without any controllers connected. If you are using a S-video or SCART cable try RF. If you only have one cart and can pick up another cart cheaply try that in case the problem is with the cart.
  4. I agree. Perhaps it is just an omission in the breadboard layout image but I noticed that there is no link at the centre of the power rails. Maybe it is not required on your by breadboard as I cannot see how anything would have worked otherwise but most breadboards I have come across the all the power rail holes on the left and right halves are connected together but the left and right each halves are not connected together- might be something worth checking if you don't already know they are linked. I managed to simulate it in Protues, as far as I could see the data being clocked out was fine, but the ACK pulse wasn't. With the original 22K for R1 the required clock speed was too fast for C1 to discharge low enough to produce a pulse, reducing the clock speed by a factor of 10 did allow it to discharge enough to produce a horrid looking pulse that was all over and undershoot. Not sure how helpful that is as it depends on how much faith your put in circuit simulators. Personally, I find digital simulation is good but analogue is utterly wrong (at least they always indicate none of my perfectly good circuits work).
  5. The data looks correct, I am not sure where you have put your LED but I would have placed it between either QH (9) pin of U1 or the 2Y1 (5) pin of U6 and Ground so that 1 = On. I wonder if the ACK signal is the problem I will see if I can simulate the circuit as I think the CR times may not be correct but it may take a few days as Proteus is a pain in the ass.
  6. Bits are clocked out of the 74HC164 in the order H-A, the PlayStation SPI bus is Least Significant Bit (LSB) first so for a data byte B7 (MSB) to B0 (LSB), B0 goes to H and B7 goes to A so that is is clocked out LSB first. You don't need a NOR gate for the logic probe, you could just use the resistors & LED's but having an isolating logic gate is a good idea, a couple of NOT gates or an AND with both inputs tied together would work just as well.
  7. It depends on if the noise is being radiated or transmitted down the power cable. If it is being transmitted then a 0.1uF (100nF) ceramic disc across the 2200uF smoothing cap may help decouple the noise, or if you can find a small 100Hz low pass filter to fit between the PSU output and the 2200uF capacitor that may help. If it is being radiated you need to determine if it is affecting the signal as it is being generated within the 2600 or if the display is picking it up. The latter can be checked by displaying a signal from another source and turning the power unit on, if you notice interference then it is being radiated (probably in contravention of regulations). In which case nothing you do to the 2600 will have any effect, moving the power unit away the the display or putting it inside a metal box may help.
  8. You do not have to use pull up or down resistors on fixed state inputs, it should not affect operation if you do, personally I just connect them directly to VCC & GND as applicable. You say you have corrected the logic state for U2 & U3 are the indicated new states... [U2] 0100 0001 (LHLLLLLH) [U3] 0101 1010 (LHLHHLHL) written in the same orientation as the pins in your circuit diagram (H to A) when read from left to right? If so then you have then you have the states for U2 back to front and are sending a controller ID of 82 which the PlayStation would no recognise and so probably terminate communications, try changing U2 to 1000 0010 (HLLLLHL) and see if that makes a difference (see post 4 above for pin by pin connection listing). If that still does not work and you have space on your bread board then making a logic probe like this may help you solve the problem, any 2 input NOR will do and just change the resistors to 330 Ohm for a 5V supply. Alternatively, put an LED and 300 Ohm resistor between ground and the the QH pin of U1 (Data out) and then replace the CLK and ATT outputs of U6 with a 330 - 1K Ohm pull up resistor to VCC and either a switch or piece of wire (to short to ground) and manually load / clock the shift registers to check that the correct data is being shifted out. If so that would then isolate the problem to U6.
  9. A circuit diagram would be helpful. As both controllers stop at the same point I would think the problem lies with something that is common to both such as power or a reference voltage somewhere that is used to define either the centre point or end point of the paddles that needs adjusting.
  10. What does that even mean? As far as I know the command codes and controller protocols are the same for all PlayStation controllers, or at least for Ps1 and Ps2 the only real difference being the extra analogue data and rumble motor commands. E8 is not a valid controller code that I am aware of so it it part of some magical byte that has 9 bits instead of the normal 8? I might accept a 9 bit byte if the last bit was parity or a stop bit but as its value is entirely arbitrary depending on if the [] button was pressed it would be useless for either of those functions. If you look at his information immediately above where is says "PSX Controller Data" in bold you will notice two things about the timing diagrams... First there are only 5 bytes of data, When ATT is high those 5 bytes are loaded into U1 to U5, E8 would be part of a sixth byte so what purpose does it serve? Second if you look at bytes 4 & 5 the bits are numbered 0 to 7 as one would expect, where is E8 for your [] button and as part of a sixth byte how will it ever be clocked out or read? Equally, if you look immediately below that point it also shows only 5 bytes. The only way we will know for certain if Mr McCubbin or myself is correct is when you build it. Actually they are not that expensive, Mouser do a 28 pin 18F24K20 for $2.08. With an internal clock there is no need for a crystal so there is probably little price difference between that and the logic chips, plus you save space making the PCB cheaper. You would need to buy a PICkit programmer to dump your code into the microcontroller but at about $50 but if you make enough units (or mark-up) the price of that is negligible, assuming you can write the microcontroller code. Run at 64MHz it was just fast enough to simulate the controller interface from the PlayStation to read a DualShock controller including full access to mode select and motor control which is much more complicated so it should be fast enough for what you want to do.
  11. I am not sure why anyone would want to build a controller when you can just purchase them but that aside I think you may have a few errors you should double check on.... I may be wrong but I think there may be a few errors… 1) You appear to have Left direction going to U5 when it should be going to U4, you are also missing the L3 & R3 buttons to U4. The order should be SLCT, L3, R3, Start, U, R, D, L connected sequentially from direction L at input A to SLCT at input H as the SPI bus is LSB first. If you are not interested L3 & R3 then tie those pins to VCC, never leave input pins floating. 2) For U5 you have the inputs connected in the correct order but not to the correct pins, L2 goes to input H instead of input G, and square goes to input A not SER. Any serial data clocked into U5 should never reach the output so just tie SER to VCC. If I am correct about the above then your button data will be out of sequence and the Square button will never work 3) For U1 tie inputs A-G to VCC, you could tie them to GND as the first byte it is junk data and ignored by the PlayStation. 4) For U2 to tell the PlayStation it is a Digital controller you need to send it $41 so tie the A – H inputs as follows… A – GND B - VCC C - GND D - GND E - GND F - GND G - GND H – VCC For U3 to tell the PlayStation it is ready to send data you need to send it $5A so tie the A – H inputs as follows… A – GND B - VCC C - GND D - VCC E - VCC F - GND G - VCC H – GND This is a dum controller design in that in unlike a design with a microcontroller it cannot understand commands sent to it from the PlayStation and is just relying on the ATT line to switch between Parallel data loading of '165's (button data read) and serial shift. When in shift mode it relies on the SPI clock to shift the data & put it onto the bus. Consequently you should not need to connect Command as it serves no purpose in this design.
  12. I also suggested putting diodes on the output lines (U, D, L, R & Fire) to the 2600 in case directly driving the RIOT inputs was causing problems as they were designed for pull down operation, did you try that I as thought that may have already resolved the interference issue as suggested by this post on page 1...
  13. From you replies to both my and ChildOfCV's suggestion for testing it looks like the switching is probably not the cause of the issue although one last test in regards to the switching would be to disconnect the everything from the 2600 joystick ports and just have the software running as it would if the circuit was attached to see if the interference goes away. If the interference is still there with the hardware disconnected then it is coming from withing the 2600 and nothing to do with the circuit, maybe you damaged a device or something to do with your code. However, if the interference goes away with the hardware disconnected then try placing diodes between the output of the circuit and the 2600 inputs (BAT 85, Cathodes to circuit outputs, Anodes to 2600 input pins) so that when the circuit outputs go high they are isolated from the 2600's inputs due to the diodes being reverse biased thereby allowing the 2600 inputs to be pulled high by the RIOT as they would normally be with 2600 joystick as opposed to being driven high by the circuit outputs which might be doing odd things to the RIOT. You could also try either separately or in conjunction with the diodes above placing the same diodes on the controller select lines, Cathode to 2600 output pins and both the Anode and a pull up resistor to the controller select pin in your circuit. I would think it unlikely but if the interference is caused by too much much current being drawn from your joystick select lines this will isolate them and prevent that.
  14. Interesting... 1) Is the interference there if you permanently(no switching) software select one joystick or the other? If no go to step 4. 2) Is the interference there if you manually select one joystick or the other (tie selection lines directly high/low - driven from 2600 output)? If no go to step 4. 3) Check the wiring for the Joystick that cause the interference & if that looks OK try swapping the ICs with those from the non interfering Joysticks in case you have a dud one. 4) If you are using a single control signal and inverter it is possible the propagation delay of the inverter results in a brief period when the outputs of both Joysticks are active at the same time in which case either diode isolation or using two selection signals to switch one off then the other on should allow enough time for the out of one to fully turn on before the other is turned on. If you have two control line to use try that method first, the instruction cycle time should be slow enough that the instructions used to turn one off and the other on can immediately follow each other, additionally if that does solve the problem it could suggest that the ROIT inputs do not like being fed a voltage for some reason. I am not sure why directly driving the ROIT inputs would be a problem but if it is then diode isolation to ensure they are only pulled down should correct it.
  15. It should be possible, one thing you need to consider though it what happens when the user changes from a game that requires it to to input to that which requires it set to an output. Will the users try the switch in the other position when it does not work or just think it is broken and what i(if any) potential hardware damage that could occur when used with the switch in the wrong position. For the former perhaps put up a message to set the switch to the correct position, as for the latter I cannot quite visualise exactly how you intend this to work so I cannot suggest a solution at this point. Unpowered logic devices can sometime draw power from their input pins, while enough inputs are high it will appear to function but when a enough go low (0V) it will stop working and so if left unpowered its correct operation could be random as the number of high/low input pins changes. So do not be fooled into thinking you can get away without connect both supply voltages. A single pole double throw (SPDT) switch has three connections (usually in a row), the pole (common connection) is usually the centre pin and when the switch is in one position it is connect to the throw at one end of the row and when in the opposite position is connected to the throw at the other end. A double pole, double throw (DPDT) switch is two separate SPDT switches positioned side by side in a single unit and switched at the same time using a single actuator.
×
×
  • Create New...