RT-55J

I don't know why anybody liked Gex, but I'm fairly certain that most people who claim to like Gex nowadays are doing it as a joke.

Kemco's Crazy Castle series is probably the only series out there that can compare to Wonder Boy in terms of release weirdness, with the license each game was attached to (from Mickey Mouse to Bugs Bunny to Garfield to Ghostbusters) changing randomly from game to game and even region to region. I'm not sure how exhaustive the Wikipedia page is, but it's still a sight to behold.

Similarly, Mega Man 10 and Mega Man X are completely different games. Oh, and of course there's the infamous case of there being a Mega Man and Mega Man 3 for MS-DOS, but no Mega Man 2.

Kinda tangential to the topic at hand, but I find it funny how people compare the Pico-8 fantasy console to the Game Boy, when in practice it's rendering model puts it much closer to the Lynx.

There are a lot of trade-offs between the two, but imo in practice they tend to be relatively minor. The NES has 256 tiles for backgrounds and 256 for sprites. The Game Boy has 128 for backgrounds, 128 for sprites, and an additional 128 shared between the two (the GBC doubles these numbers). The GB has a wavetable channel, which is more flexible than the NES's triangle channel but less powerful than the NES's DPCM channel. The Game Boy has an additional "window" layer, which is used to great effect in games like Operation C and Metroid 2. Even with the its most powerful mappers, the NES has no raster effects as sophisticated as this. Generally, I'd say the NES is more powerful, but when it comes to the stock system the GB did a much better job at hitting the sweet spot between power and usability.

Aside from it's very limited sound capabilities, I would argue that the Channel F had decently capable hardware for it's time. The issue is that its software lineup was quite anemic. If the system had kept receiving a steady supply of games after '78, it would have been more highly regarded. (As a corollary, imagine a world where the 2600 library slowed down to a trickle after '79. The system would feel a lot less impressive.)

Part of the reason dividing console generation can be difficult is that Moore's law provides (or at least provided) a sizable improvement in cost/performance every two years, while the life cycle of a decently successful console is 5 years at the very least. Those two realities do not cleanly mesh together. Another reason is that the system of numbering console generations is something invented by Wikipedia editors (who probably weren't too interested in anything prior to the NES), and not really based on actual historical realities. What they consider the "second gen" could readily be split up into two or even three different generations as others have mentioned here. Another issue is that consoles are made of several different components, which might be from different generations themselves! For instance, while the SMS's VDP was two years newer and better than the NES's VDP, it's audio chip was 4 years older and stodgier, and both of those facts are evident in how the games on those systems both sound and look.

Here it is: dodge_it_big.bin When you get one of the larger arenas the game is significantly easier, even on pro mode. Sorry about that. I reverted the project back to using the standard ves.h file. All of my additions (that I actually used) are now in the main dodge_it.asm file: namely, defines for the controller inputs, and the SETISARU and SETISARL macros I made (because I like naming registers and LISU and LISL don't play nice with that). The project should now compile just fine with only dodge_it.asm and the standard ves.h file. Since you're curious, all of the additions that I had made to ves.h are now in utils.h on the Github page. It's not the most useful stuff (and the project should compile even if you delete it).

I've been plugging away at my Dodge It disassembly for the past couple of weeks, and I'd say it's about 95% done-done (whereas I was about half-way last time I posted). It's a much cleaner and better documented than it was before. You can add it to the wiki now if you want @e5frog. Granted, I added some stuff to ves.h, so it won't compile with the standard ves.h from 2004 (we should probably sort that out first). I've made it so that by just changing a few constants near the beginning of the code you can change the max size of the playfield rather easily, like so: Not the most exciting change, per se, but its something. (I'd post the rom, but I'm not sure how kosher that is here.) The next thing I want to do is either improve the BIOS's disassembly, and/or make an original project. I'll probably make a thread in the homebrew or programming forums when I have something to show there.

You can link to it, but I'd hold off on posting the code there until I clean it up some more.

No worries! I've never cultivated much of an internet presence beyond a handful of small forums, and my handle is practically nonsense anyway. Anyhow, for a while I've been working on a disassembly of my favorite Channel F game, Dodge It. I've reached the milestone recently where I've figured out the basic meaning of every chunk of code. There's still a lot of clean-up and documentation to be done, but I'm proud of what I've done so far (though currently the drawing function is the only thing I'd consider fully up to my standards). Some interesting things I found: - After the rest of the character set, there are the letters "F", "A", "S", and "T". There is no place in the code that would display those letters. - There is an unused function that makes the screen flash (using the row attributes). I think it used to be the game over animation. - Unlike a lot of earlier games (and some later ones) it doesn't make any calls to the BIOS.

Good episode. I liked it when you referred to me as "some guy on a forum"

I wrote a post explaining the probable issue with the original cart that I'm going to add to the original topic I made on that other forum. If anyone has any complaints about it's accuracy or clarity, I'll wait before posting it there. https://pastebin.com/v7swQL0i Thanks.

Testing the different carts to see if there's a hardware difference would be nice. I doubt they would have changed any of the logic in the PSU between different production runs of the cart if they kept the ROM the same. Still, it would be nice to know for sure. As far as examining Sean's decapping photos, it looks like all of them lead to 404s now. Bummer. In any case, I'm glad that I was able to find the easter egg, and that Michael Glass Jr. ended up finding out about it at an opportune time in his life. I'm just slightly embarrassed to have shared unintentionally inaccurate information on the subject.

Hi. It's me, the fellow who found this thing. So, to make sure I'm up to speed: the easter egg on an emulator, and on the original hardware with the multicart and with a flash cart, but apparently not on the original cart. Is that correct? I know dumping Channel F games requires dedicated hardware, but I think someone with the original cart should test it and redump it just to make sure there isn't an undocumented revisional difference in the ROM causing the issue. Truncating the bit-width of the data counter register definitely sounds like a plausible cost-cutting measure a semiconductor company would do (fewer transistors -> lower failure rate in manufacturing). IIRC, didn't Sean Riddle decap some Channel F PSUs? That could be one way of verifying if they actually did that. (Note: I don't have any Channel F hardware myself.)