Revolution specs - the good side

[Bohdy]

From what I can gather of this "Z-Ram", it offers twice the density of 1T-Sram and similar performance. I would guess that this small (compared to sram -> 1t-sram) improvement would not be worth the initial production cost of this new technology.

Oh, and I'm sorry you had to repeat yourself, Squeak, but that may have been because (like myself) most people don't know what the bloody hell SoC stands for!

Edit: Wrong poster, whoops.

 

[Guden Oden]

"System on (a) Chip". Ie: basically a computer with CPU, memory, I/O, timers, PLLs etc all on the same die. Some SoCs might deviate slightly by having off-chip memory and/or PLLs, but to qualify as a "true" SoC, all basic components are supposed to be integrated.

As a previous poster mentioned, Nintendo's handhelds have used SoCs. Even the Game&Watch products did, heh. Even the NES almost qualifies, only reason it occupies two chips is they couldn't make big enough ICs back then, the NES hardware were pushing the cost envelope as it was back then. CPU die integrates sound, timers and 1Kbyte SRAM on-die. The PPU has 1Kbyte VRAM on it, I'm pretty sure there is no external RAM in the NES. Other than if you count the game cartridges that is, which could contain more RAM/VRAM, as well as extra sound channels etc. Cartridge slot really was much like a PC expansion slot than just a simple cartridge interface it seems to me. A NES cart has 80 (!) pins...

 

[OtakingGX]

SoC = System on a Chip

And does ZRAM have twice the density of 1T SRAM or 1T SRAM-Q?

 

[Teasy]

Well, the 750GX does have 1 MB L2. I'm not sure on the VMX unit though, I don't think it has one. I'm sure if that's what they based the processor off of it would likely look something like a 750GXe with Gekko's VMX derivative on it.

I'm not sure what the 750GXe supports but even if Broadway was based on this CPU it can be as custom as Nintendo want it to be. The CPU they end up with could be quite different to a 750GXe.

 

[Rolf N]

And does ZRAM have twice the density of 1T SRAM or 1T SRAM-Q?

Dig through the official info for an authorative answer, but from what I made of it it should actually be even better.
In rough terms, they outright removed the capacitor from the DRAM memory cell, so a bit is now just a single transistor. They rely on a parasitic side-effect of SOI manufacturing to functionally replace the lost capacitor.

The result is supposed to be a very dense memory cell and they claim that their advantage gets larger and larger as process litography gets smaller (because shrinking the capacitor in classic DRAM is much harder than shrinking the transistor).

They also claim that their tech does away with "memory process" vs "logic process" tradeoff because their style of memory cell works best in a "logic process" anyway. If that's true, you can have lots of embedded memory without compromising performance/power characteristics of the logic portion of the chip.

IIRC this has indeed been a problem for large-scale embedded memory. Think Bitboys Glaze3D which was supposedly "done" for years but just couldn't be manufactured, or heck, even the XBox360 GPU.

Of course take all of this with a grain of salt. All information is drawn from their official stuff, and as they want to have customers they'll naturally present the most optimistic view. Even so I think it's very interesting.

 

[Rolf N]

Gekko only have 256K of L2.

Thanks.
Makes much more sense, too
I seem to have confused 750GX with Gecko

 

[Teasy]

Yeah Gekko was based on 750CXe AFAIR.

 

[OtakingGX]

Dig through the official info for an authorative answer, but from what I made of it it should actually be even better.
In rough terms, they outright removed the capacitor from the DRAM memory cell, so a bit is now just a single transistor. They rely on a parasitic side-effect of SOI manufacturing to functionally replace the lost capacitor.

Checking into it briefly, ZRAM is claimed to be 5 times as dense as normal SRAM. MoSys states that 1T-SRAM-Q is 4 times as dense as typical 6T-SRAM.

I think the beauty of 1T-SRAM-Q, and why it will be Nintendo's first choice, is that it adds about 5% to the cost of processing a wafer. Cutting edge technology is good, but equivalent technology at a cheaper pricepoint is even better.

