superUzebox idea

Discuss anything not related to the current Uzebox design like successors and other open source gaming hardware

Re: superUzebox idea

Postby scuzz » Thu Oct 22, 2009 6:51 pm

Looking at the nxp offerings for the Cortex-M3 they have a lot of neat features but the LQFP parts appear to be lacking the external memory interface.

As neat as those wiznet modules are this whole project is being built from scratch and thus I don't really like the idea of being dependent on a prebuilt proprietary component like that like the WIZ811MJ. I could use the actual chip but it also needs a phy so it just adds extra expense (the arms with a built-in ethernet module only need a phy, rather than a phy and a wiznet). The downside is that if/when the chip I decide on has built-in ethernet, then there would be one more thing that would need to be migrated when the chip stops being manufactured, but that's a long way away.

So in defence of my original decision: The NXP lpc2388 and the lpc2478 both have all of the features of the STM32F103VE (save for the improved instruction set), costs $2 less (on digikey, on mouser the lpc2478 is only $0.91 cheaper), run at the same clock speed, and also both of them have 2 USB 2.0 ports (one can be host while the other is slave, allowing for it to take things like keyboards and/or usb sticks in addition to being debugged), they have a built in ethernet controller (allowing for me to use a $7 part to get a full ethernet interface instead of a $20 part!), and they too have a very neat eval board from olimex. Although the neat development board is pretty much what I'll be building so it doesn't really matter if either of them has that :P

Anyway, not trying to shoot you down or anything, just weighing the options. I would like to use a module with a newer instruction set, if for no better reason than it would allow go out of favour less quickly, but I would still like to have a lot of the features that NXP offers. The Cortex-M3 stuff from NXP also has a harvard architecture which means that running code from things like an SD card will not be as good. The ST Cortex-M3 is definitely more favorable in a lot of respects as far as the Cortex-M3 goes, but I still like the ARM7 from NXP more. Any more thoughts?
scuzz
 
Posts: 73
Joined: Sun Sep 13, 2009 4:57 am
Location: Maryland, USA

Re: superUzebox idea

Postby scuzz » Fri Oct 23, 2009 5:00 am

... I feel like I've scared people off from commenting :oops: ...

I'd definitely like to hear other opinions before I more forward with the final chip decision. The ARM7TDMI is still my favorite because it has a huge number of features and it's $14. Poking around the other, newer architectures:

    I see the ARM9 has two reasonably priced LQFP/QFP/PQFP units :
  • AT91SAM9260B (from Atmel). This one looks very nice! Has built-in ethernet, two usb ports (one host and one device), and of course a 32bit-wide external memory controller. The main thing I dislike? It runs at 1.8V! The thing requires multiple power supplies for the core and IO which is ask a little much on a two-layer pcb... This one supports up to 256Mb of ram, so lots of room for expansion should it be needed
  • STR912FAW42X6 (from ST). This has the same drawback as the Atmel in that it appears to need separate I/O and core voltages, but there's a lot to like about this one. It has a 32bit wide ram interface (though it only supports 64KB total), and it explicitly allows for real-time execution of the code off of external ram (assuming a few details). It also has an ethernet and usb interface, though no host usb interface and therefore no fun peripherals later :cry:

Looking more thoroughly into the Cortex-M3 stuff, luminary micro definitely did catch my eye, but I also found some ST stuff that was better peripheral-wise then the ones I was originally looking at. That being said luminary Micro doesn't offer any cpu's with a clock speed of more than 50MHz, whereas ST goes up to 72MHz. That being said, the NXP Cortex-M3's go up to 100MHz, though they're all capped at 64KB of external ram and have a harvard architecture which means that the running of code from RAM is going to be severely capped (is this true of the cortex-m3 in general? Or was this a dirty trick to get the clock speed up to 100MHz?)

Anyone with more ARM experience care to throw their opinion into the pot? Tony? Uze? Anyone?
scuzz
 
Posts: 73
Joined: Sun Sep 13, 2009 4:57 am
Location: Maryland, USA

