superUzebox idea

Discuss anything not related to the current Uzebox design like successors and other open source gaming hardware
scuzz
Posts: 73
Joined: Sun Sep 13, 2009 4:57 am
Location: Maryland, USA
Contact:

Re: superUzebox idea

Post by scuzz »

While I'm certainly still open to suggestions, a lot of what picked my path at this point has been the fact that I began working on implementing things back when I thought I'd decided on a processor.

I just finally got around to wrapping up a lot of the work, and so I thought I would show where we stand:
A work in progress
A work in progress
scuzzbox_r1.png (63.23 KiB) Viewed 7563 times
Everything is implemented except that I completely forgot to attach the headers for controllers. Can anyone give me a rundown of what I'll need for that? An output compare pin to click through the serial shift register, power, ground, a pin with which to read, and a latch, correct?

There's a number of features broke out here which are, of course, not necessary to "normal" operation (and could be left out of the kernel or deactivated using jumpers). The core idea of "only two ICs and a bunch of resistors" is nearly intact, except here it's "only three ICs and a bunch of resistors." The three necessary ICs are a ram chip, the ARM, and the NTSC chip.

The whole system is made to be editable by the free version of Eagle (only 2 layers) and has specs that allow it to be made using 33each.com
User avatar
TonyD
Posts: 134
Joined: Mon Oct 27, 2008 2:23 pm
Location: Newcastle, UK
Contact:

Re: superUzebox idea

Post by TonyD »

Wow, great looking design Scuzz.

Are you still using an NXP LPC2388 ARM7?

As for the shift registers, the 4021's need a latch (pin 9), clock (pin 10) and data (pin 3) signals to work.
scuzz
Posts: 73
Joined: Sun Sep 13, 2009 4:57 am
Location: Maryland, USA
Contact:

Re: superUzebox idea

Post by scuzz »

TonyD wrote:Wow, great looking design Scuzz.

Are you still using an NXP LPC2388 ARM7?

As for the shift registers, the 4021's need a latch (pin 9), clock (pin 10) and data (pin 3) signals to work.
Thanks! Glad you like it. :D

And yes, I ended up putting on the NXP LPC2388 ARM7TDMI, for reasons discussed previously. It may turn out that this is too slow, as I think this will need 4 clock cycles per RAM grab of 32 bits, but I decided to roll with it because frankly I want to get started, and I can do a redesign with a different/better chip later if it turns out that this is not feasible.

Anyway, I have to do some checking to make sure that everything is hooked up correctly (meaning no overly long, overly thin traces), but I think this next pic shows you what I'm going to send out for fabrication.
Nearly Finished?
Nearly Finished?
scuzzbox_with_controller.png (66.46 KiB) Viewed 7457 times
Everything is much more clearly labelled in this picture, and you can also see that I traced out the different segments of the board. In order to have the system work you'd only need to populate the main, unlabelled section, the audio/video section, and for not flashing the ARM every time you want to play a new game, the SD card section. The two 7-pin connectors are made to support either PSX controllers or SNES controllers. I think I may want to pop on another jumper to let you select which type of controller you're using, though for the time being that 5 pin breakout which has no real function except to give access to more pins will work for the time being.

You can also get a better idea of how silly some of the features are! I put an IRDA port on there just for fun. Maybe someone can make a game which, to scare you, turns off the TV! Or better yet: point-to-point link ups between different boxes, so you don't need a hub to connect. Anyway, one of those "it has the feature why not break it out" deals for some of these things.

And anyone who's paying close attention will probably also notice that there is not a separate audio DAC/synth. This is because I couldn't find a chip which wouldn't drive up the cost by another $5 bucks, and it also just seemed excessive because I would still have to do all of the sound mixing on the ARM, I would just get higher quality output.

The current cost of the non-passive parts is around $45 for the initial runs + $33 for the PCB. With bigger runs this price drops by a lot. Even just buying 50 would drop the price of the non-passive components to $28 (based on price breaks on digikey/mouser), and the PCB could obviously be dropped down as well.