http://www.electronicstalk.com/news/mos/mos127.html

http://www.cieonline.co.uk/cie2/articlen.asp?pid=1104&id=5434

 

[Fox5]

It's common in PS2 titles.....
You pad out DMA cahins with NOPs to match known timing.

I can't think of a general case on Gamecube though, but it's not massively uncommon for products to be timing sensitive, the question is what the result of the timing variation is. I'd still expect High 90's percent compatability though.

Why can't hardware backwards compatibility be handled the same way as software emulators? Just lock everything to vsync and things generally turn out fine, they may even run better.

 

[sfried]

Why can't hardware backwards compatibility be handled the same way as software emulators? Just lock everything to vsync and things generally turn out fine, they may even run better.

As stated before, some games are timing dependent. It's like Star Fox played on an emulator: Sure it runs faster, the the timing and events are off (like the intro).

 

[Rolf N]

Why can't hardware backwards compatibility be handled the same way as software emulators? Just lock everything to vsync and things generally turn out fine, they may even run better.

Things can mess up very quickly when the game itself does the same thing.
It is common good practice for PC games to do "proper" update physics. Ie when objects move, you give them a proper speed and acceleration, both of which are dependent on time (a velocity vector is an arbitrary unit per second and acceleration is a change in speed per second) and then multiply by the time elapsed since last snapshot to perform the update for the next snapshot. Snapshots are usually frames, but don't have to. Eg a physics snapshot is not a frame in Doom 3, but rather a fixed 1s/60.

You don't have to bother at all on a platform where you can rely on performance of all components being constant, and a console obviously is such a platform. You can just move objects this and that distance per frame, and accelerate them by some value per frame. This will not work properly unless the emulator goes out of its way to pretend that the frame is as long as it was on the console, despite the game running at 85Hz instead of 60Hz.

Us poor gamers living in PAL regions have many a story to tell about games that rely heavily on frame timing. Eg Metroid Prime 2 has a warning text on the box that states that the game requires a TV set that can handle PAL60. The game has not been adapted to the usual 50Hz, and now you guess why this might (not) have happened.

And you can go much crazier than just vsync.

It is not at all uncommon on console platforms that games catch a vblank interrupt for all things that are convenient to do once per frame. Vblank is the point in time where the blank period begins in the traditional TV video formats, and historically the start of the time interval which is allocated to allow the cathode ray to travel back to the upper left corner.

You can start by doing the page flip in a vblank handler. But that's just punching a different pointer into a register of the graphics processor. It's done very quickly, and you'll want to use the remainder of the time interval for other stuff. You can sample the joypad. You can do all your sound processing. And sound is the one area where I expect the biggest problems to occur.

Let's say you have a console game that uses double-buffered DMA for sound playback and is totally optimized for the console it runs on. The DMA buffers are exactly the size required for the amount of samples that will play in one frame. 736 samples for 59.93Hz (NTSC rate) vblank interval and 44.1kHz playback rate.
You can arrange things so that every time the system enters that interrupt handler, the old DMA buffer is just finishing. You then have 1s/44100~=22,7µs to prepare the next sample. Because on a 500MHz CPU that's north of 11000 CPU cycles you might ... *drum roll* get the idea that you can pull this off with single-buffered DMA. You can certainly mix a whole bunch of fresh samples in 11000 CPU cycles and be finished well in time to never have any clicks or skips.

Now, if you were to change the vblank period to 85Hz without adjusting the sound processing, you'd not play 736 samples per frame, but more like 519 and the remainder of the buffer would just drop.
If OTOH you went to 50Hz (PAL), the DMA buffers would be too small (882 samples required, 736 samples allocated and mixed). You'd end up playing whatever garbage there is in memory behind the designated sound DMA buffer.

In both cases you'll end up with terribly distorted sound. You can fix it by either maintaining the exact vblank timing, or by patching up every single game that relies on it.

As Retro didn't bother to fix it even for the PAL version of MP2, I'm pretty confident that the latter option will not come to be the general solution for backwards compatibility.