SNES hardware APU support?

[creaothceann]

[...] that only applied to the entire BG screen (limited to 128x128 tiles, i.e. 1024x1024 pixels), and never to sprites.

Fix'd. ;)

2. The Genesis was capable of displaying 64 colors out of a maximum of 512. They were able to beat this limitation with software tricks as I remember (Ranger-X used the trick), but 64 out of 512 was its official limit.

If the palette can be changed between lines then more colors are possible per screen.

3. SNES was capable of displaying 256 colors out of 32,768.

Same here. There's also a "Direct Color" mode for 8-bpp backgrounds that displays them in 32,768 colors. It was used in Actraiser 2 and a quite hidden world view mode in Secret of Mana - not very influential.

Genesis resolution was 320x224 vs. SNES resolution of 512x448.

Very rarely used though, as byuu said.

Genesis had 16-bit wrote on the top of the system and I read several different magazine articles referring to the Genesis CPU as 16-bit back in the day.

It can read/write only 16 bits at a time though, which is probably where that labeling comes from.

[byuu]

Sorry in advance if my tone seems more blunt than usual, I've been up way too long and need to sleep.

but my Genesis had 16-bit wrote on the top of the system

...

What was SOA's proposal in terms of specs/design for the Saturn?

Too tired, I'll try and look it up later on for you.

1. It is a 32 bit microprocessor sitting on a 16-bit-wide *DATA* bus.

Ah, that's what I was thinking might be the case.
I'm curious how they made this happen. Were the 32-bit instructions simply broken down into two 16-bit operations? I imagine that would be a major pain in the ass for multiplication and division, but quite simple for addition and subtraction.

You can blame that design decision on the fact that the SNES was supposed to be backwards compatible with the NES.

Yeah, and then they went and changed things too much anyway. Bastards. bsnes could've been bsnes (btw i am dumb) as well :(

Fix'd. ;)

I was referring to the tiledata, not the tilemap. I suppose I should've mentioned that before ... very well:

Only the lower 32,768 bytes are used in Mode 7. Each word is interleaved, one byte for tiledata, one byte for tilemap. That's 16,384 bytes each. Or 128x128 tiledata, and 128x128 tilemap. 128/8x8=16*16=256 tiledata, 128*8x8=1024x1024. Each tilemap entry is thus 8-bits, as is the tiledata (or 7-bits in EXTBG where the highest bit becomes a priority bit.)

Another limitation is that while the lower bpp video modes could address up to 1,024 unique tiles using their tilemaps, mode7 was limited to 256.

Same here. There's also a "Direct Color" mode for 8-bpp backgrounds that displays them in 32,768 colors. It was used in Actraiser 2 and a quite hidden world view mode in Secret of Mana - not very influential.

... what? Direct color is 8-bit, 2^8, or 256-colors, and applies only to BG1. And 11-bit if you count the unbelievably worthless RGB111 extra color that you can only specify once per tile (at best, per 64 pixels). It's actually a really useless mode as the PPU clears the lowest palette bits (white is never really white, but more of a light gray). It's only useful because it frees up the palette for use with other BGs and/or sprites.

To display all 32,768 colors at once, the tech demo took advantage of color add/sub.

[creaothceann]

There's also a "Direct Color" mode for 8-bpp backgrounds that displays them in 32,768 colors.

... what? Direct color is 8-bit, 2^8, or 256-colors, and applies only to BG1. And 11-bit if you count the unbelievably worthless RGB111 extra color that you can only specify once per tile (at best, per 64 pixels).

Yeah, my bad. I was thinking about how the pixels are no longer restricted to 256 colors, forgetting that it's not really 15-bpp.

[denzilla]

They could've at least increased the clock speed of the crappy CPU inside the snes. I can't believe they didn't foresee it as being a huge bottleneck to overall system performance.

[franpa]

i don't think nintendo cared. they would have done some tests and shown that they can make games with its low speed that are fun and look a helluva lot better then sega's console.

no one pushed the console to the limit till i think quite a while later.

[Nightcrawler]

1. It is a 32 bit microprocessor sitting on a 16-bit-wide *DATA* bus.

Ah, that's what I was thinking might be the case.
I'm curious how they made this happen. Were the 32-bit instructions simply broken down into two 16-bit operations? I imagine that would be a major pain in the ass for multiplication and division, but quite simple for addition and subtraction.

Good question. That I'm not entirely sure on. From what I understand, since the chip can operate internally at full 32-bits and it can simultaneously read two bytes of data at one time according to the datasheet, I'm thinking it simply does two read or write cycles when dealing with the data bus instead of one. The data sheet seems to suggest that depending on the mode of operation, it can read in the correct bytes and position them correctly internally before starting the operation.

