No no, I mean Star X:
https://www.youtube.com/watch?v=CZPB4FNoUS0
Hum, that probably could actually be better suited for a 32X release.
Printable View
No no, I mean Star X:
https://www.youtube.com/watch?v=CZPB4FNoUS0
Hum, that probably could actually be better suited for a 32X release.
Seriously can most of those people in that NA thread even read ? I agree with others here, it's a demo of a STOCK Genesis running it. NO FX CHIP. "Posting this 19 years after the SNES did it is silly". I think their comprehension skills are silly.
Thanks for your generous offer but i don't want any donation for that :p I do it for my pleasure too and i prefer to avoid any sort of constraint :)Quote:
Originally Posted by djvectorman
Honestly i can't give any date or whatever, i can't even say it will happen as I do it on my free time and i won't have much for the next month at least :-/
Epic job with this Stef.
I love how people strive to push the Genesis and its hardware to its limits, and even surpass its limits.
Keep it up, and great job.
Isn't it possible to resign a renderer that draws directly in cell (tile) order so no conversion is needed? I remember Tiido specifically mentioning that this is the fastest route, though also tougher to program compared to linear bitmap frames.Quote:
Originally Posted by Stef
In any case, you could still opt to double buffer the framebuffer window tiles in VRAM and page flip between them as needed. Optining for a single buffer has other advantages, but since Star Fox deals with similar VRAM constraints and double buffers anyway, I don't see this as being problematic.
Quote:
Originally Posted by djvectorman
And Hard Drivin', and Race Drivin', and F-22 Intercepter, and LHX Attack Chopper, and Steel Talons, and Mig-29, among a few others. (and some bonus stages and other effects like in ResQ -albeit unreleased)Quote:
Originally Posted by djvectorman
On SNES, the only software rendered polygon games I know of are Race Drivin and Steel Talons (which looks absolutely nothing like the Arcade -unlike the Genesis/Atari ST/Amiga/DOS versions . . . even the Atari Lynx version is arguably more like the arcade than the SNES game).
On that note though, I don't think any SNES game really showed what it could really do with polygons, since the best showing should be rendered to a mode 7 window (like Wold 3D or Toy Story's crane game maze) and would be running at 3.58 MHz in ROM. That, and I'd be curious to see how some of the cheaper "helper" chips would do for 3D short of Super FX, or just adding some fast work RAM on cart (so the CPU can render at 3.58 MHz rather than 2.68 MHz in main DRAM) . . . DSP-1 was the oldest coprocessor used on the SNES, and that sort of chip really should be able to help with 3D processing.
Of course, there's also the SA-1 chip, though I'm not really sure that's cheaper than Super FX by that much. (its adds very different added processing resource with the 10 MHz 65816, but the main usage was for the realtime tile/sprite decompression and added lockout capabilities . . . not sure if the compression was more powerful than what Super FX could do in software, but in any case it was obviously one of those cases where the ROM savings more than made up for the cost of the add-on chip)
Most GBA 3D would fall under the "suitable for 32x" category. ;) (granted, many GBA games use much more ROM than any 32x game)Quote:
Originally Posted by sheath
In the 1970s, with 8080/8085/Z80, 6800, and 6502, you typically didn't even have a 2:1 clock advantage for the Intel derivatives over the MOS/Motorola chips. Sure, the slowest Z80s were rated for 2.5 MHz, but the earliest mass-produced home computers used 1.79 MHz Z80s (TRS-80 model 1), and 1 MHz 6502s (PET and Apple II). It wasn't until the 3~4 MHz Z80 platforms arrived that the differences became more consistent (fastest 6502 platforms at 2 MHz, and more often 1.79 MHz -in spite of actual NMOS 6502s being rated up to 3 MHz), but then you also had the odd case of the .895 MHz 6809 based CoCo. (IMO, the latter is a particularly odd case given Tandy's use of Z80 in its other machines . . . the 6809 is interesting, but with that clock speed and the typical pricing of faster Z80s, it seems rather odd . . . it got more interesting when the CoCo III finally bumped that to 1.79 MHz though -granted Z80s could have been much faster at that point- and the cancelled 3.58 MHz 6309 version might have been particularly interesting)Quote:
Originally Posted by TmEE
You also saw the similar, but more costly Motorola and Intel 8-bit offerings falling out of favor in general to the similar 6502 or directly compatible and enhanced in the Z80 vs 8080/8085 case. (why the 8088 became the popular choice for IBM is another question entirely . . . and not just the typical "they should have used 68k" or even suggestions for Z8000 or NS32016, but even the Z80 itself -particularly given the clock speeds involved, component cost considerations, and 8-bit bus)
Looking back at the Z80 vs 6502 comparison specifically, though, there were faster variants of both available but not in common use. NEC at least had 8 MHz Z80 machines actually in use commonly in the mid/late 1980s, and some arcade games did that too, but no other common home computers around that time really pushed for that at all (MSX took forever to even offer 5.37 MHz options, and the popular Amstrad/Sinclair designs never expanded to faster clock speeds aside from some relatively late clone designs). You had Apple intentionally holding the Apple II line back to try to push the Macintosh (which had been quite slow to take off), but even then you finally saw the 4 MHz Apple IIC+, even if the IIGS was stuck with a gimped 2.8 MHz 65816. (though you had accelerator boards offering much faster clock rates, up to 16 MHz with the IIGS iirc)
The fact that the 65816 was only available in 8-bit bus form limited things too. (and any 650x chip featuring a 256 byte scratchpad on-die would have been really interesting . . . full-speed on-chip zero-page support could have been really interesting . . . that and SRAM is really dense on-chip so adding such a scratchpad to one of the CMOS variants shouldn't have been unrealistic either -actually I wonder if that would have actually taken less silicon than the 65816 added over the 65C02)
Anyway, with the PC Engine's 7.16 MHz 65C02S derivative, that breaks the typical context, since the clock speed was close to that of typical late 80s x86 and 68k processors of home computers and arcades. That, and Hudson tweaked a few things internally that made the memory timing constraints less sensitive. (though I do wonder if one of those changes was adding an 8-bit latch internally)
And this is where Chilly Willy's and Tomaitheous's comparisons came into play.
I was under the impression that use of bus latches could address some of that (aside from raw latency/throughput limitations of memory itself), and not unlike some related problems on faster clocked processors. (you couldn't have the zero wait state interleaved RAM accesses in the ST or Amiga without latches . . . and same thing if you wanted a 16 MHz 68000 accessing the same RAM -without interleave- with zero wait states)Quote:
The fast bus cycles that are stuck in one-another are harmful for many applications, there is a reason why nobody did that, not without bus request facilities. Most of 65x series never had any of that, you need extra hardware to achieve it which tends to null up the saving on CPU itself. Most computers used something else just because of it.
Granted, if there had actually been common use of faster clocked 650x derived CPUs (or similar), you'd need more than just bus latches to keep things going . . . and the few faster 6502/816 based machines/accelerators did implement caches to address that issue. (granted, something that became critical to all CPUs eventually, but the proportionally fast bus accesses on the 650x -and reliance on that for performance- made that problem materialize sooner than on others)
Know what else uses the 68000 processor? The Amiga:
That demo is at least being run on a 68030..
Actually i just downloaded the demo.
Needs a 68060..
And the Neo Geo... And virtually every arcade board during the late '80s / early '90s...Quote:
Originally Posted by old man
So if almost everyone used that Motorola 68000 chip in late 80s and later in computers, vgs or maybe E music instruments, why besides saving money did Nintendo use that slow seemingly unfitting/outdated chip ? I mean SNES made themselves look bad with that slowdown and flicker and if you came out after Genesis and wanted to beat it why not use something more advanced or at least the same as Genesis?
http://i45.tinypic.com/309qau9.jpg
Would using the cheapest parts/chips really save you much money anyway as you are not making money off producing consoles anyway ? Yes you don't need to be the most advance to be best but that SNES chipset hindered gameplay to the point various cheater chips needed to be made for many games yes ? Did Sega and JVC (or Tec Toy) buy exclusive rights to that Motorola 68000 + Z80 (same or another Motorola chip, why need 2 ?) chips for those specific years 1988-1996 ? So Genesis in 1988 had 7 mhz but SNES in 1992 had 3 mhz ? Uh, why ? And are the mhz an overall estimate of avg board power or just the specific main cpu ? Yes I could google it, but I signed up here to get direct answers from experts so that is why I ask questions here. I get lost reading all the 1.2 Gigawatts stuff above, so please explain simpler for me as I'm not tech savy.
The currently "accepted" answer is that the SNES was originally supposed to have backwards compatibility with the NES, and that was cut at the last minute. Personally this doesn't make much sense to me as the rest of the hardware shows no resemblance to the NES. Maybe the idea was to release an adapter later? I dunno.
The CPU (besides being horrible to program for) is actually really powerful, it's more efficient than the 68k, the issue is the speed at which it runs (2.68 MHz while reading RAM, 3.58 MHz if accessing ROM). At that speed, specially 2.68, it's not even close, the 68k just points and laughs.
Why that speed? Cost. Exactly why I'm not sure, the PCE didn't have any problem having super fast ROM and RAM.
PCE only had 8KB of that super fast RAM and usually 256KB of that ultra fast ROM...
Thanks guys.
What is crazy to me about these SNES cheat chips is now they basically put the Sega CD tech basically in a game :
http://www.youtube.com/watch?v=1SLifXglq-8
Not sure if that can run on hardware ?
But I remember in 1992 or so and being like wow Sega put 4 games in 1 or 5 games in 1 on CD this the is future then years later seeing a 6 in 1 Genesis cart in store ha ha.
But early on with pictures I posted on last page, Genesis had a Modem for back port in Japan, they visioned a CD ROM add on and Floppy add on. Not sure if all that could run at once, but that 68000 seemed like a magic chip. Was that first made for defensive purposes like most tech ?
Now even using that 1988 (or older) chip in 1995 they were going to put svc chip for Genesis Virtua Fighter and Daytona. That would have been incredible to have 3 svc Genesis games. But Sega only used it for one game on Genesis. I don't even know how many cheater chips were in SNES games.
If SNES was 3 mhz why would Nintendo even attempt a cd add on with Sony (failed) then Phillips (failed) then Sony again (failed then the hybrid SNES cart/Playstation CD proto canned) would the 3 mhz mean it would stress or slowdown handling a CD Rom ? The SNES satellite to d/l games add on was cool. So were all the Sega and Nintendo d/l services like Sega Channel or XBand etc.
All of those were supposed to have an extra CPU much like the Sega-CD.Quote:
Originally Posted by djvectorman