Slashdot Mirror

On an aside, a point I wanted to make about the 128MB of memory announced for this device - I'm guessing that this may be for storing downloaded games, much like the iQue that Nintendo's released in China... 128MB is definitely overkill for handheld games as RAM (the PSP is only set to have 32MB), but as flash or similar it could store several GBA-sized or N64-sized games on it.

Arguibly, ARM is weak in math. The original ARM cores indeed do not feature any floating point facilities, but there have always been facilities for IEEE754 floating point in the architecture. Indeed, there are hardware implementations in the form of co processors and software emulation.

The only reason FPUs were not integrated in StrongARM is that there cost (in terms of Watts) is not justified by the small benefit to performance (in terms of MIPS/FLOPS). Aparently, FPUs, in their current form only make sense for lack of anything better.

If MIPS/Watt is the focus, why not use Intel's StrongARM, XScale or other ARM based cores rather than Transmeta's stuff. Afterall, ARM was designed specifically with the MIPS/Watt ratio as objective, starting a whole new architecture from scratch. Whereas Transmeta has focussed on effectient x86 "emulation".

--
Real computer scientists despise the idea of actual hardware.
Hardware has limitations, software doesn't.
It's a real shame that Turing machines are so poor at I/O.

With a modern optimizing compiler STL vectors and lists become as efficient - or more efficient - space and speedwise over your own hand rolled code.

Is GCC 3.3.1 such a "modern optimizing compiler"? Or do C++ programmers have to shell out upwards of $6,000 per seat for the processor core vendor's own compiler in order to reap the benefits of STL?

You might try an Arm processor, many of which have great built-in features (like NIC, daq, memory management). You can get demo boards, and run linux + related gnu tools on them. ARM-based systems make great embedded/distributed systems (aka 'the future'), and are a useful to learn for the old-resume.

Most average or medicore managers don't like "really smart" people under them. They worry that you may make them look bad (be vindictive), or be a snob and put other team members down.

Ph.D. have a reputation of being not good team players. This comes from working alone on your thesis for a number of years, often independantly and not in a team of close knit research group. All real world companies need team players, because no one person can (or should) do everything.

Hiring staff (HR or the technical manager) avoid PhD for low/entry level positions because of the bordom and leaving factors. They worry that you will leave at the first better job offer. The best way to fight this is, if you really are excited about the job, show your excitment, and try to only take interviews with jobs you plan to stay at.

Once upon a time I had an interview at ARM the microprocessor design company, they were looking for a couple of IT positions (security and development) and my CV interested them. When I got into the interview, the fact that almost got me hired was that I was a licensed amateur radio (ham) operator. Since hams tend to have a boat-load of practical hands on experience with building and fixing things, they were very keen on this. I wasn't going to touch a MPU design, or even work on embedded systems, but it was this practical experience that they looked for.

If you want to work for AMD, Intel, ARM, IBM Research, Microsoft Research, or AT&T Research, then get your Ph.D. If you want to muck with designing systems to be build, get your Masters and get experience.

Education is important, but experience is golden.

This article from a sibling post makes it sound like Samsung doesn't have an architectural license.

I admit that I'm a little disappointed with XScale, but have you heard of the Halla? If you could get that core in an OMAP-like SoC...

SWEET!

... but he does misses one of the major problems with RISC architectures, the fact that RISC executables are larger that CISC programs (since RISC usually have simpler instructions and fixed instruction length). Today CPUs are fast, but memory are not. Because of this modern computers have large caches, 800MHz FSB, dual DDR memory busses, etc, but still the memory is slow compared to the raw computing power of the CPUs. But since a CISC program is smaller, the memory pressure is lower on a CISC system, and that's one of the reasons way the RISCs don't have the (on paper) large advantage compared to the CISCs.

This was not true 10 years ago, since the memory timing back then was in the 25MHz range, and the CPUs where running 20MHz. Today we have 3.2GHz CPUs and memory at 800 MHz, so program size matters.

Modern ARM RISC CPUs have worked around this problem by adding an extra instruction set called arm thumb, to make the program smaller. Smaller programs = faster execution on the same memory system

... but he does misses one of the major problems with RISC architectures, the fact that RISC executables are larger that CISC programs (since RISC usually have simpler instructions and fixed instruction length). Today CPUs are fast, but memory are not. Because of this modern computers have large caches, 800MHz FSB, dual DDR memory busses, etc, but still the memory is slow compared to the raw computing power of the CPUs. But since a CISC program is smaller, the memory pressure is lower on a CISC system, and that's one of the reasons way the RISCs don't have the (on paper) large advantage compared to the CISCs.

This was not true 10 years ago, since the memory timing back then was in the 25MHz range, and the CPUs where running 20MHz. Today we have 3.2GHz CPUs and memory at 800 MHz, so program size matters.

Modern ARM RISC CPUs have worked around this problem by adding an extra instruction set called arm thumb, to make the program smaller. Smaller programs = faster execution on the same memory system

Wrong, ARM is the best selling architecture by a clear margin. Used in cellphones, PDAs, gaming consoles, DVB/DAB devices, and well, just about everything you can think of, the x86 isn't found much outside of the desktop and low-end server markets.

The ARM company milestone list mentions "ARM announces that it has shipped over 1 billion of its microprocessor cores to date" at the start of 2002...

I think I can safely say that ARM has shipped approximately 0 processors. They have, however, licenced their technology to a whole range of semiconductor manufacturers, including Intel, who do all the mucking about with silicon and god-knows-what.

Ok, I'm being a little pedantic.. I'd be interested to know how many ARM processors had been produced by all these manufacturers - must be quite a few!

