SMS VDP data transfer bandwidth duing vblank

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: SMS VDP data transfer bandwidth duing vblank

Post by tepples »

tokumaru wrote:Sounds cool, but we got what we got. I see no point in dreaming about hardware that doesn't exist unless we can actually get it made.
In the FPGA era, getting it made becomes more and more practical.
Espozo wrote:
tokumaru wrote:more often than not, PCM/CD music sounds uninteresting, boring or just plain weird compared to "proper" video game music.
That kind of reminds me how I much prefer the original Street Fighter II games over the Super Street Fighter II games, mainly because of how they changed the music
Are you referring to SF2 arcade to SSF2 arcade, or SF2 for Super NES to SSF2 for Super NES?
Espozo wrote:I generally find PCM better, but then you also get the early SNES games that sound like a midi file played with the worst possible sound font, recorded, then played at the lowest sampling rate possible.
Probably before they picked up on the "preemphasis" trick to compensate for the low-pass characteristic of Gaussian interpolation.

ObTopic: But then audio on the Master System or Game Gear is less capable than that on the NES or Game Boy.
Espozo wrote:I actually really like the music in the Donkey Kong Country games. Not only is there a clear melody, but the instruments all sound excellent.
But then DKC is 32 megabits, much bigger than the Super Famicom's first year of games. And DKC has a long blank-screen load on each screen transition to send a new sound font subset, unlike Super Mario World which used essentially two SPC executables, one on the world map and one in levels, for faster pipe and door transitions.
Espozo wrote:People really undermine how much of an influence bad programming has on why a game may be performing poorly. Nowadays, it's baffling to me why people automatically assume it's the hardware.
But show someone a shitty game made in The Games Factory/Multimedia Fusion, Game Maker, etc., and he doesn't rush to blame the PC platform.
Espozo wrote:I remember looking the other day at what the minimum specs were for Microsoft Word, and it was something crazy like a 1+ GHz, dual core CPU with 2GB of ram. Give me a break. :lol:
The minimum specs are at least as high as those for the oldest operating system on which it is designed to run. That sounds like the minimum specs to run Windows 7 or 10.
Espozo wrote:I really don't know why someone would play the SMS version of R-Type on an emulator just to artificially make it look better, when they could just play the original arcade version on MAME...
Owning the Master System cart but not the arcade PCB, perhaps? The fair use argument for showing game footage on YouTube is stronger if no ROM infringement occurred; otherwise, the game's publisher can quash a fair use defense on grounds of "unclean hands". And in at least U.S. law, dumping your own lawfully made cartridges for use in an emulator is an "essential step" and thus not infringement (17 USC 117(a)(1)).
Espozo wrote:True. Reminds me how one of the first things I did when I went here is ask why the SNES couldn't have more palette entries (much before I even knew what I was talking about.) I'm probably the only person on this website that thinks that.
At least sometimes it leads to insightful justifications as to what they had to cut to fit everything on the die or to fit attributes for one map space or sprite in a given number of bytes. For example, more background palettes on the Super NES would mean giving up sprite flipping, giving up half the unique tiles per layer, or giving up priority. The TurboGrafx-16 chose the first, and the Game Boy Advance chose the last.
Espozo wrote:I don't think we ever had a 2D system (Neo Geo notwithstanding) with a separate chip for holding color data, instead having it inside the video chip.
The palette on the TurboGrafx-16 is in the VCE, while the rest of video logic is in the VDC. The NES PPU also has a mode to use an external VCE, which NESRGB and Hi-Def NES use, though retail consoles are wired in "act as another PPU's VCE" mode for some odd reason.
tomaitheous
Posts: 592
Joined: Thu Aug 28, 2008 1:17 am
Contact:

Re: SMS VDP data transfer bandwidth duing vblank

Post by tomaitheous »

tepples wrote:
Espozo wrote:I don't think we ever had a 2D system (Neo Geo notwithstanding) with a separate chip for holding color data, instead having it inside the video chip.
The palette on the TurboGrafx-16 is in the VCE
You always seem to find these things interesting, and I'm not sure if you know this, but when you update colors mid scanline on the PCE by writing to the VCE color regs, it causes the VCE to give priority to the CPU and ignores the digital pixel bus coming from the VDC. What gets output, is the last pixel data on the incoming pixel bus - not the what the cpu is writing to the VCE. I.e. You get sold bars of pixel runs. Actually, it doesn't matter what register you access on the VCE - it will always give priority to the CPU over the pixel bus. Check this out:
http://www.youtube.com/watch?v=-xU9uuRzLwo
^- Running on the real hardware. I'm using hsync interrupts to generate specific patterns of distortion. The slight jitter of the interrupt helps make the distortion pattern more noisy.

