XDreamMegaStationUzeBox?

Discuss general Uzebox topics here: features, wish list. nice to have, etc.
Lerc
Posts: 64
Joined: Sat Aug 30, 2008 11:13 pm

XDreamMegaStationUzeBox?

Post by Lerc »

So I saw user alamothe was asking about the 1284P on avrfreaks.

Another one entering the game perhaps?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: XDreamMegaStationUzeBox?

Post by uze6666 »

Haha that's a good one. Do you have the link to the thread?
DavidEtherton
Posts: 252
Joined: Tue Dec 02, 2008 12:38 am
Location: Carlsbad, California (USA)

Re: XDreamMegaStationUzeBox?

Post by DavidEtherton »

Just do a search on user "alamothe".

There were three threads, one that was very old and one that was pretty old, and this one:

http://www.avrfreaks.net/index.php?name ... highlight=

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

Re: XDreamMegaStationUzeBox?

Post by uze6666 »

Mhhh, but that post doesn't mention the mega1284?
ravyne
Posts: 59
Joined: Thu Sep 25, 2008 7:59 pm

Re: XDreamMegaStationUzeBox?

Post by ravyne »

So, I'm semi-active over on Andre's xgamestation site (I was one of the Hydra Demo coders). He's been touting for a couple months his new 8 and 16 bit systems, though he's never said which microcontroller arch he was using... I guess this clears up that mystery.

So, I don't think he's getting into the Uzebox game, I don't think he'd spring to put the TV encoder on board because its too expensive, and doesn't get much cheaper in volume, so a part that's 2-4 times as expensive as the MCU isn't terribly attractive from a BOM point of view.

What we know is that these new systems are different MCUs in the same family -- I'm betting the 644 in the 8bit and an xmega in the 16bit -- with all surrounding hardware being identical. It has VGA, composite video, mono audio... possibly sVideo (I forget) It has a miniSD, 2 DB9s which interface custom NES-compatible controllers (electrically speaking, not physically) and PS/2 keyboard/mouse. They're supposed to be relatively cheap -- ~100 USD each.

Kind of an interesting discovery really, until now my money was on PICs.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: XDreamMegaStationUzeBox?

Post by uze6666 »

-- I'm betting the 644 in the 8bit and an xmega in the 16bit --
Ya know, the xmegas are still 8 bits...don't you? :)

Anyways, many thanks for the heads up. The Uzebox never meant to compete on Andre's turf. He's commercial, I'm open source. Moreover, I never really liked the propeller chip. IMHO, it's too complex for the market it's competing in. Hence the 644 choice. But you already know that also, eh?! ;)

Out of curiosity, what's the game you did on the Hydra?
Lerc
Posts: 64
Joined: Sat Aug 30, 2008 11:13 pm

Re: XDreamMegaStationUzeBox?

Post by Lerc »

Moreover, I never really liked the propeller chip. IMHO, it's too complex for the market it's competing in. Hence the 644 choice. But you already know that also, eh?! ;)
I really liked the propeller in bullet point form, but once I delved deeper I went off it. 80Mhz looks good until you find that instructions aren't single cycle. and the instructions are large but in a small space. Lot's of little things here and there to take the shine off.

When is someone going to make an 8 core AVR with 32k shared memory. I'd buy me one of those :-)
ravyne
Posts: 59
Joined: Thu Sep 25, 2008 7:59 pm

Re: XDreamMegaStationUzeBox?

Post by ravyne »

But they advertise the Xmegas at 8/16 bit don't they? I assumed I should read that as 8bit core with 16bit math instructions, but I guess that's marketing for you...

I never developed anything large on the hydra, though I've got a few ideas kicking around for a nice video kernal using the 723/725 and 4 of the cogs. It is a PITA to deal with in a lot of ways, but its got an awful lot of power if you can harness it right. Even if you divy out the cores, 4 for graphics, 1 for I/O, 2 for sound and 1 for game code (running an interpreter or Large Memory Model kernel to execute from shared ram) you've got a lot of power to run the logic -- a couple million instructions/second and they're 32bit to boot. No multiply or divide though... Also, the video generator can be helpful, and the deterministic scheduling allows you to interlace instructions with shared resource access optimally.

On the downside, you basically have ASM, Forth, C (which is commercial and expensive), or SPIN (Significant whitespace anyone? It sucks HARD, but is required in at least small part to get things going, just as a compulsory kick in the ribs).

