nesdev.org

MottZilla wrote:How do you know that it wasn't used much? I would imagine a fair number of games probably used it. Pretty sure BS-Zelda uses it.

Your right, I don't know why I just said that. Maybe it was a brainfart.

You're right it was probably a good idea. Maybe the developers liked the idea to be eventually able to assign a palette for each 8x8 tile (as opposed to the NES) ?
I guess Romancing Saga and Secret of Evermore uses this... but that's all I can remember.

Bregalad wrote:You're right it was probably a good idea. Maybe the developers liked the idea to be eventually able to assign a palette for each 8x8 tile (as opposed to the NES) ?

With 16 colors in a palette I imagine programmers would rarely need to apply them to 8x8 blocks individually...

16 colours oughta be enough to anybody, but don't quote me on it!

One problem with 16x16 pixel hardware tiles is that you end up with a bunch of redundant blank tiles taking up VRAM.

Yeah I guess that's the only reason not to use them - but then the tilemap would take up 4 times less VRAM if 16x16 tiles were used, probably compensating it largely.
Another good reason is if you're using a 8x8 or 8x16 font on the same BG as the game's graphics - but as long as you use a separate BG for text I fail to see any reason not to use 16x16 tile mode.

16 colours oughta be enough to anybody, but don't quote me on it!

Sorry couldn't resist.

By doing it this way, the 68000 never gets direct access to video memory and has to go through the VDP. Then the VDP can decide if allow the access or make it wait because it needs the memory first.

No, I don't mean I/O port access to vram. I mean the vram address write setup via the COMMAND port. Requires two 16bit word writes, but the 16bit address isn't straight linear line of bits. It's a carry over from the SMS mode, the upper bits are in the second part of the WORD command. For immediate addresses, you can do a quick macro to shift in the bits. But for dynamic stuff (random tilemap and other stuff), it was just an annoyance. I think the eventually built a subroutine for it. Like I said, not a huge deal once you get used to it. But still an annoyance, though, when you need to do some quick changes or such.. or whatever.

and they probably knew nothing about what the SNES would do with color, so they just stuck with that because it was better than both the Master System and the NES.

The PC-Engine was already out a year before and had set the bar. The PC-Engine's popularity was very widely known in Japan and was extremely popular the day it was released. While it might have been nothing outside of Japan, I think it's foolish to think that Sega wasn't targeting competing with the PCE with the Megadrive as well as the Famicom.

There's also the fact that the Megadrive subpalette system is barely an upgrade from the Master System specs. And the Famicom was already capable of 8 subpalettes. Not to mention arcade systems, which Sega was no stranger to, easily has 16 and 32 and larger number of subpalettes (a lot of arcade systems still had the 16/15 color per sprite/tile cell limit). You don't need the SNES to compare to the MD, to see how made a poor decision there.

Quick question to someone that knows about the MD/Genesis, does it support 16x16 background tiles?

tomaitheous, didn't we have a similar debate about the MD on SpritesMind forums? I can't believe people defend Sega's very bad decision on the MD's sub palette situation. I think Sega's engineers (or whoever made final decisions) were just not very thoughtful, or they were just stupid. I don't think MD needs PCE level subpalettes, but 128 colors would have made a huge difference. I've said it before that maybe if they had done that people wouldn't have compared games like Mortal Kombat 1&2 between the SNES and MD and been so disgusted by the lack of color/blandness on MD.

One really bothersome thing on MD I remember is in MK1, because of palette limits Jonny Cage's projectile is a gray blob instead of the green energy bolt it was intended. I think Kano's knife is a gray color as well instead of a light blue. Not sure about some of the other characters but it was very apparent. Which makes for the very interesting situation where the MD version plays excellent while looking poor, sounding just OK. Then the SNES version looks pretty good, sound good, and plays terrible.

The 400bits of on-chip VSRAM could've gone towards another color palette instead. It's most of what another set of 64 colors would cost. I've no idea why they thought of adding vertical offset-per-tile before addressing the horrible color palette.

MottZilla wrote:Quick question to someone that knows about the MD/Genesis, does it support 16x16 background tiles?

8x8 cells. Horizontal and vertical flip options. Tile priority too.

