SMS VDP data transfer bandwidth duing vblank

Given a frame of 192 displayable scanlines on the master system, leaving 70 for vblank, what's the total number of bytes the z80 can write to the VDP? And what method does it use? I've seen the number of ~900bytes being throw around, but I thought TmEE said it could be higher than that.

Wow, that's convenient! All it needs is a block move!

With a vblank bandwidth like that, I wish more Master System games would animate background patterns to create richer visuals... But most games stick to updating only the player's patterns. Some SMS games have really good background art when compared to the NES, because of the huge advantage of 4bpp tiles, but they tend to be mostly static, which kills the mood a bit. NES games with CHR-RAM also rarely animate backgrounds, but many CHR-ROM games do it, and it makes them look more advanced. If more SMS games had such animations, some could even pass for 16-bit titles.

You didn't really see animating BG tiles even on PCE where you have no VRAM access limits at all, or on MD or SNES which have fast DMA...


There is OTIR and OTDR, but they are slower than blocks of OUTI or OUTD.

The PCE is a completely obscure console around here, so I really haven't seen enough games to judge. At first glance, many PCE games look like SMS games to me: kinda like NES games, but more colorful.


I can't think of many 16-bit games from the top of my head besides the Sonic games, which contain a decent amount of background animation: lava, parallax effects (not the kind created with scroll splits), spinning flowers, and many many more. My general impression of 16-bit games is that the backgrounds are more full of life than in earlier platforms. Palette cycling is often a part of it, but I'm sure that many update patterns as well.

Besides obscurity outside of Japan, it's also pretty expensive to collect for. Yeah, that aside, there's emulation. You don't use emulation?

PCE is one of those rare instances where the addon became the main system about halfway through its life span. If you only play Hucard games, you only get a glimpse at early titles - the evolution of games finish taking place on the CD medium. PCE = hucard and CD games. Some early games strattle that 8bit-16bit genre/design. Some devs treated it as 'nes with extra features', as Chris Covell would phrase it, so the range of game design runs the gamut on the system - more so any MD or SNES (competing systems of the era). A lot of PCE games have more of an early 16bit feel, than an 8bit feel. But I wouldn't call it SMS like. Except for some late gen SMS games, SMS games are pretty 8bit in design and feel. Some late gen SMS games, like some late gen NES games, feel closer to early 16bit stuff (or SNES games, minus the fancy graphics. SNES games in general don't put a lot of enemies on screen at once. SNES has pretty colors, and but isn't a very 'fluid' system of the era. MD reigns in that department, with PCE seconded, snes last). Dracula X on PCE has like 3 times the amount of animation compared to the SNES 'version'. Nothing on SMS comes close to Street Fighter 2 'CE on the PCE hucard, let alone the Neo Geo fighting ports to the PCE CD. Top tier SMS games are no where close to top tier PCE games. Top tier SMS games don't even equate mid tier stuff on the PCE.