But check out this game available for ARM handhelds. Its available here, and is actually pretty cool. I'm not sure if someone has already ported Quake to ARM processors (I'd be very surprised if they haven't), but the current crop of ARM processors seem to be high powered enough to run demanding applications.

Oh yeah, the yet in the subject refers to the fact that ARM devices are making the push to the wireless space in a big way.

The chips aren't being made by Sun, but by ARM who provide jazelle. ARM is a much bigger player in the embedded market anyway. Also, look at how many mobile phones already do and will support Java and you will see why Java on silicon is alive and well.

SECURITY AND DIGITAL RIGHTS MANAGEMENT (DRM)

ARM is also bringing secure solutions to market for its digital audio customers. In conjunction with its partners, ARM is working to ensure DRM solutions from companies including Liquid Audio, Intertrust and Microsoft are supported to enable OEMs to develop solutions that manage rights-protected content.

They have developed software that emulates the obsolete Acorn Microcomputer system and the video disc player.

They're basically targetting mobile phones and similar embedded systems like PDAs, because this is where ARM's main market share is at the moment. They say that they're looking at a more system-wide approach than is currently used, and they want to standardize the embedded software/hardware interface as part of this.

Also, note that "samples available Q2 2003" doesn't necessarily mean actual silicon. ARM doesn't make chips, they license their designs out to other companies which use them as a basis for an actual chip, so a "sample" quite likely means a software simulation. Actual devices which use this technology probably won't be around until 2004 at least.

think not how many PC's but phones

all new phones have Bluetooth

take a long hard look at the semiconductor world and in terms of volume x86 makes up under 1% this year compare this to the ARM and MIPS world which make up your Set Top Box, NIC, and mobile phone

ask yourself how many phones per person ?

regards

John Jones

p.s. phone booth and of course www

p.p.s. I can actually format URL's cant you ?

Bit of history. Admittedly the StrongARM is made by Intel now (after they brought Digital who previously made it), but the ARM core technology inside it is still (c) ARM Plc who are a totally independent company selling to a wide variety of chipset manufacturers. ARM, themselves, are NOT owned by Intel.
Apple, IIRC, have around a 25% share in ARM (Advanced RISC Machines, but used to be Acorn RISC Machines when they started out, but Acorn has been 'defunct' for 2yrs+ now as soon as it was realised that the Acorn Group PLCs share of ARM was worth more than the total share value of Acorn :( ).
StrongARM chips were originally used in desktop machines, I've got a 202Mhz SA in my Acorn RISC PC desktop machine - admittedly it's around 7 years old now, but in it's day it was a damn good machine: Acorn themselves (not ARM) weren't very good in marketing...

No, Intel never bought ARM, they are still around and still own the rights to the ARM IA. However, the StrongARM CPU was not actually designed by ARM, but rather DEC, who licensed the instruction set from ARM. Actually, if memory serves, DEC designed the StrongARM somewhat at the impetus of Apple at the time the Newton was being developed. A few years later, DEC sued Intel over something completely unrelated: Intel had stolen part of the Alpha design and implemented it in their own chip. Intel basically conceded this, and they reached a settlement part of which included Intel buying much of DEC's semiconductor business, including the 2114x Tulip ethernet chipset, and the StrongARM. Intel basically ignored the StrongARM for a while during which time it became rather popular in embedded devices, and now they have renamed newer versions the "XScale" and started actually marketing them. Probably Intel would love to drop the chip and stop paying royalties to ARM, but their clients would just buy other ARM processors from other manufacturers, and they would not benefit at all.

[shameless plug]

I'm an embedded development and training consultant. I have a tutorial on my website that features the ARM Evaluator 7T board (about $250) and a complete procedure for building the arm-elf GNU toolchain and debugging a simple "hello, world!" program.

I have both onsite and public training courses available, and I'm working on an elearning site as we speak. I'm also available for just plain old embedded development tasks. See my resume.

The ARM7TDMI chip that the Evaluator 7T uses doesn't have as many peripherals as the eCog chip you mention, but it is a true 32-bit chip with a GNU-supported instruction set and debugging environment. Hard to beat that!
[/shameless plug]

HTH,

The StrongARM is Digital's high speed implementation of the ARM architecture designed in the UK; Intel bought all of DEC's chips, including the ARM licences, which have allowed it to design the XScale. I suspect that you are thinking of the Amulet chip, developed at Manchester University.

Actually, it has been attempted. Sun created a java chip, called picoJava. There also is an ARM chip with a hardware interpreter for JVM bytecodes, Jazelle. There are plenty of other examples of this.

Nothing that sits on the mobo to supplement a 'real' CPU tho.

Is there a reason why these virtual machines aren't taken as a blueprint for real hardware and implemented as such?

I'm no hardware guy. But I have a wee bit of experience hacking on the Smalltalk virtual machine. I imagine that this is so because VMs are designed as VMs, not as a blueprint for hardware. To support an entire computer, I wouldn't be surprised if you had to add a lot more instructions than most VMs provide.

• The hardware supports carts up to 256 megabit (32mb) in size. There are flash carts which have more space, however, through software bank switching. No commercial ROM currently even hits the hardware size limit (manufactureing costs, it is widely believed, are to blame; it may be the case that Big N limits the available size of carts to both themselves and third parties)
  
• Yes, a linux distro would fit. No, it wouldn't be any fun without a keyboard. Yes, TCP/IP has already been done (a working webserver, which IIRC was even on SlashDot already. That's what caused me to try to post the homebrew dev scene the first time.)
  
• Emulators: there are about a dozen good ones around; many stick to VisualBoy Advance and Mappy Virtual Machine for development. VBA is often regarded as the best and fastest emulation, and Mappy is usually seen as having the best debugging tools (source-level breakpoints, register viewing, disassembly, viewers for most of the important chunks of RAM, etc). VBA interfaces with GNU debuggers, but I'm lazy, and haven't tried it.
  
