malducci

The SNES uses a 65816, not the 65c02. It's the 16bit version of the 6502 but with an 8bit data bus (for backward compatibility and cheaper memory interfacing). I can tell you that the SNES is incompatible with the NES for soo many other reasons than the cartridge port. The architecture is totally different. NES carts contained VRAM or VROM on the cart and often a MMU for VRAM/VROM, the SNES has an isolated VRAM setup. The 65816 used in the SNES is missing some instructions that were latter included in the WDC MCU versions, and thus not compatible with 'C02 code.

I started with the C version first (Rockwell variant with even more instructions than the standard C model), then later on worked with the original 02 version (NES coding). I'm not sure if that might have effected how I looked at the processor in comparison. The official dev/assembler reserved a some ZP registers(maybe 16) with Register names. Latter dev units reserved even more ZP slots with register names. They even called the registers with x86 names: AX,BX,CX,DX,SI,AL,AH, etc and then some with Rx names. I always wondered what if the assembler syntax was different. Instead of LDA <$00, you had MOV A,R0 or MOV A,[R1:XI] or MOV A,[R16]:YI, etc. If ZP registers would have still been treated like fastmode ram. Later 6502's had more ZP register interfacing opcodes - like the BBRx/BBSx bit test and branch on condition. Not really related but it's funny to note that NEC's later RISC v8xx line had a 'zero' register like the C02's (STZ <operand>) - though they labeled it R0. Anyway, about the T flag. When the T flag was set (SET), the A register is ignored/untouched and all arithmetic was done register to register - ZP registers to be exact. The value in the X register is the second operand (destination) of the two ZP registers. I would like to think that if the 65x had more evolving stages like the x86, we would have seen more implementation of ZP registers as processor registers in functionality.

I don't see any relevance in that. It's a 'fast interrupt' system (if I may borrow the term from the 6809) - you push what you want for your routine. I could just image the overhead if all the regs were pushed on the stack (if it was large enough) like the 68k - lol. You know, iirc, there is a variant of the 65x with a 16bit stack (not the 65816). Hell - there are a lot a variants of that chip Well - nobody pushed X or Y directly on the stack until the CMOS version came along. Yeah ok, that was rather lame It's not the same thing. Anyway, such a large set of registers, there's no need to push them onto the stack. If they were located on the die, I still wouldn't push them onto the stack. Just curious, but do you know about the T flag and the ZP registers for some 65x variants?

Yup. The 65x has 128 16bit wide Address Registers - or 256 8bit data registers. Located in ram or not, they're processor registers. It's not the only processor with registers based in external memory VS internal die.

Actually - I'm not a fan of that method. I've seen plenty games designed that way that are pretty shallow. I'll take a game designed from the ground up as a game first, and with high production value, over any tech/demo game.