Re: superUzebox idea

Postby TonyD » Fri Oct 23, 2009 12:56 pm

... I feel like I've scared people off from commenting :oops: ...


No, just Timezone differences and being out for a beer (or two) last night ;)
- Tony

http://zuzebox.wordpress.com/
User avatar
TonyD
 
Posts: 120
Joined: Mon Oct 27, 2008 2:23 pm
Location: Newcastle, UK

Re: superUzebox idea

Postby TonyD » Fri Oct 23, 2009 2:59 pm

luminary Micro doesn't offer any cpu's with a clock speed of more than 50MHz, whereas ST goes up to 72MHz.

Yeah, Luminary parts are a little slow (is 50MHz considered slow?) but they were one of the first Cortex-M3 licensees so their initial parts now look slow and lack many of the I/O interfaces of later Cortex-M3 licensees (ST,NXP, Cypress, Atmel) . That said, Luminary was recently bought by TI so you can expect TI will be pushing their parts strongly (lots of cheap offerings) and bringing out new devices.

I would also have a look at Cypress PSOC5, its a similar spec to NXP/ST but they also have a integrated CPLD.

Both those ARM9's look interesting, I've never used ARM9 so I can't comment on the architecture but I can't see them being too much different to ARM7 or Cortex-M3.

OT - If you want to try a more exotic processor have a look at Xmos. I've got a small software driven VGA prototype shown in my blog and the VGA driver can be found at xcores.org. Check out Yvo's Super Mario demo

- Tony

http://zuzebox.wordpress.com/
User avatar
TonyD
 
Posts: 120
Joined: Mon Oct 27, 2008 2:23 pm
Location: Newcastle, UK

Re: superUzebox idea

Postby uze6666 » Fri Oct 23, 2009 4:41 pm

Yeah I saw that video, very nice stuff. I'm wondering though, since all those newer ARMs have some sort of execution cache, how can you get deterministic state during video rendering (be cycle precise)??? Is there some way to flush the execution cache upon entering interrupts or something?
Anyone with more ARM experience care to throw their opinion into the pot? Tony? Uze? Anyone?

As mentioned I've only worked with the ARM7TDMI, but choosing the right MCU is not easy and in the end it can be a question of personal taste and experience with the device. However since the never ARM9 or Cortex chip are faster I'd be tempted to used them, would it be just to not bring "to market" something already old.

-Uze
User avatar
uze6666
Site Admin
 
Posts: 2694
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada

Re: superUzebox idea

Postby scuzz » Fri Oct 23, 2009 7:47 pm

TonyD wrote:Yeah, Luminary parts are a little slow (is 50MHz considered slow?)

:lol: No, 50MHz isn't really slow. But my vision is colored by all the wonderful 72MHz+ processors out there.
TonyD wrote:but they were one of the first Cortex-M3 licensees so their initial parts now look slow and lack many of the I/O interfaces of later Cortex-M3 licensees (ST,NXP, Cypress, Atmel) . That said, Luminary was recently bought by TI so you can expect TI will be pushing their parts strongly (lots of cheap offerings) and bringing out new devices.

Poking around some hobbyist forums I found the general opinion was that if you wanted some peripheral and a solid cpu, the luminary micro parts would probably have it, but they'd have it at a slower clock speed. I didn't realize the buyout had happened that recently! But then again I haven't really been paying attention until even more recently :P ...
TonyD wrote:OT - If you want to try a more exotic processor ...

Exotic was not the goal here! The goal is to have this be as friendly as the current Uzebox by trading off soldering complexity for easier debugging and software, and multicore is certainly not friendly! Though that is a really neat processor...

uze6666 wrote:Yeah I saw that video, very nice stuff. I'm wondering though, since all those newer ARMs have some sort of execution cache, how can you get deterministic state during video rendering (be cycle precise)??? Is there some way to flush the execution cache upon entering interrupts or something?