• How good is the processor? Good enough to emulate an NES? Yes. In fact, there's a port of an emulator which runs NES binaries which were stapled onto the end of the emu binary out there already (it uses scaling and rotation to fit the otherwise too-large pictures; some detail is lost, so text often looks funny, etc). I have no linkage; sorry.
  
• To be specific, the processor is an ARM7 TDMI running at approx 16 mhz. Also, the screen does 60hz refreshes, is 240x160, and has a bitmapped 15bpp color mode (among other modes, including z-buffered modes). The programmer is afforded extreme memory mapping flexability by the hardware; it's more fun than a Rubix' Cube.
  
• Sorry - should have clarified - the ones I listed are all emulators for the GBA. Sorry, but not even remotely close. You didn't even get the popular ones. There's a pretty decent list here, at Zophar's Domain (a pretty good dev site)
  
• Descent is probably beyond the GBA's capabilities, since it uses arbitrarily-angled perspective-correct textured polygons, which are a fair bit harder to render on a low-end CPU (the GBA has a 16MHz ARM7 CPU).You should see some of the stuff that's going on. There are a number of fully textured 3D engines out there, one of which actually uses Descent levels as its examples! (I linked to another in my previous post which uses the quake level 1) A good example is the Raylight engine, though there are probably a dozen that I've seen (and a few proprietary, one of which I'm about halfway done writing :) )
  
• Hey, maybe we'll see Tux Racer for the GBA? That'd be tight. Quite possible. A racer wouldn't be difficult - the floor is a mode 7 S/R background, the sprites are prerendered, and there's enough VRAM that they don't need to be DMAed into place or anything (though people do that anyway, often enough [grins])
  
  Actually, how low-level is the API? Any chance someone could get Linux running on one of these babies?"The API" isn't. HAM has an engine, SGADE has an engine, there are others (I don't use them), and there are some commercial ones. But, here's the thing: the hardware does a lot of stuff. Sprites and backgrounds are supported in hardware, and do scaling and blending stuff, etc. It's just register tweakage. You don't really need an API.
  
  Big N does send an API of some sort, but I'm not a licensed developer, so I know dick about it. I'm told it's not that much of a difference - mostly just wrapper functions.
• well if you realyl want to consider assembler an API, that is your answer. ARM flavored assmebler. We're not stuck to Assembly. Though there are about six assemblers in common use (the one that gets most use as not just part of a toolchain seems to be GoldRoad, but because I don't use assembly except in-line, I have a biased perspective), there are also a buttload of C and C++ and so forth compilers. Because Gnu's Compiler Collection (GCC does not mean gnu's c compiler) works and is the common compiler for the homebrew platform, you also have access to *compiled* java, pascal, and I think Objective C and Forth, or Fortran, or something that starts with an F. Too lazy to go check. :)
  
  There are other compilers which can target the platform. Commercial people often use the ARM ADS or SDT. Other tools, like the Metaware toolchain and the Green Hills Optimizing Compiler (it's part of the name, not a parroted description, settle down) are commonly used because of their purported performance. Far from being an expert myself, I'll just point you at the Dhrystone that David Welch graciously presented to the community.
  
• I was planning on trying to develop something on my friends PS2 when he got the Linux kit. But since I actually own a GBA, this is a much more worthy project. More worthy, but more difficult. You'll want a flash cart and linker - the hardware is still the only perfect binary executor, though VBA is pretty impressive. All told, the PS2 Linux kit isn't more expensive, and it's hella more fun in the long run (Tux Racer on a console anyway, doncha know!)
  
• At about $70 (Game Boy Advanced, Amazon price [amazon.com]), you can create custom games, ports of other things, etc. This sounds to me like a much more practical thing to purchase to play around with the the PS2, which is in at least the $500 range to start hacking your own stuff for. You're counting just the hardware in one, but the hardware and the mod stuff in the other. $200 (ps2) + $200 (Linux kit) is $400. There was a recent price drop. $70 (AGB) + $40 (USB Flasher) + $15 (Power cable for flasher) + $10 (Parallel cord) + ~$100 (Average flash cart - price varies by size) = $235. Granted, a $175 price difference, but not what you implied. Also, a lot of us already have both. Then, the price of a homebrew kit actually weighs in the other direction, and the AGB is small and limiting enough that unless you really want to, it's a pain of a challenge.
  
• It would be interesting to know how many people will create practical, non-game applications. I know there are many non-game attachments, like a TV tuner and digital camera available for the unit. There are already music sequencers, methods of connecting it (realtime!) to a PC for chatter, MIDI sequencers, connections to serve as visualizers for various kinds of data collectors (think forest service), and a host of weird homebrew things that aren't exactly games. I expect quite a few more over time; I'm working on one in a half-assed way right now. Moreover, over time I expect level editors for at least homebrew games, and possibly for commercial games; would you call those applications?
  
• This would totally rule.. I'd love to see Nethack for the GB. I'm currently working on a Palm version, and of course, it'll work on Windows CE, but honestly, wouldn't Nethack be an awesome alternative to bejeweled on the bus?Shhh... Shen Mansell already has Moshpit put together, and there are three or four people already rumbling about alternatives on the list. Also, note that I'm on alt.games.roguelike.development making an ass of myself all the time... (For those who may be Ccurious, a BooFly is a creature which looks like Will Riker and which doesn't meet me for coffee at E3. Thpppbbt.)
  