The next version of the propeller is going to scream though. The word from the engineers on the official forums is 256k shared RAM with 16 cores running at 160Mhz, all instructions will be single-cycle (save accessing shared resources, which will be allowed only once every 16 cycles due to the round-robin access pattern) and they're adding multiply and possibly partial divide and MAC(also all single cycle), as well as some concessions for running Large Memory Model Kernels and high-level languages. Add it all up, and you've got a potential for 2.56 billion 32bit Instructions per second (or 5.12, if they add MAC and you count it as 2, but I always thought using MAC like that a bit unrealistic since you're never going to have a program comprised solely of MACs :roll: ) Really pretty crazy for something that will be a 10 or 15 dollar chip, if you can harness it all, that is. I've already written an LMM kernal for the new chip which packs 2 instructions in each word, allowing about 20 MIPS throughput per core in a high-level language vs. the 10 MIPS you'd get otherwise, but I'm also spending some background cycles on whether a bytecode interpreter would have less overhead allowing for some frequent instruction sequences to be "microcoded" within the interpreter, yielding more effective MIPS -- The current method I use spends a lot of time just decoding, and any memory write or "microcoded" instructions would eat up 2 additional interpreter cycles (or about 32 machine cycles in total) each due to access scheduling, reducing throughput to just 2.5 MIPS.... but I digress :lol:

I never did write a complete game because I got busy at a new job just when I got my demo unit. My sole contribution was a command line disassembler for Propeller binaries, which I felt a bit bad over since the demo units were about 5 grand apiece (the propeller chip was literally manually inspected/tested by the chip designer under microscope, and in some cases die-corrected with a fancy and very expensive machine). Even that was a bit limited since it doesn't spot Data or Spin byte code since I couldn't get any information on the binary format -- I still haven't found any documentation on that to this day.
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: XDreamMegaStationUzeBox?

Post by havok1919 »

ravyne wrote: Even if you divy out the cores, 4 for graphics, 1 for I/O, 2 for sound and 1 for game code (running an interpreter or Large Memory Model kernel to execute from shared ram) you've got a lot of power to run the logic -- a couple million instructions/second and they're 32bit to boot. No multiply or divide though... Also, the video generator can be helpful, and the deterministic scheduling allows you to interlace instructions with shared resource access optimally.
The Propeller is interesting and I don't want to slight Chip's work on it (I know he was working on it for ages), but I fear it will remain little more than a curiosity. :|

On one end you've got stuff like ARM Cortex devices with better than one instruction per clock throughput, single cycle hardware multiply and devide, tons of peripherals, DMA's, full memory crossbars, compatibility across a bunch of toolchains from established vendors, etc. You've got major foundries/manufactuers so you get to ride the process geometry curve and you've largely got code compatibility across product lines and architecture compatibility across vendors. $14 in singles gets you a 72MHz ARM Cortex M3, 512K of onboard flash, 64K of onchip SRAM, 112 IO's, and a boatload of peripherals... The STM32's for example can even sit inside nested footprints in TQFP so you can scale from smallest to largest package and smallest to largest memory and speed on the same PCB just by changing the CPU IC across the family.

On the other end of the scale you've got stuff like the Kilocore256 from Rapport. 100MHz * 256 cores on one chip. If you want an obscure programming model, that's the one to beat. ;-)

Keeping a 160MHz Propeller fed with data is going to be a chore and you're tied in to a single vendor and little hope of much diversification in product roadmap... I guess I just see it as a hobbiest plaything; I can't imagine ever steering a client towards that! I suppose once someone shows me a project done on the Prop that *can't* be done on a $$$-equivalent amount of ARM I might change my tune, but right now it seems a bit like the proverbial hammer looking for nails.
The next version of the propeller is going to scream though. The word from the engineers on the official forums is 256k shared RAM with 16 cores running at 160Mhz, all instructions will be single-cycle (save accessing shared resources, which will be allowed only once every 16 cycles due to the round-robin access pattern)
That could be neat for some image processing apps or other neatly parallelable tasks. The gotcha of course being if you need to flush that internal RAM to access a larger dataset you'll take a hit to reload. Unless you've got some seriously scary memory interfaces on it (with the appropriately frightening PCB layout to go with it) I see it being bus/memory bound. Still neat in to think about though...

-Clay
User avatar
TonyD
Posts: 134
Joined: Mon Oct 27, 2008 2:23 pm
Location: Newcastle, UK
Contact:

Re: XDreamMegaStationUzeBox?

Post by TonyD »

havok1919 wrote: On one end you've got stuff like ARM Cortex devices with better than one instruction per clock throughput, single cycle hardware multiply and devide, tons of peripherals, DMA's, full memory crossbars, compatibility across a bunch of toolchains from established vendors, etc. You've got major foundries/manufactuers so you get to ride the process geometry curve and you've largely got code compatibility across product lines and architecture compatibility across vendors. $14 in singles gets you a 72MHz ARM Cortex M3, 512K of onboard flash, 64K of onchip SRAM, 112 IO's, and a boatload of peripherals... The STM32's for example can even sit inside nested footprints in TQFP so you can scale from smallest to largest package and smallest to largest memory and speed on the same PCB just by changing the CPU IC across the family.
Agree with you Clay. STM32F103VE (512KB Flash, 64KB RAM, 100pin QFP, 72MHz, Digikey ~$14) looks a winner. It also has an external bus so if 64K of RAM is not enough for you, you can slap on a external RAM chip.
On the other end of the scale you've got stuff like the Kilocore256 from Rapport. 100MHz * 256 cores on one chip. If you want an obscure programming model, that's the one to beat. ;-)
Kilocore256 looks awesome. But can you silicone for it? If you want something here and now, have a look at Xmos (http://www.xmos.com) who have a 4-core 32-bit device. 4x 32-bit cores running at 400MHz, each core with 64KB of RAM and each has access to 64 I/O pins, high speed serial links to other cores and other external XS1-G4 devices. Their on-line store has XS1-G4 512BGA Package costs $31.30 and smaller package XS1-G4 144BGA Package costs $20.90 for low volumes 1+/2+. Expensive compare to 644 or STM32. Development board is available for $99. A couple of Xmos users are already designing 'stamp' like boards for the smaller device. Only downside is they are BGA devices which makes building your own boards next to impossible unless you have a smt reflow oven. Xmos have promised a QFP type package version but it looks like it will just have one 32-bit core.

- Tony
Post Reply