I'll plop the schematic/layout/bill of material/gerber files/libraries you'd need to get this fabbed once I verify the design is ever pretend working by buying a working copy for myself! Thanks for staying interested, hope I'll get this done before the end of time :P

PS: Anyone who notices any ridiculous routing paths: I routed this in the laziest manner possible! This is just what the auto-router spewed out with a 2mil routing grid. I worked like mad to try and get the parts placed such that routing wouldn't be a pain. In the final non-debugging board I will probably go through and meticulously route everything by hand.
User avatar
TonyD
Posts: 134
Joined: Mon Oct 27, 2008 2:23 pm
Location: Newcastle, UK
Contact:

Re: superUzebox idea

Post by TonyD »

Scuzz, very nice write up. It looks like you've used EagleCAD for the design, so I'm looking forward to seeing the schematics when you post them.
scuzz
Posts: 73
Joined: Sun Sep 13, 2009 4:57 am
Location: Maryland, USA
Contact:

Re: superUzebox idea

Post by scuzz »

Alright. A few more questions before I consider this completely done:
I have a number more nifty little features on this ARM, and I'm wondering what should be hooked up to something special.
I currently have the following pins hooked up to output compare modules:
1) Audio output
2) CSYNC
3) SNES/PSX Controller clock
4) Controller Latch (SNES)/Controller Attention (PSX)

The only question I really have here is mostly whether or not audio output should be a PWM or something. Can anyone think of any important connections I might be missing? Especially anything which may need a chip feature. Obviously things like the SD card, the ethernet port, the USB ports, and the IRDA are all hooked up to the pins that they need to be hooked up to.
User avatar
uze6666
Site Admin
Posts: 4812
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: superUzebox idea

Post by uze6666 »

Through to answer since I don't know this chip. What about the "power" led? Regarding sound, what other on-chip option do you have? Is there a DAC? if so sure I'd use it. Otherwise, what's the PWM resolution and max clock rate?

-Uze
scuzz
Posts: 73
Joined: Sun Sep 13, 2009 4:57 am
Location: Maryland, USA
Contact:

Re: superUzebox idea

Post by scuzz »

uze6666 wrote:Through to answer since I don't know this chip. What about the "power" led? Regarding sound, what other on-chip option do you have? Is there a DAC? if so sure I'd use it. Otherwise, what's the PWM resolution and max clock rate?

-Uze
There is a DAC which has a quite excellent setlling time (2.5us max, 1us when not biased), but it can only drive 700uA max (350mA when biased), which I worry may be an issue. Should I pop in an op-amp or something to allow for a higher current output? The plain old digital i/o pins can drive 100mA a pop.

I'm assuming you mean that I should hook up a "power" led to some GPIO pin so we can indicate the current on/off state. I actually just realized I have no on/off mechanism except plugging in power! I should add a switch or something...

As for other on-chip options the answer is a bunch. I have a real-time clock module for which I currently don't have a battery attached, but it would be easy enough to add. You can read the whole list of features in the bookmarked sections of the manual.

:::EDIT:::
So doing out the math, If I used the built-in DAC I could have, at a minimum 4.714k resistance straight to ground. So to be on the safe side I'll pop a 5k in there.

Then we need to make a resistor divider, we'll need a potentiometer to adjust the second impedance so that 1V=Z*(3.3V)/(5k+Z) which gives 2.174k. So if I popped in a 2.5k potentiometer in there, we should be able to use the DAC as audio output. I already had some jumpers in there, so for now I'll make it jumper selectable between the output compare module and the DAC.

:::EDIT2:::
I realized there was a pin multiplexed with both a PWM and an output compare on it so I remapped the other side of the audio to that pin. No we can compare PWM, DAC, and output compare sound fidelity all on this design! :D

Can anyone think of anything else I could/should map to different features? Also, my idea using the potentiometer is sound, yes?
Post Reply