Well... not really - if you're using the term demo in the way I think you are. Demos don't really show practical effects in general. A lot of demos exploit *extreme* situations that are just not practical for real use - huge precalculated LUTs and animations, near maxed out cpu resource intensive code, the 'infinite' sprites onscreen effects, etc. Demo coders are more like illusionists. A lot of Amiga demos are misleading in what people think the system is actually capable of (talking about the 7mhz A500 series, not those 030's with AGA chips, etc).

I think the z80's built in DRAM circuitry meant something to developers (i.e. cost and simplicity). Other than that, nothing else really. The 65x was cheaper and faster. Not any more of a challenge than it was for the MSX. I'd say less so.

I'd consider the original inspiration of Air Zonk a good thing Good to hear the game is still in the works. I'll have to pickup a Lynx for that game when it comes out.

Hey TailChao, Is that Zaku game still in development? It looks a lot like Air Zonk...

Bullet Hell shooter!

S1500: More than likely. Also, I mistyped. The NES is XXX x 240 or XXX x 480 for the tile map, not 256/512. The screen res is also 256x240. If the game uses a mapper where the tile map is 512x240, then you're bound to see some garbage either on the top or bottom when scrolling vertically. MMC1 games have a work around for this - see Zelda 2 overworld scrolling. It clips the display to 240x240 and changes the tilemap from 512x240 to 256x480 for the overworld part, so it can do both horizontal and vertical scrolling without graphic glitches on the edges. Earlier mappers didn't have this switchable tilemap mirroring option, it was fixed as one or the other. It's not a hack on the hardware either, this was built into the design of the PPU. Does the Onestation NES clone look like a PS1? I have a 'PSkid' that looks like a PS1. You plug the cartridge into the system(after lifting the pseudo CD lid), but the cartridge is actually the all-in-one NES clone and rom. The system is just the wires extending to the joystick ports, video, and DC power.

I'd still like to know the source of representing resolution like that. I don't think I've ever seen it like that officially (manuals, docs, patents, etc).

http://cgfm2.emuviews.com/txt/vdppin.txt It has an 8bit data bus connected to 'vram' 64kx8 memory interface (two 64kx4). Not sure what you mean by "Both VDP's". There's only one VDP (video display processor) in the genesis. It isn't a misuse of the term. It was term used to separate and define the newer generation from the previous one - the speed of the system in general. It's just that, a term. Same with '16bit graphics'. On a PC is refers to bits per pixel, on a console it's generic and has a broad specification. If we were to be too strict, then the Colecovision is a 16bit console. And you know that doesn't fit. Then you have to start adding exceptions -blah blah blah. The PCE has 8bit CPU but two 16bit graphic chips (4 for SGX since it has another VDC and a 16bit VPC priority mixer). How does that fit in? That's the problem with using the term '16bit' and '8bit' specifically/narrowly.

Yeah, technically the PCE and SGX are not 16bit in CPU bitness, but that's not what the term really signifies. At least for consoles. A 16bit system signifies the era/generation the system belongs to - because of it's abilities. At least here in the States. NES/SMS belonged to the 8bit generation, the PCE/SNES/GEN belonged to the 16bit generation. For the Jaguar - it would be in the 32bit system from the 32bit generation - 3DO, Jag, PS1, Saturn. Interesting. If the 65x had 16 bit support (with paired 8bit registers), it would be the same number of steps as the 65816 for ADC #$1234 cycle 1 fetch opcode cycle 2 fetch operand cycle 3 perform operation / fetch operand cycle 4 perform operation and fetch next opcode But your forgetting INC. If we apply the rule that the 65x and 65816 can do one ALU operation and memory fetch in one cycle, then INC A would be 3 cycles on the 65816. But it is in fact 2 cycles on the 65816 in 16bit mode. I wouldn't doubt that the 65816 might have chained 8bit ALUs, but that's essentially the same as a single 16bit ALU. (They work together in a single cycle). That would make dropping down into 8bit mode much less work on the architecture side. I believe the original z80 (or was it 8080) had chained 4bit ALUs. Nope - it's a byte size bus. You can write a word and it will count as two bytes. Set the incrementor to something other than 1 and write a word. The upper half of the word will be n amount of bytes from the lower half. The VRAM 'address' is byte based as well.

6502? Or do you mean 65c02? The 65816 can drop down in and out of 8bit register at anytime. You can make some optimization routines for this too. My only thing with the SNES version of the 65816 is that it's missing the added instructions that Rockwell defined for the 65CS02. WDC later added these in. The 65816 has a 16megabyte address range, though. It's segmented similar to the x86, but perfect for games. Super R-Type is an example of bad coding, while Super Darius Twin and other shooters are better examples of knowing how to code for the cpu. For homebrew, the SNES makes for a perfect setup. There's nothing more fun than pushing a system to it's max, that people believed otherwise wasn't possible. In case of the SNES, that would be speed.

That's the first I've ever seen anyone have that opinion about the SNES. Regardless of its bus, it definitely has a 16bit ALU. What really hurts the SNES is that WRAM (work ram) has wait states that bring the overall speed down. Even when in 3.57mhz mode. WRAM is 8 *master* cycles for the memory fetch/write part of the opcode if in WRAM, instead of 6. The 8bit bus isn't so much a hindrance as is the clock speed. It should have been 7.16mhz (which is faster than the 68k @ 7.16mhz - IMO). 16bit is somewhat of a generic term for consoles. Generally, it more pertains to the 'prowess' of the graphics capabilities The PCE/SGX are regarded as 16bit consoles because of their graphic processors, when they in fact have an 8bit CPU (8bit ALU, 21bit BUS). The SGX has two 16bit graphic processors. If I remember correctly, the VDP in the Genesis/Megadrive is actually an 8bit IC internally. Not that it really matters, they're all more or less a 'state machine' than a processor. Another reason probably why the SNES didn't use a 68000 is that they were still expensive back then. And Motorola didn't license its 68k core for custom packages like WDC did at the time ('88-89) Gotta love wiki The 8bit bus *really* hurts cycle times of the 68k instruction set, as if they weren't slow already. Maybe faster than the z80 or 8080 <_<;

The support by Tec Toy in Brazil probably helped as well, indirectly. Have you seen some of the GG to SMS converted roms (hacks)? I remember there was one of Aleste, but the palette was cut down to SMS. Still looked pretty good. I didn't find that out until last year. Funny as I had coded GBC demos in assembly back in '99, all the long thinking it was a z80. I had no clue about the shadow registers. But yeah, that's why I put 'variant' in there The GBC's sprite per scanline limit is nice though, even more so considering the ratio of sprite pixels to screen res limit. I thought it was a great little system. Smurfs, albeit difficult, was an impressive GBC game.

The palettes has 32 entires of 2bit RGB (64 colors), unlike some other systems that use HSV. So there would be no way to display more colors than what the palette has. Not like the NES which has 52 colors but additional color emphasis bits allowing for up to 400+ color palette ( though only accessible in fixed segments of 52 colors). How does that work on the NES? I've never heard much about it before.. ( Not that I've looked at the NES much, went from Gameboy/Gamegear to SNES in programming ) Found it now... just had to read some docs... The GBC is a great and easy system to code for. The z80 in general is quite slow, but the 8(2)mhz variant in the GBC is really nice. All that vblank time is gold too! Same with GG.

I remember those numbers too. I'm pretty sure they originated from some magazines - probably EGM. The palettes has 32 entires of 2bit RGB (64 colors), unlike some other systems that use HSV. So there would be no way to display more colors than what the palette has. Not like the NES which has 52 colors but additional color emphasis bits allowing for up to 400+ color palette ( though only accessible in fixed segments of 52 colors). The SMS has 16 colors for sprites, but color 0 is transparent - so only 15 colors are visible. Tile has 16 colors, but color 0 is transparent to show color # 0 form the master palette - this is for tile/sprite priority layering so sprites can appear underneath tiles but never underneath color slot 0. Aslo, each individual tile can also be set to use the the BG 16 color palette or the sprite 16 color palette. So the background has access to the whole palette block in a segmented fashion. Also, the sprites are only 8x8 or 8x16. There are no 16x16 sprites for SMS. That would have been great, but it's not the case. The GameGear is the same as the SMS except the palette format is 4bit RGB (4096 colors) but still limited to 32 slots.

Yeah, the SMS has more colors per tile and per sprite (16 for tile - 15 per sprite). Much cleaner looking agreed

The SMS is same 'flicker fest' when it comes to sprites. They both have the same sprite per scanline limit. And the Coleco is even worst than the NES for sprite scanline limit. That makes no sense.

Can't stand that western RPG crap Never could, even before JRPGs hit the US shores in '90. That said, the new 'Tales' game is out for 360. I bought it but won't have a chance to sit down and play it until this weekend.

Most have both in some point of the game, but yeah it's less so than horizontal scrolling game. The short answer is that without using the corresponding mapper, you'll get some color artifacting at either the very top or the very bottom (depends on the scrolling direction) because the smallest color change areas being effected are 16x16. Though most likely the artifacts at the top and bottom will be partially in overscan area. The NES has a virtual 512x512 tile map, but the system only came with enough ram for half of that. The system mirrors the other half either vertically or horizontally unless a cartridge provides the additional ram. The mirroring is a hardware feature of the PPU set by cartridge. MMC1 chip introduced switching vertical and horizontal mirroring on the fly as previous chips had this fixed to vertical or horizontal. Megaman 1 is an example of a NES game that has vertical scrolling but with a mapper that's fixed for 512x256 horizontal tilemap (lower half is mirrored). Trust me, that's the shorter answer

supercat is right. The method for smooth scrolling on the CV, as vigo already stated technically, it very limiting. Very limiting. It's based on "animated" tiles if you will. This effect has also been used in conjunction with hardware scrolling on NES, SMS, and even PC-Engine to give it more simulated multiple layers to scrolling. But back to the CV's case, doing the animated tile method also cuts in on your color choices for horizontal scrolling (vertical is less limited). Animated tile also limits you to type and/or number of tiles you can have onscreen. It looks good in some situations because of X exploit. And "X" specifications/requirements can be very narrow in design choice.

You could change the color intensity bits mid scanline since it's a separate reg ($2001), but that limits you to effecting the whole color range. Still, that'd give you some type of color effects. Too bad the NES couldn't independently/freely access all of the 400+ color palette.