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:
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
superUzebox idea
Re: superUzebox idea
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.
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.
Re: superUzebox idea
Thanks! Glad you like it.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.
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.
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
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.
Re: superUzebox idea
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.
Re: superUzebox idea
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.
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.
Re: superUzebox idea
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
-Uze
Re: superUzebox idea
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.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
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!
Can anyone think of anything else I could/should map to different features? Also, my idea using the potentiometer is sound, yes?