Wich could have been an realistically accurate SNES by DATE?

Greetings.

Lately have been rounding over my head some questions about the snes and its potentially spectrum of possibilities in terms of hardware.

The option of an different cpu than the 65816 is discarded cause it always been plannified an custom WDC, but the question is, What kind of solutions would have been possible in that dates according to its costs?... How many 65816 were abailable in 1989, and maybe 1990?... prices?...

And what about the WRAM?, What was its cost?, How many kind of memories could be implemented to improve its 2,68Mhz?.

An spc700 with 2Mhz?... and the mother of all laments, How is possible that nintendo declined to include an 5$ SFX chip in all the snes?.


i'd really like to know what were the prices of all the available components in that years to figure out how could have been an realistic different configuration, but google doesn't helps too much...

I found this newspaper article from 1984 and it says the 68000 was only $15. If that's the case how cheap was it in 1990, and how much money did Nintendo really save by using a custom 65816?

https://www.nytimes.com/1984/06/29/busi ... -chip.html

They went with 65816 instead of 68000 because they wanted to make it easy to port NES games to SNES (my guess).

A custom memory controller was needed anyway for the DMA functionality. Consoles from 1996 and later tend to integrate the memory controller onto the GPU (cf. N64 RSP and Xbox 360 Xenos), but the S-PPU was already two chips. Also remember that for perhaps the first few months, Nintendo pursued compatibility with Famicom cassettes, and even after Nintendo discarded that, a 65816 was still familiar to experienced 6502 programmers. So it was one of these:

1. Use the 68000, add yet another chip for the memory controller, and discard previous-generation programmers' ISA experience.
2. License the 65816 core from WDC, put it on the same die as the memory controller, and leverage previous-generation programmers' ISA experience.

The Genesis got away with A because its VDP was much simpler: no affine backgrounds, fewer layers, very limited color math (shadow/highlight being a 50/50 mix with black or white), and smaller palette. This let it integrate some of the DMA functionality into the VDP; its memory controller mostly performs bus arbitration among the 68000 CPU, VDP, and Z80 CPU.

Not only in matters of money, i think the election of an 65816 was better having in mind the kind of software that the console was going to have.

It was too early to need math complex computation in these hardwares, cause all of its needings passed through by the capabilities of its video systems, so the better accesses and interrupts of the 65816 are better when you need to command many things in short spaces of time, for that games.


P.D: I've been searching for the link of the super fx costs, but i can't find nothing (and i'm sure i've read that was not more than 5$).

There is the small matter that the SFX didn't exist when the SNES was made. The fact is was made in the UK by Argonaut.

Does the SNES make use of the phi1 half of the clock cycle to bus share?

It's too bad 98% of the SNES library was programmed by robots who can't figure out how to juggle 3 registers.

I've read that it was near to be real simultaneously during the fabricantion of the american snes.



Here you have some info about this question:
http://forum.6502.org/viewtopic.php?f=4&t=4350



I meaned that the software of the 16 bits consoles doesn't require managing code for dooms, 3D games, complex physics, the use of multiplication intensively (motorola 6000 has it, but is not recommended precisely for lack of raw power).


Let me do you a couple of questions...
-Hard drivi'n in a motorola 68000 or in a 65816, both at the same speed.
-Final fight in a 68000@3.58mhz or in a 65816@3.58mhz.

In my opinion, 65816 is better for the kind of games of the second option, and the 68000 is better for the one's. All in terms of real perfomance, not friendliness coding.


But i tried to speak about another theme.

Nothing like the C64.

In the stock 65816, φ1 is used to drive the bank address on the data bus, but that's not visible in the SNES. I'm not clear how/if the bank address is multiplexed and then demultiplexed inside the CPU die, or if it just stays demultiplexed all the way from the core.

(from the other thread)


WRAM can operate at 3.58MHz (iirc byuu tested it?), but perhaps not reliably. DMA is always 2.68MHz.

If the SA1 has a 16-bit data bus then how can it read single bytes? All the addressing modes would have to be changed...

WRAM via its interface on the B bus is always at 3.6MHz, because of where it's addressed.

As far as I remember, no-one has seen any SNES parts work reliably at 2.7MHz but fail at 3.6MHz.

