nesdev.org

Espozo wrote:

tepples wrote:which is equivalent to 85 16x16 sprites.

Wait, what? How would we all of the sudden be able to cover the screen a little over 5 times with 4bpp graphics using sprites, if no BG mode can even get to covering the screen 4 times with 4bpp graphics?

Background maps and tiles are both read from VRAM, and ordinarily, a program can't completely disable backgrounds to gain more sprite sliver reading time.

Espozo wrote:Are you thinking that sprite data would still all be on the PPU, which I assume is much faster to get data from?

I was assuming placement of a larger OAM either inside the PPU or on a dedicated SRAM.

Espozo wrote:I never understood the why Mode 3 (8bpp and 4bpp layer) wasn't more often used. I'm guessing a lot of it has to do with rom size.

That and VRAM size; gotta leave room for 16K sprites of and 6K of maps. But the title screen of Super Mario All-Stars uses an 8bpp layer. So does Zoop because its playfield is an 18x14 grid of cells, each 12x14 pixels. The usual workaround for 12-pixel-wide cells, as seen in Puyo Pop and Luminesweeper, needs two backgrounds, and I imagine Panelcomp (the company that presumably ported Zoop to the Super NES) wanted to use more than 2bpp for the "Opti-Challenge" background. So instead, it composites the game graphics onto a frame buffer in software.

Okay, I have yet another VDP VRAM setup idea (and yes Tepples, it is based on the GBA).

The VDP accesses 4 8-bit RAM chips at 13.5 Mhz. 2 are used for BG layers, the other 2 are used for sprites. It could do 4 BG layers, or 2 rotate/scaling layers, or 2 BG layers + 1 rotate/scaling layer.

For sprites, it does it's accesses like this. There are 858 cycles per line:

128 cycles spent looking through the Y-coordinates of sprites
192 cycles spent fetching 6 attribute words (X-coordinate, attributes and 4 rotate/scale parameters) for 32 sprites that appear on the scanline
512 cycles fetching the sprites, either 1 pixel at a time (affine sprites) or 4 pixels at a time (regular sprites)
26 open cycles

Because we're really just thinking of random ideas for a video chip instead of actually making one, can anyone think of a custom video chip that someone has made? It would almost certainly be FPGA, because I have no idea how you'd manufacture your own microchip.