• I think that companies like Nintendo and Sony and such should sell stipped down dev kits for like, say $50... including software you'd need and maybe a transfer cable. This gets kicked around a lot in the chatrooms and on the dev lists. The consensus seems to be that yeah, it'd be nice, but though a lot of people would really use it for what it was for, a whole lot of people would use it to pirate games, and besides, Big N's licensing fees per cart and hegemony on software support their business model, so they'd be hurting themselves anyway. In conclusion: not bloody likely.
  
• No disrespect to the great underground game hackers out there, but I don't think there is much of a risk of an uber fantastic game like Gran Tourismo 3 getting put out. Whereas art and sound resources usually make this true, with time, they actually often do. Take a look into the very mature NES or 2600 development scenes; you'll see things you'd never imagine possible (for instance, someone ported the Z-Machine interpreter Frotz to the GameBoy Advance as GBA Frotz, which seems impressive until you realize that the no$gmb guy, who I think is Martin Korth or something, and who really needs to put his damn name in his bio page, did it for the gameboy(!) in *8* *K* of RAM (far smaller than the real Z-Machine was supposed to be), and it works fine! Linkage
  
  Homebrew developers thrive on being told it can't be done. The more you tell them they can't do commercial stuff, the more you're going to see commercial stuff done. That's what got me started. :)
  
• Yes, Craig Rothwell is reliable (someone else's post). Also, though Lik-Sang is reliable (that's where I got mine), right now cyustoms is banning the import of these, and so you won't get one even if lik-sang mails it to you. Craig Rothwell currently goes under their radar, but don't try him if you're seeing this post a month or so old - things may have changed (they often do, unfortunately). The best thing to do is to go to the Yahoo! Group and ask; you'll get a lot of replies in 48 hours.
  
• I know that the Game Cube can use GBA as controllers. I am not sure what the interface protocol is like, though. Do you think that it might be possible to make custom GBA carts for Cube games, that provide enhancements (cheats, etc) to a game playing on the Cube? No. The GC uses half-size DVD discs which are difficult to burn and which have not yet had their protections cracked or circumvented. Things may change later.
  
• So does this mean that with the ROMS that are for the SNES, we could somehow make our own port of say "Secret of Mana" (or some other SNES title) for the GBA? That would be awesome! Though probably not awesome enough for me to spare time to learn this. If you're dedicated. you need to scale a lot of graphics down; the sound hardware is completely different, so the audio stuff will need to be wholly rewritten. There are odd considerations due to the different CPUs. But, yeah, many people have been porting SNES and Genesis games commercially; I don't see why a team of amateurs with lots of time and skill couldn't do the same. It's not easy, though, mind you.
  
  This is our world now...the world of the electron and the switch, the beauty of the baud. Pre-chewed pieces of pap! And shouldn't be teaching anyway!!@!3T1!! r00l!
  
  cough Sorry. Old habits die hard.
  

• The hardware supports carts up to 256 megabit (32mb) in size. There are flash carts which have more space, however, through software bank switching. No commercial ROM currently even hits the hardware size limit (manufactureing costs, it is widely believed, are to blame; it may be the case that Big N limits the available size of carts to both themselves and third parties)
  
• Yes, a linux distro would fit. No, it wouldn't be any fun without a keyboard. Yes, TCP/IP has already been done (a working webserver, which IIRC was even on SlashDot already. That's what caused me to try to post the homebrew dev scene the first time.)
  
• Emulators: there are about a dozen good ones around; many stick to VisualBoy Advance and Mappy Virtual Machine for development. VBA is often regarded as the best and fastest emulation, and Mappy is usually seen as having the best debugging tools (source-level breakpoints, register viewing, disassembly, viewers for most of the important chunks of RAM, etc). VBA interfaces with GNU debuggers, but I'm lazy, and haven't tried it.
  
• How good is the processor? Good enough to emulate an NES? Yes. In fact, there's a port of an emulator which runs NES binaries which were stapled onto the end of the emu binary out there already (it uses scaling and rotation to fit the otherwise too-large pictures; some detail is lost, so text often looks funny, etc). I have no linkage; sorry.
  
• To be specific, the processor is an ARM7 TDMI running at approx 16 mhz. Also, the screen does 60hz refreshes, is 240x160, and has a bitmapped 15bpp color mode (among other modes, including z-buffered modes). The programmer is afforded extreme memory mapping flexability by the hardware; it's more fun than a Rubix' Cube.
  
• Sorry - should have clarified - the ones I listed are all emulators for the GBA. Sorry, but not even remotely close. You didn't even get the popular ones. There's a pretty decent list here, at Zophar's Domain (a pretty good dev site)
  
• Descent is probably beyond the GBA's capabilities, since it uses arbitrarily-angled perspective-correct textured polygons, which are a fair bit harder to render on a low-end CPU (the GBA has a 16MHz ARM7 CPU).You should see some of the stuff that's going on. There are a number of fully textured 3D engines out there, one of which actually uses Descent levels as its examples! (I linked to another in my previous post which uses the quake level 1) A good example is the Raylight engine, though there are probably a dozen that I've seen (and a few proprietary, one of which I'm about halfway done writing :) )
  
• Hey, maybe we'll see Tux Racer for the GBA? That'd be tight. Quite possible. A racer wouldn't be difficult - the floor is a mode 7 S/R background, the sprites are prerendered, and there's enough VRAM that they don't need to be DMAed into place or anything (though people do that anyway, often enough [grins])
  
  Actually, how low-level is the API? Any chance someone could get Linux running on one of these babies?"The API" isn't. HAM has an engine, SGADE has an engine, there are others (I don't use them), and there are some commercial ones. But, here's the thing: the hardware does a lot of stuff. Sprites and backgrounds are supported in hardware, and do scaling and blending stuff, etc. It's just register tweakage. You don't really need an API.
  
  Big N does send an API of some sort, but I'm not a licensed developer, so I know dick about it. I'm told it's not that much of a difference - mostly just wrapper functions.