For most of the ones I've looked at you can actually flush the cache at any point, and a lot of the processors also allow for you to put blocks of code where it will run it without using the cache at all. In any case there must be a way to do it as there are a *ton* of audio/video processing ARMs on the market, and almost all of these seem to suggest that they can handle deterministic applications.
uze6666 wrote:As mentioned I've only worked with the ARM7TDMI, but choosing the right MCU is not easy and in the end it can be a question of personal taste and experience with the device. However since the never ARM9 or Cortex chip are faster I'd be tempted to used them, would it be just to not bring "to market" something already old.

I was more curious about other's personal experiences, as I have very little (I've mostly been a PIC person). While coming in with an ARM7TDMI would technically be coming to market with something old, I know that a lot of the ARM9 cpus are binary compatible with ARM7, so it wouldn't be too much of a leap to start with an ARM7 and move up later, transferring the code over slowly. Either way, I guess I was hoping to mooch off of someone else's personal preferences just because I haven't really formed an attachment to any particular ARM core yet as I've never really messed with them.

The main bear with the newer, bigger, better ARMs is the demand for multiple voltages, which as I previously mentioned makes routing on a two layer board a bit unrealistic. The really neat super ridiculous ARMs (like the OMAP) are all BGA, which makes them non-starters. Even PGA is pretty much a no-go as it would drive up the cost of the PCB far too much (it would need a 4-layer PCB and it would be really annoying to solder).

I found out that the Cortex-M3 Architecture is by design Harvard architecture which means that this is can't run code off of an SD card (at least not without it self-flashing, which would reduce the life of the CPU). So Cortex-M3 is now officially off the table as far as I'm concerned.

This was more a testing of the waters to see if there was some strong demand to design the "Super Uzebox" with a newer CPU, and whether anyone knew of excellent chips to use. The ARM7 definitely seems like it may not be the ideal choice, so I'm going through looking for ARM9 and Cortex-M series processors to see what I can find, but these appear to be generally less feature-rich than the similarly priced ARM7's out there. The ones listed above are definitely my top choices so far, but I haven't had a few hours to devote to searching yet.
scuzz
 
Posts: 73
Joined: Sun Sep 13, 2009 4:57 am
Location: Maryland, USA

Re: superUzebox idea

Postby scuzz » Tue Oct 27, 2009 3:44 am

Well, I decided to wait until the end of the weekend to see if anyone else would post a reply, but after doing some additional investigating I think I've settled on two final candidates:

1) The NXP LPC2478. The old familiar standby this one has already been explained. Sells for $14.91 on Digikey. Runs up to 72MHz, has built-in ethernet, USB (both a host port and a device port allowing for simple flashing and fun peripherals), 32bit-wide memory bus (which I think will allow for close to full speed execution off of the RAM), and SD/MMC support. This one also has an LCD controller, but I won't be making use of that, it only serves as something goofy for when a motivated individual decides to make a portable version :P

2) The Atmel AT91RM9200. This one was originally discounted due to the high price of $23.76, but it has a price break down to $14.91 when you buy 25 on Digikey. This seems a bit ridiculous, but basically once these get rolling hopefully we could cut costs. The main advantages over the LPC2478? A 180MHz max speed along with an integrated memory-management unit. This has no particular advantage outside of allowing plain 'ol linux to run right on the IC. This isn't the main point of the project but it certainly is a fun side effect :D (the NXP has to run uClinux). The hesitations here come from a separate core and i/o voltage making routing on a two layer board hairy. It also seems to sail completely clear of the original intent of the project :? . Yes this should be more powerful than the original Uzebox, but is this going too far?

Anyway, looking forward to some input now that the selection is narrowed down...
scuzz
 
Posts: 73
Joined: Sun Sep 13, 2009 4:57 am
Location: Maryland, USA

Re: superUzebox idea

Postby paul » Tue Oct 27, 2009 5:07 am