Some early hucards that were popular (in the US released in '89-90):
Bloody Wolf
Ninja Spirit
Dungeon Explorer (5 players at the same time)
Splatter House
Legendary Axe
Legendary Axe II
Neutopia
Blazing Lazers
Rtype
Devil's Crush
Aero Blasters
Bravoman
Cyber Core
Psychosis
Military Madness
Side Arms Hyper Dyne
Space Harrier

^I wouldn't say any of those reminded me of SMS games when I was playing them. The didn't play like SMS games, or look like SMS games, to me.

I did give PCE games a try, and although I didn't think they were bad, none caught my attention for more than a few minutes. I still think it's an interesting system, but I wasn't able to develop a personal connection with it like I did with SEGA's and Nintendo's 8 and 16-bit machines.


Definitely not as a whole, it's just that during the limited experience I had with the system, many of the games felt to me like better looking Famicom games, which is something that can also be said about some SMS games. I know that the PCE is much more capable than the SMS, but I didn't see that power being used very often.


True, but the late games are the ones that made an impression on me, so I can't help thinking about them first. Games like Astérix and the Great Rescue, Deep Duck Trouble, Chuck Rock II, Daffy Duck in Hollywood, Aladdin, Cheese Cat-Astrophe, Gunstar Heroes (this might be GG only, but still), Masters of Combat, and so on, are damn impressive for an 8-bit console, and definitely comparable to PCE titles.


Being an artist, graphics is the first thing I'm going to compare, so I find it kinda hard to consider NES games comparable to early 16-bit stuff, due to the extremely low color count. Some of the games that I personally feel that get close are Sword Master, Astyanax, Moon Crystal (mainly for the cutscenes and smooth animations) and Bucky O'Hare. There are probably others I couldn't think of right now.


Probably not.


That I don't know. The PCE looks pretty cool, but from what I've seen, there are lots of questionable games, and games with uninteresting graphics. For a system with so many palettes, I find it surprising how hard it is to find PCE games with outstanding graphics... Most games I see look just OK, compared to a lot of incredible stuff you can find on Genesis and SNES, but not because of hardware restrictions, probably just lack of talented artists (and lack of third-party developers to add variety and raise the bar). The SMS also has trouble breaking that graphical threshold, because of both hardware and talent, but the final result is that I end up seeing some similarities between it and the PCE. Not a whole lot like they're equivalent in every way, but still somewhat similar depending on the games I'm looking at.

For me, it depends on the game genre. It could be graphics or it could be gameplay. SMB3 on the NES is a pretty advance game. I would put the complexity of the gameplay as part of the 16bit era. Gimmick on the NES feels and plays like a 16bit era game. Matter of fact, it kinda feels like devs took to take a step back in gameplay complexity in the 16bit era - instead focusing on simplistic interaction with larger sprites instead. So in that respect they have more in common with later gen 8bit games (NES here) - just larger sprites. At least on the SNES. Megadrive games seemed to always be pushing that boundary - pushing around way more sprites.

Well, for those who says the PCE has uninteresting graphics comparing to the MD, judge for yourself.

Note: this is getting highly off-topic!

Sure there are cases where the PCE compares favorably to the MD or the SNES (from a quick look at that page, I can say this is the case of Lords of Thunder and Raiden, for example), but that doesn't necessarily mean that the graphics are particularly groundbreaking on any of the platforms, or on the arcade originals even. A lot of games in that page are arcade ports, so there's not much originality there, it's often the port that's most faithful to the arcade original that wins the battle, and the PCE undoubtedly has decent enough video capabilities to pull off nice graphics, so it can usually compete against the MD and the SNES despite having a single background layer.

If you really want me to, I'll try and list some MD and SNES games I consider to have groundbreaking graphics (most games will probably be exclusive to a single console, meaning that the games were designed to take advantage of that specific hardware, instead of adjusted to fit), so you guys that know the PCE much better than I do could give me some examples of impressive pixel art on that console, that isn't based on games from other platforms.

Stills make the PCE look better than it is because the biggest thing missing from the PCE graphically is parallax scrolling.

Come on, wouldn't you say these look quite Master System like?

http://tg-16.com/comparisons/tatsujin_pce_2.png
http://tg-16.com/comparisons/aero_pce_4.png
http://tg-16.com/comparisons/aero_pce_12.png
http://tg-16.com/comparisons/tiger_pce_6.png
http://tg-16.com/comparisons/lair_pce_5.png
http://tg-16.com/comparisons/lair_pce_8.png
http://tg-16.com/comparisons/hellfire_pce_4.png
http://tg-16.com/comparisons/tb_pce_05.png


That's true. To judge properly, we'd have to see the games in motion.

Lol! If you actually played those games, then you wouldn't think so. You know that Monster's Lair is also on the Genesis, and is a Sega system16 game (lair_pce_x images)? Tatsujin looks SMS-ish???

And the aero_pce_x pics? This game looks sms-ish to you? http://www.youtube.com/watch?v=LAjr4sJrhrs

PCE doesn't have a lot of top tier graphical games. Even when it came to RPGs, which don't require parallax. If I were to post pics showcasing graphics, it would only show what the system is capable, rather than what's representative of typical, average, or even top tier stuff on the system. You'd have to take the time to play through the library yourself (hucard and CD), and not spend just a few minutes with each game.











The biggest achilles heel of the system. So much so, they tried to fix the problem before the SFC came out with the PC-Engine SuperGrafx. But, original games didn't have to suffer from the lack of parallax as much as they did. With sprites, hsync scrolls, and dynamic tiles - most original dev'd games could have been more parallax capable than they were. It'll never be on the level of systems that have more than 1 BG layer, but it could have been more that what's the norm is for the system.

Effects that the NES can do as well. MetalStorm is an exercise in dynamic tile basturmation, and later NES games like Vice: Project Doom, Bucky O'Hare, and The Curse of Possum Hollow show off hsync scrolls. The one thing PCE has over NES and SMS in this sense is more sprite overdraw.

In relation to parallax effects? I would say that it goes a little bit farther than that. The PCE has a proper X/Y/BG/Spr reg control system for scanlines effect - per scanline. All the regs are buffered, and don't have to worry about precise timing in order to get updates done per scanline. The SMS can't even change the Y scroll mid scanline. The PCE can do all of it (including changing the screen res, and bit depth mode per scanline), and without timing issues - and the processing power to back it up (effectively 4x times those systems). PCE has unlimited bandwidth to write to VRAM during active display. Whatever dynamic tile setup the NES and SMS can do, the PCE can take it much further. It can even do hardware assisted transparency (abusing planar tile format) as independent scroll layer (I have demos for this).

NES can swap out a whole block of memory, but the dynamic tile edges are going to be severely limit (to squares), on top of the color limitations of dynamic tiles showing behind objects (Gradius 2, Parodius on PCE). On the PCE, you write dynamic tile data to bit planes 0 and 1, for edges, so that the fake BG layer scrolls behind none tile segment seams (Ninja Spirit does this for the tree leaves in the second stage). There's quite a bit of unexplored area of what you can do on the PCE in relation to dynamic tiles that you can't do on the SMS or NES. Some of it has to do with more cpu resource available, and some of it has to do with the expended subpalettes of the BG layer.

Probably not, but those static screens do invoke a Master System feeling from me.


Yeah, and it doesn't look particularly good there either.


Not all the time.


At times, yes.


I'm sure it's a good console, but to be honest, knowing that it would cost me a fortune to acquire the actual hardware kinda puts me off. I know I can just emulate, but I can't help wanting to buy the actual systems I like.

Highly unrepresentative of the system though. You could cherry pic graphics on the Megadrive and say the samething. It would be just as inaccurate or unrepresentative.


That's irrelevant to me, because that's subjective. I don't care if someone dislikes the PCE library or whatever aesthetics about it hardware. I dislike 95% of the games on the SMS because they just don't click with me (I own the real system) - it's 8bit like the NES, but it lacks the charm and the play style of the NES games IMO. But my point, is that PCE games don't look like SMS games. If anything it would be the other way around - later gen SMS games approached PCE and MD in some graphic departments. But as tepples pointed out about pics being deceiving relative to graphics and parallax (PCE), the same is true for SMS coming closer to the next gen era systems; SMS games look better in stills than they do in action and in gameplay.

@Tokumaru
My first console as a kid was a sms and played a lot with it. I was able to get a turbograph later as an adult and there is a lot of interesting games to try. Emulation is more than enough if you want to try.

Compared to sms pce could do bigger objects on screen and usually game felt more smooth. Some were slower like bloody wolf but the arcade was similar in speed so I didn't mind much (it's a good game by the way). There is a lot of cd game with great music like lord of thunder and many shooter too like megadrive.