Thinking about it though, it's a bit funny to make your own 2D hardware considering how much 2D hardware exists, mainly from different arcade boards. I don't even want to know how long the list of different arcade hardware is. (Hardware with the game built into it is irrelevant for this.) I think it is kind of surprising that no company was manufacturing general purpose video hardware at this time, like the TMS9918, because many systems almost seem copy-paste from another. Just think of how many had 3-4 4bpp BG layers with 4bpp, 16x16 sized sprites and 4096 palette entries, out of a 15-16 color palette. Few seemed to have color math, unless they were dedicated for one game. (For whatever reason, the example of an arcade machine with color math that comes to mind for me is Raiden II, but I'm not actually sure if this is dedicated hardware or not, because I'm pretty sure Raiden DX uses the same hardware. It's always possible the game is still attached to the board though.)

It is really weird when arcade manufacturers would have several different BG and sprite chips that act completely different from eachother, but all custom made for the arcade game. If they wanted more bg layers, wouldn't it make more sense to use two of the same chip?

I'm guessing you're talking about arcade machines that are only designed to play one game? I'd have thought much of the hardware would have been recycled. If I'm not mistaken, Konami had it to where every game had its own board. I don't know why you'd do this (especially if you're making as many games as Konami was) because it seems really cost ineffective. If I were to guess why they did this (while virtually every other arcade developer didn't) it would be that games would be harder to pirate, but I'm not sure it would be worth it. There couldn't be nearly as many pirated arcade games as home console games.

About what you said again though, I'd imagine that you'd need to build the video hardware around being expanded upon to where they could be linked together. I think I heard that the Supergrafx actually has 2 PCE video chips, but I have no clue how they're connected, if it even is the exact same chips.

It still blows my mind how many different video processors there were back then, but how they were not commercially released or used outside of the one device they were put in. The funniest part about it all is how the CPUs were commercially produced, and that there was barely any variety. 90% of the time, it would be a 68000 paired with a Z80. If you're lucky, you'd see a V(XX) (V30, V33, etc.), but that's about it. Oh yeah, and there's the 6809.

I wouldn't underestimate the world-wide market for bootleg arcade games. From what I've heard about Street Fighter 2, there were supposedly more bootleg copies sold than legit ones. If anyone can just buy the chips somewhere, or owners can convert old boards to new games themselves with just a ROM replacement, it would be done if there was demand for the game. Nintendo's VS is another example of this, all using slightly different PPUs so owners would have to buy the games instead of just copying the ROMs.

It still blows my mind how many different video processors there were back then, but how they were not commercially released or used outside of the one device they were put in.

I agree. It also makes it difficult to make your own homebrew arcade or pseudo-arcade game, because there's absolutely no standard for graphics, as opposed to sound where a couple of Yamaha FM chips are standard.

Konami had it to where every game had its own board. I don't know why you'd do this (especially if you're making as many games as Konami was) because it seems really cost ineffective.

Actually manufacturing a bunch of PCBs is very cheap and probably accounted for a tiny amount of the game's price. Also, designing the said PCBs was probably expensive, but by re-using design and brining small modifications, that wouldn't be expensive.

They did the same for Famicom games using VRC mappers, just changing the wiring a little in order to confuse reverse engineers, and it worked well.

Espozo wrote:I think I heard that the Supergrafx actually has 2 PCE video chips, but I have no clue how they're connected, if it even is the exact same chips.

Here's how I understand it: The nine signals that come out of the VDC are background/sprite (1 bit), palette index, and subpalette index. The TG16 VCE just uses this as a 9-bit index into CGRAM. The SuperGrafx VCE combines each VDC's background/sprite bit with its subpalette index (0 for backdrop or nonzero otherwise) to produce a 3-way: background, sprite, or transparent. This is fed into a priority encoder, where VDC0 or VDC1 could be given priority for each combination of VDC0 background or sprite and VDC1 background or sprite.

Espozo wrote:It still blows my mind how many different video processors there were back then, but how they were not commercially released or used outside of the one device they were put in. The funniest part about it all is how the CPUs were commercially produced, and that there was barely any variety. 90% of the time, it would be a 68000 paired with a Z80. If you're lucky, you'd see a V(XX) (V30, V33, etc.), but that's about it. Oh yeah, and there's the 6809.

Perhaps that's because CPUs were full custom designs, while application-specific video processors were made out of rows of standard cells, or prefabricated gates that could be copied and pasted into an integrated circuit design, as if typing in a proportional font. Kevtris has pointed out how on the 2A03, the CPU is a tight block of custom NMOS design, while the APU is standard cells.

Bregalad wrote:It also makes it difficult to make your own homebrew arcade or pseudo-arcade game, because there's absolutely no standard for graphics, as opposed to sound where a couple of Yamaha FM chips are standard.

For the past roughly a decade and a half, it's been possible to just put a PC's chipset on your arcade PCB. And lately even ARM SoCs are decently powerful. The biggest problem is attracting enough people away from touch-controlled phone games to insert coin.

For the past roughly a decade and a half, it's been possible to just put a PC's chipset on your arcade PCB. And lately even ARM SoCs are decently powerful.

I meant a retro arcade. Sure I could just fake retro graphics and call it a day, but sticking to realistic limitation would help I think.

The biggest problem is attracting enough people away from touch-controlled phone games to insert coin

Sadly, attracting people away from touch-controlled phone at all (games or not) is close to impossible today It's almost scary.

All your design ideas could be implemented with an FPGA? How does it works? The FPGA does the logic and you just need to connect a port to it for output and that's it?

To my own experience, FPGA design is, well, a complete and total nightmare, and extremely unreliabe (i.e. a design could work or not work just based on romplete randomness). Also you need huge "project" folders with 500 MB of crap in them every time. So I am really sceptical right now. This could change in the future though, if the FPGA manufacturers would focus on ease of use and great tools instead of focusing on pure hardware performance and provinding bloated and shitty tools. I'm not even mentionning the 5000 pages of doccumentation which is so huge that it looks it was made purposedly to discourage people.

@Bregalad

Well, from your post I can guess that you really don't like FPGA but that didn't answer the question though . Is my assumption correct that you would need the FPGA for the logic then a port for the output? Is something else required?

Graphics chips can probably be done on microcontrollers, even though microcontrollers have to waste most of their time outputting pixels.

Okay, I had an idea today about modding a Super Nintendo as a small upgrade. Disconnect the HALT pin from the ground and hook it up to EXT pin, and maybe it can allow enhancement chips to take over the CPU busses. But, then there's the question of how fast can the sPPU be written to.

The PPU most probably cannot accept stuff faster than its DMA speed.