Why No Cartridge Access to the PPU?

[turboxray]

I've always found it interesting that the SNES and Mega Drive both seem to have been designed for 128 KB of VRAM in two 64 KB chips

So is the PC-Engine. It supports 128k vram. The PC-FX, that uses stock PCE VDC chips as one part of its video system, gives them the full 128k each.

[Oziphantom]

no, as the PPU bus is not going to marshal with the 65816 bus and do a 50/50 split perfectly, as the PPU needs full bandwidth. so you would need to add another 16 address lines and then 16 data lines as the PPU bus is 16bits to the cart. But then how do you get data into said RAM faster as its on the PPU bus you will still have to access it via the port and during blanking anyway. So you just have more, and don't have any faster way. Unless its banked ROM which gives you instant access I guess. But that doesn't seem to really help any instances were people want this, they want a faster way into VRAM which a separate bus won't accommodate.

But doesn't the sdd1 operate like this? If any of the cartidge rom address pins were shared with either vram or the ppu (or possibly the ppu output pins and just giving full control of the picture output to cart), it should be easy to perform writes with a simple additional pin that acts like a switch to some kind of multiplexer that could accept data from a cartridge cpu. It would have been very cheap to implement some copper and a few simple chips as a work around to crimping the vram from 128kb down to 64kb, considering they weren't planning on nerfing vram to begin with.

But I guess you're saying that even if there was 32 address lines available, the data rate would still be to slow. I thought the speed of the 65816 was the bottle neck for hdma writes as dma is capped at 2.68mhz? Wouldn't a faster main cpu give double the data write speed during blanking?

Well you could do that but then you would have to stall the CPU while the PPU was using the bus, which is like programming a ZX-80/81 or a Macintosh, absolutely rubbish, last thing you want. You would be reduced to VBlank only time for the CPU.

[mannes]

I've always found it interesting that the SNES and Mega Drive both seem to have been designed for 128 KB of VRAM in two 64 KB chips

So is the PC-Engine. It supports 128k vram. The PC-FX, that uses stock PCE VDC chips as one part of its video system, gives them the full 128k each.

Does the PC-Engine support vram upgrades through the hucard interface? I thought you needed a hucard 3 to play it's GOAT because it used more vram than the earlier games like monster world 3.

[Pokun]

No it's just that the VDC video chip is designed to be able to use more VRAM if used in another hardware configuration (like the PC-FX is), the PC Engine itself is probably not upgradable this way. It's the same for SNES and Mega Drive.

[tepples]

As I understand it, system card upgrades for PC Engine add to the work RAM, not the video RAM. The Arcade Card has a separate 2 MiB streaming memory that I'm guessing is meant mostly as a disk cache, a repository for data to be copied to VRAM using block transfer instructions.

[Pokun]

Yeah it's just work RAM, the Super CD-ROM² System Card has 192 kB extra RAM and the CD-ROM² unit itself contains 64 kB for a total of 256 kB extra work RAM (a Super CD-ROM² instead has the 256 kB RAM and the Super System Card ROM built-in, so the card is not needed but can be used).

The Arcade Card additionally adds 2 MB DRAM, but I think this doesn't go directly into the CPU address space. It comes in a Duo and a Pro version with the only difference is that the Duo is missing the 256 kB extra work RAM so it can only be used with a Super CD-ROM² unit that has this built-in while the Pro version is for a regular CD-ROM² unit.


The EXP port does expose the video data bus (unlike the HuCard slot), but I don't think you can extend VRAM from there either.

[lidnariq]

The EXP port does expose the video data bus (unlike the HuCard slot), but I don't think you can extend VRAM from there either.

It contains the raw composited pixels output from the VDC, after all sprites and backgrounds and merged, but before palette lookups.

And unlike the peculiar "VCESEL" pin on the EXP port, which disables the VCE digital outputs (hsync, vsync, pixel clock), there's no signal to disable the VDC digital outputs and inject our own pixels for the VCE.

[turboxray]

I've always found it interesting that the SNES and Mega Drive both seem to have been designed for 128 KB of VRAM in two 64 KB chips

So is the PC-Engine. It supports 128k vram. The PC-FX, that uses stock PCE VDC chips as one part of its video system, gives them the full 128k each.

