I will give it a try later tonight if not tomorrow.
I swapped the pins back on my cable to match the original pinout you used, and it all of a sudden stopped working again. I’m going to desolder the cable tonight and try again, but I may have to make you switch the pins. The good news is that it CAN work, so one way or another NES will be finished and working.
Okay, guess I will wait to hear back from you before I give it a go then.
First post updated. Version 1.8 released!!! (yes, I skipped a number. It’s been a while since the last one)
Changes in this version:
-NES support corrected. Pinout for a NES UPCB cable is different from what was in the previous versions. Please make sure to check the current nes.h file for the right pinout. Sorry Chaosdragon13, but it would refuse to work the way it was originally written. Flip the two pins (D-sub pins 12 and 13) and it would work just peachy.
-SNES code updated to match the newer, better NES code. Tested and works awesome, so the NES and SNES have been moved to the tested and supported list on the first post.
-Sega Saturn support still doesn’t work on real hardware yet, but in attempting to get it there, the code was streamlined a bunch. Previously, the Magic Box adapter would lag a bit, but with the streamlined code, it works very very well. So, the Saturn code is improved, and getting it working on real hardware is next.
-PC/PS3 USB code now reports the stick to BOTH the d-pad (POV hat) and left analog stick (XY-axis). Hopefully this will help with some PS3 games, and also make it easier to use PC games, like doujin fighters/shmups, that will only use the XY axis for movement.
Also updated the full schematic image to match what the rev 2.1 boards were made with.
Sounds good. I will give it a try when I get home later.
One question though, why was there a need to change the SNES code? Were you having problems with it? Or did just realize that you had a lot of extra stuff that you could cut out? I only ask because SNES support worked fine for me in the past.
Just being a pedantic coder. The newer code has better checking of the latch line, so there is almost no chance of the UPCB not catching if the SNES freaks or starts changing the timing. The checking of the buttons and sticks is now done in the wait time between transfers instead of during the actual process. Since button mapping (and future recording) takes longer to return the status of the button, its risky to check during that super fast transfer. It’s just more solid code.
For what it’s worth, I tested it out on a whole crap ton of Axelay (“Arms installation is complete. Good luck.”). It works, and there’s no change to the pinout. I’d be damn surprised if you noticed any difference at all.
I just updated.
The change you made to the USB code works nicely with doujin games and other computer games.
One thing I am not sure if you ment to do or if you are aware of it, is that when you first start a system with v1.8, non of the buttons are set to anything. I dont know if its for all systems or just the computer, but I had to hold each button and tap the programming button in order to set them all to what they should be set to by default. Because you can save the button mapping its not really a bad thing since I can just save it once I get it how I want it. But you might want to let people know this before they think the buttons dont work anymore.
I will say more when I test it out on the NES.
Actually, it will be that way for every console when you update and use a .hex with programming button support. I haven’t figured out how to not have the flasher rewrite the EEPROM, but I will look into it.
Very nice. I just got my blank PCBs…real professional stuff. Of course Jameco had a database hiccup and I “ordered” the wrong crystals, so I have to wait until I get free time to run to the shop before I can get these things up and running. I’ll let you know how it goes though.
Any progress on the Dreamcast connection?
I am working on a similar project to this. My controller has 20 buttons and simultaneously supports USB and Playstation connections, and I am trying to add a Dreamcast connection too.
It’s easy to build on stripboard.
WIP: http://joystick.world3.net
So far I can read commands from the Maple bus, but I’m not getting the command codes I expected and the lack of documentation and sample implementations is making it hard to progress.
If it can’t be done I will do a Sega Saturn or PS2 (keyboard) connector instead, but I want to do native DC.
Any native dreamcast support will have to come from a second daughterboard with a different microcontroller or maybe a CPLD. The PIC is running 12 MIPS, and that’s just too slow for 2 megabit/sec communication without help. If you can read commands off the maple bus, then snoop a legit controller for a while. You should be able to figure it out from the commands going back and forth on a legit controller, and looking them up here: http://mc.pp.se/dc/maplebus.html#funcdata
Thanks Toodles, I was using that site and the patent application as a reference too 
I am using a 12MHz AVR, but I might bump it to 16MHz. 12MHz gives you six instructions per bit, which is enough to read and write on the Maple Bus, just. Not sure if a PIC could do it, are they mostly single cycle instructions?
Writing to the bus is no problem. The problem is detecting the falling clock edges for reads. I was trying to do it with some cycle exact code based off detecting the first fall, assuming each bit takes exactly 0.5us. I seem to be able to read four bytes, and two of them are what I expect, but the others are not.
However, I think a better way might be to use some logic gates to read two bits at a time. That way there would be 12 cycles available to deal with them.
Another possibility would be to use two serial in shift registers, one for each data line, with an interrupt that counts four falls on one line and then clocks in all 8 bits simultaneously. I’m starting to run out of I/O pins on the AVR though…
An interrupt might be able to do it too.
A lack of solid timing in the attention phase is a bit of a pain in the arse though. The patent implies that it is tied to the 2MHz clock, but the web page says otherwise.
I generally want to avoid using a CPLD because I want the interface to be easy to make. I think it can be done on an AVR.
Are you sure your 12 MIP AVR can do 2 megabits? That’d be a ton of hand tuned assembly. The AVR-USB project was BARELY able to get low speed USB going at 12 Mhz and they used a ton of coding tricks to make it happen. Low speed USB is 1.5 mbits/sec.
Using the shift registeres like the patent docs shows always seemed weird to me; there’d be no way to know when to read in the shifted bits, at least that I could see. The used of different counters to detect the different packet start/ends and CRC options seemed kinda cool, but I’ll be damned if writing out wouldn’t be a bitch with the way they have like 4 different clocks going. Meh.
The easiest way I could think of to try and read (since you could hand tune to assembly out to write at perfect speed and wont need the additional glue logic) the bus would be to use an OR gate. Have the two data lines going to pins you can have interrupt on falling edge, and have the interrupt just read in the bit from the OR gate output. Since the falling edge marks when to read, ORing the two lines would always give you the bit from the other line. The only question is whether or not the AVR interrupt is fast enough to detect the line, do what you need, and return in 500ns, and I dont know enough about AVRs to be able to answer that.
Any more progress on your list, Toodles? Sorry to bug but I’m waiting on #8 on the list so any progress is good progress :china:
USB probably isn’t as hard as you think. The main reason it’s difficult to manage 1.5 megabits/sec is that USB needs decoding (IIRC runs of six or more unchanged bits are padded). The Maple Bus protocol is “raw” so six instructions to read and store a bit is fine. In fact, my reading code used NOPs to get the timing exact
Interesting idea. The AVR would be fast enough to handle incoming interrupts that fast, but it would be tight. Because a falling edge could occour in the middle of an instruction and you need one cycle to call the interrupt and one to end it, you would be left with exactly three cycles to do something. A better option might be to use a 20MHz AVR, but then all the USB timing goes out the window…
That’s why I suggested using a buffer for one line. You can the read two bits at a time and you get 12 cycles per two bits to play with. That is enough to do it I think, especially since you can cheat to some degree by assuming any data you get will always be five bytes long (since you only care about two commands - request device info and get condition, so 4 or 5 bytes with a minimum of 4 bytes transmitted for frame header + crc).
Then, as you say, sending data probably fairly simple, although one slight issue is that you wouldn’t be able to do much processing to the data so it would have to be in a pre-prepared format read to go. I’d just continuously sample all inputs and keep an up-to-date copy of the data ready.
Saying that, you can get 20MHz AVRs for <1 so a co-processor might be in order.
None yet. I’m spending the spring break finishing up an old project so the UPCB can get more attention.
I really don’t have a solid idea what you’re describing here. Could you elaborate?
Whenever it seemed viable to work on, that was the plan. I set aside a connector on the second batch of UPCBs with power, ground, two UART lines, and two lines connected to the output cable. I was figuring that whenever this became feasible, the UPCB could sent the button/stick status over the UART, and the coproc took care of all of the dreamcast stuff.
So, if you do make progress on this, please try to leave the UART and I2C lines out of your formula. I was planning on trying to put in a 24LC1025 or 24FC1025 in as psuedo VMU storage. But even if they aren’t available, just actually seeing an implementation would be awesome. I got a few Atmega8’s and Atmega168’s lying around, tons of different oscillators/crystals, and even a pair of Arduino’s (one decimillia, one self made) so let me know if you come up with something I can throw together. (and for what it’s worth, Im a big fan of the stripboard as well. I always pick up a bunch of the $0.95 and $1.95 strip boards from every futurlec order. That home made Arduino? on one of those same $0.95 small stripboards. )
Have a 1 bit buffer, clocked on the falling edge of say D1. The uproc then watches for falling edges on D2, and when it sees one reads both the current bit on D1 and the buffered bit.
That way you end up reading both bits at the same time, and only dealing with a 1MHz clock.
The biggest problem I have is that I don’t have an oscilloscope… I will have to look into getting a PC based one. I’ll let you know if I get any further. There are a lot of good shooters and fighting games on the DC so I’m keen to support it. I have a PSX->DC converter but it’s not that good. I think it uses an AVR, but the manufacturer rubbed the markings off 
I agree with mojochan, write to the bus is easy, I can send a Device request to a controller using a 18F2550 PIC and a buffer, and the controller response is the Device status, so if the controller can understand the device request from the PIC the Dreamcast can understand commands sent by the PIC too (I think that the MIE of Dreamcast are the same of the controller). The video of that is here
[media=youtube]5STjeFKJ9uM"[/media]
(the video isn’t too detailed because I use the camera of my W300 cellphone)
I want to connect the Dreamcast controller to the PC by USB to play quake 3 arena like in Dreamcast :wgrin:. Marcus comstedt (http://mc.pp.se/dc/) tell me that I can’t :mad: but I think that he’s wrong.
Toodles the last month I sent you a private message in instructables, and I couldn’t post on this forum because my spam filter delete the verification e-mail :shake:…
Sodor, I got you rmessage here, but I did not see the message on Instructable until now. I understand what you are saying in the instructables message. I think you are correct; the maple bus should work at almost any speed, as long as the falling edges are correct. I agree that this is probably true. However, writing to the maple bus is not difficult. Reading the maple bus, at the 2 megabit speed the Dreamcast uses, is difficult.
If you are able to read the Maple bus with your 18F2550, I would love to see the schematic and program; I have many 18F2550 PICs and could duplicate your circuit. I will help you get it working on the maple bus if I can.
What are the specs on the 18F2550 vs the 18LF4550 we use and the 18F4550 that I have lying around? Just curious if I’m going to have to upgrade chips to follow the development.