Wich could have been an realistically accurate SNES by DATE?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

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

Post by psycopathicteen »

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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

93143 wrote:I'm not totally clear on how DMA works, but I imagine there's a reason the read and write aren't fully simultaneous.
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.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

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

Post by 93143 »

lidnariq wrote:Read and write in the SNES are fully simultaneous.
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?
psycopathicteen wrote: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.
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.
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

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

Post by creaothceann »

93143 wrote:
lidnariq wrote:Read and write in the SNES are fully simultaneous.
I thought I'd read that they weren't.
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.
93143 wrote: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?
The rest of the hardware still operates with the 2-phase system...
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

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

Post by psycopathicteen »

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?
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

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

Post by 93143 »

creaothceann wrote: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.
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.
The rest of the hardware still operates with the 2-phase system...
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?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

93143 wrote:I thought somebody had said that it was two four-clock half-cycles,
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 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.
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.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

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

Post by Oziphantom »

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.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

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

Post by psycopathicteen »

What does CS, CAS and RAS mean?
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

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

Post by Oziphantom »

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.
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

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

Post by TOUKO »

psycopathicteen wrote: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
I really doubt that the 68k was available at that price .

Look at this interview :
https://www.polygon.com/features/2015/2 ... i-ishikawa
Arcade consoles were already using 16-bit systems, but cost considerations meant that the decision to use an 8-bit or 16-bit CPU was made quite late in the design process. I think the final decision was made by the manager at the time, Sato-san, who later became president of the company. By using the 68000 we could take advantage of the programming resources already available for arcade use, plus the hardware — bus components — and software — for coding — were relatively simple to get to grips with.
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
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

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

Post by 93143 »

Oziphantom wrote:The DMA needs to be able to do its maths and then update the address lines on the BUS
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...
and it can't change the lines while it driving the bus otherwise it will conflict.
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.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

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

Post by Oziphantom »

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 )
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

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

Post by 93143 »

Oziphantom wrote:But that costs more silicon, registers are expensive.
Now we're getting somewhere.
The S-WRAM sounds like its an all-in-one chip to cut down costs.
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.
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
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...
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

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

Post by lidnariq »

Oziphantom wrote: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 )
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)
Post Reply