You should give it a try. I can make a list of interesting games to try someday, even though I'm not as knowledgeable about it compared to nes.

Maybe we should go back to sms vdp subject, there was some interesting information coming out and I would like to learn more about it too.

I know, but in addition to not having much time these days for new games, I fear that I might like them enough that I'll want to buy the real thing, which I don't currently have the money or space for.


True. I don't think these platforms are as similar as some of my comments in this thread may have led people to believe I do, but both invoke "not quite 16-bit" and sometimes "Famicom but more colorful" feelings from me, even though the PCE obviously has more sprites and smoother gameplay. Many SMS games run smoothly too, so I can only attribute the slowdown found in a large number of games to the incompetence of their programmers. I mean, compare Daffy Duck in Hollywood against Taz in Escape from Mars and it's really difficult to believe both are running on the same console.


I rarely find CD soundtracks interesting. Sometimes it seems like the musicians are so excited about not being restricted by the hardware that they focus more on the variety of the sounds than on creating engaging melodies. At least on the Sega CD I often felt like that was the case. Nothing beats a catchy upbeat chiptune.


Shooters and RPGs are waaaay at the bottom of my list of preferred game genres. There are a couple of shooters I like, but they're more like exceptions.


By now you probably know that my favorite genre is platformers, preferably with above average graphics.


