GCW Zero - Open Source Gaming Handheld


^^^^^^^^So even if the ds is more or less a handheld n64 it does not have the same issues as the n64 has in being emulated?slightly different hardware or something?
 
The nintendo DS is a completely different beast. The hardware is seriously crippled when it comes to performance, but its quirks and other additions makes it a tricky machine to emulate accurately on a low-power system.


The N64 is a lot more powerful than the NDS, but the NDS have a few hardware periphials that you need to sync with the CPU. For example, the hardware matrix co-processor. The CPU expects a result to be read from the registers within tens of cycles, so you'd need to splice that into the CPU emulation. I have never written a dynarec, but my gut feeling tells me that this will result in horribly slow code.


The GPU seems okay, and *should* be possible to translate to GLES calls, even though it seems to be desgiend to be emulated with OpenGL 1.0 glBegin...glEnd sillyness. Also, I'm not sure about everything else it can do apart from bare primitive rendering and what incompatibilities with OpenGL that might be waiting there.


I guess the good news is that the NDS GPU emulation doesn't have to handle that replaceable microcode bullshit the N64 required.
 
Working on pictures and such for sneak peak will have them up this weekend... Here are some answers to questions


what is the battery life is expected to be of actual use at 800mhz? 6 to 9 hours according to what you are doing


- how long does it take to boot currently? About 10 to 15 seconds on boot about 20 on shutdown


- can it be charged via USB and external power connection? Yes it can be charged via usb or the charging adapter


- can you confirm no ghoasting or visual tearing of motion on screen at 60fps? There is minumal tearing on some games but for most part no and it is being worked on not a hardware issue.


- what is the maximum simultaneous button presses for combo buttons? Uknown answer on this one but have been told combos seem to work


- what is the discharge rate when the device is off? % per day(s) Not tested but will test


- how rugged is this compared to say the a320/a330? Same plastics/mold being used? The plastic is of higher quality then the A320 or A330


Another good piece of news in discussion with some homebrew developers of different consoles to bundle there past work on the console and they might be interested in selling there new work on the commercial end of repository/store.
 
The N64 is a lot more powerful than the NDS

How do you figure? DS has a lot of advantages over N64 and vice-versa. It's really difficult to compare them. Two games that are written with the strength of both in mind will look very different from each other.

but the NDS have a few hardware periphials that you need to sync with the CPU. For example, the hardware matrix co-processor. The CPU expects a result to be read from the registers within tens of cycles, so you'd need to splice that into the CPU emulation. I have never written a dynarec, but my gut feeling tells me that this will result in horribly slow code.

Nah.


The whole 3D pipeline on DS is actually pretty decoupled from anything the CPU sees, thanks to the majority of the results going to private memory which can't be read back, or at least not until much later when the capture unit gets to it. There are some exceptions, like getting the state of the matrices or reading back the results of the box tests, but games don't do a lot of this. For the most part an emulator can queue up an entire scene's worth of commands before actually doing anything with it.


However, game code does rely on pretty tight synchronization between the ARM9 and ARM7. As part of its initialization routine the ARM9 attempts to communicate with the ARM7 and waits for the result in a busy loop, and will pretty quickly time out and fail if it doesn't get a response. So you can only run several dozens of instructions on the ARM9 before you need to catch up with the ARM7. This isn't that bad though, nothing in the realm of dynarec killing, and since only a few ARM7 binaries are used for all games you could probably HLE/hack your way around it.

The GPU seems okay, and *should* be possible to translate to GLES calls, even though it seems to be desgiend to be emulated with OpenGL 1.0 glBegin...glEnd sillyness. Also, I'm not sure about everything else it can do apart from bare primitive rendering and what incompatibilities with OpenGL that might be waiting there.

Its interface may be sort of OpenGL-like but there are all sorts of low-level things that OpenGL 1.x (and for that matter, standard OpenGL ES 2.0) can't handle properly, or can't handle without a ton of shader power (more than is reasonable even for the DM3730 Pandora). For instance, just off the top of my head:


