Page 1 of 1
enhancement chips and PPU accessing
Posted: Sun Oct 10, 2010 10:24 am
by psycopathicteen
What is the maximum speed an enhancement chip is allowed to access PPU registers and V-RAM? The PPU is 10 Mhz and it's V-RAM is 5 Mhz, so that means the PPU regs should be allowed access at 10 Mhz, and the V-RAM address and data ports at 5 Mhz. However, knowing Nintendo's engineers messed up a lot when developing the SNES, something tells me they messed this up too.
Posted: Sun Oct 10, 2010 11:07 am
by mic_
knowing Nintendo had pretty bad engineers during this time period, something tells me they screwed this up too.
They did? I wasn't aware of that..
How did you find out which of their decisions were results of incompetence, and which simply came from the requirements they were given by management, the target bill of materials and the time they had available?
Posted: Sun Oct 10, 2010 11:13 am
by psycopathicteen
Maybe not "bad" engineers, but the SNES was originally going to be another 8-bit system, then when they finally had the hardware figured out, the Sega Genesis came out, and they had to make 1,000,000 changes in the last minute.
Posted: Sun Oct 10, 2010 3:17 pm
by ccovell
Not true. It had been known that the SFC would be 16-bit since 1987, and its specs were essentially finalized by late 1988, before the MD came out. The only change in the hardware (that I can see) between 1988 and its release in late 1990 was an increase of system RAM on the SFC.
For proof, see here:
http://www.disgruntleddesigner.com/chri ... 988Q4.html
and
http://www.disgruntleddesigner.com/chri ... 989Q3.html
So your claim that they made 1,000,000 changes is simply not true, unless you're counting every bit of RAM added. A more damning criticism that I like to make of Nintendo is that they did almost
nothing, hardware-wise, to beef up the SFC in the two years before its release.
Posted: Sun Oct 10, 2010 3:26 pm
by MottZilla
I think that was pretty awful too Chris. You'd think with such a delay they would have done more than add RAM. Increase in CPU speed would have been very nice. If it were practical at the time, which I don't know that it would have been, it would be a shame for them to have not done this. Not that the SNES is severely handicapped by it, but more CPU time is always good.
Re: enhancement chips and PPU accessing
Posted: Sun Oct 10, 2010 5:28 pm
by Near
psycopathicteen wrote:What is the maximum speed an enhancement chip is allowed to access PPU registers and V-RAM?
0MHz. A special chip inside a cartridge cannot access the PPU registers, and thus cannot access VRAM.
The S-CPU controls the address and data bus, so a special chip can only control busses on its end of the chip. In other words, cartridge ROM and RAM.
From here, the S-CPU can read this data back if the special chip lets it, and with DMA, that effectively allows a transfer rate of 2.68MHz to VRAM.
Posted: Sun Oct 10, 2010 5:51 pm
by tepples
ccovell wrote:A more damning criticism that I like to make of Nintendo is that they did almost nothing, hardware-wise, to beef up the SFC in the two years before its release.
Nintendo is known for designing something and then introducing it once the manufacturing price has fallen. This was true of the Game Boy Advance, which was developed under code name Atlantis in parallel with the Game Boy Color.
byuu wrote:a special chip can only control busses on its end of the chip. In other words, cartridge ROM and RAM.
From here, the S-CPU can read this data back if the special chip lets it, and with DMA, that effectively allows a transfer rate of 2.68MHz to VRAM.
What are the side pins for again? Super FX, SA-1, and Super Game Boy won't run without them.
Posted: Sun Oct 10, 2010 7:11 pm
by psycopathicteen
Then why is Bus-B and the halt pin connected to the cartridge for?
Posted: Sun Oct 10, 2010 10:42 pm
by Near
Bus B is connected so that it can detect B-bus writes FROM the S-CPU. You could use this to implement your own $21xx MMIO registers on a cartridge if you wanted.
There is no halt pin on the cartridge connector. You may be thinking of the refresh pin which is to tell the cartridge that the S-CPU is sleeping for DRAM refresh. Cartridges can use that to refresh their own DRAM or whatever.
The reason you have all these read-only signals is so that games can do heuristics for various extra features. The S-DD1 spies on DMA commands to begin decompression from ROM only when you are performing a DMA transfer.
Code: Select all
MCK - 01 32 - /RAMSEL
EXPAND - 02 33 - REFRESH
PA6 - 03 34 - PA7
/PARD - 04 35 - /PAWR
<key>
GND - 05 36 - GND
A11 - 06 37 - A12
A10 - 07 38 - A13
A9 - 08 39 - A14
A8 - 09 40 - A15
A7 - 10 41 - A16
A6 - 11 42 - A17
A5 - 12 43 - A18
A4 - 13 44 - A19
A3 - 14 45 - A20
A2 - 15 46 - A21
A1 - 16 47 - A22
A0 - 17 48 - A23
/IRQ - 18 49 - /ROMSEL
D0 - 19 50 - D4
D1 - 20 51 - D5
D2 - 21 52 - D6
D3 - 22 53 - D7
/RD - 23 54 - /WR
CIC0 - 24 55 - CIC1
CIC2 - 25 56 - CIC3
/RESET - 26 57 - SYSCK
+5V - 27 58 - +5V
<key>
PA0 - 28 59 - PA1
PA2 - 29 60 - PA3
PA4 - 30 61 - PA5
SOUND-L - 31 62 - SOUND-R
Posted: Mon Oct 11, 2010 4:15 am
by Bregalad
The only change in the hardware (that I can see) between 1988 and its release in late 1990 was an increase of system RAM on the SFC.
Didn't they remove the NES backwards compatibility, too ?
Super FX, SA-1, and Super Game Boy won't run without them.
I haven't any SA-1 games, but on my Super FX games, only one pin is just grounded though a capacity or something like that.
Posted: Mon Oct 11, 2010 5:16 am
by psycopathicteen
Dang it. There is no way of getting around this stupid DMA speed limit.
Posted: Mon Oct 11, 2010 5:36 am
by ccovell
Bregalad wrote:The only change in the hardware (that I can see) between 1988 and its release in late 1990 was an increase of system RAM on the SFC.
Didn't they remove the NES backwards compatibility, too ?
No, as early as 1988 (again, see my link above) the SFC was completely incompatible with the Famicom.
Posted: Mon Oct 11, 2010 9:13 am
by MottZilla
If you check out his link you can see this "adapter" that looks sort of like the Tristar that actually was released and does basically the same thing except being a crappy NoaC.