I have great interest in SMS programming myself, since it's superior to the NES in many ways, but because of poor third party support there are a lot of things we never saw it do, while the NES was practically squeezed to the last drop. It would be great if the SMS had games as good as the best NES hits, but with improved visuals.

No mid-frame vertical scroll splits on a Master System means you won't see effects like the background of Recca, hilly roads like those of Rad Racer and Road Rash have to be rendered (slowly) in software, and even status bars have to be much simpler. So if you're making hills, you'll need all the VDP data transfer bandwidth you can get.

True, that's one significant disadvantage of the SMS compared to the NES. But you can still fake a little bit of detail in scroll splits by using clever tricks. For example, if you have a big boss that moves up and down made of background tiles, you could draw the floor using striped patterns (like those found in similar situations in NES Mega Man 1 and 2, which didn't do scroll splits) that are easily updatable to compensate for the vertical movement, and add extra detail using sprites (like the road in the intro of NES Darkwing Duck). Yes Ys on the SMS managed to draw steady colored bars in its status bar using background tiles when scrolling vertically by selectively blanking scanlines above and below the bars.

The lack of sprite flipping is another drawback of the SMS, but with good management of pattern updates you might be able to overcome that without much trouble.

By "Yes" you mean Ys, pronounced somewhat like "ease", right?

For a moment, I thought you were saying two prog-turned-pop rock bands from England had a SEGA-related namesake.

Yeah, shit like this happens when I post from my phone...

@tokumaru

If I would buy all the old game I like I wouldn't have the money or space (especially in Japan!) to do it so emulators are a good compromise.

It always ends up sounding like a bunch of white noise to me. That's why a lot of PS1 and Saturn ports of arcade games suck to me. The graphics are pixel perfect, but they change the soundtrack, because they think it's better I guess. They might a well "upgrade" the graphics too while they're at it.


I just thought I'd support this:
https://www.youtube.com/watch?v=Q-CMqe3Aa9M vs. https://www.youtube.com/watch?v=m9GOa1dxLQ4


Sounds like the same situation with some other system...


R-Type? I've found all the shooter games starting with Donpachi have been shit, being about carefully moving your ship (with digital controls) along a bunch of slow moving crap that you're not even sure how close you can get to. I'll take tests in reflexes or planning over car parking simulators any day of the week. The closest I'll ever delve into that shit is Cho Ren Sha 68K, and even that's pushing it.

From the SMS perspective, this has always been interesting to me. System design wise, the SMS is very "clean" for the most part. Proper hsync interrupts and such, but why wouldn't they have Y mid screen updates. That baffles me. The choice for a small tilemap size is also weird. Under normal game conditions, it's fine - but depending on some effects, the small tilemap makes it difficult or impossible.

There are a number of clever ways SMS games do to get status windows, or floors, and mid screen scrolling. Dragon's Trap uses char scrolling for Y movement, and fine scrolling for X movement of the bosses. It actually works out pretty decent. Cool Spot turns off the display, and then re-enables it with a BG relocation mid screen (change BG map pointer), and finished it off with sprites in the new status bar area. I couldn't tell from the crappy debugger, but that's what it appears to be doing.



Well, the trade off was tile flipping in the BG. Road Rash wouldn't have been able to do what it does without it. I think more than sprite flipping, is that fact that you can't use all 512 cells on the SMS, since the tilemap is using some of that space. I think the max is 448 cells (8x8), but I guess the flip side to that is you can allocate that however you want between sprites and tiles.



Just one thing to note; you have to be careful with SMS videos on youtube. People love to turn off the sprite limit in emulation for those videos. Makes them more impressive than they are. I remember watching the Gunstar Heroes port and being absolutely amazed.. until I tried it for myself (serious flicker).

Oh, you're right, I just noticed... Still a pretty good port though.