• well if you realyl want to consider assembler an API, that is your answer. ARM flavored assmebler. We're not stuck to Assembly. Though there are about six assemblers in common use (the one that gets most use as not just part of a toolchain seems to be GoldRoad, but because I don't use assembly except in-line, I have a biased perspective), there are also a buttload of C and C++ and so forth compilers. Because Gnu's Compiler Collection (GCC does not mean gnu's c compiler) works and is the common compiler for the homebrew platform, you also have access to *compiled* java, pascal, and I think Objective C and Forth, or Fortran, or something that starts with an F. Too lazy to go check. :)
  
  There are other compilers which can target the platform. Commercial people often use the ARM ADS or SDT. Other tools, like the Metaware toolchain and the Green Hills Optimizing Compiler (it's part of the name, not a parroted description, settle down) are commonly used because of their purported performance. Far from being an expert myself, I'll just point you at the Dhrystone that David Welch graciously presented to the community.
  
• I was planning on trying to develop something on my friends PS2 when he got the Linux kit. But since I actually own a GBA, this is a much more worthy project. More worthy, but more difficult. You'll want a flash cart and linker - the hardware is still the only perfect binary executor, though VBA is pretty impressive. All told, the PS2 Linux kit isn't more expensive, and it's hella more fun in the long run (Tux Racer on a console anyway, doncha know!)
  
• At about $70 (Game Boy Advanced, Amazon price [amazon.com]), you can create custom games, ports of other things, etc. This sounds to me like a much more practical thing to purchase to play around with the the PS2, which is in at least the $500 range to start hacking your own stuff for. You're counting just the hardware in one, but the hardware and the mod stuff in the other. $200 (ps2) + $200 (Linux kit) is $400. There was a recent price drop. $70 (AGB) + $40 (USB Flasher) + $15 (Power cable for flasher) + $10 (Parallel cord) + ~$100 (Average flash cart - price varies by size) = $235. Granted, a $175 price difference, but not what you implied. Also, a lot of us already have both. Then, the price of a homebrew kit actually weighs in the other direction, and the AGB is small and limiting enough that unless you really want to, it's a pain of a challenge.
  
• It would be interesting to know how many people will create practical, non-game applications. I know there are many non-game attachments, like a TV tuner and digital camera available for the unit. There are already music sequencers, methods of connecting it (realtime!) to a PC for chatter, MIDI sequencers, connections to serve as visualizers for various kinds of data collectors (think forest service), and a host of weird homebrew things that aren't exactly games. I expect quite a few more over time; I'm working on one in a half-assed way right now. Moreover, over time I expect level editors for at least homebrew games, and possibly for commercial games; would you call those applications?
  
• This would totally rule.. I'd love to see Nethack for the GB. I'm currently working on a Palm version, and of course, it'll work on Windows CE, but honestly, wouldn't Nethack be an awesome alternative to bejeweled on the bus?Shhh... Shen Mansell already has Moshpit put together, and there are three or four people already rumbling about alternatives on the list. Also, note that I'm on alt.games.roguelike.development making an ass of myself all the time... (For those who may be Ccurious, a BooFly is a creature which looks like Will Riker and which doesn't meet me for coffee at E3. Thpppbbt.)
  
• I think that companies like Nintendo and Sony and such should sell stipped down dev kits for like, say $50... including software you'd need and maybe a transfer cable. This gets kicked around a lot in the chatrooms and on the dev lists. The consensus seems to be that yeah, it'd be nice, but though a lot of people would really use it for what it was for, a whole lot of people would use it to pirate games, and besides, Big N's licensing fees per cart and hegemony on software support their business model, so they'd be hurting themselves anyway. In conclusion: not bloody likely.
  
• No disrespect to the great underground game hackers out there, but I don't think there is much of a risk of an uber fantastic game like Gran Tourismo 3 getting put out. Whereas art and sound resources usually make this true, with time, they actually often do. Take a look into the very mature NES or 2600 development scenes; you'll see things you'd never imagine possible (for instance, someone ported the Z-Machine interpreter Frotz to the GameBoy Advance as GBA Frotz, which seems impressive until you realize that the no$gmb guy, who I think is Martin Korth or something, and who really needs to put his damn name in his bio page, did it for the gameboy(!) in *8* *K* of RAM (far smaller than the real Z-Machine was supposed to be), and it works fine! Linkage
  
  Homebrew developers thrive on being told it can't be done. The more you tell them they can't do commercial stuff, the more you're going to see commercial stuff done. That's what got me started. :)
  
• Yes, Craig Rothwell is reliable (someone else's post). Also, though Lik-Sang is reliable (that's where I got mine), right now cyustoms is banning the import of these, and so you won't get one even if lik-sang mails it to you. Craig Rothwell currently goes under their radar, but don't try him if you're seeing this post a month or so old - things may have changed (they often do, unfortunately). The best thing to do is to go to the Yahoo! Group and ask; you'll get a lot of replies in 48 hours.
  
• I know that the Game Cube can use GBA as controllers. I am not sure what the interface protocol is like, though. Do you think that it might be possible to make custom GBA carts for Cube games, that provide enhancements (cheats, etc) to a game playing on the Cube? No. The GC uses half-size DVD discs which are difficult to burn and which have not yet had their protections cracked or circumvented. Things may change later.
  
