enhancement chips and PPU accessing

enhancement chips and PPU accessing
by psycopathicteen on 2010-10-10 (#68435)

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.

by mic_ on 2010-10-10 (#68436)

Quote:
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?

by psycopathicteen on 2010-10-10 (#68438)

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.

by ccovell on 2010-10-10 (#68449)

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.

by MottZilla on 2010-10-10 (#68450)

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
by byuu on 2010-10-10 (#68453)

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.

by tepples on 2010-10-10 (#68458)

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.

by psycopathicteen on 2010-10-10 (#68463)

Then why is Bus-B and the halt pin connected to the cartridge for?

by byuu on 2010-10-10 (#68475)

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

by Bregalad on 2010-10-11 (#68477)

Quote:
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 ?

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

by psycopathicteen on 2010-10-11 (#68480)

Dang it. There is no way of getting around this stupid DMA speed limit.

by ccovell on 2010-10-11 (#68482)

Bregalad wrote:
Quote:
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.

by MottZilla on 2010-10-11 (#68492)

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.