Pixelboy

I second this. I happen to have an unused CV console that barely works and is all ready for a drop-in replacement motherboard. Not sure what kind of TV out options I'd want with it, but I'd settle for regular RF through the original RF output plug if that's an option. Other options would probably force the drilling of additional holes in the console casing, which is no big deal for me as long as it's done cleanly.

This is highly unlikely to happen, especially with the internet and with video games being so well integrated into our culture. People will always want to play games on their TV, or on the go. But there's always the possibility of big companies going under because of bad management, or a string of bad games that sink the company's reputation to the point where they drown in debt. First-person shooters are bound to (finally) go out of style at a certain point, and I can only imagine what the video game landscape will look like once that point is reached.

Even if an interesting new console had been released, I don't think it would have worked. You have to keep in mind that that the "video game crash of 1984", as most people call it, wasn't just about Atari and other industry players going out of business, it was about retailers generally losing faith in the video game industry. At the time, North-American retailers were clearing off all their consoles and games in their bargain bins, believing that the video game fad was over, and that home computers were the next big thing. A new console released by Coleco at that time would have been unlikely to convince retailers to give video games another chance. It took the NES and SMS to make them realize there was still a large market for dedicated cartridge-based consoles. Kids still wanted to play video games, after all.

I like this one, especially the green keypad buttons.

The better question to ask would be whether the levels are randomized.

Right... And I suppose you cannot "disconnect" the Coleco's VDP when running a regular Coleco cart via the cartridge port, in order to redirect the graphic output to an expansion module that can output something better. Forget I said anything.

Your comment got me thinking... The Expansion Module #1 (i.e. the Atari 2600 expansion module) somehow manages to bypass the Coleco VDP entirely and output directly to the TV screen via the ColecoVision's TV out cable. Could another, more advanced expansion module use that same "bypass method" to output colorful graphics like those in your Dracula's Castle game? Or is it something on the ColecoVision's motherboard that's custom-tailored for the Expansion Module #1 only?

Yeah, the Expansion Module #1 surely doesn't look for a cartridge in the CV cartridge port, and it bypasses the CV's VDP altogether.

Very nice, but I hope players will have the option to remove the Nichibutsu logo. Arcade accurate, yet a little annoying on a non-TATE screen.

Just my (very small) two cents here: A drop-in replacement CV motherboard is a good project, but if you want to really raise some eyebrows and make history in our little community, I would recommend something that was discussed repeatedly but never actually done: An Intellivision expansion module. Not sure if this is a project that would actually interest you, and I have to admit that I'm not personally all that interested in the Intellivision myself, but on the other hand, given your technical credentials, this seems like a challenge you could have fun tackling. Again, just my two cents.

That's the main reason why libraries were invented, after all, so you could use other people's code all bundled up in nice little packages, without worrying about how they're coded under the hood. The downsides are that the library you're using often doesn't have quite all the functions/features you want, and of course, popular libraries keep being updated to the point where they become eventually practically incompatible with your own code, so if you program something and don't keep it updated with the latest revisions of libraries and frameworks, your little program will become obsolete pretty fast, to the point where it will be flagged as a security risk by anti-virus apps. And don't get me started about cross-platform development, which is admittedly not as bad today as it used to be, but it just goes to show that any "popular" piece of software you put out there will become a constant responsibility to keep it running as operating systems (and anti-virus software) evolve. Most people will call that a "necessary evil", and they are not wrong, but when you release a cool piece of software that people like, you're not necessarily planning to keep it up-to-date in the future, you just wanted to reach the top of your personal mountain. Just look at how emulators stop being worked on by their authors after a few years. Wow, I'm going all over the place with this post... Sorry for the off-topicness.

Incidentally, I took a course in assembly programming a few years ago (it was a mandatory course for a university certificate) and I discovered that I was really good at it. But that was with PEP/8, which is a learning-oriented assembly language that is much simpler than the Z80's assembly instruction set. Still, I'm sure that if I took the time to learn Z80 assembly, I could get the hang of it quickly enough. All this to say that if you want to know if assembly programming is something you could get good at, check out PEP/8 (also spelled PEP8) before the ColecoVision's Z80. There are a few tutorials on YouTube devoted to PEP/8.

Assembly programming is hard. It's hard even for people who are used to "readable" programming like C or Basic. It takes a good amount of time and dedication to wrap your head around assembly if you've never done it before.

You could say the MSX and ColecoVision are "cousins". There are some differences in architecture, sound chips and controller inputs, so porting a game from one machine to another is usually possible, but can yield some surprising challenges. The worst is when the game seems to run correctly but suddenly crashes for no apparent reason. Good luck finding the source of the problem...

Actually, Burn Rubber is a sort of "reskin" of Lotus F3. Both games are from the same guys.

I think Nintendo should do the exact same thing with the Game Boy: Different casing colors, each color having a specific set of games, but far more than just 4 games. With 10+ games (including a few third-party titles) you'd have something worth buying.

So I'm guessing the Dina 2-in-1 and the Bit-90 computer were never sold in Japan?

Not everything...

You're mixing up the pattern and display tables. There's room reserved for 256 sprite patterns in VRAM on an unmodded ColecoVision. Divide that number by 4 because each 16x16 sprite requires 4 tile patterns, and you get 64 sprite patterns. The sprite attribute table can only display up to 32 of those 64 sprite patterns on the TV screen. Some people keep confusing the two concepts. The hardware can only display up to 32 sprites on the screen. But in VRAM, you can define 64 sprite patterns and those 32 displayable sprites can use any of those 64 patterns. Uninformed people come here looking for information, and this information should be clear. I recall a video I saw on YouTube recently where the guy explained that the ColecoVision could display 16 of 256 possible colors, which is absolutely not true. The ColecoVision is limited to 15 colors plus one "background color" that can be set to any of the actual 15 colors. It's very easy for noobs to get their facts wrong because they think all the old consoles and computers had very similar graphic chips, which was far from being the case.

You can display 32 sprites on stock hardware (which can use up to 32 of 64 different sprite patterns), but on any particular TV screen scanline, only 4 sprites can be displayed. Anything over the first 4 sprites (for that scanline) will be ignored by the VDP.

And the total number of definable sprite patterns in VRAM is 64, if I'm not mistaken. There's often some confusion about this (definable versus displayable sprites).

I hope you ("you" meaning everyone out there) are not unplugging/swapping controllers while the console is turned on. I'm always careful to turn the console off before plugging/unplugging controllers in the controller ports of my ColecoVision or ADAM, and I've never had a problem like the OP reported. Or perhaps I'm just lucky. I dunno.

They used a sensor bar with the Wii as that was state-of-the-art back then from a consumer market point of view, but since then, they likely figured out new techniques that do the same thing without the need for a sensor bar. I never really bothered to look into how Joy-cons work (I don't own a Switch) but they're certainly less bulky and evidently more advanced than Wiimotes. Gotta love progress.

No news since January. I hope this hasn't been cancelled...