• So does this mean that with the ROMS that are for the SNES, we could somehow make our own port of say "Secret of Mana" (or some other SNES title) for the GBA? That would be awesome! Though probably not awesome enough for me to spare time to learn this. If you're dedicated. you need to scale a lot of graphics down; the sound hardware is completely different, so the audio stuff will need to be wholly rewritten. There are odd considerations due to the different CPUs. But, yeah, many people have been porting SNES and Genesis games commercially; I don't see why a team of amateurs with lots of time and skill couldn't do the same. It's not easy, though, mind you.
  
  This is our world now...the world of the electron and the switch, the beauty of the baud. Pre-chewed pieces of pap! And shouldn't be teaching anyway!!@!3T1!! r00l!
  
  cough Sorry. Old habits die hard.
  

• The hardware supports carts up to 256 megabit (32mb) in size. There are flash carts which have more space, however, through software bank switching. No commercial ROM currently even hits the hardware size limit (manufactureing costs, it is widely believed, are to blame; it may be the case that Big N limits the available size of carts to both themselves and third parties)
  
• Yes, a linux distro would fit. No, it wouldn't be any fun without a keyboard. Yes, TCP/IP has already been done (a working webserver, which IIRC was even on SlashDot already. That's what caused me to try to post the homebrew dev scene the first time.)
  
• Emulators: there are about a dozen good ones around; many stick to VisualBoy Advance and Mappy Virtual Machine for development. VBA is often regarded as the best and fastest emulation, and Mappy is usually seen as having the best debugging tools (source-level breakpoints, register viewing, disassembly, viewers for most of the important chunks of RAM, etc). VBA interfaces with GNU debuggers, but I'm lazy, and haven't tried it.
  
• How good is the processor? Good enough to emulate an NES? Yes. In fact, there's a port of an emulator which runs NES binaries which were stapled onto the end of the emu binary out there already (it uses scaling and rotation to fit the otherwise too-large pictures; some detail is lost, so text often looks funny, etc). I have no linkage; sorry.
  
• To be specific, the processor is an ARM7 TDMI running at approx 16 mhz. Also, the screen does 60hz refreshes, is 240x160, and has a bitmapped 15bpp color mode (among other modes, including z-buffered modes). The programmer is afforded extreme memory mapping flexability by the hardware; it's more fun than a Rubix' Cube.
  
• Sorry - should have clarified - the ones I listed are all emulators for the GBA. Sorry, but not even remotely close. You didn't even get the popular ones. There's a pretty decent list here, at Zophar's Domain (a pretty good dev site)
  
• Descent is probably beyond the GBA's capabilities, since it uses arbitrarily-angled perspective-correct textured polygons, which are a fair bit harder to render on a low-end CPU (the GBA has a 16MHz ARM7 CPU).You should see some of the stuff that's going on. There are a number of fully textured 3D engines out there, one of which actually uses Descent levels as its examples! (I linked to another in my previous post which uses the quake level 1) A good example is the Raylight engine, though there are probably a dozen that I've seen (and a few proprietary, one of which I'm about halfway done writing :) )
  
• Hey, maybe we'll see Tux Racer for the GBA? That'd be tight. Quite possible. A racer wouldn't be difficult - the floor is a mode 7 S/R background, the sprites are prerendered, and there's enough VRAM that they don't need to be DMAed into place or anything (though people do that anyway, often enough [grins])
  
  Actually, how low-level is the API? Any chance someone could get Linux running on one of these babies?"The API" isn't. HAM has an engine, SGADE has an engine, there are others (I don't use them), and there are some commercial ones. But, here's the thing: the hardware does a lot of stuff. Sprites and backgrounds are supported in hardware, and do scaling and blending stuff, etc. It's just register tweakage. You don't really need an API.
  
  Big N does send an API of some sort, but I'm not a licensed developer, so I know dick about it. I'm told it's not that much of a difference - mostly just wrapper functions.
• well if you realyl want to consider assembler an API, that is your answer. ARM flavored assmebler. We're not stuck to Assembly. Though there are about six assemblers in common use (the one that gets most use as not just part of a toolchain seems to be GoldRoad, but because I don't use assembly except in-line, I have a biased perspective), there are also a buttload of C and C++ and so forth compilers. Because Gnu's Compiler Collection (GCC does not mean gnu's c compiler) works and is the common compiler for the homebrew platform, you also have access to *compiled* java, pascal, and I think Objective C and Forth, or Fortran, or something that starts with an F. Too lazy to go check. :)
  
  There are other compilers which can target the platform. Commercial people often use the ARM ADS or SDT. Other tools, like the Metaware toolchain and the Green Hills Optimizing Compiler (it's part of the name, not a parroted description, settle down) are commonly used because of their purported performance. Far from being an expert myself, I'll just point you at the Dhrystone that David Welch graciously presented to the community.
  
• I was planning on trying to develop something on my friends PS2 when he got the Linux kit. But since I actually own a GBA, this is a much more worthy project. More worthy, but more difficult. You'll want a flash cart and linker - the hardware is still the only perfect binary executor, though VBA is pretty impressive. All told, the PS2 Linux kit isn't more expensive, and it's hella more fun in the long run (Tux Racer on a console anyway, doncha know!)
  
• At about $70 (Game Boy Advanced, Amazon price [amazon.com]), you can create custom games, ports of other things, etc. This sounds to me like a much more practical thing to purchase to play around with the the PS2, which is in at least the $500 range to start hacking your own stuff for. You're counting just the hardware in one, but the hardware and the mod stuff in the other. $200 (ps2) + $200 (Linux kit) is $400. There was a recent price drop. $70 (AGB) + $40 (USB Flasher) + $15 (Power cable for flasher) + $10 (Parallel cord) + ~$100 (Average flash cart - price varies by size) = $235. Granted, a $175 price difference, but not what you implied. Also, a lot of us already have both. Then, the price of a homebrew kit actually weighs in the other direction, and the AGB is small and limiting enough that unless you really want to, it's a pain of a challenge.
  
• It would be interesting to know how many people will create practical, non-game applications. I know there are many non-game attachments, like a TV tuner and digital camera available for the unit. There are already music sequencers, methods of connecting it (realtime!) to a PC for chatter, MIDI sequencers, connections to serve as visualizers for various kinds of data collectors (think forest service), and a host of weird homebrew things that aren't exactly games. I expect quite a few more over time; I'm working on one in a half-assed way right now. Moreover, over time I expect level editors for at least homebrew games, and possibly for commercial games; would you call those applications?
  
• This would totally rule.. I'd love to see Nethack for the GB. I'm currently working on a Palm version, and of course, it'll work on Windows CE, but honestly, wouldn't Nethack be an awesome alternative to bejeweled on the bus?Shhh... Shen Mansell already has Moshpit put together, and there are three or four people already rumbling about alternatives on the list. Also, note that I'm on alt.games.roguelike.development making an ass of myself all the time... (For those who may be Ccurious, a BooFly is a creature which looks like Will Riker and which doesn't meet me for coffee at E3. Thpppbbt.)
  