Ok so if the SNES doesn't use the Phi1 cycle for anything or access internally.. then why don't the expansion chips use that half of the bus instead of blocking the CPU when they want to access the RAM/ROM sigh..


So the US launch was Aug 91.
While the Japanese launch was Nov 90.
Given they needed to get hardware "locked" for devkits, documentation(ahahhaha) and so teams could finish their Launch titles at least 3 months before ROM fab, which took a month or so. So that puts final hardware 4 months min before Japanese launch. They would have needed working prototypes of the hardware at least 6 months before final devkits.They couldn't even just run a theoretical emulator on a more powerful PC because those didn't exist. I don't know how slow the Japanese MRA would have been back in the days of paper to clear and approve a machine. Plus time to setup production runs, board manufacture. However they also had to design, make and fab test their own custom chips, given I don't think Nintendo had in house Fab, that adds more delay. They would have also needed to get yield levels up to make sure a product was viable. Basically I feel that the final SNES specs or 90% of them of which the CPU and it timing characteristics would have been a massive part of the design would have needed to be worked out at least 1.5 years before launch. The SNES would have been designed before even Argonaut knew there was a SNES to make the SUPER FX for. While their is the story that the SNES was to be 68K but the MD forced their timelines to accelerate, and a switch to the 65816, so maybe they were having trouble with the 68K timings and the simpler 65816 meant they cold finalize the design faster.. however at that point all code would have had to be rewritten, so that must have been early enough in the dev process. the Mega Drive was announced in June '88 and launched in Oct '88 however development started in '86.

But then to split their market and make the US SNES have a FX chip while the SFC doesn't, doesn't make sense, as most of the SNES dev was done in Japan by Japanese developers, whom wouldn't make use of the FX chip because they would want to sell and target the SFC. And then 3D wasn't a big thing, sure Star Fox went on be a massive hit, but sitting at '90 you wouldn't have called it. The Quirky Gaigen game might have been a flop, and 3D a waste of money. I mean Sega didn't even think 3D was going to be a big thing with the Saturn.. Japan was anti and still kind of is 3D.