Does the PC-Engine support vram upgrades through the hucard interface? I thought you needed a hucard 3 to play it's GOAT because it used more vram than the earlier games like monster world 3.

No. Expanding the vram on the PCE requires an internal mod just like on the SNES and MD. The rear expansion bus gives you access to a lot of things, but not vram.

[Señor Ventura]

It seems like 128KB of vram in snes was considered to have two mode 7 backgrounds, and i wonder if it occurs automatically just "installing" 128KB, since that function is still in the ppu as i've read time ago, or if that functionality was removed after cut in half the vram until 64KB.

In any case, How that two planes were supossed to behave between them?, Do the two planes could clip each other?.


Edit: something similar happens to the DMA's frequency... the WRAM frequency COULD be forcing to the DMA being underclocked to its speed, due to pipeline simetry conditions, in wich all the components work at the same frequency of the lowest frequency component (2.68mhz roms underclocks the cpu).

Anyway, it would be great if a 3,58mhz WRAM could unlock a 3,58mhz DMA.

[93143]

Pretty sure Mode 7 uses the whole VRAM bandwidth, because it needs to look up a tile index in the map and a pixel value in the tile for every dot it renders. VRAM reads run at 5.37 MHz for each chip, so that's that. You'd need four VRAM chips (or two double-speed chips) to overlay two Mode 7 layers, and the S-PPU isn't rigged for that.

With 128 KB of VRAM, you could have two separate Mode 7 tilemaps while still leaving room for sprites and data for other BG modes. This might have prevented Super Mario Kart, because F-Zero 2's two-player mode would have worked out fine.

...

As for the WRAM, I'm pretty sure it has no effect on the CPU timing, and that includes DMA. The 5A22 is completely internally timed and cannot be forced to slow down or wait by any external device. "Slow" regions of memory are accessed at a slower rate because the S-CPU is hardwired to access those areas of its address space at a slower rate, not because the memory itself is necessarily incapable of operating faster.

[Oziphantom]

You can have 2 Mode7 maps, not over the top of each other, but you can split them easily. Setting the SC to something other than 0 should make it use the upper half of VRAM just that has no practical effect on real hardware. However setting 128K VRAM in emulators should enable you do to it.

Well the WRAM timings are what forced them to lock the DMA to 2.58mhz rather than the chip actually clocking the 5A22 down. The WRAM can handle a 3.58mhz setting as shown by the WRAM port running at 3.58mhz. But maybe there is something fancy going on with the port vs normal bus timings to accommodate it.

I do wonder what speed boost we would get if we made WRAM and DMA 3.58mhz in emulators, a "next step" FASTROM for the really stubborn games.

[Señor Ventura]

Seems like there is nothing possible to do... here are some considerations:

-The ppu really could not have internally the function of managing two planes in mode 7.
-4 chips means doubling the number of conections, thing that the ppu is not be able to "communicate".
-2 chips increasing the frequency must not synchronize with the ppu, but at 21mhz to match ppu's frequency maybe could work.
-Increasing DMA frequency by changing the wram to another at 3,58mhz doesn't fix the pipeline cause the vram and the ppu's are within there too, and are a match for 2,68mhz, so... not possible. All of this, if the DMA is not really setted at 2,68mhz, and not for pipeline reasons...



P.D: By the way, AI's are mad (lol), gemini suggest me using vram as work memory from an external processor to send compressed tiles to vram, and uncompress these just in there, really could be possible... almost convinced me xD

[Oziphantom]

-The ppu really could not have internally the function of managing two planes in mode 7.

it would need another set of the ABCD registers to give it its own transform for a start.

-4 chips means doubling the number of conections, thing that the ppu is not be able to "communicate".

yes.

-2 chips increasing the frequency must not synchronize with the ppu, but at 21mhz to match ppu's frequency maybe could work.

well 10.5mhz, but getting DRAM that fast was probably not possible back then and it would had to switch to expensive sram, and by expensive sram I mean it was expensive compared to normal sram.

-Increasing DMA frequency by changing the wram to another at 3,58mhz doesn't fix the pipeline cause the vram and the ppu's are within there too, and are a match for 2,68mhz, so... not possible. All of this, if the DMA is not really setted at 2,68mhz, and not for pipeline reasons...

