The Dreamcast is by far and large one of my all-time favourite consoles.
SEGA’s level of innovation here was extreme.
From great developer support, online play (even if the Broadband Adapter for Ethernet was extremely rare); the VMU, and an extremely impressive library of quality titles (Skies of Arcadia, Crazy Taxi, Soul Calibur 2, etc) - it was literally a situation that seemed geared to greatness.
If it had a DVD player, I think it literally could’ve saved SEGA, after the awful litany of repeated terrible decisions they made in the mid-90’s. (Here’s looking at you, 32X...)
I was just at A&C games here in Toronto, lamenting to an employee of the demise of SEGA’s consoles - but the Dreamcast, in particular, deserved better than it got.
The Saturn will always have a special place in my heart, though, as an extremely early example of multi-processor architecture (the Saturn technically has 7 processors, each for a different task - 2 GPU’s, CD I/O, sound, etc.)
Sega was already bleeding money so bad by the time the Dreamcast launched I am not sure they could have done anything to recover at that time. The fact that they missed their first sales target in the US (they wanted to sell a million units by a specific timeline but were 40% off) marked the end of the party.
About dev support dont forget that EA pulled out of supporting Sega since they did not want their sports games to compete with Sega's own line of sports games. That may have be a big deal not to have games like John Madden in the US.
There is a hack that you can do (soldering on an IDE cable) that allows you to connect a DVD drive and boot games and access files from DVDs. The Dreamcast modding community is still very active to this day. A lot is known about the internals which I find fascinating.
Say what? The Dreamcast used a GD-ROM which was 1 gig, hence it's name. The was an alleged specific model CD-Rom drive with modified firmware that could have read the GD-Roms directly from a PC.
Rippers used a DC with the Ethernet adapter to rip games however.
Now you can also mod the Dreamcast to use an IDE hard drive with Dreamshell and modified bios since the Dreamcast used and IDE bus for the GD-Rom.
There are 2 drive emulators for the Dreamcast where you replace the GD-ROM with a device that allows for either SD card storage or USB.
I have not seen this DVD rom hack you are talking about though
The Dreamcast was an amazing console. The fact it had Capcom VS SNK 2 faithfully running, Ikaruga and Power Stone immediately makes it one of my all-time favourite consoles. I'm praying SEGA releases a "Dreamcast Mini" one day.
A&C Games is an absolute gem of a retro store, and if anyone reading ever makes it to Toronto and has an affinity for old videogames, make it a point to stop in to the shop.
> If it had a DVD player, I think it literally could’ve saved SEGA
It was released just as the PS2 was announced, back in an era when people only bought one game system. I think it was the timing more than anything else that killed it.
At least among myself and friends, we didn't care about that - we had to decide which system we wanted because our parents would only get one, and went for the bigger name/more familiar games.
(To my and my brothers' initial disappointment, my parents didn't understand why we wanted a PS2 and got us a Dreamcast instead, then refused to get a second game system. One of my brothers still has and plays that Dreamcast.)
But the PS4 never got a UHD Blu-ray player, some think it was an obvious candidate for the 4K pro model. Or perhaps we've gone the other way again and discs are dead, streaming is king.
You have to keep in mind that when the PS2 was released, the DVD was also just released. I remember a stand alone DVD player by itself was ~$200 during the PS2 launch. So part of the argument of it being $299 is that it was a bargain to get it and then not have to buy a DVD player on top of it.
The Xbox required the IR remote controller to play a DVD (So you had to pay $300 plus that price), and the Gamecube could not play a DVD at all (but it was $150 at release).
A note here since I did not know this: It looks like Redream is no longer open source. As far as I can tell its not formally acknowledged anywhere. It seems like it was silently closed source when it moved from GitHub to GitLab some time ago. I feel like people ought to know since some folks may be under the impression it is open source when it's not. I usually don't bother trying to use closed source emulators personally, for practical reasons (At the very least, closed source anything is a pain in the ass under NixOS.)
Good spot. It used to be GPL licensed. How odd. If you goto the gitlab project at https://gitlab.com/inolen/redream it's basically just a support forum. Anyone got any more details on this? Is this an attempt to monitise the work?
Small anecdote: many years ago I tracked down a working Dreamcast and acquired Sonic Adventure 2, arguably one of the best SEGA games ever created. At the time, I remember spending $40 for a used copy of the game that was now a decade old. After just scanning eBay, it looks like SA2 for Dreamcast is still selling for between $20-$70/ each. Incredible.
Other side note: one flaw of the original Dreamcast was that the circuit board that houses the controller ports had a capacitor that would occasionally fail. To the uninitiated, the console would become a brick since you can't play without a controller. I used to buy large sets of "broken" Dreamcasts, and could usually fix more than half of them by simply swapping internal components. I miss the days of this level of modding. Though the OG Xbox was pretty fun too in this hacking space.
People do a surprising amount of repair and combining multiple broken ones into a working one with modern systems like the Switch too. (swap screens, fix broken connectors, ...)
Impressive stuff, this will be massive for archive efforts. I am still yet to find a good performance emulation experience for the Play Station 2 console.
PS2 is legitimately really hard. It's both just fast enough that cycle accurate is off the table and probably always will be on conventional processors, and is just barely old enough that it has tons of little special instruction streams that need to be in close sync with each other, sometimes without explicit synchronization in their code.
PCSX3 exists, now, and while I understand the underlying complexities of the PS2’s architecture, I am very curious about the challenges, in particular, of PS3 emulation, especially with regards to the Cell processor.
Anyone with more knowledge that myself with regards to emulation care to chip in? I’d love some insight, or related articles.
Saturn emulation has been a fascination of mine for 15-some years.
There are three killers here: self-modifying code, synchronisation, and parallelism, all of which are major headaches for a JIT.
The PS3 does not have self-modifying PPC code (SCEI forbade it), which means the PPE blob can be compiled ahead-of-time (RPCS3 converts it into LLVM). The SPE data can self-modify, however, but (to my knowledge) does not require extensive synchronisation, therefore each SPE core can be put on a thread.
The PS2 code has fairly extensive use of self-modifying code; Naughty Dog in particular will frequently load parts of the executable in and out of memory on both the PS2 main processor (the EE) and the PS1 processor (the IOP), and rely on the synchronisation between these two separate processors to be fairly tight. Trying to make the EE and IOP separate threads running simultaneously breaks this synchronisation, so the EE and IOP have to run on the same thread.
Additionally, the PS2 has two vector units; VU0 is associated with the EE (it can be used as a floating-point SIMD unit in the EE instruction stream) and VU1 is associated with the GS [the PS2's GPU, the Graphics Synthesizer] Interface (GIF) (it can directly output primitives to the GS). This means that VU0 needs to run on the same thread that the EE runs on (because there is instruction stream interlocking), and VU1 needs relatively tight synchronisation to the GS (it is feasible to put it on its own thread, but games can be quite picky with timings)
Sony did manage to ship a PS2 emulator that ran on the second-generation PS3 though (1st generation PS3 had actual PS2 hardware inside, but the second generation was software-only emulation if I recall correctly?). Besides knowing exactly about every hardware detail, any idea how they pulled that off on hardware that was much weaker relative to a PS2, compared to a modern PC?
So I guess there's a couple levels to emulation where the answer is different in each.
For sort of 80/20 compat the PS2 is easier. You can HLE a couple of the processors, the GPU side of things is from the fixed function days, and has a split VRAM like your PC. The PS3 also has a nasty habit of making the SPEs make up for the anemic GPU and what would traditionally be pixel shader post processing tasks.
For Dolphin level full compat, IMO the PS3 is easier. The complexity memory subsystem and just plain number of jobs in flight meant that synchronization was very explicit between the components, as you couldn't really get away with "I'm just going to assume some happens before relationship is valid because I counted the requisite number of cycles". So you can rely quite a bit more as an emulator author that the game authors will make their intentions clearer. There's also more legacy in the PS2; the IO processor is itself a full PS1, that's how backwards compat worked. So you're really looking at all the work to make two emulators in one.
Are you maybe actually refereeing to RPCS3? If not, check it out. Their progress reports contain a lot of interesting technical details on the PS3 and its emulation: https://rpcs3.net/blog/
Yeah, I forgot about that; they aren't 754. I'd be curious to see what a modern JIT taking some cues from dynamic language VMs that have multiple internal primitive formats hidden from the guest code like V8 could do with that. It'll never be 1 to 1, but I could see it getting pretty damn close.
On my relatively modern machine the emulation is everywhere - sound is off, emulation running 1.25 times slow-down. Graphics are all over the place in terms of quality. I can't play many of the high-end games (at the time) reasonably.
Try emulating any of the "Need For Speed" games, which made tonnes of use of graphics tricks.
That said I do appreciate their efforts, it's just we're still a way off until it could be considered complete.
Luckily the PS2's still hanging on at the edge of "pretty easy to play with real games and real hardware", outside a handful of very expensive games. And the discs aren't old enough that tons of them have been lost to damage and rot yet, though I've seen several of mine rot to death in the last 5 years or so, even always being stored indoors, so that's changing fast. By 2025 I expect this to have joined most of the consoles before it in being easier to get an OK experience through emulation than to play on real hardware.
Timing remains my main problem with emulation. Input and output lag have gotten really bad and so hard to predict until you start actually messing with the equipment you'll be using, and even then little config quirks or the way things are hooked up (adding a receiver to the mix, for instance) can throw it all over the place. Lots of games become unplayable or unreasonably hard with just a little extra lag, so it's a real problem.
Not only that, but it's easy to set up loading games from a hard drive with a broadband adapter and memory card exploit. From there, you can rip your own games or download rips and load to the external hard drive and play that way.
Have you tried a recent build? 1.4.0 is pretty outdated by now, and it's also worth noting that the snapshot currently in Debian/Ubuntu is significantly broken.
Not for a few months, but it was out of the Ubuntu repo. If that's the case I'll give it another go, you would hope it improves after all. Thanks for the heads up.
For most games, VU borrowing "cycles" from CPU can help a great deal, so can enabling the threading. The defaults are the most compatible, but also slowest.
Also, GSDX is the only gpu plugin that works semi-decently, and only with actual DirectX. Opengl is all over the place.
Most games work fine even on a ten year old computer, with these settings, as long as you're on Windows.
Linux support could be better, but there's no manpower for that. It is kept alive by one or two developers who use Linux, most of the team being on Windows.
It's not open source, though. That means whatever improvements for preserving Dreamcast games will be taken to the author's grave. A lot of emulator development revolves around people sharing knowledge about how things work and making incremental improvements.
Taken to an extreme, if you were trying to fully map out a system from top to bottom for the explicit purpose of preservation like byuu's higan[1], it would make no sense to keep the source closed. There's an article[2] describing his request for help mapping the SNES PPU at the transistor level for the purpose of perfectly emulating it. The kind of effort moving in the direction of preseration requires is nontrivial and open source would be a massive benefit. And if there are any flaws there's no need to rely on the motivations of a single contributor to fix them.
I don't believe such a goal is compatible with a profit motive.
SEGA’s level of innovation here was extreme.
From great developer support, online play (even if the Broadband Adapter for Ethernet was extremely rare); the VMU, and an extremely impressive library of quality titles (Skies of Arcadia, Crazy Taxi, Soul Calibur 2, etc) - it was literally a situation that seemed geared to greatness.
If it had a DVD player, I think it literally could’ve saved SEGA, after the awful litany of repeated terrible decisions they made in the mid-90’s. (Here’s looking at you, 32X...)
I was just at A&C games here in Toronto, lamenting to an employee of the demise of SEGA’s consoles - but the Dreamcast, in particular, deserved better than it got.
The Saturn will always have a special place in my heart, though, as an extremely early example of multi-processor architecture (the Saturn technically has 7 processors, each for a different task - 2 GPU’s, CD I/O, sound, etc.)