I'm interested in the kind of changes that would be required from the games development side of things. You guys are more qualified than I am to decide on the best chips to utilize. Let's assume everything goes to plan (for the first time in history) and it's all up and running. If we're talking snes capabilities, then making a game of that quality would probably be more of a team effort. That definitely interests me as I think it would be more fun to make a game as part of a team. But if such a culture didn't come about, then making a game solo would be a pretty big task. If you're only working on it on weekends and a few spare hours during the week, that's going to be a long time between drinks with a fairly high attrition rate.

If you make a nes quality game on snes quality hardware, then no one really cares that much. I still think it's an awesome project and I really look forward to seeing your progress, but I'm just thinking out loud. You're definitely setting the expected standard of quality with these hardware choices.
User avatar
paul
 
Posts: 416
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: superUzebox idea

Postby scuzz » Tue Oct 27, 2009 7:38 am

paul wrote:I'm interested in the kind of changes that would be required from the games development side of things.

Well my hope would be that from a purely coding standpoint I could get most of the non-kernel stuff to be 100% portable (save for assumptions like ints are something like 8 bits and the like). The kernel will of course need to be re-plumbed for that, but that's going to start as my side of work :D
paul wrote:If we're talking snes capabilities, then making a game of that quality would probably be more of a team effort. That definitely interests me as I think it would be more fun to make a game as part of a team. But if such a culture didn't come about, then making a game solo would be a pretty big task.

Well there's a lot of variability in that statement. If you make games like say... starfox, you'll probably find that you need a lot of dev time. But if you make games like Cavestory? Sure! You could do that here. Hopefully this won't raise the barrier to entry too much. The actual coding should be easier, I just don't know if this will create an explicit expectation of quality...
paul wrote:If you make a nes quality game on snes quality hardware, then no one really cares that much.

It'd be fun to see a few games that are big team projects, but it would also be fun to see games which were NES quality but with fun add-ons like internet play. Remember that they don't all have to be super-ridiculous awesome, a big part of this is not to be impressive but to be fun! And also, you might not make use of 100% of the resources all the time, it may just serve as extra hardware for a fun experiment mid-game.
paul wrote:You're definitely setting the expected standard of quality with these hardware choices.

Hence why I think I'm going to steer clear of the 180MHz monster. As nice as it may be to have an ARM9 (in a number of respects), I like the ARM7 a bit more mostly because it doesn't feel so far out of reach. With a 180MHz I think that we've rocketed directly out of the "retro-minimalist" and into "cheap computer". That being said I'm open to arguments for the ARM9, or perhaps a different ARM9 who isn't quite clocked so high. The problem is that the featureset I'd like kind of demands a higher-end ARM.

Perhaps I'm hoping for a bit too much from the built-in section, but the nice thing about a bunch of built-in features is that it leaves plenty of room for expansion with a minimal requirement of new hardware. A lot of what I'm probably going to have is sections of the PCB which have footprints for the other, non-necessary features and have the builder decide to populate or not populate those sections of board. The idea being that it can be the nice, "easy" three-chip system to start, then when you decide you want to play with it, you can add the ethernet section. The other idea being that this can drive down the initial investment in the board, so that you can just play games to start and when you feel ready and know you want to invest more, but an ethernet upgrade baggy with the $10 in parts to add full ethernet connectivity.

Anyway, I hope in my rambling I managed to answer your question :P .
scuzz
 
Posts: 73
Joined: Sun Sep 13, 2009 4:57 am
Location: Maryland, USA

Re: superUzebox idea

Postby TonyD » Tue Oct 27, 2009 10:05 am

I would definitely consider one of the smaller (pin wise) ARM's first and then progress to a heavy weight champ. The LPC2478 is a pretty big chip at 208-pins :!: .

IMHO I feel its pin count will put off a lot of potential builders :( .
- Tony

http://zuzebox.wordpress.com/
User avatar
TonyD
 
Posts: 120
Joined: Mon Oct 27, 2008 2:23 pm
Location: Newcastle, UK

PreviousNext

Return to Uzebox Derivatives & open source consoles

Who is online

Users browsing this forum: No registered users and 2 guests