Another interesting thing you can do, is use the PCE's block transfer instructions to write to the VCE mid scanline. Unlike a combination of sta port commands which leave games in the 'stretched' pixels, the Txx instructions make solid lines. Its possible to draw "lasers" without using a lot of sprites. You just need a starting sprite to initiate the color to be stretched across the screen, and an ending sprite to get precise length (and hide jitter; both sprites hide jitter).

Also because of the VCE and VDC setup on the PCE, you can forced the VDC to display sprites at half resolution by skipping every other line of a sprite. It's a useful technique because normally the PCE only has 16x16 size as the smallest building cell block for all sprite sizes. This creates a 16x8 cell block. In vram, sprites are now stored differently. A 16x16 sprite cells holds two 16x8 sprite cells that are interleaved. And the way to access which interleaved set, is bit 0 of the Y position in sprite attribute table. Does that make sense? That video, running on the real hardware, is doing that with the row of 8 Link sprites (hard to recognize because they're are missing every other row of pixels). This is all possible because of how the VCE and VDC interface with each other.




Espozo: You could divide the two 16color palettes on the SMS into four 8color palettes. Just define with cells use the upper or lower part of the palette. Some Genesis games do this. It gives you more control over in the range of colors throughout an area in a game; you can swap in and out divide 8color palettes for different enemies throughout the stage - make them blink alt colors like in 16bit era games, etc.
__________________________
http://pcedev.wordpress.com
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: SMS VDP data transfer bandwidth duing vblank

Post by Drew Sebastino »

tepples wrote:Are you referring to SF2 arcade to SSF2 arcade, or SF2 for Super NES to SSF2 for Super NES?
I was referring to the arcade ports, but I do think the music also got worse for the SNES.
tepples wrote:DKC has a long blank-screen load on each screen transition to send a new sound font subset, unlike Super Mario World which used essentially two SPC executables, one on the world map and one in levels, for faster pipe and door transitions.
A handful of early SNES games did have to wait to load a new song though. Super Mario World doesn't necessarily have a lot of musical variety...
tepples wrote:show someone a shitty game made in The Games Factory/Multimedia Fusion, Game Maker, etc., and he doesn't rush to blame the PC platform.
PC master race? :wink:
tepples wrote:the game's publisher can quash a fair use defense on grounds of "unclean hands".
Yeah, okay, Irem will rise from the grave to strike this one person. :lol:
tepples wrote:retail consoles are wired in "act as another PPU's VCE" mode for some odd reason.
So the made it to where it can connect to another chip that has the color data, only to wire it back to the PPU? What was the point in that? I don't think the NES/FC's PPU was used in anything else (not including the VS. and Playchoice), was it?

I could be wrong, but I thought I remembered hearing something similar with the Genesis, and that there was an arcade game largely based on Genesis hardware but with more palettes.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: SMS VDP data transfer bandwidth duing vblank

Post by psycopathicteen »

Espozo wrote:
tepples wrote:DKC has a long blank-screen load on each screen transition to send a new sound font subset, unlike Super Mario World which used essentially two SPC executables, one on the world map and one in levels, for faster pipe and door transitions.
A handful of early SNES games did have to wait to load a new song though. Super Mario World doesn't necessarily have a lot of musical variety...
I think I remember reading that Miyamoto thought SMW was a little "unfinished" and I can understand why. Almost every level uses the same theme. The graphics are somewhat inconsistent too. Mario's hat should be the same red as the red Yoshi, but it isn't. Some of the graphics look like they were originally planned to use Mode 0.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: SMS VDP data transfer bandwidth duing vblank

Post by tepples »

