Those DIN connectors were used in the "Ueberspielkabel" of my childhood. Germany decided to use 5 pin DIN as stereo cables, two in two out with one ground.
Speaking of: I just discovered that newly manufactured keyboards with PS/2 keyboard interfaces are now an oddity. I should have bought some "gaming keyboards" with PS/2 interfaces five years ago.
Newly manufactured true AT and PS/2 keyboards were rare even 20 years ago. The cheap keyboards from even that time implement only the subset of behavior of true AT keyboard required for PC with OS that leaves the hardware in PC-like state. These keyboards tend to confuse the hell out from various 90's RISC workstations (SGI, DEC…) that also use PS/2 interface.
https://www.reddit.com/r/TheMakingOfGames/ is about getting material like that in front of viewers who appreciate it. It's rare material. So, contributions are always welcome.
Thank you for sharing Shmuplations. It’s an absolute treasure trove of (to me) unknown interviews with Japanese game designers from the past 40 years. I’m delighted.
I agree, FF7 was a long long time ago, but the warnings are still nice and appreciated. New people are born, grow up, and get introduced to old things after all.
Plus, some gamers are always playing a decade or two behind since prices become dirt cheap, games get re-released in more complete forms without a need for buying a bunch of DLC to access the parts they paywalled off, and most of the bugs and crashes will be patched out.
The remake by the way is brilliant in it's own right.
The team made comments around making something sufficiently different that it wouldn't be seen as trying to replace the original, but that could sit alongside it as a retelling of the story. I think they absolutely nailed it in this regard and if anything, finishing FF7R has me wanting to play through the original all over again.
Even at that, I wouldn't expect the spoiler we're talking about from the article to happen the same way in Rebirth, or possibly even at all. It's too good of an opportunity to surprise people that I think they take a dramatically different direction (my guess would be on the same story element happening featuring another major character, but this seems like lazy writing).
"In my mind, I view emulators as a sort of converter in and of themselves, ones that primarily take orders designed for old processors and translate them into ones that the new target processor can understand and execute. In that sense, even if sound and graphics hardware have their fair share of differences, in the end, they’re both still fundamentally sending commands. All an emulator is doing is changing the shape and flow of those commands. So long as an emulator is fully tested, it should all work out in the end, even if that’s obviously the really tough part in practice."
Sadly, that is the most technical part of the essay. The rest of it is just anecdotes. They talk briefly about a Crash Bandicoot freezing issue just before launch, which they got around by trying to play the game repeatedly: "All I could figure out was that as long as Crash kept moving, the game remained stable for whatever reason."
Crash Bandicoot was developed at Naughty Dog back when Naughty Dog was a a hardcore software development house. They routinely did clever, not-quite-kosher bullshit like unload parts of Sony's graphics library to free more RAM. If the backwards-compatibility people took an HLE approach and assumed the graphics library was a constant in memory, I can see the emulation going totally sideways. It could probably go sideways for a bunch of other reasons too.
Before they were really pushing the envelope from an execution perspective, delivering different types of games with quality and features we really haven't seen before. Today they're riffing on The Last of Us, their "state of the art game engine" an extended version of the one they used for Uncharted. Their last major release was... a remaster of The Last of Us. And there were huge problems with the production of The Last of Us 2.
It's been known that ND haven't been doing anything with GOOL or GOAL since the end of the Jak & Daxter era, around the time that Andy Gavin left. But the programmers there were still using Racket to generate data, scripts, and glue code for their new engine well into the era of TLOU. My conspiracy theory regarding TLOU's third remaster/rerelease is that it happened in significant part because they wanted to get rid of the Racket bits so that they could focus on hiring average developers from a large talent pool to execute on Druckmann's auteur-wannabe vision. Retconning Ellie to not look like Elliot Page and promotion for the HBO series were also factors, but I think the focus at ND has changed to becoming Yet Another Generic Game Studio, and managing the TLOU IP.
All state of the art game engines are multi-game iterations because the number of features and complexity is so large that it cannot be done for a single game any more
Fascinating read, even if not very technical. That type of deep work must be a joy to do. Wonder if there are still places where one might get a chance to work like that, specifically on “low level” stuff
It's wild how often these "this was my first development job of any kind" stories crop up in the gaming industry. This seems like a deeply technical project requiring expertise in some very niche areas. Yet Sony trusted this fresh grad with zero experience to knock out one of their marquee features essentially on his own... and it worked??
I don't have any evidence for this but I feel like things used to work more this way in the future. Now we send everything to experts, people with licenses and degrees and years of experience. And I mean it works, but we pay in terms of lost creativity, and create fewer opportunities for younger and lesser experienced people to become experienced themselves.
Low-level programming isn't that hard if you've got all the docs. Hard part of emulator development is when you have to figure out everything yourself.
Also, as part of backward compatibility the PS2 just has a miniature PS1 in it, so the hardware is fundamentally able to do the old things.
In my humble opinion, the PS2 is the best retro console for tinkering.
So many of them were sold, they can be had cheaply, lots of aftermarket stuff for them (HDD/Network adapter), Crazy huge library of weird and interesting titles, vibrantly active homebrew community. And of course, the built-in backwards compatibility. Several interesting hardware revisions to play with as well (although the "fat" ones are the most moddable).
Xbox being basically a PC is interesting considering 20+ years later there is still no great emulator for it. xemu plays about 3% of games without minor issues.
I would agree, which is why a PS2 is on my list of consoles to acquire at some point, but it does have one significant nit: there is easily available no digital video output mods for them, which makes getting a decent picture out of them a challenge unless you already have a suitable CRT to pair with it.
720p/1080i CRT's can be had - I have a late model Sony Wega 36" I snagged for $30.
I've used component cable as well as one of those HDMI adapters which are powered off USB - and it's not that much different with my CRT. Maybe it makes more of a difference with an LCD.
You don't really need a CRT, any television with a RCA or S-video input would work. If you track down the component video cable (kinda pricey and rare) you can use that too. Most of the LCD TVs at least of the 2010s still had those analog inputs. I'd be surprised if you didn't get at least a RCA input on most new TVs today.
It's not so much a matter of it working as it is the picture looking acceptable. A friend brought over and hooked their PS2 up to my LCD TV in the past with component cables and it looked terrible compared what I remember from PS2s hooked up to CRT TVs back in high school. The built in PS1 emulation on a PS3 through HDMI looks way, way better on the same TV.
Prices of playstation and playstation 2 stuff is going up fast in my experience. Ten years ago I was regularly finding ps2s in goodwill and thrift stores for dirt cheap (slim ps2 hardware for 10-15 bucks). Nowadays you only find them in used game stores behind glass cases with $100+ price tags. Get them now if you see a deal IMHO, they will never get cheaper. Same story for the good software/games of that era, it's hitting the point where rare stuff is going for hundreds of dollars and people are paying it.
As far as modding goes, keep an eye out for one of a handful of games with exploits like one of the 007 James Bond games. There's a software mod exploit you can run that turns a memory card into a mod device effectively, no hardware changes necessary. It's a little fiddly but works great and you just do it once and are good to go playing burned backups, homebrew, etc.
The GameCube is pretty sweet these days with PicoBoot + SD2SP2 + Swiss. Don't forget the Game Boy Player either. If you get a DOL-001 model (has the digital video port) you can also very easily get a good image out of it with an external HDMI adapter. It's arguably the best way to play GBA games.
> All an emulator is doing is changing the shape and flow of those commands.
Maybe if you're SIMH and you're emulating an old CPU that was connected asynchronously to like RS232 peripherals. But I think this statement understates the complexity of emulating something like a console.
Emulating a console or home computer, or even something like an old console's GPU, is HARD because you have to do these translations in a bug-for-bug compatible way, with strict timing constraints -- for the system's many components -- and you have to take into account the raster nature of CRT displays, which allowed for changing the display in significant ways between frames or scanlines.
There's a reason why emulation is these days usually only undertaken by some of the strangest most terminally online people, and it can take even them decades to get the details right. Of course, this engineer worked at Sony and probably had the benefit of being able to talk to the developers of the graphics chip he was emulating, but that's still a daunting task.
> ou have to do these translations in a bug-for-bug compatible way, with strict timing constraints -- for the system's many components
Not only that, but you need to catch the way the hardware is accessed on the emulated console by generating a fault or trap, then rearrange everything for the actual hardware, and then pass control back to the emulated code on a processor that had, IIRC, no provision for hardware assisted virtualization.
I used to really enjoy byuu's detailed articles on the matter. They effectively demonstrated the effort necessary to accurately reproduce the behavior of these machines.
> the raster nature of CRT displays, which allowed for changing the display in significant ways between frames or scanlines
In case anyone would like to know more, this is a really good explanation of these concepts:
> There's a reason why emulation is these days usually only undertaken by some of the strangest most terminally online people
They could be perfectly normal people for all we know... A few days ago I saw a comment here from someone who worked with an emulator developer. Only revealed that fact to him after 4 years working together.
The PS1 GPU is a bit easier than something like the the SNES to get to the compat to meet their goals since it really doesn't encourage 'racing the beam' style techniques. It's a more modern design which runs scanout asynchronously from drawing using a relatively large VRAM buffer between them. For anything other than emulating absolute batshit demoscene level code, you can get away with just being in the right ballpark for how long drawing a frame takes. And apparently they were OK with blacklisting a few of the problem titles.
51 comments
[ 2.1 ms ] story [ 73.8 ms ] threadSpeaking of: I just discovered that newly manufactured keyboards with PS/2 keyboard interfaces are now an oddity. I should have bought some "gaming keyboards" with PS/2 interfaces five years ago.
Did You Know Gaming?: https://www.youtube.com/@DYKGaming/videos Shmuplations: https://shmuplations.com/
In both cases, I think enough time has passed :-)
Plus, some gamers are always playing a decade or two behind since prices become dirt cheap, games get re-released in more complete forms without a need for buying a bunch of DLC to access the parts they paywalled off, and most of the bugs and crashes will be patched out.
The team made comments around making something sufficiently different that it wouldn't be seen as trying to replace the original, but that could sit alongside it as a retelling of the story. I think they absolutely nailed it in this regard and if anything, finishing FF7R has me wanting to play through the original all over again.
Even at that, I wouldn't expect the spoiler we're talking about from the article to happen the same way in Rebirth, or possibly even at all. It's too good of an opportunity to surprise people that I think they take a dramatically different direction (my guess would be on the same story element happening featuring another major character, but this seems like lazy writing).
Very excited for the next entry regardless.
Sadly, that is the most technical part of the essay. The rest of it is just anecdotes. They talk briefly about a Crash Bandicoot freezing issue just before launch, which they got around by trying to play the game repeatedly: "All I could figure out was that as long as Crash kept moving, the game remained stable for whatever reason."
I still want to know what was wrong with Crash Bandicoot.
https://all-things-andy-gavin.com/video-games/making-crash/
they have their own state of the art game engine with cutting edge features
It's been known that ND haven't been doing anything with GOOL or GOAL since the end of the Jak & Daxter era, around the time that Andy Gavin left. But the programmers there were still using Racket to generate data, scripts, and glue code for their new engine well into the era of TLOU. My conspiracy theory regarding TLOU's third remaster/rerelease is that it happened in significant part because they wanted to get rid of the Racket bits so that they could focus on hiring average developers from a large talent pool to execute on Druckmann's auteur-wannabe vision. Retconning Ellie to not look like Elliot Page and promotion for the HBO series were also factors, but I think the focus at ND has changed to becoming Yet Another Generic Game Studio, and managing the TLOU IP.
Also, as part of backward compatibility the PS2 just has a miniature PS1 in it, so the hardware is fundamentally able to do the old things.
So many of them were sold, they can be had cheaply, lots of aftermarket stuff for them (HDD/Network adapter), Crazy huge library of weird and interesting titles, vibrantly active homebrew community. And of course, the built-in backwards compatibility. Several interesting hardware revisions to play with as well (although the "fat" ones are the most moddable).
Xemu has had a lot of work put into it recently though, and is a lot further along.
I've used component cable as well as one of those HDMI adapters which are powered off USB - and it's not that much different with my CRT. Maybe it makes more of a difference with an LCD.
As far as modding goes, keep an eye out for one of a handful of games with exploits like one of the 007 James Bond games. There's a software mod exploit you can run that turns a memory card into a mod device effectively, no hardware changes necessary. It's a little fiddly but works great and you just do it once and are good to go playing burned backups, homebrew, etc.
If you have a HDD adapter you can just image it and chunk it right in with no FreeMcBoot.
Maybe if you're SIMH and you're emulating an old CPU that was connected asynchronously to like RS232 peripherals. But I think this statement understates the complexity of emulating something like a console.
Emulating a console or home computer, or even something like an old console's GPU, is HARD because you have to do these translations in a bug-for-bug compatible way, with strict timing constraints -- for the system's many components -- and you have to take into account the raster nature of CRT displays, which allowed for changing the display in significant ways between frames or scanlines.
There's a reason why emulation is these days usually only undertaken by some of the strangest most terminally online people, and it can take even them decades to get the details right. Of course, this engineer worked at Sony and probably had the benefit of being able to talk to the developers of the graphics chip he was emulating, but that's still a daunting task.
Not only that, but you need to catch the way the hardware is accessed on the emulated console by generating a fault or trap, then rearrange everything for the actual hardware, and then pass control back to the emulated code on a processor that had, IIRC, no provision for hardware assisted virtualization.
> the raster nature of CRT displays, which allowed for changing the display in significant ways between frames or scanlines
In case anyone would like to know more, this is a really good explanation of these concepts:
https://youtu.be/Q8ph2OVqZeM
> There's a reason why emulation is these days usually only undertaken by some of the strangest most terminally online people
They could be perfectly normal people for all we know... A few days ago I saw a comment here from someone who worked with an emulator developer. Only revealed that fact to him after 4 years working together.