Page 2 of 4

Re: Wich could have been an realistically accurate SNES by D

Posted: Thu Sep 27, 2018 7:15 pm
by SeƱor Ventura
According to this link, the super fx2 costed 10$:
http://www.anthrofox.org/starfox/superfx.html

Re: Wich could have been an realistically accurate SNES by D

Posted: Sat Nov 17, 2018 11:50 am
by psycopathicteen
I never could understand why Nintendo was stuck with slow ROMs for so long when Hudson/NEC got fast ROMs back in 1987.

Re: Wich could have been an realistically accurate SNES by D

Posted: Sat Nov 17, 2018 12:12 pm
by tepples
Probably because Hudson/NEC spent more on speed and less on megabits (at least until the Arcade Card era).

Re: Wich could have been an realistically accurate SNES by D

Posted: Sat Nov 17, 2018 1:13 pm
by creaothceann
Also, part of the reason is the 8-bit data bus. If the 65c816 would use 16 bits per memory access like the 68k, it'd be much faster...

Re: Wich could have been an realistically accurate SNES by D

Posted: Sat Nov 17, 2018 2:30 pm
by Memblers
psycopathicteen wrote:I never could understand why Nintendo was stuck with slow ROMs for so long when Hudson/NEC got fast ROMs back in 1987.
From wikipedia: "NEC Semiconductors business unit was the worldwide semiconductor sales leader between 1985 and 1990". That's a pretty big deal. We hear about Nintendo having ROM shortages. NEC would probably say "ROM shortage? Sucks to be you".

Re: Wich could have been an realistically accurate SNES by D

Posted: Sat Nov 17, 2018 6:03 pm
by 93143
You know what else Hudson spent time/money on that Nintendo didn't? Removing the pointless half-cycle strobe that doubled the memory speed requirements (or halved the achievable CPU speed, depending on your perspective). This is why the HuC6280 ran at 7.16 MHz, while the 5A22 could only run at 3.58 MHz even with very expensive ROM.

