superUzebox idea

[scuzz]

I was actually going for the 208-pin package because it featured a 32-bit wide external memory bus (and more than 64KB of RAM). And really, the 144-pin package (LPC2388) is not much friendlier...

[TonyD]

I'm definitely not knocking you or the superUzebox because as I've already said I think it's a really cool project, but having hand soldered 208-pins SM chips in the past its not an easy thing to do and get right and I feel IMO it will scare off a lot of builders. But having said that I'm sure the others here, myself included, would love to see the superUzebox fly and only be too willing to offer advice and help. So go for it

[uze6666]

Btw, I just want to mention that I'd like to retain the name Uzebox for this project only for the moment (meaning 8-bit-retro-minimalist). I don't think the name is yet synonymous with "NES/SNES" so better not dilute the "brand" at this point.

-Uze

[TonyD]

OK, no to calling it SUzebox or Uzebox32 etc.

[uze6666]

Well, thing is, such console wouldn't have much in common with the current design. Your Zuzebox is fine since it's an extension and 100% compatible with the current Uzebox. That said, I'm willing to reconsider...got to give it some thinking.

-Uze

[scuzz]

So... I'm tentatively going to call it the Scuzzbox? (I see a theme here, maybe I should redo my account name as "Scuzz6666" )

I'm hoping that it will be "uzebox compatible" under the assumption that I keep the kernel calls the same and I have something which auto-casts a current Uzebox games into an 8-bit kernel mode or something. Hopefully the end product would essentially be an extension which would be able to play current Uzebox games (yes, they would have to be recompiled but I'm hoping that I can do something which makes that a less painful process), and then have an "updated" kernel which utilizes the complete feature set. Essentially every game would start up in 8-bit mode, then have a kernel call to jump into full 32-bit mode, or start in 32-bit mode and have a call to jump into 8-bit mode (this would require old games to have a line added at the begining to make the switch).

This is probably going to end up making me insane (this must be why Windows is so terrible ), but when we get to that bridge we'll figure it out. I'll probably come back here for votes on how to handle old-kernel, new-kernel transferring. Should old games have to have a line added to leap into 8bit mode? Or vice-versa?

(Note: don't vote on this now unless you really want to. I probably won't remember )

[paul]

Hmm, well the online dictionaries might suggest people would think twice before opening a Scuzzbox to play a game, but there appears to be a tv channel in Britain with a similar theme, so maybe it's not a common interpretation of the word.

[scuzz]

...Which online dictionaries? Urban dictionary doesn't define it and dictionary.com offers "suzzbag." So yes, I suppose scuzzbox may not be the best name but I like it

[paul]

...Which online dictionaries? Urban dictionary doesn't define it and dictionary.com offers "suzzbag." So yes, I suppose scuzzbox may not be the best name but I like it

This one and others. You should go with what you like, but if it ever ends up in some tech blog, it could get some odd comments. But as they say, any publicity is good publicity.

[boondaburrah]

Well, from a hobbyists perspective, it would be great if the microcontroller and other components are easily sampleable.

ST has a great sampling program for their STM32F series of microcontroller, which you can get in up to 256k flash/64k RAM. Out of that I would go with either the STM32F105 or 107, because they have an I2S interface for sound. The STM32F107 series also comes with Ethernet. Sound could be done through a PCM1748 Stereo DAC (found it on ladyada's mintyMP3 page), which is also sampleable from TI. I would favor the 64-pin packages, mainly for soldering reasons, though they're available in 100-pin as well. One drawback though, is none of them seem to have external RAM interfaces, so it would have to be done in software. The only microcontrollers ST offers for sampling with that are the older STR7 series, which don't have nearly as many features, and ar ARM7TDMI based rather than the STM32F's Cortex-M3, and run slower. (If I remember correctly.) Also, the STM32F series is featured in some ARM-based Arduino lookalikes (and have the software to match) and are available from Futurlec in $25 dev board, though these are STM32F103s (No I2S for sound, but I'm sure it's still possible somehow). Also, you don't need a JTAG interface to program them, because they have a built in serial bootloader. You just need a USB-to-serial dongle and a python script I found using google. That alone makes the console at least $20 less (If you have a parallel port) to build (For some reason ARM-JTAG seems to be expensive, with a USB dongle being $50-70). Most hobbyists probably have a USB-to-Serial doohickey laying around if they've worked with any other microcontrollers (I think).

I've been taking a look at some of Atmel's offerings, and they look good, but I can't tell how their sampling works. TI offers a lot of Cortex-M3s for sampling, but I haven't had the time to attempt to sort through their system. It's really hard to figure out what MCU will do what on their site.

I couldn't figure out how to sample from NXP's site, looks like you might not be able to.

Disclaimer: I haven't actually done any ARM hacking myself- it just seems that there's a lot of schematics and stuff out there for the STM32F series, and they seem to be readily available.