Espozo wrote:
tepples wrote:show someone a shitty game made in The Games Factory/Multimedia Fusion, Game Maker, etc., and he doesn't rush to blame the PC platform.
PC master race? :wink:
Several things made me PCMR: the market shift toward TVs compatible with PC video output, the "599 US Dollars" launch price of the PlayStation 3 made a living room PC look affordable, console makers' attitude against home-based game companies prior to the eighth generation, and console makers' general treatment of fan-made game mods as "criminal activity". Consoles are compromised, and though these compromises may be good for some, a PC has more headroom especially for fan creativity.
Espozo wrote:
tepples wrote:the game's publisher can quash a fair use defense on grounds of "unclean hands".
Yeah, okay, Irem will rise from the grave to strike this one person. :lol:
The company is still around, making mostly pachinko games and rereleasing its old stuff on VC.
Espozo wrote:
tepples wrote:retail consoles are wired in "act as another PPU's VCE" mode for some odd reason.
So the made it to where it can connect to another chip that has the color data, only to wire it back to the PPU? What was the point in that?
When the PPU is configured with EXTBG as input, any pixel not occupied by an opaque sprite or background pixel displays the color in $3F00-$3F0F, selected by the EXTBG lines. When it's an output, bits 3-0 of the color index is output on the EXTBG lines. Bit 4 (background vs. sprites) isn't, but a program can load a palette with black background and white sprites to distinguish the two. It was presumably intended to link up two PPUs in a configuration comparable to SuperGrafx, where one PPU's graphics would be composited on top of the other's.
Espozo wrote:I don't think the NES/FC's PPU was used in anything else (not including the VS. and Playchoice), was it?
Just as the Texas Instruments TMS9918 in the TI-99/4A computer was reused in other systems, such as CreatiVision, MSX, and the Master System's direct predecessors (ColecoVision and the similarly specced SG-1000), I imagine Nintendo was trying to keep its options open.
Espozo wrote:I could be wrong, but I thought I remembered hearing something similar with the Genesis, and that there was an arcade game largely based on Genesis hardware but with more palettes.
SEGA had a couple Mega Drive-based arcade platforms: Mega-Tech (counterpart to PlayChoice, where credits buy time) and Mega Play (counterpart to Vs. System, where credits buy lives).
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: SMS VDP data transfer bandwidth duing vblank

Post by Drew Sebastino »

tepples wrote:The company is still around
Irem Software Engineering is, but Irem Corporation has been dead since the 90's. I know this isn't the most uncommon thing to do, like SNK to SNK Playmore (I always joked that if they went under again, they'd be SNK Playevenmore :lol:) but unlike SNK Playmore, I don't even know if the staff is the same, as I know a significant amount of them went to work for SNK on Metal Slug 1-3 (Unlike the rest of SNK, I heard they disbanded when SNK originally went under, which is a shame, because they were one of their most talented teams) and I know this team is directly responsible for In the Hunt, and Gunforce 2, (there are several easter eggs in Metal Slug 1-3 that allude to this) and I think also responsible for R-Type II, Air Duel, and Undercover Cops. The only noteworthy thing I can think of that Irem Software Engineering did is R-Type Delta. (It's a shame they couldn't recreate that success for the next R-Type game...) They still have the rights, but unfortunately, they're on their last legs now. You're pretty damn desperate if all you make is pachinko games (on a video game system, meaning there's no money involved, making it completely pointless.) I guess they still have the rights though, but I sincerely doubt anyone is afraid of being bothered by them.
tepples wrote:It was presumably intended to link up two PPUs in a configuration comparable to SuperGrafx, where one PPU's graphics would be composited on top of the other's.
You know, does the SuperGrafx have half of its sprites fixed between BG 1 and 2? It seems it would have to be this way.
tomaitheous
Posts: 592
Joined: Thu Aug 28, 2008 1:17 am
Contact:

Re: SMS VDP data transfer bandwidth duing vblank

Post by tomaitheous »

Espozo wrote:
tepples wrote:It was presumably intended to link up two PPUs in a configuration comparable to SuperGrafx, where one PPU's graphics would be composited on top of the other's.
You know, does the SuperGrafx have half of its sprites fixed between BG 1 and 2? It seems it would have to be this way.
It doesn't. It has a priority chips that takes the input of both VDCs, mixes it, and send it to the VCE. There are also 'window' regs, where you can define sections of the screen in how this priority takes place. But no, it's no limited to in having BG1 sprites only attached to BG 1 (or VDC 1) display. The VDCs have a sprite pixel output bit on the pixel bus, so the priority controller knows when the pixel from either VDC is a background pixel or a sprite pixel; all sprites can show above all BG layers if it set it as so. It does have 128k of vram, and that vram is divided as 64k to each VDC. The VDCs can't access each others video memory.
__________________________
http://pcedev.wordpress.com
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: SMS VDP data transfer bandwidth duing vblank

Post by TOUKO »

It does have 128k of vram, and that vram is divided as 64k to each VDC. The VDCs can't access each others video memory.
And have each a quick DMA VRAM->VRAM for tiles animation, or other stuffs .
Post Reply