I'm excited by the possibility of being able to run classic games as native apps. Portable FPGAs are great (shoutouts to Analogue and FunnyPlaying), but if one created a buildchain where you...
I'm excited by the possibility of being able to run classic games as native apps. Portable FPGAs are great (shoutouts to Analogue and FunnyPlaying), but if one created a buildchain where you could, say, take a Gameboy game and recompile it on your Steam Deck as easily as loading a ROM, that would be phenomenal. We aren't even at the compilable games being confirmably fully functioning, but this is still amazing, and the current state is a huge step towards game preservation and playability.
Emulation is in a great state, too, but I just find the idea of running games natively to be cool.
Recomps still require you to provide a ROM because all of the assets in the games are still subject to copyright. If anything they are less convenient than emulators. That is assuming you are not...
Recomps still require you to provide a ROM because all of the assets in the games are still subject to copyright. If anything they are less convenient than emulators.
That is assuming you are not talking about companies producing these and selling them as new games.
I'm talking about something like even a Decky extension, or some desktop GUI for enthusiast use. Of course you need the rom, but some projects, like the Harbour Master stuff, makes it dead easy to...
I'm talking about something like even a Decky extension, or some desktop GUI for enthusiast use.
Of course you need the rom, but some projects, like the Harbour Master stuff, makes it dead easy to manage the process of extracting the data by having a drag-and-drop or simple command with the rom as an argument (Linux is the exception here, soh.appimage oot_name.z64 to run the build).
I just did a build of Link's Awakening with this and it was pretty easy. But you do need a full build stack. In Debian I needed build-essential sdl2-dev cmake ninja-build, so you'd need the standard stack for any other OS. It did take a minute or so to link the last two blocks while compiling, but it was still pretty quick.
Assuming this could be made to run every game 100% OOTB on build (I did a run with Link's Awakening that crashed after five minutes), you could at least eliminate the overhead of emulation and any...
Assuming this could be made to run every game 100% OOTB on build (I did a run with Link's Awakening that crashed after five minutes), you could at least eliminate the overhead of emulation and any input latency it provides which could, theoretically, help with things like high-level Tetris, and the few other games that would benefit. You're still subjected to input processing + LCD latency, but it's one more small point of potential optimization. You can remove some of this overhead with emulators, like Retroarch, but this requires running multiple instances of the emulator which even causes issues with 8-bit system emulation efficiency.
But like 90% of the thought is because I just think it would be cool.
I didn't even know we were doing PS2 recomps to any extent, I have some games I need to try it on that are notoriously difficult to emulate, but don't, to my knowledge, use extended hardware.
I didn't even know we were doing PS2 recomps to any extent, I have some games I need to try it on that are notoriously difficult to emulate, but don't, to my knowledge, use extended hardware.
Wait... what? I didn't know we were talking about the PS2. The Z80 was a processor used in things like the original GameBoy or the TI-83 calculator we all used in highschool, and people continue...
Wait... what? I didn't know we were talking about the PS2.
The Z80 was a processor used in things like the original GameBoy or the TI-83 calculator we all used in highschool, and people continue to use to this day because Texas Instruments has government contracts that mean they never have to upgrade their shit, which means you can still find a Z80 processor being made today for about four bucks, despite it being a 45+ year old part.
Zilog actually recently discontinued the Z80. They recommend the Z800 for new designs. Even if they hadn’t it would be doubtful that any single product line could keep an IC in perpetual production.
Zilog actually recently discontinued the Z80. They recommend the Z800 for new designs.
Even if they hadn’t it would be doubtful that any single product line could keep an IC in perpetual production.
Nah, a chip as popular as the Z80 or the 6502 or the 8086 etc will have enthusiasts who sketch out every single logic gate on paper if they have to. Then they can reimplement it on a FPGA or...
Nah, a chip as popular as the Z80 or the 6502 or the 8086 etc will have enthusiasts who sketch out every single logic gate on paper if they have to. Then they can reimplement it on a FPGA or whatnot.
The Z80 has definitely been reverse-engineered to such a point as clones are 100% accurate.
Honestly, fuck Zilog, their CPU design has been known since the early 80's, it's basically open-source at this point. It's like 8086 without the 6.
Yes, the Z80 is a well known archetechture, down to the differences between implementations on different manufacturing processes even. But as far as I'm aware, there is no direct drop-in...
Yes, the Z80 is a well known archetechture, down to the differences between implementations on different manufacturing processes even. But as far as I'm aware, there is no direct drop-in replacement for it.
In any case it's not like those calculators are using the original Z-80. According to Claude, they swapped it with a different software-compatible processor in the late 90s and the later ones have them built into an ASIC.
The discussion seems a bit abstract to me, given that we're discussing the Game Boy. The Game Boy's CPU isn't a Z80. It's a custom design, not even binary compatible with the Z80. "Z80" in the OP...
The discussion seems a bit abstract to me, given that we're discussing the Game Boy. The Game Boy's CPU isn't a Z80. It's a custom design, not even binary compatible with the Z80.
"Z80" in the OP link is a bit of a misnomer. That's fine if that's what the community decided to call it, but you shouldn't conflate the longevity of the Game Boy "Z80" with that of the Zilog Z80. I don't imagine the GB CPU was in production after the Game Boy.
Within the DMG-CPU, the main processor is a Sharp SM83,[25]: 15 a hybrid of the Intel 8080 and Zilog Z80 processors. It combines the seven 8-bit registers of the 8080 (omitting the alternate registers of the Z80) with the programming syntax and additional bit manipulation instructions of the Z80. The SM83 also includes new instructions optimized for operations specific to the Game Boy's hardware arrangement.[7][26][27] It operates at a clock rate of 4.194304 MHz.[25]: 12
We've even got attempts at PS3 and Xbox 360. PS3 has successfully done flow, 360 has several playable titles. https://github.com/sp00nznet/ps3recomp https://github.com/sp00nznet/360tools
We've even got attempts at PS3 and Xbox 360. PS3 has successfully done flow, 360 has several playable titles.
I'm excited by the possibility of being able to run classic games as native apps. Portable FPGAs are great (shoutouts to Analogue and FunnyPlaying), but if one created a buildchain where you could, say, take a Gameboy game and recompile it on your Steam Deck as easily as loading a ROM, that would be phenomenal. We aren't even at the compilable games being confirmably fully functioning, but this is still amazing, and the current state is a huge step towards game preservation and playability.
Emulation is in a great state, too, but I just find the idea of running games natively to be cool.
Recomps still require you to provide a ROM because all of the assets in the games are still subject to copyright. If anything they are less convenient than emulators.
That is assuming you are not talking about companies producing these and selling them as new games.
I'm talking about something like even a Decky extension, or some desktop GUI for enthusiast use.
Of course you need the rom, but some projects, like the Harbour Master stuff, makes it dead easy to manage the process of extracting the data by having a drag-and-drop or simple command with the rom as an argument (Linux is the exception here, soh.appimage oot_name.z64 to run the build).
I just did a build of Link's Awakening with this and it was pretty easy. But you do need a full build stack. In Debian I needed
build-essential sdl2-dev cmake ninja-build, so you'd need the standard stack for any other OS. It did take a minute or so to link the last two blocks while compiling, but it was still pretty quick.Can you explain why having the game on your Steam Deck like that is better than just running the ROM in an emulator? I'm curious
Assuming this could be made to run every game 100% OOTB on build (I did a run with Link's Awakening that crashed after five minutes), you could at least eliminate the overhead of emulation and any input latency it provides which could, theoretically, help with things like high-level Tetris, and the few other games that would benefit. You're still subjected to input processing + LCD latency, but it's one more small point of potential optimization. You can remove some of this overhead with emulators, like Retroarch, but this requires running multiple instances of the emulator which even causes issues with 8-bit system emulation efficiency.
But like 90% of the thought is because I just think it would be cool.
Thanks for that.
Writeup on Retrohandhelds.gg
https://retrohandhelds.gg/game-boy-roms-go-native-with-new-static-recompiler/
I didn't even know we were doing PS2 recomps to any extent, I have some games I need to try it on that are notoriously difficult to emulate, but don't, to my knowledge, use extended hardware.
Wait... what? I didn't know we were talking about the PS2.
The Z80 was a processor used in things like the original GameBoy or the TI-83 calculator we all used in highschool, and people continue to use to this day because Texas Instruments has government contracts that mean they never have to upgrade their shit, which means you can still find a Z80 processor being made today for about four bucks, despite it being a 45+ year old part.
Zilog actually recently discontinued the Z80. They recommend the Z800 for new designs.
Even if they hadn’t it would be doubtful that any single product line could keep an IC in perpetual production.
Nah, a chip as popular as the Z80 or the 6502 or the 8086 etc will have enthusiasts who sketch out every single logic gate on paper if they have to. Then they can reimplement it on a FPGA or whatnot.
The Z80 has definitely been reverse-engineered to such a point as clones are 100% accurate.
Honestly, fuck Zilog, their CPU design has been known since the early 80's, it's basically open-source at this point. It's like 8086 without the 6.
Yes, the Z80 is a well known archetechture, down to the differences between implementations on different manufacturing processes even. But as far as I'm aware, there is no direct drop-in replacement for it.
In any case it's not like those calculators are using the original Z-80. According to Claude, they swapped it with a different software-compatible processor in the late 90s and the later ones have them built into an ASIC.
The discussion seems a bit abstract to me, given that we're discussing the Game Boy. The Game Boy's CPU isn't a Z80. It's a custom design, not even binary compatible with the Z80.
"Z80" in the OP link is a bit of a misnomer. That's fine if that's what the community decided to call it, but you shouldn't conflate the longevity of the Game Boy "Z80" with that of the Zilog Z80. I don't imagine the GB CPU was in production after the Game Boy.
Indeed:
(wikipedia)
There's a mention in the article that calls out N64 (Harbour Masters, and others) and PS2 (PS2Recomp) de/recompilation projects.
We've even got attempts at PS3 and Xbox 360. PS3 has successfully done flow, 360 has several playable titles.
https://github.com/sp00nznet/ps3recomp
https://github.com/sp00nznet/360tools