Quantcast

Page 66 of 66 FirstFirst ... 16566263646566
Results 976 to 986 of 986

Thread: Comparison of 5th generation ("32/64-bit") game console hardware

  1. #976
    Master of Shinobi
    Join Date
    Sep 2012
    Posts
    1,275
    Rep Power
    38

    Default

    N64 ones. They are all shit.

    There is one that aims to be entirely low level and cycle accurate, but it is still under development, last I checked.

  2. #977
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    78

    Default

    The N64 is pretty fun to program. I've done a few things on it myself, but you really need MESS and a hefty PC for proper N64 emulation that also handles homebrew apps. When I did my port of Yeti3D Pro for the N64, I ran it under MESS to do the screenshots for my thread on it.

    I haven't had anything new in a while for the N64 for a couple reasons - one, I've been working on some other consoles, and two, I've been working on using the RSP in the N64 in homebrew. A lot of work I tend to do in older console homebrew tends to be of the "invisible" sort - not actual apps/games, but libraries and the like that make homebrew easier for everybody.

  3. #978

    Join Date
    Jan 2014
    Location
    Frankfurt, Germany
    Posts
    181
    Rep Power
    0

    Default

    Quote Originally Posted by zyrobs View Post
    Probably also the fact that emulators are near useless, so you wouldn't have many ways to get your code running right.
    I think that's pretty spot on. A lot of your CPU performance on the N64 was lost because the memory controller was on the RCP and had awful bandwidth. It was a real limiting factor. I imagine that particular trait might not be emulated properly, so you might not see performance issues on an emulator that you would run into on the actual hardware.

  4. #979
    Master of Shinobi
    Join Date
    Sep 2012
    Posts
    1,275
    Rep Power
    38

    Default

    Quote Originally Posted by rusty View Post
    I think that's pretty spot on. A lot of your CPU performance on the N64 was lost because the memory controller was on the RCP and had awful bandwidth. It was a real limiting factor. I imagine that particular trait might not be emulated properly, so you might not see performance issues on an emulator that you would run into on the actual hardware.
    Most N64 emulators just do "HLE", as in translating the microcode to D3D/OGL/Glide (!!) calls. Games with custom microcode suffer greatly and a lot of them are "impossible to emulate".

    Because the point is not to emulate the hardware, it is to get Zelda and Mario to work in 1600x1200.

    I imagine there is also a lack of documentation on the, what was it called, RSP chip, the one that had reprogrammable microcode, to which Nintendo never actually released the low level docs, other than to maybe 2 or 3 developers (and even then they had to translate it from japanese), so most devs had to use the inefficient default microcodes.
    I know Rare got the docs (the developers admitted it recently in the Conker BFD Directors Commentary on youtube), I think Factor 5 may have had them too.
    Last edited by zyrobs; 04-07-2014 at 03:03 PM.

  5. #980
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    78

    Default

    Quote Originally Posted by zyrobs View Post
    I imagine there is also a lack of documentation on the, what was it called, RSP chip, the one that had reprogrammable microcode, to which Nintendo never actually released the low level docs, other than to maybe 2 or 3 developers (and even then they had to translate it from japanese), so most devs had to use the inefficient default microcodes.
    I know Rare got the docs (the developers admitted it recently in the Conker BFD Directors Commentary on youtube), I think Factor 5 may have had them too.
    There used to be no docs on it, but that's not been the case for years now. MESS emulates the RCP (RSP+RDP) at low-level rather than high level like most N64 emulators. That's why I said you need MESS + beefy PC for emulating N64 homebrew.

    And there was never any REAL microcode on the RCP. Nintendo/SGI just used that term to make people think their processor was Magic Tech when it was really just another limited processor. The RCP is RSP + RDP + a couple DMA channels. The RDP is a regular 3D GPU like everybody else's, while the RSP is just a MIPS R4000 limited to 32 bit registers, no multiply or divide, and no likely branch instructions, coupled to a vector unit to do multiplies and divides (among other things). The vector unit is kinda like SSE, but much more limited. What Nintendo/SGI called "microcode" was actually a list of instructions that the normal MIPS code in the RSP would go through, interpreting them one at a time. Engineers call that pseudo-code, not microcode; microcode is something else entirely. It's just another case of bullshit marketing to try to make your tech look better than it really is in an effort to make more money.

  6. #981

    Join Date
    Jan 2014
    Location
    Frankfurt, Germany
    Posts
    181
    Rep Power
    0

    Default

    Quote Originally Posted by zyrobs View Post
    Most N64 emulators just do "HLE", as in translating the microcode to D3D/OGL/Glide (!!) calls. Games with custom microcode suffer greatly and a lot of them are "impossible to emulate".

    Because the point is not to emulate the hardware, it is to get Zelda and Mario to work in 1600x1200.
    Probably. But then it's more translation than emulation. I'm talking more the CPU side of things, which relied on the RCP for memory accesses. I don't have a problem with emulators not doing that down to the cycle-level, but I wouldn't want to develop on an emulator for such a complex piece of hardware.


    Quote Originally Posted by zyrobs View Post
    I imagine there is also a lack of documentation on the, what was it called, RSP chip, the one that had reprogrammable microcode, to which Nintendo never actually released the low level docs, other than to maybe 2 or 3 developers (and even then they had to translate it from japanese), so most devs had to use the inefficient default microcodes.
    I know Rare got the docs (the developers admitted it recently in the Conker BFD Directors Commentary on youtube), I think Factor 5 may have had them too.
    Yeah, there were a few people who had the documentation or reverse engineered the micro-code. For most developers (including us) it wasn't such a big deal to use the faster/less accurate code, because there were ways around the issues that it caused. As an example, the 3d-transform stuff tended to suffer from severe rounding errors, making everything very jittery. How we got around that was by scaling up the 3d world by a factor of 8, which added 4 more bits of precision internally to the fixed-point math micro-code. This was a trick we used to get around issues on the PS1 because the GTE, which did all of the 3D stuff did it using 1:20:11 fixed-point, which could cause nasty jitter where rounding errors would show up (typically in animations and skinned geometry).

    It was only if you wanted to do something really out there, such as curved surfaces that you needed micro-code, or if you *really* needed accurate & fast rendering.

    I remember when Nintendo announced that they were canning the N64, there was a great article in Game Developer magazine that month detailing how to program RCP microcode! It even used a bezier-patch renderer as an example!

    The real issue was that it felt that no matter what you did with your CPU code, there was never a definite performance gain. You were always thinking "well, there's a 40% chance that my code will run three times faster if I do this optimisation, but the rest of the time it will run at an unknown speed because I can't rely on the RCP giving the CPU access to memory".
    Last edited by rusty; 04-08-2014 at 01:55 AM.

  7. #982
    Death Adder's minion
    Join Date
    Jun 2010
    Posts
    18
    Rep Power
    0

    Default

    Can we talk about the 3DO?

    I've seen posts that state how much more powerful the Jaguar was than the 3DO (because it had 2x26Mhz RISC processors, 13Mhz 68000, 64bit Blitter and 64bit Object Processor, but the 3DO only had the 12.5Mhz ARM60 to do its processing).

    However, having read the 3DO SDK documentation and the 3DO patents, I've been getting a different picture.

    The 3DO had the 12.5Mhz ARM60, but offloaded matrix operations to a custom maths co-processor (clocked at 25Mhz since it was part of the MADAM custom chip?). The audio was handled by a 25Mhz DSP and the Cel Engine, also clocked at 25Mhz, appears to comprise of a colour manipulation processor (capable of mixing two sources into a single destination), a pair of "corner engines" for calculating the position of destination pixels that are being scaled, rotated or stretched, a pair of "fast decision making circuits" and a pair of "slow decision making circuits" to speed up painting destination pixels, plus a pair of "maths engines" that the other Cel components use to perform calculations. In addition to this, a Video Generator does the interpolation of the 320x240 image into 640x480 pixels, and can perform per-line operations in a way that seems similar to the Amiga's Copper.

    All of which seems to be pretty powerful stuff. So while the Jaguar might have had more "raw" CPU available for a programmer to use, the 3DO offloads much of the common operations using its custom chips that are more finely tuned for specific tasks. Am I right in thinking that for many of the operations that the Cel Engine does internally, the Jaguar would need the GPU to run code to drive the Blitter, thereby using up GPU time?

    The inclusion of 1MB of VRAM and 2MB DRAM, the Serial Port (SPORT) DMA for rapidly drawing a background graphic (prior to writing cels on top) and the lack of hardware bugs (when compared with the Jaguar) seems to give it an advantage over the Jaguar as well. In fact, the only thing I have read that would seem to have been a major improvement would have been to use an ARM chip with a cache (e.g., the ARM610) so it could do work while the Cel Engine was on the bus and maybe increase the ARM clockspeed to 25Mhz (which according to one interview, was planned, but never happened).

    I would guess that if a) the 3DO had had a longer life and b) programmers had been allowed to program to the metal instead of through the 3DO operating system, the 3DO was likely to have produced far more impressive results that we actually got to see in released games.

    Anyone have any thoughts or experiences using the 3DO?
    Last edited by jregel; 04-22-2014 at 03:45 AM.

  8. #983
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    78

    Default

    The DSP in the 3DO is half the rate you mention, and a plain 16-bit DSP like the one used in the SVP by SEGA. It's good for audio, but not nearly as powerful as Jerry in the Jaguar. The Jaguar wins big here.

    The "math coprocessor" in MADAM is a VERY limited matrix operator - it takes two matrices and gives you the resultant matrix for a few different operations. You still need to load the arguments by hand with the ARM, and read the result out by hand with the ARM. The matrix operations and registers in the JRISC chips (GPU and DSP) are far faster and much more flexible. There are instructions dedicated to them as well, making their setup and usage faster and easier. Clear win for the Jaguar.

    The ARM processor in the 3DO doesn't have a cache, so it's completely bus locked - it runs only as fast as it can fetch instructions and data, and store the results. The GPU and DSP in the Jaguar both have local ram for far faster data transfer. The ARM is indeed faster than the 68000 in the Jaguar, but you try to do as much as you can with the GPU, which trounces the ARM, hands down. Another clear win for the Jaguar.

    The MADAM is a better video processor than the BLITTER in the Jaguar, but the combination of the BLITTER and GPU together is a bit more flexible. Harder to use, but could give better results. May be counted as a win for the 3DO, but not a big one.

    The CEL is not very flexible compared to the OP in the Jaguar, being merely a set of DMA channels. Not incredibly important for most purposes, but still a win for the Jaguar.

    In the end, it comes down to how the hardware was used. The 3DO had mature and fairly bug-free tools, but 3DO limited devs to using only their libraries to make future compatibility with altered hardware easier to do. That never came about, but it was there. Had devs been allowed to "bang on the hardware" with optimized assembly, you could have done much better. The Jaguar was burdened with buggy tools, and hard-to-make-full-use-of hardware. Nearly everything on the Jaguar used assembly, which devs of the time were not fond of as everything was shifting to C with a few assembly snippets for better speed. The lack of a robust C compiler for the JRISC chips in the Jaguar was probably the biggest problem.

    So I think the Jaguar was probably a much better console from a hardware point of view, but hampered by a lack of tools and "odd" architecture. The 3DO had great tools and a straight-forward design (like the PSX), but was hampered by restrictions imposed by 3DO in view of a future that never came about.
    Last edited by Chilly Willy; 04-28-2014 at 06:18 PM.

  9. #984
    Death Adder's minion
    Join Date
    Jun 2010
    Posts
    18
    Rep Power
    0

    Default

    Quote Originally Posted by Chilly Willy View Post
    The DSP in the 3DO is half the rate you mention, and a plain 16-bit DSP like the one used in the SVP by SEGA. It's good for audio, but not nearly as powerful as Jerry in the Jaguar. The Jaguar wins big here.

    The "math coprocessor" in MADAM is a VERY limited matrix operator - it takes two matrices and gives you the resultant matrix for a few different operations. You still need to load the arguments by hand with the ARM, and read the result out by hand with the ARM. The matrix operations and registers in the JRISC chips (GPU and DSP) are far faster and much more flexible. There are instructions dedicated to them as well, making their setup and usage faster and easier. Clear win for the Jaguar.

    The ARM processor in the 3DO doesn't have a cache, so it's completely bus locked - it runs only as fast as it can fetch instructions and data, and store the results. The GPU and DSP in the Jaguar both have local ram for far faster data transfer. The ARM is indeed faster than the 68000 in the Jaguar, but you try to do as much as you can with the GPU, which trounces the ARM, hands down. Another clear win for the Jaguar.

    The MADAM is a better video processor than the BLITTER in the Jaguar, but the combination of the BLITTER and GPU together is a bit more flexible. Harder to use, but could give better results. May be counted as a win for the 3DO, but not a big one.

    The CEL is not very flexible compared to the OP in the Jaguar, being merely a set of DMA channels. Not incredibly important for most purposes, but still a win for the Jaguar.

    In the end, it comes down to how the hardware was used. The 3DO had mature and fairly bug-free tools, but 3DO limited devs to using only their libraries to make future compatibility with altered hardware easier to do. That never came about, but it was there. Had devs been allowed to "bang on the hardware" with optimized assembly, you could have done much better. The Jaguar was burdened with buggy tools, and hard-to-make-full-use-of hardware. Nearly everything on the Jaguar used assembly, which devs of the time were not fond of as everything was shifting to C with a few assembly snippets for better speed. The lack of a robust C compiler for the JRISC chips in the Jaguar was probably the biggest problem.

    So I think the Jaguar was probably a much better console from a hardware point of view, but hampered by a lack of tools and "odd" architecture. The 3DO had great tools and a straight-forward design (like the PSX), but was hampered by restrictions imposed by 3DO in view of a future that never came about.
    Thanks Chilly Willy.

    It's useful to get a perspective from someone who knows both platforms well! I've read the SDK documentation about the maths instructions, but don't have the background to understand how it compares with the GPU (or GTE in the Playstation).

    I got the DSP clock speed from the 3DO FAQ, so assumed that was correct.

    With regards to the Cel Engine, do you know what the 3DO FAQ is referring to when it shows two "Dual Animation Processors" in the block diagram? Does this actually refer to the "Corner Engines" within the Cel Engine (I believe there are two in the Cel Engine and they work in parallel to process Cel lists), or are there two identical Cel Engines (so a total of four Corner Engines)? Different documents imply different things, but I've never managed to get a definitive answer.

    Thanks!

  10. #985
    ESWAT Veteran Chilly Willy's Avatar
    Join Date
    Feb 2009
    Posts
    6,744
    Rep Power
    78

    Default

    First, even today most console FAQs have more misinformation and advertising speak that real facts. Nearly all 32X FAQs still say it has hardware scaling and rotation, as well as QSound audio hardware. Second, where I said Cell in my post, I meant CLIO. I mix that up all the time.

    The "Dual Animation Processors" in the 3DO FAQ are just MADAM and CLIO. CLIO is a simple state machine that reads a command list and controls the DSP, timers, and DMA. I'm not certain how internals map to any FAQ... I suspect they're mostly wrong. MADAM has two functional units inside that deal with rendering, and are referred to as CELs, so I suspect those are the "Corner Engines" they mention. Most all the in-depth info is Russian documents released by the FreeDO programmers. You can look at those and the code of FreeDO for the best info on the actual hardware.

  11. #986
    Death Adder's minion
    Join Date
    Jun 2010
    Posts
    18
    Rep Power
    0

    Default

    Thanks Chilly for the useful info!

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •