Do we have room for another N64P? (t64 WIP)

[kibble]

I've kinda already ruled out power issues because I've tried powering it from a different 5V source that I knew worked fine with the amps and it still does the same thing. It sucks that the sounds is kinda distorted because I was hoping this would be one of the easiest things to develop for the portable. Maybe I'll have to play around with the capacitor and resistor values. ARRRRRRRGH!!! Why's it gotta be so difficult!?!?!?!!?!? I'll be ok, I promise.

The biggest thing I'm happiest with is that I got the I2C routine to write to the potentiometer working, which means that once I get the LCD, it should be just a matter of loading the data needed to the registers and sending the data over to initialize it.

[kibble]

Really good news! Thanks to my uncle, I ordered my 3.5" screen today! I have a few other goodies on the way too so I can experiment with.

[kibble]

Tripple post..

So I have been playing around with microcontrollers a lot lately, which, if you've read pretty much through the whole thread, you'll remember that I mentioned that I would probably be including one in my portable for control of various functions. When I first started this project, I knew hardly anything about programming a PIC micro. I have been gaining a lot of knowledge about them just by trying stuff out and getting simple programs to work.

I had originally thought about modifying the control stick from an original N64 controller, but am now leaning more towards using a PSP nub. One of the functions I could have the micro do is allow me to interface the control nub with the n64 controllers' chip. Sure, it would be much easier to use a nub with a third party controller, but in case it's not too obvious, the main reason I'm sticking with using first party stuff for this portable is because all the semiconductors are easily removable from their boards, not "glob-tops", and therefore, I can design boards around those components without having to keep the boards they're mounted on.

So, here's a video that I made showing one of the axis of a c-stick from a gamecube controller going through a PIC16F873. The output from the micro is the upper 8 bits of the 10 bit ADC, which is shown on the 7 white and 1 orange LED's. Now I just gotta make some more code that will take that binary value and convert it to something I can interface with the 64's controller chip. This video was also posted on the thread about the PS control stick in a 64 controller.

[thewise1]

Bad axel, bad.


Looks awesome, you baffle most of us so we'll just wait patiently to see if it works. Hopefully it does!

[evilteddy]

Looking really cool to see what you're doing. Are you going to have the PIC save settings in EEPROM for when its off or do the digital potentiometers not lose their value when turned off. I've been thinking for a while of the possibilities of having a microcontroller inside a portable to control basic functions and I can see you're making the most of it. Its very exciting to see it finally happening.

I've also been making a N64 controller with a PIC but my new computer doesn't have a serial port and with the speed you're moving at you'll be finished long before me.

Keep up the good work.

Evilteddy

[kibble]

Thanks for the kind words, guys!

Are you going to have the PIC save settings in EEPROM for when its off or do the digital potentiometers not lose their value when turned off.

That's actually a very good question. If I keep this particular digital pot in the circuit, I'd have to store the data in EEPROM so that when I turn it back on, the volume would be at the same level as it was before I turned it off. The DS1803 is volatile, so as soon as the power is shut off, the device loses its settings. The good thing is that the same commands that are used to write the volume level to the digi-pots can be used to write data to an EEPROM, and both devices can use the same 2 wire bus, so the whole process can go:

1: (Volume button pushed)
2: Write data to pot
3: Write data to EEPROM
4: Return to main program

If the device is shut off, at power on, the program can go:

1: Read EEPROM address where volume level is stored
2: Copy data to RAM
3: Write data to pot
4: Goto Main program

If I were to use some other digital pot that has a non-volatile storage that's also controlled by I2C, I wouldn't have to do anything else other than just write the data to the pot.

I've also been making a N64 controller with a PIC but my new computer doesn't have a serial port and with the speed you're moving at you'll be finished long before me.

Unless your OS is 64 bit, you can just get one of those USB to Serial adapters for pretty cheap on the bay. I've been doing my programming on a cheap laptop running 32 bit XP because it's a PITA to use the serial port on a PC running 64 bit OS.

[evilteddy]