The datasheet seems vague on the subject. However, with 189 pages of information, maybe I missed it.

[whicker]

1. It is a 32 bit microprocessor sitting on a 16-bit-wide *DATA* bus.

Ah, that's what I was thinking might be the case.
I'm curious how they made this happen. Were the 32-bit instructions simply broken down into two 16-bit operations? I imagine that would be a major pain in the ass for multiplication and division, but quite simple for addition and subtraction.

Good question. That I'm not entirely sure on. From what I understand, since the chip can operate internally at full 32-bits and it can simultaneously read two bytes of data at one time according to the datasheet, I'm thinking it simply does two read or write cycles when dealing with the data bus instead of one. The data sheet seems to suggest that depending on the mode of operation, it can read in the correct bytes and position them correctly internally before starting the operation.

The datasheet seems vague on the subject. However, with 189 pages of information, maybe I missed it.

The 68k series was also my first CPU I learned to program for.

Basically, don't worry about bus size. Data and Instruction granularity is 16-bit chunks. Depending on how the instruction is set up, immediate data and such follow the instruction. The longest instruction was, I believe, 11 words long. 68K was "fun" to program for because you could do so much per instruction (like copying a location from one ARRAY to another ARRAY).

Copied directly from the programmer's manual:

Because address registers and stack pointers are 32 bits wide, address registers cannot be used for byte-size operands. When an address register is a source operand, either the low-order word or the entire long-word operand is used, depending upon the operation size.

When an address register is the destination operand, the entire register becomes affected, despite the operation size. If the source operand is a word size, it is sign-extended to 32 bits and then used in the operation to an address register destination. Address registers are primarily for addresses and address computation support. The instruction set includes
instructions that add to, compare, and move the contents of address registers.

Ugh. This brings back memories. BAD THINGS HAPPENED with an odd address (illegal address interrupt). Again, this thing was WORD aligned.

Now, to further confuse, there was this chip called the 68008. In order to get it into a smaller package instead of that MONSTER of a DIP package of the regular 68000, they reduced its data bus to 8 bits. But, it ALWAYS read two bytes every single memory access.

[Snark]

Ok, let's put this to bed. I have the definitive information taken directly from Motorola/Freescale documentation.

http://www.freescale.com/webapp/sps/sit ... H3YTLC6165

The MC68000 is the first implementation of the M68000 16/-32 bit microprocessor architecture. The MC68000 has a 16-bit data bus and 24-bit address bus while the full architecture provides for 32-bit address and data buses. It is completely code-compatible with the MC68008 8-bit data bus implementation of the M68000 and is upward code compatible with the MC68010 virtual extensions and the MC68020 32-bit implementation of the architecture. Any user-mode programs using the MC68000 instruction set will run unchanged on the MC68008, MC68010, MC68020, MC68030, and MC68040. This is possible because the user programming model is identical for all processors and the instruction sets are proper subsets of the complete architecture.

What does this mean for the Genesis? Let's review:

1. It is a 32 bit microprocessor sitting on a 16-bit-wide *DATA* bus.

2. The 68000 implements a 24-bit *ADDRESS* bus, allowing it to address up to 16 MB of physical memory.

3. Address storage and computation used 32 bits, however, with the high byte ignored due to the physical lack of pins.

4. The internal data registers are indeed 32-bits.


This was a great CPU architecture design with forward thinking and compatibility in mind. There's good reason it was widely used and is still being used today. The SNES would have been a beast with this processor. You can blame that design decision on the fact that the SNES was supposed to be backwards compatible with the NES. Otherwise, there's just no good reason to have selected the 65816.

Hope I could clear up this debate for everyone. No applause necessary.

And I was just about to ask "So, why Nintendo DID used a poor cpu for their console?" thanks for clearing that up.

Snes with Megadrive cpu/68000... drools...Then again, maybe we would have gotten fast-action games with loads of sprites but very little in the RPG department. I mean, maybe developers started focusing on RPGs precisely because the Snes couldn't quite pull off frantic 2d games but was less penalized with regards to RPGs, as gfx and sound capacities was more crucial and Cpu speed mattered less.

.So...no sense thinking what could have been.

[jonwil]

The Megadrive hardware seems to reflect Sega's arcade heritage and what their arcade hardware was like at the time.

As for the 65816, the only known uses of the 65816 are in systems that are sequels to/upgrades of systems that used the 6502. The apple IIGS used the 65816 as did the SNES. Some evidence suggests that Nintendo planned backwards compatibility (using the 6502 emulation mode on the 65816) but dropped it (due most likely to the costs of supporting the NES sound and video hardware in the SNES hardware)