[HN Gopher] OpenFPGA. The future of video game preservation
___________________________________________________________________
OpenFPGA. The future of video game preservation
Author : _benj
Score : 199 points
Date : 2024-02-11 11:16 UTC (1 days ago)
(HTM) web link (www.analogue.co)
(TXT) w3m dump (www.analogue.co)
| junaru wrote:
| So how is this different from MiSTer FPGA [1]?
|
| [1] https://mister-devel.github.io/MkDocs_MiSTer/
| multiplied wrote:
| You can't carry a MiSTer in your Pocket, but you can Dock a
| Pocket.
|
| It doesn't support a few power-hungry systems supported by
| MiSTer.
|
| MiSTer doesn't support OG physical carts.
| fayalalebrun wrote:
| What about the actual FPGA specs? Is it more power efficient
| per LUT? A newer generation or the same generation but a
| smaller chip?
| ndiddy wrote:
| The Pocket has an FPGA from the same series as the MiSTer,
| but it's a lower-end model that's optimized more for power
| consumption. Most notably, it's missing the 800 MHz ARM
| core (meaning that it runs a custom "OS" off of a
| microcontroller rather than Linux like the MiSTer), and it
| has a bit less than half the amount of logic elements. This
| means that 16-bit console emulation is about the highest
| you can go on the Pocket, while the MiSTer can emulate the
| Playstation, Saturn, and N64.
| paulhart wrote:
| I've pasted the specs below, but in my opinion the biggest
| difference is that the OpenFPGA - in its Analogue Pocket form -
| is an end-user friendly target. MiSTer is more "enthusiast-
| friendly" with more options and upgrades (including an
| recommended add-on to the basic kit).
|
| MiSTer "tech specs":
|
| Intel/Altera Cyclone V SE (5CSEBA6U23I7) FPGA SoC with
| 110,000LE (41,500ALM) and 5,570Kbit of Block RAM.
|
| ARM Cortex A9 dual-core CPU at 800MHz.
|
| HDMI video and audio allowing easy connectivity to any modern
| monitor/TV.
|
| 1GB of DDR3 RAM that is directly available to both ARM and
| FPGA.
|
| High-speed ARM <-> FPGA interconnect due to both being in the
| same chip.
|
| OpenFPGA specs:
|
| Intel/Altera Cyclone V FPGA 49K logic elements and 3.4Mbit BRAM
|
| Intel/Altera Cyclone 10 15K logic elements
|
| 2x independently addressable 16MB cellular RAM (128Mbit x 16)
|
| 32MB low latency memory 1x synchronous DRAM 64MB (32Mbit x 16)
|
| 1x asynchronous SRAM 256KB (128Kbit x 16)
| lagrange77 wrote:
| The name is a bit misleading.
| nereye wrote:
| It also seems to re-use the name of a (from what I can tell)
| separate project:
|
| https://github.com/lnis-uofu/OpenFPGA
|
| https://openfpga.readthedocs.io/en/master/
| q3k wrote:
| Yeah, it makes no sense. It's like naming a TV remote
| 'OpenMicrocontroller'.
| gchadwick wrote:
| I think it's a bit rich to describe this as the 'future of video
| game preservation'.
|
| The MiSTer project https://github.com/MiSTer-
| devel/Wiki_MiSTer/wiki more rightfully deserves that title. It's
| got a huge range of systems (across consoles, arcade and micro
| computers) and it's all GPL licenced. The base board is a Terasic
| DE10 Nano which is proprietary but all other hardware required is
| open source.
|
| The MiSTeX project aims to make MiSTer portable across different
| FPGA platforms https://github.com/MiSTeX-devel so a DE10 Nano
| won't be mandatory enabling a new ecosystem of open hardware and
| commercial for profit solutions.
|
| I take no issue with people wanting to make money in this space.
| I take great issue with trying to gatekeep system preservation
| behind a mostly closed system you stamp an 'open' moniker on.
| DrNosferatu wrote:
| Absolutely 0 mentions of the word "MiSTer" negatively impacts
| this "open" project.
|
| Their self-appraising pitch applies more to the MiSTeX project
| than themselves.
|
| [https://github.com/MiSTeX-devel]
| pipes wrote:
| Yeah but they seem to be suggesting no one has done fpga
| emulation before.
|
| (I'm biased, I love my mister!)
| jonhohle wrote:
| After DE-10 Nanos what up in price (likely due to MiSTer),
| there was rumblings that it was too tied to the hardware to
| be portable.
|
| I missed out when things were cheap and always assumed
| buying a board at the higher prices would be the trigger
| which caused the project to move to the next generation of
| hardware.
| pipes wrote:
| Yeah I paid the higher price unfortunately. The best
| thing about it is I don't spend all my time fiddling with
| settings like I do with software emulators.
| thrillgore wrote:
| Which is just rich, as Analogue takes advantage of preorders
| to limit hardware on a per-order basis, meaning they are
| always out of stock. Don't have this issue with the MiSTer.
| pbj1968 wrote:
| Five years ago the Mister people were similarly unable to STFU
| about raspberry pi's. Mister is still emulation, it still has
| tons of issues, and it's still $700 invested before you're
| actually playing games. Meanwhile we're in a golden age of RGB
| mods, flash carts, and optical drive emulators for original
| hardware.
| xqzv wrote:
| "FPGA is emulation"
|
| You can have any number of issues with Mister, but this is
| just flat out incorrect if you know the definition of either
| of those words.
| thehias wrote:
| Of course Mister uses emulation - there are only few chips
| in older arcade boards that truly can be simulated in FPGA
| with circuit-accuracy.
|
| The Mister SNES core has less accuracy like the software
| emulator bsnes, not all game work or there a bugs - they
| still "emulate" the hardware how they interpret it.
|
| FPGA is just a different way of "hardware emulation"
| instead of traditional "software emulators".
|
| The only real advantage of FPGA compared to software is the
| improved latency.
| vardump wrote:
| An FPGA can be 100% hardware perfect with practically no
| extra processing cost. The potential is there, even if
| it's not initially exploited.
|
| CPU based emulation will require a fairly powerful CPU
| just to emulate SNES. It's pretty expensive to emulate
| hardware in 180-190 ns increments.
| scientist4397 wrote:
| Not only, the ability to replicate hardware allow to
| render some effects that can't be render with software
| emulation. I'll try to find the video I saw on YT
| explaining that point.
| chungy wrote:
| > if you know the definition of either of those words
|
| Let's put that to the test, ok
|
| https://www.merriam-webster.com/dictionary/emulate
|
| 1a: "to imitate by means of an emulator"
|
| https://www.merriam-webster.com/dictionary/emulator
|
| 2: "hardware or software that permits programs written for
| one computer to be run on another computer"
|
| Yup, FPGA recreating other hardware definitely fits the
| bill of emulation. Granted, Analogue has played up a
| marketing spin that boxes in "emulation" to mean "software
| running on some generic CPU" in order to claim "no
| emulation", but it's just marketing doing the work of
| marketing.
| Gormo wrote:
| > Yup, FPGA recreating other hardware definitely fits the
| bill of emulation.
|
| It really doesn't. The FPGA actually _implements_ the
| target hardware, rather than using other hardware to
| produce equivalent behavior.
|
| That's not to say that no emulation is involved, as not
| all of the functionality is actually achieved through the
| FPGA, but where it is, it's perfectly valid to
| distinguish it from emulation.
| naikrovek wrote:
| FPGAs are reimplementations, to me, not emulation. But I
| don't begrudge anyone who wants to be a stickler on the
| definition of "emulation".
|
| Even the original hardware "emulates" a game if you want
| to get down to it.
| markemer wrote:
| That's how I see it too. The FPGA version are knock offs,
| like would have been done back in the day but with fancy
| future hardware. A gate level reproduction would be kinda
| strange aside from pure desire for preservation. (Which
| is still a decent goal, just not of these projects)
| cacois wrote:
| So your argument is that its closer to virtualization,
| than to emulation?
| Gormo wrote:
| Not really. And I'm not sure the concept of
| virtualization makes sense when applied to hardware in
| the first place.
|
| The FPGA is _actually implementing_ the hardware. It 's
| like using a newly manufactured edition of the original.
| fourfour3 wrote:
| The FPGA is used to implement an approximation of the
| original hardware's functionality - not a perfect clone
| of the original hardware itself, which means they have
| their own unique bugs and inaccuracies compared to the
| original designs.
|
| I think "emulation" fits as a reasonable description of
| this, personally - at least as something an average
| person will understand.
| BearOso wrote:
| It doesn't implement the original hardware. It's not copy
| of the original chip. Reverse engineering is used to get
| the _behavior_ of the hardware. They reproduce the inputs
| and outputs with Verilog and write it to an FPGA.
|
| If it weren't emulation, they would decap the original
| chip and directly copy the chip, gate-by-gate. It could
| be done, but it hasn't been done that way anywhere to
| date.
| mburns wrote:
| WINE fits that definition but is generally considered to
| be Not Emulation in a technical (if not colloquial)
| sense.
| armada651 wrote:
| It depends on your interpretation of the definition. If
| the two "computers" that the webster definition is
| referring to have a different architecture, then Wine
| does not fit that definition, because Wine relies on the
| fact that it's the same computer architecture, namely an
| x86 PC.
|
| If you combine Wine with Rosetta to run Windows programs
| on an M1 Mac, then it _is_ definitely emulation by any
| definition. But then it 's not Wine that's doing the
| emulation, it's Rosetta.
| jtvjan wrote:
| They may have read this article written by Near arguing
| that FPGA-based products are still (hardware-based)
| emulation: https://archive.is/fWosI
|
| It's a well-written article, and presents a balanced view.
| Its stance is against the idea that FPGA-based emulation is
| always better than CPU-based emulation.
| pipes wrote:
| That is a fantastic read. Thanks.
| BearOso wrote:
| There's no circuit-level reproduction happening anywhere
| yet, it's basically emulation with a hardware clock.
| Analogue and kevtris know that FPGA isn't magic. Rather
| than contribute to the knowledge pool, like the MiSTer
| project, they're being bad actors and trying to muddle
| the situation to make money off of it. Near was trying to
| clarify the situation, but now we see where good
| intentions gets you.
| armada651 wrote:
| The argument being made is that the distinction between an
| FPGA and CPU is irrelevant to determine whether something
| is emulation.
|
| An emulator accelerated by an FPGA is still an emulator and
| a CPU simulating a console at the circuit level is no
| different in accuracy than an FPGA doing the same thing.
|
| The main difference is the experience, where the FPGA can
| offer an experience closer to the original than a CPU
| running an operating system can, especially for older
| consoles. Not because of a difference in emulation
| accuracy, but because the user experience is different.
| belthesar wrote:
| While I'm a strong supporter of your position that the MiSTer
| (and any FPGA console implementation) is still emulation,
| it's worthwhile to keep in mind that this will indeed be _a_
| future for preservation (unsure about it being the only, and
| warmer to, but not sold on it being the best way).
|
| Original hardware is great, but it's getting older, and
| failing. The Super Nintendo / Super Famicom, for instance,
| uses a ceramic oscillator as a clock source for its sound
| processing unit, and as the console is designed, the sound
| clock is essential for keeping the entire system in sync.
| Members of the Tool Assisted Speedrunning community have been
| experimenting with parts replacements to resuscitate this
| clock source with only mixed successes. This is one of many
| pieces of silicon on these old platforms that will continue
| to fail as time goes on.
|
| We can't make brand new classic consoles because the parts
| are just unavailable, and the industry has a well trodden
| path of reimplementing discrete electronics in FPGA for
| decades now with great success. If your goal is to keep
| playing games for a while longer on your OG console, then
| heck yeah, go for it. It does indeed do the thing. But if we
| want to be able to preserve this history in as close to the
| original form factor and play environment as possible, then
| we have to explore other options, and FPGA system cloning is
| a grand way to do this.
| AlienRobot wrote:
| I think the most worrying thing about emulating old
| consoles by reverse-engineering them is that you're running
| out of time to test it. Say for example that the original
| Luigi looks blue in the hardware it was made for, but in an
| emulator he looks green. If there are no original NES left,
| you will never be able to know the emulator's code doesn't
| match how the NES actually worked. From that point on, the
| emulator experience is as canonical as it gets.
| incrudible wrote:
| Different NES revisions actually output different colors.
| Plus, _originally_ it 's an RF signal, then composite. It
| was displayed on some CRT. It's possible to RGB mod an
| NES, but is that authentic? No.
|
| The one true color of Luigi is the one that you saw as a
| child on a sunday afternoon in the eighties. Lost in
| time, like tears in rain.
| vardump wrote:
| My MiSTer FPGA was about $200 before I was playing games.
| $700 is either hyperbole or have DE10 Nano board prices
| really gone up THAT much?
|
| After DE10 Nano, you need just a RAM module and a I/O board
| and you're ready to go.
| dark-star wrote:
| I wish people would stop treating FPGAs as the Second Coming of
| the Lord or whatever. It is really not.
|
| It's emulation, plain and simple. Not bettero or worse than
| software emulators. It usually lags behind the pure software
| emulators because there are fewer devs and because emulating
| stuff in hardware is harder than emulating stuff in software.
|
| Just because it's in hardware doesn't mean that it is "better" or
| "more accurate".
| grapescheesee wrote:
| Isn't it hardware emulation, built with software?
| 15457345234 wrote:
| You're getting into the weeds and will get different answers
| based on semantics, here.
|
| A FPGA emulation isn't inherently better than a CPU-based
| emulation of any given chip; it's not more authentic because
| it still lacks the particular quirks of any old CPU that are
| associated with the way the hardware was laid out, path
| lengths, imperfections etc.
|
| I'm glad it's introducing FPGA programming to a wider
| audience because FPGAs are probably going to become more
| important going forward - and are probably going to be what
| keeps Intel alive - but it doesn't make the emulator
| inherently better.
| flohofwoe wrote:
| When you look at typical FGPA emulator source code, it often
| looks pretty close to software emulator code ported to
| VHDL/Verilog instead of an attempt to re-create the original
| reverse-engineered 'transistor-level design' which would
| automatically reproduce any 'undocumented behaviour' of the
| original chip (like
| http://www.visual6502.org/JSSim/index.html)
|
| As such, an FGPA emulator isn't necessarily any closer to the
| original hardware behaviour than a software emulator. I guess
| the main advantage of FGPA is better performance on lower
| cost hardware.
| m45t3r wrote:
| > As such, an FGPA emulator isn't necessarily any closer to
| the original hardware behaviour than a software emulator. I
| guess the main advantage of FGPA is better performance on
| lower cost hardware.
|
| The price of the majority of FPGA chips are really
| expensive compared even against cheap (yet still way more
| powerful) SoCs (like really cheap ARM CPUs that are used in
| sub $100 handheld emulators). Also, technically a FPGA
| based emulator could be more efficient compared emulating
| everything in software, but AFAIK even Analog Pocket is not
| really that better in battery life compared to say a Miyoo
| Mini + (maybe because a ARM SoC have better energy
| management, but I don't know).
|
| I think really the main hype of FPGA is lower input
| latency, that is really difficult to archive with software
| emulation. There are still some tricks you can do in
| software that reduces the input latency significantly, but
| they generally are expensive to compute [1], so it wouldn't
| be feasible to be done in a cheap handheld device (at least
| yet).
|
| [1]: https://arstechnica.com/gaming/2018/04/better-than-
| reality-n...
| astrange wrote:
| Many people think an FPGA is automatically accurate emulation
| because it's "hardware" and the original console is
| "hardware".
|
| But the FPGAs are based on C software emulators because
| that's where all the knowledge in the world of how to emulate
| the original system is kept. You can't translate original
| hardware to Verilog and skip the figuring out how it works
| process.
| robinsonb5 wrote:
| There are a very few cores which are derived from die shots
| of the original chips - but in the majority of cases you're
| correct.
| actionfromafar wrote:
| One practical difference is that software emulation almost
| always runs under an operating system and all sorts of cruft
| which can add latency and jitter. An FPGA just does the one
| thing.
| ndiddy wrote:
| The main advantage of FPGA emulation is concurrency. When
| you're emulating a piece of hardware with multiple chips in
| software, you're often forced to run the emulation in batches
| (i.e. run the CPU for 10 cycles, then run the video chip for 10
| cycles, then run the audio chip for 10 cycles) for performance
| reasons. This matters because some games require a higher level
| of timing accuracy to (for example) paper over bugs in the game
| code, or perform fancy graphical tricks. There are cycle-
| accurate software emulators, but they aren't really playable
| for consoles after the 16-bit era and require relatively
| powerful CPUs. FPGAs allow you to run multiple chips in
| parallel, which eliminates this issue, allowing for accurate
| emulation in a small battery-powered handheld device.
| bowsamic wrote:
| Very few systems depend on this to the point of being an
| issue. The only one that this was a reasonable problem for
| was the PS2.
| flohofwoe wrote:
| For pretty much all 8-bit home computers cycle-correct
| emulation is essential, without it most modern scene demos
| simply don't work, but also a lot of old games (although
| those are usually more forgiving).
|
| In later computer architectures, hardware components have
| become more and more decoupled from each other, running on
| separate clocks and busses, with caches and buffers
| inbetween and what not, all of which makes timing less
| predictable but also less important in emulation, giving
| the emulation much more slack when it comes to
| "synchronicity" (which ironically makes modern computer
| systems "easier" to emulate than older systems - at least
| when it comes to correct timing).
|
| But 8-bit home computers (and also the early 16-bit systems
| like the Amiga and Atari) were essentially a single 'mega-
| chip' all running off the same clock and all chip timings
| being deterministic, which was and is exploitet by
| software.
| bowsamic wrote:
| Yes but they're so slow that it's trivial to emulate them
|
| EDIT: That's why I point out PS2. The PS2 was the first
| system that was fast enough while being dependent on
| timing enough that there were huge issues with its
| emulation
| bitwize wrote:
| Near / Byuu wrote a lot about their experience with
| timing bugs on the SNES and how it takes a quite powerful
| CPU to emulate it cycle-accurately.
|
| https://arstechnica.com/gaming/2011/08/accuracy-takes-
| power-...
| wiz21c wrote:
| Writing an Apple2e emulator, I wouldn't say it's trivial
| :-/ Proper video decoding is not exactly easy and neither
| is speaker emulation and neither is floppy disk
| emulation.
|
| It's easy if you're looking at 99% accuracy. But if you
| aim at 99.9% it's a different story.
|
| Plain and simple, there's no fully accurate Apple2e
| emulator so far and it's not like nobody has given a try
| in the last 20 years...
| flohofwoe wrote:
| For people interested in this topic: I converted my 8-bit
| emulators to a complete 'cycle-stepped model' (the last
| holdout were the CPU emulators), and wrote a couple of blog
| posts in the process:
|
| From newest to oldest:
|
| - Cycle-stepped Z80 emulator:
| https://floooh.github.io/2021/12/17/cycle-stepped-z80.html
|
| - Z80 instruction timing details:
| https://floooh.github.io/2021/12/06/z80-instruction-
| timing.h...
|
| - Cycle-stepped 6502 CPU emulator:
| https://floooh.github.io/2019/12/13/cycle-stepped-6502.html
| wiz21c wrote:
| Hey Floh! I ported your 6502 emu to rust for my AccurApple
| emulator. You saved me tons of time :-)
| flohofwoe wrote:
| Thanks! Glad to hear it's useful :)
| amelius wrote:
| I guess it would be a great hacker project to build a PCIe
| card with an FPGA (or several) that can e.g. be used to
| accelerate emulators.
|
| Or would a GPU be more fit for this purpose, and a more cost-
| effective and practical solution?
| zdw wrote:
| GPU are for data data parallel operations, which does not
| help for emulators which are (for the most part) running
| much slower traditional CPUs and a handful of support chips
| all at the same time, which is not data parallel.
| gchadwick wrote:
| Whilst it's true FPGA doesn't inherently imply accuracy it does
| make it simpler to recreate things in a more accurate way, in
| particular around interactions between CPU,audio and video. It
| also enables accurate input latency with respect to these
| things.
| rcxdude wrote:
| The main advantage is it makes it possible to do more accurate
| emulation without needing to sacrifice performance in the same
| way as software emulators. But the very large gap between
| affordable CPU performance and affordable FPGA performance
| makes it not an obvious tradeoff.
| deelowe wrote:
| > Not bettero or worse than software emulators.
|
| FPGAs and the associated dev tools allow for timing
| analysis/timing constraints that cannot be done with software
| based emulators.
| bowsamic wrote:
| That's a huge amount of marketing effort with very little actual
| answers to basic questions such as "why is this the future of
| video game preservation?" Seems like a hype-based product
| sebastianconcpt wrote:
| Why hype-based? Isn't an easy to use vintage experience device
| a legitimate value proposition within itself?
| bowsamic wrote:
| It's a value proposition in the sense that it already exists
| and people want it, but it's nothing new. Cheap handheld
| emulator devices have existed for literally decades.
|
| The "hype-based" aspect is that they're pretending like it's
| something revolutionary, hence why they are leaning on this
| Teenage Engineering-esque marketing style.
| BrazeBeefNoodle wrote:
| This isn't really new (it came out a couple of years ago),
| but as far as I know it was the first handheld FPGA
| emulator available.
|
| There's debate in this thread about whether FPGA emulation
| is better or more accurate. In my experience it is,
| especially in recreation of sound as I remember it from
| back when these games were new.
| Someone wrote:
| So, what happens if this particular FPGA no longer can be bought?
|
| Isn't it more likely it will be possible to compile and run
| current C code on 22nd century hardware (possibly on some
| virtualization solution) than that it will be possible to compile
| and run FPGA code on 22nd century hardware?
| johnfernow wrote:
| I agree. For me, one of the challenging long term parts of
| video game preservation will be non-standard controllers and
| other peripherals, such as the Wii remote, Wii balance board,
| Guitar Hero/Rock Band guitars and drums, etc. Sure, technically
| you can use a mouse and keyboard for some of those, but it's
| fundamentally an entirely different experience from the
| original.
|
| The Wii came out over 17 years ago and third party companies
| still make controllers for them. Maybe that will still be the
| case 40 years after release, but eventually nearly all Wii
| consoles will stop working. Will there always be a big enough
| market of people playing Wii games on emulators to justify
| making those controllers and peripherals? I hope so, but am not
| sure. There near certainly won't be enough demand for 3rd party
| Wii balance boards, which I can honestly live with, but I do
| hope the main controllers themselves are still available for
| purchase or possible to make out of other hardware available in
| the future.
| bogantech wrote:
| > So, what happens if this particular FPGA no longer can be
| bought?
|
| The same code can be easily target another FPGA as long as you
| don't use any vendor specific primitives or IP cores
| cm2187 wrote:
| I agree, this is tying the video game to a more recent
| hardware, which will also disappear in its own time. Much
| better to have a full software emulation that can be ported /
| recompiled to newer CPUs and new OS.
| markemer wrote:
| Verilog is just a logic implementation. It should be pretty
| portable. There are some issues, and certainly the bitstreams
| won't be compatible, but if C still works, I imagine verilog
| would too.
| ageitgey wrote:
| (2022) - I don't think there is anything new here since this was
| announced two years ago.
|
| FWIW, OpenFPGA on the Analogue Pocket works pretty well. Many of
| the most popular MiSTer cores were ported over and there are some
| nice desktop tools to make it easy to configure [1].
|
| [1] https://github.com/neil-morrison44/pocket-sync
| fayalalebrun wrote:
| I am surprised no one has yet tried to make a portable shell for
| the DE-10 Nano (Mister-FPGA's target platform). With a power
| usage of 10 watts, I think it should be quite feasible even with
| the addition of a small LCD panel. However, it would probably
| require re-engineering some of the standard addon boards for the
| form factor.
| gchadwick wrote:
| They have https://youtu.be/8eAgjgbZyPw?si=ZIBEFLOc_13hitGp
|
| Though sadly it's remained a prototype. I think the issue they
| had was you needed to mod the DE10 Nano (remove the pin headers
| and I think the ethernet jack) to fit it into the portable form
| factor. So they had concerns with either selling it in kit form
| where people had to do the mods themselves to expensive boards
| or doing it in house and effectively reselling modded DE10s.
|
| A fully custom board would be the solution but then price is a
| big issue. The DE10 Nano is very cheap vs its BOM cost at
| catalogue prices.
| CivBase wrote:
| Even if this were the future of emulation, we need a lot more
| than emulators for anything to really be considered the "future
| of video game preservation".
|
| Modern games so frequently require connections to servers - often
| needlessly. For example, Ubisoft is shutting down the servers for
| 2014's The Crew on March 31, 2024. That's less than 10 years
| after release. When the servers are shut down, the entire game
| will stop working - including the lengthy _single player_
| campaign. No emulator will bring that game back from the dead.
|
| In a similar story, Square Enix recently announced that they will
| be shutting down Nier: Reincarnation's servers in April 2024,
| less than just 3 years after its worldwide release in 2021. And
| yes, it's a single player game. My wife is a fan of the Nier
| franchise and has been playing Nier: Reincarnation since it's
| release. In a couple months she'll never be able to play it
| again. Square also pulled the plug on Babylon's Fall in 2023,
| less than _just 1 year_ after it 's 2022 release.
|
| If you're concerned about game preservation, be prepared for the
| disaster coming soon. FPGAs won't be enough.
| cybrox wrote:
| While this is being done intentionally now, it has been an
| issue for over a decade. - And it hasn't kept people from
| preserving these games in the slightest.
|
| Even now, there is a lot of work being put into reviving games
| that required master servers etc. by means of reverse
| engineering and essentially cracking. I do however agree with
| you that this is not the way it should I be and I still think
| developers and publishers should be legally bound to either
| allow software that they sell to function indefinitely or
| release the server code when they shut down the official
| servers.
| CivBase wrote:
| I think "in the slightest" may be a bit of an exaggeration.
| Not every game with a required server connection has been
| resurrected. And as this problem continues to escalate, I'm
| doubtful that hackers and preservationists will be able to
| keep up.
| jonhohle wrote:
| I play Overwatch with my sons and not only can you not run
| a personal server, the game frequently has fundamental
| mechanic changes for certain characters (and all characters
| in this Tuesday's update). The Overwatch of a year ago is a
| very different game than is now or will be a year from now.
|
| If someone was to provide an Open Overwatch server, I don't
| even know what it would look like at this point since game
| clients aren't available for particular versions (maybe on
| PC, but not console). When Microsoft is done with Overwatch
| it'll be gone.
| nottorp wrote:
| > Square Enix recently announced that they will be shutting
| down Nier: Reincarnation's servers in April 2024, less than
| just 3 years after its worldwide release in 2021. And yes, it's
| a single player game.
|
| Hmm? The Nier games are always online? I keep meaning to try
| them (although by now i probably have to buy used discs).
| You're saying there's no point any more?
| CivBase wrote:
| Nier: Reincarnation is a mobile game. If you're planning on
| playing Nier: Automata or Nier: Replicant, those are still
| available for the forseeable future.
| nottorp wrote:
| Ah okay, I can't afford free to play games anyway.
| jonhohle wrote:
| And amazing. I normally don't play games through multiple
| times in a row, but I played Replicant through Al endings
| and then finished the endings in Autamata immediately
| after.
| HtmlProgrammer wrote:
| I purchased the Analogue Pocket and it's a great little device.
| Got an archive of all GB and GBC games and can play them off an
| SD card using some of the FPGA cores available. while expensive,
| it's great to have that tactile feel just like an original
| gameboy with modern quality of life features
| nottorp wrote:
| That's illegal isn't it? And it's Nintendo's intellectual
| property so you shouldn't admit it in public :)
| jonhohle wrote:
| Im sure he owns properly licensed copies of all those games.
| He's just format shifting /s
| nottorp wrote:
| So is this really "open"? Or as open as OpenAI?
|
| The web site looks like your average ex-googler's SaaS startup so
| I'm sceptic.
|
| Hoping people who are more in the emulation scene will clear
| things up.
| snvzz wrote:
| What exactly is "open" about this?
| willis936 wrote:
| The cores that are community contributed can be open source.
| The hardware and tooling are not open, so it doesn't meet most
| people's definition of open. On the spectrum it's much closer
| to being open than closed source emulation products that first
| parties distribute.
|
| Is MiSTer considered open? It's dependent on a closed source
| toolchain to generate the bytestream.
| snvzz wrote:
| So it is only open in the sense of commercially (for profit)
| taking advantage of pre-existing open HDL written by third-
| parties.
|
| Disgusting.
| willis936 wrote:
| No. You need to explicitly request the tooling from the
| for-profit company (Analogue, which wraps Intel/Altera) so
| that the open source cores you write can run on their
| closed source hardware. It sounds exactly like the
| situation with MiSTer, except that there is a second for-
| profit middleman. Afaik MiSTer cores can't run on open
| source hardware or compile on open source toolchains.
|
| It's really a matter of taste whether you like Intel more
| than Intel+Analogue. It's wrong to call MiSTer an open
| source project but openFPGA not just because the number of
| for-profit companies needed is different.
| markemer wrote:
| Yeah. Open toolchains have come a long way, but they're
| not there yet. The Lattice ICE family are the best
| supported.
| FPGAhacker wrote:
| I think this is not a great name for a product that isn't
| developing silicon.
| WhereIsTheTruth wrote:
| Lol, the audacity of a for profit company with a proprietary and
| closed source stack
| opisthenar84 wrote:
| I fail to see how programmable logic patched together == "the
| future of video game preservation". There's community, software,
| testing, etc... involved as well.
| indrora wrote:
| Just a reminder that Analogue have made very little on their
| promises to those they stole time from.
|
| Analogue isn't even the only ones to do an FPGA rebuild of a
| console; there's a near-perfect GB/GBC clone (with quirks
| toggles) that fits into a traditional Gameboy shell:
| https://funnyplaying.com/products/fpgbc-kit
| dansalvato wrote:
| I recently bought an Analogue Pocket and I think it's a great
| piece of hardware, but I'm really not a fan of this company's
| business model. This page has told me nothing I actually want to
| know about OpenFPGA.
|
| Here's my question: If I'm developing an FPGA core, why should I
| develop for OpenFPGA instead of MiSTer? I want to know why it's
| better for preservation that I develop for OpenFPGA. Is it a more
| portable platform that has a more guaranteed future? I need to be
| convinced that OpenFPGA solves problems that make it a more
| likely choice than MiSTer 10+ years from now.
|
| If someone with more experience than me in this space can answer
| the above, I would be really grateful. I'm astounded that
| Analogue's page on OpenFPGA is all marketing fluff without
| actually answering this.
___________________________________________________________________
(page generated 2024-02-12 23:00 UTC)