malducci

Raster interrupts with certain mapper chips (excluding sprite 0 flag limited method). But I'm not sure there's enough time to update the palette ram in the PPU during hblank. It's pretty tight (~17 cycles total I think). You would have to re-update 2005/2006 before the PPU grabs the values. I'm not sure if the clipping mode for 8 pixels each side effects when the PPU grabs the vram position values from 2005/2006.

The MMC3 in SMB is just a mapper chip. It's nothing special other than it has an additional programmable counter/IRQ (used for the none moving status screen). NES games were using mapper chips long before. If the 7800 had the level of production from developers of the NES (and the memory), you'd see some great games. Regardless if the 7800 is weaker in some areas. It has other strong points. I wonder how J-RPGs would have been on the 7800. As far as audio, I would assume pokey at the least.. or maybe a variant of SCC.

Ahh, ok. That makes more sense

Ok, you mean spiritually - not directly related as in a modified core. That's what I figured you were referring to. I think the 5.37mhz clock was chosen more for the pixel aspect ratio and lower cost for clock speed. The pixels are almost perfectly square on an NTSC television. That matches up great for 8x8 tile segments. But that's just speculation. I confirmed with Charles Macdonald, the modes are missing from the Megadrive/Genesis VDP. Apparently one SMS game uses this mode, some flight simulator, and is the only SMS game that doesn't work on the Genesis VDP..

Found this link: http://www.gamedev.net/community/forums/to...topic_id=454803 That's an old disassemble, this is the new/different one - http://www.romhacking.net/docs/smbdis.zip This version you can actually assemble the source file.

This is almost correct. MSX1 and Colecovision use the same videochip. The Sega Master System however, uses its own videochip developed by Sega, which on the other hand, IS backward compatible to the MSX/Colecovision videochip. And this backward compatibility is also present in the Genesis and Game Gear VDP. Yes, the 16bit Genesis CAN display the original MSX1/Colecovision graphics modes! I suppose all of you know that the Genesis can also play SMS games. You sure about that? I thought it was just the SMS modes the Genesis VDP could display and lacked the SG1000 modes. Which connection are you making with the TMS9918 VDP and the PPU, sPPU, and VDC? That they were tile/tilemap based?

There's a full disassembly of Super Mario Bros for NES with comments. It would be interesting to see a port of that source on the 7800.

I don't see how the z80 is a gift from god.

Strange that you list the res with vertical value first. Is that an atari thing/way? The CV had 4 sprites per scanline before it dropped on them on the that specific scanline. Nothing flicker couldn't fix. Except for sound, the 7800 destroys the CV. I'd take lower res with more color flexibility over the color clashing of the CV, Speccy, and MSX (version 1).

Though not a standard 6502, the HuC6280 does block copying at 6cycles per byte - with a 17 cycle setup overhead but it pushes and pops all registers for you. Block copy up to 64k similar to the 65816's block copy opcodes. I'm curious about your music player. Are you handling the volume of the samples in software? I have something similar using 262 scanline interrupt system for MOD, but I'd like to do something else (chiptune style). What are some of the type of effects you plan or have implemented (LFO, FM, AM, etc)? Sorry to disappoint, but it's not a pissing contest. End it at that.

That sort of tells me you might not know how to efficiently code for a 65x processor then. It's called optimize accordingly. I've been coding on a 65x for years and I haven't had a problem with the lower register count. Never had a problem with the 256 ZP registers either And I never said that you did. The discussion is in the context of consoles, not computers, and as such is optimized/written differently. No, that wasn't my point. Geez. My point was that optimizing for 32bit operands represents such a small percentage of the overall CPU resource for 68k on the Genesis. And that you keep repeating generic examples of LONG operands as if it's strength of the 68k and the sole exertion power in context of the Genesis (and even in general). It's not. But you keep repeating it... If you knew how to effectively code for the 65x, you'd know optimizations are totally different than coding for a 68k. That's not hard to understand. Limited registers means a different approach to coding and problem solving than a processor with a larger amount of registers. Some solutions are less (than) graceful, but the faster instructions times help expedite this. Never underestimate small LUTs on a 65x either . There are also other memory/test(compare) effective instructions besides using load/store - sparing register usage. Game logic is pretty simple. It's not complex. It doesn't require overly complex code. 8bit elements easily fit into the core design logic. In the context of the PCE and the MD. Narrow minded? I prefer the term "focused" I'm not saying that the 68k is crap. It's not. The 68k has lots of positive attributes. It has a great instruction set, a roomy register set, easy to code efficiently for, and my favorite - linear address range. It's just not exaggeratingly "much more powerful" as you say. Seems to be a trend with a lot of 68k old schoolers, that nothing can touch 68k. Performance is relative to context. And in the context of the 16bit consoles, the PCE's huc6280 shines spectacularly.

Vigo: I think the problem is that you might be arguing the same things in multiple context. What does "much more powerful" relate to? Speed/performance or the complexity of it's instructions? Anyway, my point is that game dev on a 16bit console doesn't *require* 32bit integers, nor does it give it a speed boost in *general* - just the opposite in most cases. Some cases, yes - like shifting through a bit mask for LZ decompression, or moving larger chunks of data, or what not - but that's somewhat small percentage to the overall game code. 68k's strength comes from its larger set of arithmetic registers and 16bit ALU+16bit bus. It's the slow bus access times that bring it back down. There are always special case operations that might benefit from 32bit arithmetic instructions on a single 16bit ALU versus two 16bit instructions, but the same can be said of 8bit operations on the 65x/68-9 which are faster than on the 68k. So I don't understand why you keep showing that 32bit example . Depending on what you mean by "much more powerful", I'd say that's definitely not the case. It's fairly safe to say they are pretty much even overall in speed when it's relevant to console game code. If this was for a computer, I'd say the 68k. Still, 2 channel audio seems a bit simplistic. I mean, considering they did improved the graphic capabilities. What was GUMBYs specs?

You misunderstand. Why would you even consider using 32bit elements in console development? 16bit data/var cover almost anything and execute faster on the 68k. You optimize your code for 16bit operations and operands. The same concept in that you optimize 65x/6809 for 8bit data operations when ever possible. Hell, 90% of the time 16bit arithmetic is 8bit+16bit or 1bit+16bit(inc), not even 16bit+16bit. Except for your address range, 32bits isn't needed on 68k consoles - or more specifically the Genesis/Megadrive. For the record, the HuC6280 is based on the R65C02, not the 6502 or 65C02. (/me finds new love with the TST instruction). Also, I thought the 7800 had the Pokey chip. I was always thought the 7800 was an A8 with a slightly better graphics chip. But that's totally bizarre that they excluded the Pokey. Sound/music was pretty important games back then (IMO). At least it could be accessed via cartridge add-on.

Ehh? Maybe on a 68020. It's preferable to use 16bit data/var on the 68000. That's a waste of cycles or am I taking that statement out of context?