DMA and WRAM are in a totally different area of the machine than VRAM and the PPUS. Changing WRAM and DMA speed won't have any change or impact on the VRAM or PPU speed.

[Señor Ventura]

As for the WRAM, I'm pretty sure it has no effect on the CPU timing, and that includes DMA. The 5A22 is completely internally timed and cannot be forced to slow down or wait by any external device. "Slow" regions of memory are accessed at a slower rate because the S-CPU is hardwired to access those areas of its address space at a slower rate, not because the memory itself is necessarily incapable of operating faster.

Do you mean then that DMA works at 2,68mhz no matter what, cause it is really its frequency within the 5A22?.

It would be great some documentarion at this respect, but not sure if there is at electronic level.

well 10.5mhz, but getting DRAM that fast was probably not possible back then and it would had to switch to expensive sram, and by expensive sram I mean it was expensive compared to normal sram.

One time someone told me snes can't write into vram during active screen due to the type of technology of that kind of chips, and not by dma or ppu's restrictions...

Speaking about dram not that fast as 10,5mhz (if frequency doesn't match, lag must almost not exist, and this is not possible with 90's technologies), maybe a 7,16mhz sram could do the work, and fix two problems in one shot...

DMA and WRAM are in a totally different area of the machine than VRAM and the PPUS. Changing WRAM and DMA speed won't have any change or impact on the VRAM or PPU speed.

It reminds me how another world/out of this world works. Theoretically, the game is accessing to wram at 3,58mhz to buffer some kind of data... if dma is working at 3,58mhz in these moments, it answers all questions...

So, 7,16mhz vram could achieve the dma working at 3,58mhz (in case of really being possible), but... ppu's frequency doesn't match, and its 21mhz frequency instead 28mhz, yes or yes seems to be a dead end...

[Oziphantom]

As for the WRAM, I'm pretty sure it has no effect on the CPU timing, and that includes DMA. The 5A22 is completely internally timed and cannot be forced to slow down or wait by any external device. "Slow" regions of memory are accessed at a slower rate because the S-CPU is hardwired to access those areas of its address space at a slower rate, not because the memory itself is necessarily incapable of operating faster.

Do you mean then that DMA works at 2,68mhz no matter what, cause it is really its frequency within the 5A22?.

It would be great some documentarion at this respect, but not sure if there is at electronic level.

DMA always runs at 2.68mhz it doesn't matter where you DMA from or to, each byte is transferred at 2.68Mhz speed. So even if you DMA from FastROM to WRAM port it will transfer at 2.68Mhz speed. The speed of DMA is set by the DMA controller in the 5A22.

well 10.5mhz, but getting DRAM that fast was probably not possible back then and it would had to switch to expensive sram, and by expensive sram I mean it was expensive compared to normal sram.

One time someone told me snes can't write into vram during active screen due to the type of technology of that kind of chips, and not by dma or ppu's restrictions...

Not sure what they are on about, turns out VRAM is already SRAM not DRAM. Other consoles let you write to VRAM via a slower FIFO buffer, which the SNES doesn't have, but the SNESes more advanced graphics modes use up all the bandwidth anyway. Maybe if you had double ported chips it might be able to do it, but that would be rather insane for them to have added.
For a detailed look at why the SNES graphic limits are what they are see https://fabiensanglard.net/snes_ppus_why/

Speaking about dram not that fast as 10,5mhz, maybe a sram could do the work, and fix two problems in one shot...

DMA and WRAM are in a totally different area of the machine than VRAM and the PPUS. Changing WRAM and DMA speed won't have any change or impact on the VRAM or PPU speed.

It reminds me how another world/out of this world works. Theoretically, the game is accessing to wram at 3,58mhz to buffer some kind of data... if dma is working at 3,58mhz in these moments, it answers all questions...

So, 7,16mhz vram could achieve the dma working at 3,58mhz (in case of really being possible), but... ppu's frequency doesn't match, and its 21mhz frequency instead 28mhz, yes or yes seems to be a dead end...

changing the speed of VRAM won't change the speed of DMA, VRAM is already faster than the DMA speed anyway. The DMA is on the CPU side of the PPU not on the VRAM side of the PPU, so making VRAM faster doesn't have any impact on DMA speed.