The way I see it, there are two separate issues for discussion here.

The first is permanently altering a classic console. That’s an issue of historical preservation, and I’m not going to get into that.

The second issue is whether or not, being prepared to go as far as having removed the original optical drive, one might not just as well drop the console entirely and go the emulation route. To me, suggesting this shows a lack of understanding about how emulation works.

A real console consists of IC semiconductors and discrete components that propagate electrical fields and shuffle the occasional electron around. A software emulator is a bag of rules and tricks that tries to replicate the overall output of a console. Even FPGA-based emulators aren’t 100% perfect, because their gates and connections aren’t configured identically to the original hardware.

Game consoles are very complex systems that operate via the interplay of dozens of intricate subsystems. That’s why emulators start off supporting only a handful of games, and rarely reach 100% compatibility. Emulator developers are forever picking the next emulation inconsistency from the bug report list, tracking down what their emulator is doing differently to the original hardware, and then adding a new rule for dealing with that particular case. If they’re lucky, a couple of other games will also start working better. If they’re unlucky, a couple of other games will start working worse.

(For the interested, the author of BSNES wrote a detailed article about these issues for Ars Technica)

Take the Atari 2600. It’s a very old console that was very popular. The community has full schematics not just for the mainboard, but even the CPU and custom video chip. More patient people than me have sat for hours with oscilloscopes and test ROMs to probe the console inside and out. There are emulators that can play every game that was released back in the day without fault. Heck, the emulator I use is so advanced that you can set it to emulate specific revisions of the console with specific CRT TV parameters, and it will glitch in the same way that the game would glitch on that combination of hardware in real life. But it’s still not a “perfect” emulation! Homebrew developers are still finding quirks in the real 2600 hardware that the emulators don’t replicate, at least until the next update.

I have a PS2 which plays my games from an internal hard drive, and which has its output fed through an HDMI converter. Why don’t I just emulate it? Well, if you want to play FFX, or MGS2, or Ratchet & Clank, that’ll work great. Those are popular games, and emulator developers have put a lot of effort into making sure that the rules of their emulation work for those games. But I have dozens of more obscure games that have game-breaking glitches or don’t launch at all under emulation. And I also still have hundreds of discs that I don’t want to paw through, and are slowly degrading until one day they’ll no longer work, as well as an optical drive that gets a little closer to wearing out for good every time I use it, and a big, modern TV that hates analog inputs (not to mention no room for a bulky CRT). Getting the data into the console, and getting the final video and audio out, are both fairly well-understood and usually can be reimplemented reliably. But the heart of the console, where the data is turned into executing code, mixed with player input, and transformed into the output? That’s where the actual magic happens.

In my opinion, saying that if you’re going to replace an optical drive then you may as well just emulate the whole thing is a bit like saying that if you’re going to talk to Angela over the phone instead of in person, then you may as well just replace her with a well-trained AI chatbot.

Why bother? Because feeding data into the console and getting audio-visual signals out of it are both very well understood and can actually be replicated with essentially total accuracy. But the complex operations and subtle interactions of CPU, VDUs, RAM, and other support chips can’t. That’s the important part of the console, not the optical drive or the analog video output.

Software emulators and FPGA-based systems give it a good try, and can often run the majority of software for a console at an acceptable fidelity for most users, but they’re a long, long way from being 1:1 perfect, and the more recent the console, the more games either don’t run properly or don’t run at all.

Oh my goodness, replacing the optical drive with a modern solution isn’t close to halfway to complete software emulation. It’s not even 20% of the way there.

You’re quite right! I didn’t notice that.

Many special editions of the Dreamcast were released over the years, in a variety of different colours. However, every special edition Dreamcast that I’ve seen has had some other visual change besides just the colour.

Looking at the pictures, I suspect that your console has just been put into a replacement aftermarket shell. However, if the bottom half of the console is solid grey, and there’s a pale yellow limited edition number sticker on the back, then you have a quite rare Code: Veronica (Claire version) console. I’m guessing that if the sticker was there, though, you wouldn’t be here asking about it, as it’s a real giveaway.

That being said, it still looks cool, but I don’t think it’s going to command an especially high price or anything. The controllers were always available in a wide range of colours, although it’s funny that the beige controller on the right has the blue European swirl. I guess someone got a deal.

I first learned about Java in the late 90s and it sounded fantastic. “Write once, run anywhere!” Great!

After I got past “Hello world!” and other simple text output tutorials, things took a turn for the worse. It seemed like if you wanted to do just about anything beyond producing text output with compile-time data (e.g. graphics, sound, file access), you needed to figure out what platform and which edition/version of Java your program was being run on, so you could import the right libraries and call the right functions with the right parameters. I guess that technically this was still “write once, run anywhere”.

After that, I learned just enough Java to squeak past a university project that required it, then promptly forgot all of it.

I feel like Sun was trying to hit multiple moving targets at the same time, and failing to land a solid hit on any of them. They were laser-focused on portable binaries, but without standardized storage or multimedia APIs at a time when even low-powered devices were starting to come with those capabilities. I presume that things are better now, but I’ve never been tempted to have another look. Even just trying to get my machines set up to run other people’s Java programs has been enough to keep me away.

I don’t know if this will work or even compile, but I feel like I’m pretty close.

long main () {
    char output;
    unsigned char shift;
    long temp;
    
    if (i < 152) {
        shift = (i & 1) * 7;
        temp = b[i >> 1] >> shift;
        i++;
        output = (char)(64 & temp);
        output += (char)((n >> (temp & 63)) & main());
        printf("%c", output);
    }

    return 63;
}