Wich could have been an realistically accurate SNES by DATE?
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Wich could have been an realistically accurate SNES by D
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.
Re: Wich could have been an realistically accurate SNES by D
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 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.
Re: Wich could have been an realistically accurate SNES by D
I thought I'd read that they weren't. Oh well. That's what I get for not checking.lidnariq wrote:Read and write in the SNES are fully simultaneous.
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.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.
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.
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: Wich could have been an realistically accurate SNES by D
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:I thought I'd read that they weren't.lidnariq wrote:Read and write in the SNES are fully simultaneous.
The rest of the hardware still operates with the 2-phase system...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?
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Wich could have been an realistically accurate SNES by D
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?
Re: Wich could have been an realistically accurate SNES by D
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.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.
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.The rest of the hardware still operates with the 2-phase system...
No?
Re: Wich could have been an realistically accurate SNES by D
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.93143 wrote:I thought somebody had said that it was two four-clock half-cycles,
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.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.
I don't really have any better guesses than that as to why DMA timing isn't more aggressive.
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Wich could have been an realistically accurate SNES by D
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.
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.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Wich could have been an realistically accurate SNES by D
What does CS, CAS and RAS mean?
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Wich could have been an realistically accurate SNES by D
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.
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.
Re: Wich could have been an realistically accurate SNES by D
I really doubt that the 68k was available at that price .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
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 .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.
@Oziphantom: I don't know if this can help:
http://www.archaicpixels.com/HuC6280
Re: Wich could have been an realistically accurate SNES by D
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?Oziphantom wrote:The DMA needs to be able to do its maths and then update the address lines on the BUS
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.and it can't change the lines while it driving the bus otherwise it will conflict.
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.
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Wich could have been an realistically accurate SNES by D
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 )
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 )
Re: Wich could have been an realistically accurate SNES by D
Now we're getting somewhere.Oziphantom wrote:But that costs more silicon, registers are expensive.
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 S-WRAM sounds like its an all-in-one chip to cut down costs.
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.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
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...
Re: Wich could have been an realistically accurate SNES by D
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.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 )
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)