I'd say that's a little subjective (even if "for the most part"). I never understood why they decided to use 4bpp graphics with only 2 16 color palettes. a 3bpp background layer but with 3bpp sprites being able to cover close to, if not, the whole screen would have been a much better deal to me. Doubling the palettes would also be nice too; I don't know why Sega has trouble with that...

I wouldn't necessarily call it white noise, but more often than not, PCM/CD music sounds uninteresting, boring or just plain weird compared to "proper" video game music. Compare the soundtrack of Sonic 3D Blast on the Genesis and on the Saturn. I think the Saturn version is pure crap, boring as fuck, while the Genesis one is much more memorable (but not perfect).


Not to disagree with you, but the approach one particular developer took when porting a game doesn't necessarily reflect what the platform is capable of. Sometimes ports look bad because of ROM size restrictions imposed by the publisher, so the console itself isn't to blame. Horizontal shooters will invariably suffer on platforms like the NES or the SMS, that can only show a very limited number of sprites per scanline.


I never thought of that, but you may be right.


Not sure if I ever gave R-Type a proper try, but no. Since you want to know, from the top of my head, the only shooters I remember having enjoyed playing (as in "played more than once" and "played more than one level") are Tyrian 2000 for DOS and Ikaruga on the Dreamcast.


I agree. I never programmed for it, but looking at the docs, everything is very concise and straightforward, it just makes sense. The NES appears to have way more quirks.


It bothers me a bit that to have something as simple as glitchless horizontal scrolling you have to mask the leftmost 8 pixels of the screen and end up with a weird 248-pixel wide viewport (I know this often happens in the NES as well - and you still get attribute glitches!). Other than that, I don't see any problems.


Never played it, but looking at videos now, that's a very nice looking game at times! Some backgrounds look great, like this one, but then they go and mix that with crap like this... go figure. Characters look consistently good though!


I don't see any relocation, it just appears to blank some scanlines to smooth out the transition between the gameplay window and the status bar. The sprites are nicely spread though, and cover a decent enough amount of the the status bar area to not look weird. Earthworm Jim uses sprite magnification to cover a bigger area, but it looks a little weird IMO (and AFAIK magnification doesn't work on all VDP variants).


When you say it's a trade off do you mean that there's a hardware justification for why both couldn't be implemented or that it's a trade off when compared to the NES? The Good thing about the NES is that while it doesn't support background tile flipping natively, this feature can be implemented by a mapper in the cartridge.


I like the fact that the VRAM layout is configurable.


That's true. People frequently do that with NES games too.


There have been worse decisions... PCs had 4bpp graphics with a single constant 16-color palette in EGA... now *that* sucked. I can think of a lot of cool things to do using the Master System setup.


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.


They did, for the Genesis. Sure, by the time they did it, 4 palettes was pretty lame.

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 (and the announcer sucks). 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. 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.


To be fair, this comes to mind with many systems. I don't think any have had it as bad as the Jaguar though. 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. It could be infinitely powerful, but I'm sure somebody would program something infinitely bad, and whenever the hardware gets more powerful, there's less of a reason to make it as efficient as possible. 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.


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


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. (Which is why I'm trying to make a system to have sprite palettes changed mid screen.) The good old days of two years ago...


It's just strange to me, because I've always considered the amount of color palettes to be the main thing arcade boards led consoles by. (the SNES only had 16, while most arcade board I've seen from the time had 256) 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. It became really bizarre with the GBA, with it's hardware leaving anything that wasn't a Sega amusement park ride from the time period in the dust. 4 8bpp layers isn't entirely useful when they're fighting for one palette...

In the FPGA era, getting it made becomes more and more practical.


Are you referring to SF2 arcade to SSF2 arcade, or SF2 for Super NES to SSF2 for Super NES?


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.


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.


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.


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.


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)).


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.


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.

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.

I was referring to the arcade ports, but I do think the music also got worse for the SNES.


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


PC master race?


Yeah, okay, Irem will rise from the grave to strike this one person.


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.

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.

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.


The company is still around, making mostly pachinko games and rereleasing its old stuff on VC.


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.


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.


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).

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 ) 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.


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.

And have each a quick DMA VRAM->VRAM for tiles animation, or other stuffs .