• I think that companies like Nintendo and Sony and such should sell stipped down dev kits for like, say $50... including software you'd need and maybe a transfer cable. This gets kicked around a lot in the chatrooms and on the dev lists. The consensus seems to be that yeah, it'd be nice, but though a lot of people would really use it for what it was for, a whole lot of people would use it to pirate games, and besides, Big N's licensing fees per cart and hegemony on software support their business model, so they'd be hurting themselves anyway. In conclusion: not bloody likely.
  
• No disrespect to the great underground game hackers out there, but I don't think there is much of a risk of an uber fantastic game like Gran Tourismo 3 getting put out. Whereas art and sound resources usually make this true, with time, they actually often do. Take a look into the very mature NES or 2600 development scenes; you'll see things you'd never imagine possible (for instance, someone ported the Z-Machine interpreter Frotz to the GameBoy Advance as GBA Frotz, which seems impressive until you realize that the no$gmb guy, who I think is Martin Korth or something, and who really needs to put his damn name in his bio page, did it for the gameboy(!) in *8* *K* of RAM (far smaller than the real Z-Machine was supposed to be), and it works fine! Linkage
  
  Homebrew developers thrive on being told it can't be done. The more you tell them they can't do commercial stuff, the more you're going to see commercial stuff done. That's what got me started. :)
  
• Yes, Craig Rothwell is reliable (someone else's post). Also, though Lik-Sang is reliable (that's where I got mine), right now cyustoms is banning the import of these, and so you won't get one even if lik-sang mails it to you. Craig Rothwell currently goes under their radar, but don't try him if you're seeing this post a month or so old - things may have changed (they often do, unfortunately). The best thing to do is to go to the Yahoo! Group and ask; you'll get a lot of replies in 48 hours.
  
• I know that the Game Cube can use GBA as controllers. I am not sure what the interface protocol is like, though. Do you think that it might be possible to make custom GBA carts for Cube games, that provide enhancements (cheats, etc) to a game playing on the Cube? No. The GC uses half-size DVD discs which are difficult to burn and which have not yet had their protections cracked or circumvented. Things may change later.
  
• So does this mean that with the ROMS that are for the SNES, we could somehow make our own port of say "Secret of Mana" (or some other SNES title) for the GBA? That would be awesome! Though probably not awesome enough for me to spare time to learn this. If you're dedicated. you need to scale a lot of graphics down; the sound hardware is completely different, so the audio stuff will need to be wholly rewritten. There are odd considerations due to the different CPUs. But, yeah, many people have been porting SNES and Genesis games commercially; I don't see why a team of amateurs with lots of time and skill couldn't do the same. It's not easy, though, mind you.
  
  This is our world now...the world of the electron and the switch, the beauty of the baud. Pre-chewed pieces of pap! And shouldn't be teaching anyway!!@!3T1!! r00l!
  
  cough Sorry. Old habits die hard.
  

Essentially, BREW does much of the heavy lifting that wireless carriers prefer not to tackle. It is also an open standard that supports multiple languages including the Java platform -- which means game developers don't have to worry about writing multiple versions for different devices.

This statement is misleading. BREW is a "Binary Runtime Environment for Wireless" by Qualcomm. It is just a friggin' API for phones with an ARM CPU! The only reason they claim Java - which does not ship by the way - is that is is conceivable to port and run Java under any environment. Putting a JVM on top of BREW is totally useless since the JVM does not need BREW whatsoever to run on an ARM - it's all marketing hype promoting the false associating with Write-Once Run-Anywhere. BREW competes with Java and locks you into the Qualcomm licensing machine. BREW is not open (or maybe it is, check for yourself here), not cross-platform (ARM only), and does about as much for reducing the need for different software versions as Win32 - or any other proprietary "environment" - does for the desktop.

ARM helped Intel.

Expect something tangible from ARM in Q4...

Expect something tangible from ARM in Q4...

AMD and Intel are likely to continue battling it out for the next few years, purely so people can still run Windows.

well, only for nerdz, then.
we all know how these companies want to have each other publicly bashed.
AMD makes burning processors, Intel made "tech inflation" a law.
Intel even think they are the biggest proc manufacturer in the world which they are not.
how shit.
I don't want to be insightful, I want to thank our friend above for his excellent non AC FP !
Fuck the (moderation) system !

Two statements, both 100% wrong. At least you're consistent.
JVMs have JITs, and ARM and others have hardware VMs such as Jazelle.

Especially an ARM with a JVM in hardware.
Contrast with the dismal Itanic - moving in completely the wrong direction - painful optimization, dumb VLIW RISC instructions etc etc