The 5A22 was already somewhat custom. Going the 6280 route on the bus handling would have resulted in the best CPU of the generation. Doubling the bus width the way they did with the SA-1 might have been possible too, but unless the core were redesigned to use it natively, wait states would be abundant and the speed increase might be a bit disappointing (the SA-1 runs at half speed when accessing BW-RAM, or when branching, or when reading data from ROM - basically anything the memory controller can't preload, other than I-RAM which appears to genuinely support 10.74 MHz access).

As I've said before, a custom 65xx-type chip with a 16-bit bus and full-cycle memory access (allowing 7.16 MHz native speed with 4.3 MHz RAM/SlowROM access) would have been an amazing CPU for the SNES, close to quadruple the power of what we got. Make the bottom 8 KB of WRAM a fast SRAM cache, and now you can work at 7.16 MHz in RAM, equivalent to about 14 MHz on the actual 5A22, or maybe 25 MHz on the 68000 (the exact multiplier is task-dependent and somewhat of a controversial topic).

With a 16-bit bus, DMA would be twice as fast even at 2.68 MHz (which might be as fast as WRAM can go anyway; I'm not totally clear on how the DMA works electronically). That gives you, broadly speaking, PAL VBlank performance on an NTSC machine.

128 KB VRAM? The PPU is already set up for it... Two-player F-Zero without shenanigans? Park a second Mode 7 area at $8000 and add a selector bit (or just make Mode 7 moveable) and Bob's your uncle. On the other hand, maybe Mario Kart wouldn't exist...

Supposedly the DSP-1 was nearly part of the Super Famicom, and Pilotwings had to be equipped with it in a hurry to avoid a massive rewrite. I've looked at the specs of the chip, and it's way more powerful than it gets to show off; it seems most of the time is spent working around the horrible strict Harvard architecture. Give it a dual-ported program RAM (or even just a couple of registers to let the 5A22 poke values in branch instructions) and you're looking at some serious coprocessor muscle.

...

Of course, the lowest of low-hanging fruit was the ability to use DMA and HDMA at the same time without risking a crash. This was actually in the final design (HDMA is supposed to seamlessly interrupt bulk DMA, which resumes afterwards), and Nintendo caught the bug that caused the crash, but not before shipping a ton of consoles...

Re: Wich could have been an realistically accurate SNES by D

Posted: Sat Nov 17, 2018 10:16 pm
by psycopathicteen
What year did Nintendo fix the DMA/HDMA bug?

Some little changes I would've made to the final design:
- 24kB of RAM in bank $00
- Ignore DRAM refresh unless accessing RAM
- 16 byte FIFO for accessing VRAM during active display

Re: Wich could have been an realistically accurate SNES by D

Posted: Sat Nov 17, 2018 10:31 pm
by 93143
Well, it's one of the things they changed in the rev. 2 CPU, so whenever that came out.

Also, it seems the SNES serial number database has been discovered by spammers...

In addition to the VRAM FIFO, I'd add a way to access OAM during HBlank. Also, OAM itself is a bit suboptimal; a few more bits per sprite and a saner layout could have alleviated a lot of issues.

Re: Wich could have been an realistically accurate SNES by D

Posted: Sat Nov 17, 2018 10:41 pm
by Oziphantom
The half strobe is not pointless, it is necessary. In that you need the 2 'T' cycles in order for the CPU to operate. You could make the die a lot larger and probably avoid it, but that would ramp up costs a lot and require the chip be redesigned from the ground up. So if the external bus is 7mhz the chip internal must be running at 14mhz. As the C64 6510 runs "at 1mhz" but it has a 2mhz bus and a 2mhz internal speed of the 6502. The NES has an external bus of 1.8Mhz and an internal speed of 3.6Mhz. The SNES has an external speed of 3.6 and internal speed of 7.2.

I imagine the HuC6280 pre-fetches the next byte, in that you only need 1 byte per "cycle" however the CPU expects data at the fall. But if you go the byte the cycle before, you can give it to it when it wants it, while you then read in the next byte off the bus at half the speed. If anybody has and docs on the internal workings, or fetch timings of the HuC6280 please share. The SA-1 basically does this as well, just it grabs 16bits at once, and then holds on to the other 8 bits for the half cycle.

Re: Wich could have been an realistically accurate SNES by D

Posted: Sun Nov 18, 2018 2:13 am
by creaothceann
Right, afaik you need 2 phases because it's a bidirectional bus. You could read/write in every phase if you had an outgoing "write" data bus and an incoming "read" data bus - of which only one would be active at a time except (maybe) for Read-Modify-Write instructions.

Re: Wich could have been an realistically accurate SNES by D

Posted: Sun Nov 18, 2018 2:23 am
by 93143
Oziphantom wrote:If anybody has and docs on the internal workings, or fetch timings of the HuC6280 please share.
That would be interesting to know. It's possible that whatever they did wouldn't stack with the benefit of a 16-bit bus.

Either way, Hudson did a thing that Nintendo didn't, and the result was that their CPU was twice as fast. And since it was in 1987 and not 1995, the question of whether it would have been feasible in 1990 doesn't arise.

Re: Wich could have been an realistically accurate SNES by D

Posted: Sun Nov 18, 2018 11:24 am
by psycopathicteen
Having a 16-bit DMA at 5.37Mhz with no DRAM refresh gives you 25kB per frame, which is already bigger than the SNES sprite pattern VRAM.

Re: Wich could have been an realistically accurate SNES by D

Posted: Sun Nov 18, 2018 6:32 pm
by FitzRoy
I don't really understand why arcade games didn't influence Nintendo's CPU decision more. The NES got tons of arcade ports. The 68k was being used in a lot of arcade boards at the time, including CPS1. It would've made for more and better ports.

I'm also wondering why something like the S-DD1 wasn't part of the console from the get-go. I'm sure there's an explanation for it, but... given how expensive roms were, a chip that could let developers compress their data by 50% at the expense of load times would've been very welcome for RPGs and arcade ports.

I just think Nintendo is a great software developer that had tunnel vision for their own games. Popular opinion is that they did it to save money. Yet... how much money did they spend on SA1 chips? How much money did they lose to Sega by letting Sega market their older console as being faster? And then to Sony by ignoring third-party devs? How do you lose Squaresoft and Capcom to an upstart? There's a saying for this: penny wise, pound foolish.

Re: Wich could have been an realistically accurate SNES by D

Posted: Sun Nov 18, 2018 7:43 pm
by psycopathicteen
I'm more bothered by the fact it took almost every developer 6 years to figure out how to make an optimized collision detection code and it only took me a couple seconds to do it. :roll:

Re: Wich could have been an realistically accurate SNES by D

Posted: Sun Nov 18, 2018 8:30 pm
by 93143
FitzRoy wrote:at the expense of load times
What load times? The S-DD1's decompressor could feed DMA; there was no significant loading penalty as far as I'm aware. Load times could end up being an issue without the S-DD1 if the CPU had to do a bunch of decompression, but an S-DD1 should be roughly on par with an uncompressed ROM.

The SFA2 loading pauses seem to be for audio data; Capcom used a slow manual loading method that required the whole game to stop and wait for it to finish. It's probably possible to eliminate these pauses with a clever scheme, but the issue is unrelated to the S-DD1.

Also, we should probably be careful when loading up a fantasy SNES with bells and whistles; there are a lot of ideas that seem good in isolation, but when you put them all together you get a much more expensive and complicated console. My suggestion of 128 KB VRAM probably wouldn't play well with the DSP-1 being part of the console too, for instance; there's a reason they were both taken out. Note also that the S-DD1 wasn't used in a game until 1996; it might not have been feasible in 1990 for a reasonable price (Moore's Law was in full swing back then), or perhaps the idea simply didn't occur to anyone.
psycopathicteen wrote:DMA at 5.37Mhz
Is that electronically possible without faster memory? I'm not totally clear on how DMA works, but I imagine there's a reason the read and write aren't fully simultaneous.