Joined: Tue Mar 25, 2008 2:11 am Posts: 423 Location: Newcastle, Australia
Pretty self explanatory. Shortly after this video was made I managed to destroy my crystal so it'll be a while until my next update but I thought I'd share what I've done so far.
The aim is to get a fully fuctioning controller with support for pot joysticks (optional support for C stick) and rumble and memory. It will be very small compared to a normal controller using a cut up 64 controller board with a mem-pack and a rumble pack.
In answer to Blaze, I haven't had a huge amount of experience with PICs but unlike what Marshall is doing this isn't rocket surgery and there is some great documentation out there but only from the perspective of people talking to the controller not the other way around.
Stuntpenguin, if you do the same project that would be excellent. I'd be interested in seeing some different ways of doing this.
Joined: Sat Sep 10, 2005 2:17 pm Posts: 2968 Location: here and there
Nice work so far. Before you get too far I would rewrite most of that code, though. For your own sanity later, trust me
I'm crossing my fingers for you with the controller pak stuff. Your PIC should hopefully be fast enough for it, but you can always migrate to a faster one if that happens.
I haven't gotten too far in my pic programming adventures. Lately I've just been doing blinking leds and doing potentiometer stuff in C. I started off with assembly, so I understand what most of the code is actually doing (except for that "goto $+3" thing), but I'm not entirely sure what the purpose is for some of the code.
correct me if I'm wrong on any of this:
From what I understand, the first step to building something like this would be to answer the n64's polling request to see if a controller is present, and the timing has to be perfect... and that's why you used all the "no operations".
from http://www.mixdown.ca/n64dev/ I've gathered that the n64 will send a 0x00 to the controller to see if it's there. Then the controller, or pic in this case would respond with ??? fill in the blank ???
After this week I should finally get some time to work on this. Good luck with yours
Joined: Tue Mar 25, 2008 2:11 am Posts: 423 Location: Newcastle, Australia
This program is going to be improved a huge amount obviously. It will look completely different in its next rewrite, at the very least I'll compress Record8bits and Send8bits to an eighth of the lines.
The goto $+3 is the same as any other goto but the address it goes to is where the PCL is pointing to at the moment + 3. In simpler language, go down 3 lines.
What the mixdown site told you is broadly correct except many games seem not to care about what you return to an 0x00 request as long as you respond. This is of course only for basic operation where you're only pushing buttons. The controller will not count as being detected unless you are responding to both 0x00 requests and 0x01 requests be it garbage or quality data.
I assume via your question marks that you missed http://svn.navi.cx/misc/trunk/wasabi/devices/cube64/notes/n64-observations when you were looking through those other links. It'll get you up to speed with whatever mixdown has missed, in short the nintendo 64 responds with 05 00 02 if no controller pack is inserted. I cannot recommend enough getting an oscilloscope or logic analyser. Working blind is a pain.
Oh, and timing is fairly important and will be even more important when the 64 will eventually want to do a full page eeprom write.
I made this which is largely based off of your code. In fact, it's pretty much just parts of your code copied and pasted together. I believe this code will answer the n64's request to see if a controller is attached, except I need to get a logic analyzer or something so I can get the right timing down.
Spoiler:
Code:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; PIC N64 CONTROLLER ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; LIST p = 16f690 include "P16F690.INC" ;Config bits here ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
cblock 0x20 tempout ;tempout created at 0x20 endc
org 0x0000 ;The start address goto start ;skip to start -- kind of unnessacary right now
start movlw 0x07 movwf CMCON ;comparators are now off
bsf STATUS, RP0 ;move to bank 1 to setup I/O movlw 0x00 ;put 0x00 in register W movwf TRISA ;PORTA is now output bcf STATUS, RP0 ;To bank 0
loop ;infinite loop call contstatus goto loop
contstatus movlw 0x05 ;send 05 00 02 in response to n64 movwf tempout ;0x05 is now in temput call Send8bits ;send the 0x05 to the n64 movlw 0x00 movwf tempout call Send8bits movlw 0x02 movwf tempout call Send8bits
Send8bits bcf PORTA, 4 ;set porta bit 4 to 0 (pull low) nop ;waste 1us nop ;waste 1us btfsc tempout, 7 ;if tempout bit 7 is 0 skip the next instruction bsf PORTA, 4 ;set porta bit 4 to 1 (pull high) call delay2 ;delay for 5us (or maybe more?) bsf PORTA, 4 ;set porta bit 4 to 1 (isn't it already pulled high?) call fourus ;probably a 4us delay?
bcf PORTA, 4 ;set porta bit 4 to 0 (pull low) nop ;waste 1us nop ;waste 1us nop ;waste 1us btfsc tempout, 6 ;if tempout bit 6 is 0 skip the next instruction bsf PORTA, 4 ;set porta bit 4 to 1 (pull high) call delay2 ;delay for 5us bsf PORTA, 4 ;set porta bit 4 to 1 (pull high) call fourus ;probably a 4us delay?
bcf PORTA, 4 ;and on and on until 8 bits have been sent nop nop nop btfsc tempout, 5 bsf PORTA, 4 call delay2 bsf PORTA, 4 call fourus
Joined: Tue Mar 25, 2008 2:11 am Posts: 423 Location: Newcastle, Australia
This code wouldn't work for a couple of reasons. For one if you pull the Nintendo 64 data line low while its trying to let it go high while its sending a command or any other data it will just stop and not send anything. At the moment your'e just spitting out controller status constantly and there's no garantuee that the everything would magically sync up and it will return the controller status in the couple of us after the N64 requested it. This is why I used an interrupt. You can work as normal in the main program and the interrupt helps keep timing clean. If you use an interrupt to test this make sure that you delay until after the whole byte has been transmitted and not just send the interrupt as soon as the data line goes low.
Of course if you do this you'll need to connect an interrupt pin to the data line because RA4 can't act as an interrupt trigger in the majority of PICs (and at the moment I've got a 3rd pin connected for TTL input which registers a 1 at a lower voltage than schmitt triggering but in the future I'll just turn the interrupt off RB0). Another very important thing when it comes to timing is of course what you're using as your clock. 20Mhz is the speed I made my program for.
Lastly, even if you make these alterations will still show the controller as not connected until you respond to button status requests with a full 32 bits of data. If you need a basic test then you can respond to the controller status requests with the button status 32 bits.
ok, I kind of expected that. If I'm bugging you, just tell me and I'll go away .
On a side note, the reason I was thinking of a PIC n64 controller was because of another project I was thinking of in which a PIC would plug into a computer on one end, and the n64 on the other, and then there would be a program that would let you use controllers plugged into your computer on the n64.
It's not like I have enough experience / knowledge to make something like that anyways, but I can still dream.
_________________ SNESP WIP Case - 50% acquired parts - 90% assembly - 0%
Joined: Tue Mar 25, 2008 2:11 am Posts: 423 Location: Newcastle, Australia
Well, I have managed to take the really messy code seen above and by not being an idiot I halved the length of the program. I have also been looking through the magical world of CRCs in general and with the memory and rumble pack. I'm definitely sure that I can get the rumble pack working because there is only ever two messages written to one place so I only need to use a PIC to read what CRCs are returned. On the other hand memory packs will be quite a bit harder but I'm going to give them a try in any case. Big thanks go to Michael Dowty who has a slightly working implementation already in asm.
Joined: Tue Mar 25, 2008 2:11 am Posts: 423 Location: Newcastle, Australia
I would love to release a working version at the moment but there still are a couple of things to go with the basic stuff. Simple things like needing to migrate to a PIC with more buttons and A2D support for joysticks. I'm currently working on migrating to the 16f887 so its happening but at the same time I don't have a crystal anymore so either I make it work at 8Mhz (pretty sure that's impossible even for basic operation) or I have to wait until I get another crystal which isn't coming anytime soon.
Users browsing this forum: Google [Bot] and 0 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
Login
FAQ
Search