tomaitheous, didn't we have a similar debate about the MD on SpritesMind forums? I can't believe people defend Sega's very bad decision on the MD's sub palette situation. I think Sega's engineers (or whoever made final decisions) were just not very thoughtful, or they were just stupid. I don't think MD needs PCE level subpalettes, but 128 colors would have made a huge difference. I've said it before that maybe if they had done that people wouldn't have compared games like Mortal Kombat 1&2 between the SNES and MD and been so disgusted by the lack of color/blandness on MD.

Yeah, we did And you're right. It didn't need the overkill amount of subpalettes that the PCE had (I'd go so far as to say that the PCE needed that many subpalettes because of the single layer BG system). 128 color would have been a huge increase in color flexibility - IMO. I've done little stuff on the MD, but the biggest project I did was porting Bonk 1 over to the MD. Something as simplistic looking as that, still had to have the colors stripped back for just the first level. It was a pain (and I have a bit of experience in this department already, so I'm not stranger to color reduction by hand). I had room left for another 32 colors - which I reserved for sprites. 1 for Bonk (15 colors) and two 7 color slots on the last subpalette for enemies. No room for flashing or greyscale/frozen state of the original for the enemies, either. I really applaud developers that manage to get good visuals out of the system. It's a testament to their skills.

One really bothersome thing on MD I remember is in MK1, because of palette limits Jonny Cage's projectile is a gray blob instead of the green energy bolt it was intended. I think Kano's knife is a gray color as well instead of a light blue. Not sure about some of the other characters but it was very apparent. Which makes for the very interesting situation where the MD version plays excellent while looking poor, sounding just OK. Then the SNES version looks pretty good, sound good, and plays terrible.

Yeah. And it really had little to nothing to do with the 9bit color palette. Most games don't even hit that limitation on the Genesis, because of the restrictive subpalette issue.

tomaitheous wrote:[The MD] didn't need the overkill amount of subpalettes that the PCE had (I'd go so far as to say that the PCE needed that many subpalettes because of the single layer BG system).

It might have been overkill at the time, but GBA gave up priority per tile to use the same number of subpalettes.

128 color would have been a huge increase in color flexibility - IMO. I've done little stuff on the MD, but the biggest project I did was porting Bonk 1 over to the MD. Something as simplistic looking as that, still had to have the colors stripped back for just the first level.

What are you talking about? Bonk was also on the NES.

What are you talking about? Bonk was also on the NES.

...but didn't look anywhere near as good as the original.

128 color would have been a huge increase in color flexibility - IMO. I've done little stuff on the MD, but the biggest project I did was porting Bonk 1 over to the MD. Something as simplistic looking as that, still had to have the colors stripped back for just the first level.

You only used one single palette for the whole BG... on PCE there were more used....

ReaperSMS wrote:A quick point about the CPU speeds.

65816: 21.477275/6 (FastROM), instructions are 2-9 cycles or so.
So, at 3.58MHz, the insruction rate ranges from 1.78M insns/sec to about 360K insns/sec

68000: wikipedia says it's running at ~7.67MHz
Move instructions range from 4-34 cycles, giving instruction rates from 1.9M/s to 226K/sec.

The two are not in completely different leagues, despite what some might try to claim. Well written 816 code that takes proper advantage of the direct page and whatnot should run on par with 68k code running primarily from registers. The 68k does have an easier time working with 16 bit quantities, since there's no extra penalty on those over bytes.

Forgot to respond. YOU ARE ABSOLUTELY CORRECT!!!

Perhaps the effective MIPS of the 65C816 needs to be lowered, as I'm guessing the average instruction will have a cycle of SlowRAM access. Immediate and jump instructions have fewer, instructions in 16-bit have more, and RMW instructions have more.)

With similar instructions-per-second counts, the question becomes how much does each instruction do? The 68K has autoincrement addressing, memory-to-memory addressing, 'addq' and 'subq' which work like 'inc' and 'dec' with values up to 8, 'asr' that saves an instruction over cmp/ror on the 6502 family, 32-bit ALU ops, hardware 16-bit multiply and divide, more conditions for branches involving <=, >, signed <, signed <=, signed >, and signed >=, fused decrement and branch for loops ('dbxx'), and multi-register block copies like ARM's LDMIA/STMIA.