http://www.arm.com/news.ns4/iwpList125/B88B5796636 DF17E802569440062D45B?OpenDocument&style=Press_Roo m

I had no clue about this XScale thing, however that was the first thing I came across on Google, so it appears to be an ARM instruction set processor, using technology Intel obtained when they bought DEC, which was a co-creator of StrongARM.

ARM != StrongARM.

This is very similar to how Athlon != IA-32. Don't confuse an architecture with an implementation of that architecture.

The ones to watch out for are ARM. They have a tendency to sneak their way into practically everything: cars, mobile phones, PSIONs, even your Gameboy Advance.

They have their sticky thumbs in a lot of different pies and because of the practical collapse of PSION handhelds, are probably itching to get back into the palmtop market.

Oh, they're also in your iPod too, and quite possibly your car :)

Well, the ARM got ignored up to now, so here's a link to Jazelle, the (90% of) Java bytecode native to CPU trick. And the benchmarks are quite impressive too...

...by mobile processors, I would say. To be honest, I think it's likely (if it isn't already the case) that processors in mobile networked devices will fast surpass desktop and server processors as objects of desire. Instead of one or two souped up power hungry beasts on your desk, you'll have 5-6 devices floating around (phone, pda, mp3 player + more) that will start to displace your desktop machine as what you spend most of your time and money on. PC processors will become an important minority concern in the world of mobility. I think that the ARM architecture is the likely future market leader by volume (if it isn't already!)

ARM has the option of JVM accelleration, partial execution direct by the CPU, called jazelle

It does indeed make sense for embedded systems:

Toshiba signs for ARM mobile Java chip

ARM Jazelle Technology

> its claims of 56k transfer rates are highly optimistic.

From ARM.com:
The secret to the Pogo's hi-speed wireless web connection lies in its unique proprietary compression technology. It is powered by an ARM7 core, which was selected for its excellent code density and speed.

marmite

I've considered this, but it seems to be that the main advantage of a calculator for medium complexity calculations is having a huge array of specialized buttons that can be memorized -- a user interface that never changes (with the exception of the context buttons just to the bottom of the HP's screen). It would take either a cumbersome menu system or entirely too much screen real estate to do the same thing on a Palm Pilot. A Palm Pilot also isn't a fantastic number cruncher; I don't believe the Moto processors do much floating point.

The new ARM10 core supports a VFP10 floating point coprocessor, as well as having extremely low power sleep modes that would be necessary for use in a calculator. It even has some DSP-like features in its instruction set. Instead of struggling to graph a parabola like current calculators do, it'd be able to do 3d surfaces, FFTs, etc. easily. It would be an obvious extension of that to add an expansion module with high quality ADCs and DACs on it and use it as a realtime DSP control box with a very approachable user interface.

Don't forget that a lot of what's great about HP48s is simply the clicky buttons (the 49 and TIs have mushy buttons that don't give you any tactile sense of when the calc considers it 'pushed'), too.

It shouldn't matter how their competitors were able to copy their RISC processors, the important fact here is that the device has been granted a US patent. I'm sure people are going to say that reverse engineering makes it perfectly legal, but that is simply not the case. Reverse engineering protects OpenCores.org from being accused of corporate espionage, by proving that they legally obtained the information necessary to copy the core, but their posting of patented information to their website is what is being argued against. Reverse engineering is nothing more than a legitimate way for engineers to steal the intellectual property of competitors and gain an unfair business advantage. ARM has invested millions of dollars and countless hours into developing their processor core, and they are completely justified in defending what is rightfully theirs against so-called "reverse engineering" patent theft.

Let's look at it this way, there are hundereds of very simple devices that have received US patents. Ever seen that microwavave bacon cooker advertised on Infomercials? I'm pretty sure that without too much effort, I could figure out how that was made without looking at any of it's inventors design specs. Do I legally have a right to sell my own "reverse engineered" version of someone elses invention? I should think not!

200MHz is a lot. 1GHz is utterly ridiculous. The biggest concern with having faster chips is reducing battery life. Most, if not all, WinCE devices have a max battery life in the hours. Granted, most such devices have colour screens, but it would be foolish to say the faster chips doesn't play a part in it.

The Motorola MC68328 DragonBall microprocessor uses about 55mW. The power consumption for a modern colour LCD screen is about 25mW. So CPU power usage is an important factor in battery life. There is a paper on power consumption which is worth a read which shows that power consumption for the Palm Pro 16MHz uses between 26mW (sleeping) and 160mW for intensive tasks.

Now the ARM family has been designed for high MIPS/Watt ratios. Looking at the ARM10 tech specs the ARM chip uses 275mW when running, and can drop down to less than 5mW when idling, and in sleep mode uses 0mW with the option for fast wake up.

So what does this mean for the average Palm user? If the CPU goes to sleep in between uses, and idle mode is invoked during any period of inactivity, the new Palms should maintain good battery life while being a lot snappier to use. To me, it looks like you should get the same sort of battery life if you use it for the same sort of tasks. If you want to play MP3's all day long, then your Palm will be chewing around 350mW out of the batteries. Given that a single AAA battery gives roughly 1000mAH (milliAmp Hours) so that would imply a pair of AAAs would give you about 8 hours of continuous 100% CPU usage.

Cheers,

Toby Haynes

ARM also patented revolutionary network technologies such as a (V22 soft modem) based on their lovely chip so we might soon see some real and versatile alternatives to these phone/organizers behemots.
--

ARM also patented revolutionary network technologies such as a (V22 soft modem) based on their lovely chip so we might soon see some real and versatile alternatives to these phone/organizers behemots.
--

ARM also patented revolutionary network technologies such as a (V22 soft modem) based on their lovely chip so we might soon see some real and versatile alternatives to these phone/organizers behemots.
--