Afaik the Phi1 phase (it's one half of a clock cycle) is used to set up the address bus, plus the data bus if it's a write access.


This page has some interesting info/links.

You pull the 65816 Data bus off the Main bus, and then connect it to your "bank" latch. Thus leaving the bus open. But the address propagation etc takes time so you can you can set up the Phi1 address while the Phi2 is falling and the main device is reading/writing the data bus.
65816 has the complication that you need to have external logic to tristate the 65816's bus during the Phi1 phase, and connect it to your latches and stop it from appearing on the "bus" but that is not hard to do



So the CPU was locked by Aug '88 and the hardware was mostly developed 87~88 with revisions to the layouts, small features etc tweaked up until 90

Here is a link from nintendolife (i didn't read yet).

The North American SNES Almost Shipped With Super FX Built-In
http://www.nintendolife.com/news/2013/0 ... x_built_in

According to this link, the super fx2 costed 10$:
http://www.anthrofox.org/starfox/superfx.html

I never could understand why Nintendo was stuck with slow ROMs for so long when Hudson/NEC got fast ROMs back in 1987.

Probably because Hudson/NEC spent more on speed and less on megabits (at least until the Arcade Card era).

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...

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".

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...

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

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.

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.

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.

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.

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.

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.

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.

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.


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.

The sPPU reads VRAM at 5.37 Mhz on a 16-bit bus, so I think it would be able to write to it at that speed too.

Read and write in the SNES are fully simultaneous. The DMA controller asserts /RD on A or PA bus and /WR on the other bus at the same time, while driving different addresses at the same time.

I thought I'd read that they weren't. Oh well. That's what I get for not checking.

In that case, it should at least be able to hit 4.3 MHz without upgrading any memory. Unless there's a good reason the DMA unit needs to observe 65xx half-cycle behaviour?


Well, yeah, VRAM is faster. But the source has to be able to keep up, and 4 master cycles is only 186 ns. I can imagine Nintendo not feeling comfortable with trying to drive a 200 ns memory at that speed.

On the other hand, 120 ns would handle it easily. It therefore seems that variable-speed DMA could indeed have allowed 5.37 MHz from a FastROM cartridge. It might also be possible to reliably run WRAM that fast, but who knows...

...

It's been suggested that the early plan for Famicom backward compatibility distorted the design process of the Super Famicom. It might have had a 68000 and a saner sprite system if they hadn't tried to do that.

MVN/MVP (already implemented by the 65c816 core itself, not the 5A22) reads a byte in one cycle and writes it in the next. As fas as the 65c816 is concerned, there is only one address bus.


The rest of the hardware still operates with the 2-phase system...

I don't think redisigning the sPPU to accept 5.37Mhz DMA would've been that difficult. Does anybody actually know how fast the original sPPU can pass data from the CPU's bus to VRAM?

We're talking about DMA. I thought somebody had said that it was two four-clock half-cycles, but apparently either the somebody was wrong or I misremembered.


My point is that I don't see why it needs to. Nothing else needs the bus. The DMA unit is not part of the core, and it should in principle be possible to design it to link up the data lines and push valid addresses and read/write signals on both buses for the whole cycle. And if that's true, there's no reason the cycle needs to be longer than five master clocks in the worst case.

No?

That's what I remember seeing in the logic analyzer traces from Poot36. 4 master clocks for φ1, 4 master clocks for φ2, 2.7MB/sec. Really not clear why it's not the same 3/5 timing as ordinary 2.7MHz operation.

The DMA hardware should be simpler than the 65c816 hardware, so theoretically the timing should be more lenient, and able to run faster. But IF the majority of the delay were due to the bus drivers instead of internal logic, maybe not.

I don't really have any better guesses than that as to why DMA timing isn't more aggressive.

Hardware is not this magic thing that can do something in 0 time, gates have delays, and traces have capacitance. The DMA needs to be able to do its maths and then update the address lines on the BUS and it can't change the lines while it driving the bus otherwise it will conflict.
So it needs to

so it needs to
Phi Hi
set CS lines
set CAS / Set other
set R/W lines
waits
CAS fires
waits
set RAS
waits
RAS fires
waits
wait for Byte to transfer
Phi Lo
clear CS lines
work out which address to inc
inc address
dec number of bytes to do
sort priority of which channel gets the BUS next
Do HDMA check

its not just magic byte in zero time down the buses.
However it would have been nice is they used Page Mode RAM, so once it started doing the transfer it could pump data across with only RAS updates. But then when a HDMA kicks in that wrecks it and you would need a bunch of logic to handle such cases. And then the CPU+PPU Ports etc would then have to be fast enough to be able to handle Data at twice the speed as well as normal speed, so it would need an extra control signal to handle the RAS read/write strobe.

This is not a trivial thing to solve. Case in point they stuffed it up on initial launch And it grows in complexity fast..

This is all academic however. the SNES is the most powerful of the two and it won handsomely, Nintendo didn't need to add anything more, it was already fit to win the race.

What does CS, CAS and RAS mean?

Chip Select - I.e I want to talk to this chip so listen the the control signals

Column Address Select
Row Address Select
DRAM uses half the pins for the address, to make smaller chips. RAM is stored in a grid. So you select the Column, then the ROW you want. This works out to be 8bits each, so the upper 8 bits make the Column then the lower 8 bits make the Row and that selects a unique "bit" of the RAM. ( you can switch the RAS/CAS such Column is lower 8 bits and Row is upper it doesn't matter )

so when you have DRAM at 120ns its 120ns to set up CAS, then 120ns to set up RAS, then usually some smaller amount to get valid data on/from the Data pins.

I really doubt that the 68k was available at that price .

Look at this interview :
https://www.polygon.com/features/2015/2 ... i-ishikawa


I read in another interview the use of a 68k was possible because SEGA has negotiated a very good price from Signetics(until the VA3 revision, all the Md have a signetics 68K),without this good price (for 300.000 unities),the Md would have come out with a 8 bits CPU .

@Oziphantom: I don't know if this can help:
http://www.archaicpixels.com/HuC6280

It seems to me that the part that does the math has very little in common with the part that handles the buses. Why couldn't the logic happen in parallel?

Now, if the logic by itself takes the whole cycle, that's another story...


What will conflict? The S-CPU pinout includes 24 A-bus address pins, 8 B-bus address pins, and 8 data pins; it looks like the bank byte is demuxed internally. I'm not familiar with the details of how the system works electronically, but if you want me to shut up and go away you're going to have to be a little less vague.

Besides, your postulated(?) sequence of operations has the entire bus handling operation happen during one half-cycle, and it really doesn't matter how much maneuvering you have to do in there as long as it fits.

Also, your DRAM description doesn't seem to match what we know of the S-WRAM, which is a 64-pin package including 17 A-bus address pins, 8 B-bus address pins (why?), and 8 data pins.

so you have a register, and it currently outputting a value onto the address bus. You then can't add or modify that value, while it is outputting it, otherwise you potentially get a mixed address on the bus.Now it will take time for all of it to propogate down the bus. So the DMA out outputs $1000, then you add $8 so now it outputs $1008.. this travels down the bus, WRAM sees $1008 while the PPU2 still sees $1000, so now the bus is in 'Conflict', one side says $1008 another says $1000, you need to wait for it to settle. 'Set up' time, then for the RAMs to be able to use the value they need it to be stable for set period 'hold time'. If you look at any timing diagram for any DRAM you will see they have the CAS, RAS, Setup times, hold times etc shown. You can have 2 registers and then double buffer it, so you can have a 'live' value on the bus, and then another value hidden behind that you do maths on. But that costs more silicon, registers are expensive. 16bit ones doubly

When you are doing DMA, the DMA controller is the BUS master, so it is driving and controlling the BUS and doing the Maths.

The S-WRAM sounds like its an all-in-one chip to cut down costs. So it will internally generate the CAS RAS signals from the simpler A BUS. If you look on say a C64 schematic you will see there is external chips that control the RAM bus, and do the RAS CAS logic.(https://www.commodore.ca/manuals/funet/ ... 64-22r.gif U12-U21 is the RAM, U13 25 are driving the RAS/CAS address by splitting the bus, pin 15 is CAS, pin 4 is RAS on the RAMs) The 128 fixed this by putting an signal from the VIC-IIe, as the C64 doesn't have a dedicated off a clock signal for it and relies upon propagation delay.
To reduce chip count S-WRAM holds the logic internally. It will also hold A and B bus arbitration. S-WRAM is not "a DRAM chip" its all the RAM + controller glue logic. I've not looked at the internals of the SNES enough to know how and when it would need to choose between A and B, but having a 2nd bus that is 8 bits simplifies logic, saves on traces allowing for less layers on a a board, and less pins on chips. So if things only need an 8bit address is a nice cost saving method ( see the 8088 vs 8086 and the M68K half bus )

Now we're getting somewhere.


Yep. Nintendo was apparently not all about piling off-the-shelf chips onto a board and selling it. This has unfortunately resulted in the SNES being very difficult to repair when the CPU or RAM goes bad... Compare the Mega Drive, which reportedly suffers only minor game compatibility issues when you drop in a stock 68010.


The B bus is mostly for PPU communications; the expansion port is also on it. From the CPU's perspective, the B bus is mapped to $21xx in banks $00-$3F and $80-$BF. DMA is always between bus A and bus B. The audio data ports are also on the B bus, as is a one-byte-wide WRAM gate to allow DMA from cartridge to WRAM.

So technically the WRAM can be accessed via the B bus, but it's always at the same address ($80) and the actual target location in WRAM is a 17-bit auto-incrementing value specified via MMIO. I still don't get why WRAM has those B bus pins, unless it's literally just to implement the address and data ports...

Indeed, the SNES's S-WRAM shouldn't need any particular DRAM timings at all: it might use the exact same addressing hardware as a conventional static RAM.

In both SRAMs and DRAMs, there are both rows and columns; it's just that in most DRAMs, the address bus is multiplexed to reduce pin counts. But EDO and FPM DRAMs and their older predecessors are still asynchronous technologies; it's only the multiplexing that enforces these timing constraints. So I wouldn't be surprised to see something that looks shockingly SRAM-like in a decapped S-WRAM. (Too bad the people who decapped all the other chips in a SNES didn't bother with the S-WRAM)

There's a word for DRAMs that expose an SRAM-like interface: pseudo-static RAM (PSRAM). Based on this discussion, S-WRAM sounds like a PSRAM, though I seem to remember it was customized to listen on two address buses (though one at a time) and have extra logic for mapping banks $00-$3F and $80-$BF to $7E rather than $7F.