- Polygons are rendered with two-fold linear interpolation instead of standard affine parameters. For triangles this just means they look glitchier but quads can look totally different


- Edge marking which at the very least requires you to read back the framebuffer and depth buffer, former is very expensive, latter can't be done at all


- Paletted and compressed texture formats which require expensive texture caching or expensive shaders


- Need to be able to read back framebuffer to combine it with 2D, again, very expensive


- DS can pre-load the depth buffer,


- Polygon-ID rendering nuances which means more outputs in addition to color/depth/stencil, problematic to do without multiple render targets


- Edge anti-aliasing which doesn't look MSAA et al

I guess the good news is that the NDS GPU emulation doesn't have to handle that replaceable microcode bullshit the N64 required.

The "replaceable microcode bullshit" is why N64 has been successfully emulated on such weak hardware. N64 does not have hardware with programmable microcode, rather it has a vector coprocessor. Since there's not a lot of program/data memory on this coprocessor most games are instead using it to interpret a stream of commands in a standard Nintendo/SGI interpreter, commands they (badly) call microcode. These commands are also used to handle audio. Because of this most N64 emulators don't emulate this vector coprocessor, or the GPU for that matter, but instead emulate the microcode interpreters. That means that the only substantial piece of hardware that these emulators have to handle a low level is the CPU, which is in practice much slower than you'd expect it to be because the memory sucks so badly. Proper low level N64 emulation would never be fast enough on something like Pandora.


On DS emulating the geometry engine + GPU isn't that much more intricate than emulating microcode on the N64, per se. But on DS you have to emulate two ARM CPUs, the main one which is not as crippled as N64's, and you have to emulate two real 2D engines (both more powerful than GBA's) and a real audio engine. The memory layout of the CPUs is a lot more complex and accesses are a lot more varied, so I doubt you'd have as much success with the kind of optimization N64 emulators use for memory access, which is a huge chunk of CPU emulation.
 
and you have to emulate two real 2D engines (both more powerful than GBA's)

are really the engine more powerfull than GBA? I remember them working almost like the GBA ones (of course you have two of them to emulate on the DS...)
 
are really the engine more powerfull than GBA? I remember them working almost like the GBA ones (of course you have two of them to emulate on the DS...)

They're extensions of the GBA ones. They can work exactly the same way, but also add a bunch of stuff. I mean, outside of the difference in resolution, which right off the bat means you need to emulate 20% more scanlines (that are each a bit wider)


Now you can do two normal BG layers in addition to two affine ones. And there's an extended mode for the affine ones that gives more tile attributes and is much more expensive to emulate. You can see how the ante is upped a lot for potential emulation workload. There are also extended 12-bit palettes and 16bpp sprites with per-sprite alpha values. The blend muxing logic, which is a fair part of the emulation complexity, is more extensive, in order to handle different kinds of forced blends.


On top of all the 2D stuff there's a new master brightness that has to be applied to everything.
 
Well I'm up moving and back too work at day job about 50% but better then no percent
 
I love my Caanoo... What I want is someone to drop a cortex A9 1ghz in my caanoo. Is this it (approxamatly)??? If so, I'm gettin' it. The thing i'm worried about is that it looks like new software must be developed for it to be usefull. Thats the same problem the Caanoo had, then, it didn't sell enough. Then GPH fell of the face of the earth. Then... software development almost compleatly stopped. The android handhelds ... Ya, their cheap and not put together all that well but... Android does have a huge user base to support these things. I realy wish the zero luck because thats the way I would like to see things go but not everyone is as idealistic as we are.
 
Ooh, it's like leaking super secret pics! Can't wait for mine! Also, out of curiosity, how what's the split like between those who wanted a black unit and those that wanted a white unit? I know I opted for a black unit.
 
Last edited by a moderator:
gcw, do you have a link to the pic's

main website right here http://game-consoles-worldwide.com/?page_id=15


20120615165154.jpg



according to gcw, these prototypes are meant for testers-- these units have wifi enabled and the control nub mapped to a separate IC
 
Last edited by a moderator:
Back
Top