I actually just bought a PCI card with serial ports on it. Its in the post at the moment because I got the cheapest shipping. Hopefully it will be here soon.

As for the storing in EEPROM while its true that you'd be using I2C to communicate with many EEPROMs heaps of PICs have a few bytes of EEPROM memory built in. Looking up the datasheet for your PIC you have 128 bytes of internal EEPROM. Should be enough to store volume levels and the like.

Evilteddy

[kibble]

Looking up the datasheet for your PIC you have 128 bytes of internal EEPROM. Should be enough to store volume levels and the like.

Yeah, except it seems like it's more of a hassle to save to the internal EEPROM than it is for using something else... but maybe I'll give that a shot anyway. Can't learn if I don't try, right? I'd also have to use the EEPROM to store init values for the LCD too, which I should be receiving this Friday! I'm really hoping that pure digital video looks sweet!

I'm experimenting on the F873, although I'm leaning towards using a TQFP F877, as it has a 2 more ports than the F873, for the final design and I have a F877 dev board I can do testing on. There's way more that I want to implement into the design other than volume and controller functions. Plus, if I include some sort of connection for ICSP, I can always add more functions just by updating the programming without having to open the thing back up every time I want to change something.

[evilteddy]

True that, ICSP is many a good thing. As for the difficulty of using the internal EEPROM it is a bit mistifying at first however in the datasheet there's a block of code around 4 lines long which you can pretty much copy changing the address depeding on where you want to read or write.

That said I understand that learning to use different things is usually half the fun. Why play around with the internal EEPROM when you can try something new and different?

How will you get the digital RGB for your screen? Can you grab digital RGB somewhere off the board and if so how many bits is it?

Can't wait to see it.

Evilteddy

[kibble]

Well, the color info is 21 bits and has to be demultiplexed from the 7 data and 2 clocks going from the RCP to the video ADC. The LCD I'll be using has a 24 bit color input, so I'll have to tie the LSB to gnd and keep the upper 7 bits. I found all the info for that here:

http://members.optusnet.com.au/eviltim/ ... 64rgb.html" onclick="window.open(this.href);return false;

It seems like it should be pretty straight forward and I just hope there's not some really funky stuff I have to to do get it to work.

About the EEPROM, I could just make use of the internal portion of it to begin with and make a spot on the board for an external part if the need ever arises.

[marshallh]

Tip: when running an X-bit signal to a Y-bit device, repeat the sequence for the remaining bits.

So if you have 7bits per channel, and the LCD is 8bits per channel, put the MSB of the video on the LSB of the LCD.

It's really pretty small but if you tied that to ground your entire image would lose a very small amount of contrast and brightness. In this case it would be pretty minimal, but if you were running, say, a 8-bit audio signal to a 16-bit DAC, you would repeat the 8bit sequence of bits, twice to fill all 16 bits.

Just a little trick

[kibble]

So you're saying to do something like this:



I think I see what you're saying; that leaving that line tied to gnd would make me lose a substantial amount of color values going into the LCD and tying that line to the LSB to the MSB would sort of help fill in for the missing data? Took me a bit of thinking about it, but I think I got it. Is that right?

[evilteddy]

I see how that works now. Funny thing is that the circuit to get digital RGB is simpler than the circuit to get analog RGB because you'll be chopping off the resistor ladders. Looks like it'll work well though how are you going to get and use a CPLD? Keep us updated.

Evilteddy

[marshallh]

Yeah, you got it

[stuntpenguin007]

Don't know if this would help you at all, but I have an old ball ps/2 mouse that's based off a pic microcontroller. I'm not sure if there's any protection to prevent me from dumping the contents of the pic, but I could try. Then I'm not sure how well disassemblers work, but I could try disassemble it to get the code. Of course it wouldn't have comments, and it'd probably be more work than it's worth the figure it out, but who knows.

here's some information on ps/2 protocol that the pic converts ball movement into.
http://www.computer-engineering.org/ps2protocol/" onclick="window.open(this.href);return false;