[HN Gopher] MiSTer FPGA: Recreate classic computers using modern...
___________________________________________________________________
MiSTer FPGA: Recreate classic computers using modern hardware
Author : lnyan
Score : 119 points
Date : 2022-09-18 13:30 UTC (9 hours ago)
(HTM) web link (mister-devel.github.io)
(TXT) w3m dump (mister-devel.github.io)
| ilaksh wrote:
| It seems like there really needs to be an alternative that uses
| more available hardware.
| vintermann wrote:
| There's one thing you don't get, which I see many people find
| they miss: savestates. It's technically possible and I know a few
| cores try to support them, but it's just a million times easier
| (and more reliable) if you do everything in software anyway.
|
| Hardware emulation has a pretty small niche between software
| emulation and real hardware. If you care about accuracy at all
| costs, real hardware is usually still available and not too
| expensive, and if you care about convenience, software emulation
| is better.
| fermentation wrote:
| I personally have found it more enjoyable to play a lot of
| games without savestates.
|
| Playing earthbound a few years ago I was constantly
| savescumming. My recently replay on mister without savetsates
| was way more enjoyable because the stakes were higher.
|
| Wouldn't want to play a Mario World rom hack without them
| though
| reidrac wrote:
| > real hardware is usually still available and not too
| expensive
|
| I all depends. There's a "retro" bubble currently and people
| ask silly money for the original hardware. Then capacitors
| burst, original hardware needs maintenance, and is not
| something everybody can do.
|
| The MISTer provides an experience that gets very close to the
| original hardware, without all those _nuances_.
| flatiron wrote:
| I'm unsure what you mean about hardware emulation not being
| reliable. Save states is a good point. SNES for example does
| not have them. Adding that stuff as an after thought is
| extremely tricky. Most newer cores are creating with save
| states in mind for two reasons. Makes debugging much easier as
| you can share states with testers on top of the QOL you get
| with that feature for end users. PSX for example has really
| good save state support with rotating save states.
| dtx1 wrote:
| I applaud the MiSTer Project for their brilliant work. I'd even
| be interested in buying something like it. But the most complex
| console it can emulate is a ps1 and that can be emulated
| perfectly fine in software. I wish most 5th gen/6th gen consoles
| were in reach to emulated with it. But alas that's out of the
| question and even software emulation is still far from great for
| most of these consoles and require beefy hardware...
| koala_man wrote:
| For anyone else wondering about the name: it's actually "MiSTer",
| from "MiST on Terasic [FPGA board]", with "MiST" being a previous
| "aMIga/ST" FPGA reimplementation effort.
| lnyan wrote:
| Seems that HN automatically replaces "MiSTer" with "Mister"
| when I submitted this post
| layer8 wrote:
| As the submitter you can edit the title after submitting to
| undo any of HN's auto-normalization.
| dang wrote:
| Twont happen again. Not if followed by "FPGA" that is.
| fortran77 wrote:
| Can you actually buy a DE-10 Nano FPGA board today? The links say
| "pre-order"
| badlucklottery wrote:
| For a semi-normal price? Probably not.
|
| Terasic has been getting stock pretty regularly though and
| their pre-order dates don't seem to be too far off reality.
| kaoD wrote:
| I'm curious, is there any advantage to this over software
| emulation, besides "I did it because I could"? (which is of
| course cool in itself).
| cmrdporcupine wrote:
| Latency.
|
| It doesn't matter how fast your emulator is, throughput-wise.
| Your operating system (and other stuff) sits between it and
| output and input devices. And usually adds multiple frames
| worth of latency. There's ways to improve this, certainly, but
| you won't get that experience "out of the box."
|
| Now, it's also possible to accomplish this by running emulators
| "bare metal" or "close to the metal" like my friend Randy did
| with his BMC64 project: https://github.com/randyrossi/bmc64
| musicale wrote:
| > Latency
|
| As long as the correct output signals are generated before
| the clock edge, there is little meaningful difference between
| software or hardware implementations.
|
| A cycle-accurate software emulator can actually replace a
| hardware CPU. Consider this example of a cycle-accurate
| software emulator running on a 600 MHz Teensy/ARM
| microcontroller board plugged into the CPU socket of an Apple
| II:
|
| https://microcorelabs.wordpress.com/2021/01/08/mcl65-worlds-.
| ..
|
| The 8088 version (an impressive achievement, though he had to
| overclock the microcontroller to 800MHz) apparently also
| worked as a drop-in replacement for MiSTer's FPGA
| implementation - he suggests that graphical bugs in the area
| 5150 demo were not due to the CPU but due to timing issues
| with MiSTer's PC XT peripheral implementations.
|
| https://microcorelabs.wordpress.com/2022/08/12/area5150-runn.
| ..
| cmrdporcupine wrote:
| No, that's not at all the case for what the poster I was
| replying is referring to. I think you misread them/me. They
| seemed to be talking about software emulation on commodity
| PCs.
|
| Total time, from input to physical display on the screen is
| not under the user space programmer's control if you're
| running an emulator on a Linux or Mac or Windows system.
|
| You can be cycle accurate all you want. That doesn't get
| you past the windowing system, GPU, display controller,
| HDMI interface, etc. any faster. All of that sits between
| you and pixels.
|
| It is possible, on an FPGA (or under any hardware you
| control directly, really) to go straight from framebuffer
| to HDMI (or etc) signals without pauses inbetween. In some
| ways it's easiest on FPGA.
|
| Your example is running on custom hardware. That is
| entirely feasible, yes. But isn't what was being asked
| about. That's similar to the BMC64 example I gave.
| musicale wrote:
| I think we're making compatible points. You noted that
| you can bypass the OS by running on bare metal. (True!
| You can also use real-time OS features, devote one or
| more cores entirely to running the emulator flat out,
| write directly to a frame buffer - or maybe even generate
| the actual video signal[1], etc..) Another nice thing
| about a microcontroller board like a Pi or Teensy is that
| you can easily get signals in (e.g. controllers,
| keyboards) and out (e.g. sound, video) of it.
|
| Note that Linux (which I'm familiar with) makes it fairly
| easy to bypass much of the OS for real-time applications,
| but you can get most of the benefit by simply running a
| single process (i.e. just run the kernel and a single
| emulator process.)
|
| My point is similar to yours actually: that as long as
| you calculate the output signals on time (e.g. before the
| clock edge) there is not a meaningful difference between
| hardware and software implementations.
|
| [1] http://www.radanpro.com/Radan2400/mikrokontroleri/rtv
| ideo5.h...
| blcknight wrote:
| It's a good way to learn about FPGA's. Other thna that, the FAQ
| has a good example about where the Amiga software emulation
| falls short:
|
| > Let's take a well-known emulator, UAE, emulating an Amiga. On
| a Raspberry Pi 3, you can run some Amiga CPU benchmarks and get
| crazy numbers like 100 times the original 68000 processor. So
| you may assume you have an emulated Amiga that is 100 times
| faster than real one. No, you don't. If you run different kinds
| of demos or games, you will see the video stutters sometimes.
| For example, if you play the well-known "State of The Art" demo
| by Spaceballs, you will notice video stuttering at some points,
| while a real Amiga 600 with 1x CPU speed plays the whole demo
| very smoothly.
|
| https://mister-devel.github.io/MkDocs_MiSTer/basics/faq/#why...
| 0xcde4c3db wrote:
| The main disadvantage of software emulation is that really
| making the timing consistent with the original hardware is
| computationally expensive because it needs to account for
| things like bus arbitration and DMA interactions between the
| CPU and graphics hardware. This means that you can't get away
| with JIT translation, or even having your CPU emulation iterate
| over a bunch of instructions at once. For most games this
| doesn't make a big difference, but it matters in some edge
| cases, and also for accurate slowdown behavior (most old-school
| game engines let physics slow down when the CPU falls behind),
| which is important for speedruns and other high-level play on
| some games.
|
| While it's not intrinsic to software emulation, modern PC and
| mobile operating systems tend to be somewhat bad about input
| lag by default. This can be overcome, but it's work, and
| vendors seem to invent an exciting new way to fuck it up every
| few years.
|
| Similarly, a lot of old-school hardware ran at oddball frame
| rates that modern systems won't do without a bit of coercion
| (e.g. NTSC SNES runs at around 60.09 Hz in most modes), so
| you're usually forced to choose between running the system at a
| slightly inaccurate speed or allowing periodic stuttering. That
| being said, modern displays don't necessarily support the
| original refresh rates either, so FPGA-based systems have
| needed to make the same compromises, just less often than
| software emulators.
| layer8 wrote:
| It removes the need for a high-end CPU for accurate emulation,
| and potentially reduces video/audio lag.
| foft wrote:
| If you want to eg add original ports and hardware interfaces
| that tends to be easier with an fpga: cartridges, midi etc. Of
| course you can do that in software/ bit bang. Though it's
| complicated by emulator timing, they tend to run frame by frame
| and sync at the end of a frame.
| giantdude wrote:
| It's a shame it's not on a Xilinx FPGA. I am out.
| Koshkin wrote:
| FPGAs are fun, for sure, but I still have never felt the flair of
| "authenticity" from the use of FPGA as opposed to software
| emulation on a microcontroller or the PC. In fact, software
| emulation is so much more practical, and you can simulate pretty
| much any aspect of it that you wish, not just the CPU and some
| peripherals. A modern flight simulator is another example of
| using software to bring the user's experience close to what it
| would be in reality (especially with the VR gear).
| randombits0 wrote:
| Um, I don't understand how you might feel software emulation
| has more "flair of authenticity" than a MISTer rig. FPGAs don't
| emulate hardware, they are hardware. They are almost exactly
| like the original.
| greenbit wrote:
| I wonder how much the misapprehension that FPGAs somehow
| emulate is due to the fact that the way we configure them
| looks so much like code. VHDL is ghastly, but I prefer it
| over verilog bc verilog seems to actually try to look like C.
| I think especially for beginners it's too easy to lose sight
| of the fact that while you may "read through" your
| VHDL/verilog, that when it hits the FPGA fabric it's all
| going to happen in parallel. Maybe if the source matter were
| made to resemble data more than code, we could simultaneously
| ditch the verbosity of VHDL and the imperative algorithm
| appearances of verilog. I'm thinking maybe JSON at the
| moment. =P
| BearOso wrote:
| They're hardware, but not the same set of logic as the
| original systems. They still rely on reverse engineering
| efforts that occur when developing software-based emulators.
| They produce the end results that were measured from the
| original system, but not the exact behavior. As a result,
| they're not naturally more exact than a software emulator.
|
| Where the FPGA comes in handy is in concurrent logic and a
| fixed clock. This makes synchronization easy, and that is
| what makes software emulators much more demanding.
| prezjordan wrote:
| Often times it's not flair but latency! I have yet to find a
| handheld that plays my GBA titles with the same feel as my
| actual SP, save my Analogue Pocket which has an FPGA.
| Aromasin wrote:
| I've wanted to give Mister FPGA a go for the longest time, but
| the boards are never in stock any time I look. How are people
| getting their hands on them?
| etiam wrote:
| Tough, given the difficulties the last few years I guess.
|
| But Terasic have the FPGA board listed for pre-order with
| estimated shipping at the end of this month. I haven't had
| opportunity to get one before either, so I'm not sure how the
| availability for expansion cards has been.
| fermentation wrote:
| It's rough. I followed the misteraddons owner on twitter and
| waited a few months for them to notify that kits were back in
| stock
| sigstoat wrote:
| placed a backorder on mouser and then just waited. easier than
| constantly checking and hoping. they don't charge your card
| until it ships.
| gchadwick wrote:
| Apparently if you buy direct from Terasic you can get hold of
| them. The downside is a large shipping cost and import
| duties/taxes on top. I have heard of people successfully
| getting them shipped from Terasic offices within the same
| country as them to avoid the import duties issue.
| krupan wrote:
| Speaking from ignorance of the details of this project, but
| couldn't other FPGA's/boards be used? Is it using some
| Terasic specific features
| flatiron wrote:
| There's a required RAM module for most cores that slides
| into the de10 nano. The software and the Linux kernel are
| also tightly coupled. Individual cores can be ported to
| different FPGAs though. The SNES one for example was
| recently ported to the analogue pocket.
| MegaDeKay wrote:
| The Terasic boards are essentially an evaluation board and
| despite the recent price increases, still give you a lot of
| hardware for the money. Other boards that come close in
| capability and have what you'd want for something like an
| emulator platform (like HDMI out) are a lot more expensive.
| Pretty sure Sorgelig (project lead) has said he has no
| interest in ever porting it to a new platform. Doesn't mean
| someone else couldn't, but it would be a major effort to do
| so and keep up.
| dang wrote:
| Related:
|
| _Mister FPGA: The Future of Game and Computer Emulation_ -
| https://news.ycombinator.com/item?id=29439279 - Dec 2021 (64
| comments)
|
| _MiSTer FPGA GBA Splitscreen Multiplayer_ -
| https://news.ycombinator.com/item?id=27547848 - June 2021 (9
| comments)
| flatiron wrote:
| I was lucky enough to get in on this when the boards were ~$130.
| It's one of my favorite pieces of tech. It "just works" and the
| UI is very good. Updating is super easy and it even goes and
| grabs the MAME Roms for you. CPS2 games feel much different than
| my MAME box running Arch. I can 100% pick up the controller and
| I'm a few seconds know which one I'm playing. The video
| processing presets have some that make the games look amazing.
| Psx I mainly play rpgs so latency isn't a huge deal there. If
| anyone has any specific questions let me know. I think they are
| twice the price now but even at that I would probably rebuy. I
| use it probably 8-10 hours a week so worth a good investment.
| radicalbyte wrote:
| Same here, it's a fantastic piece of kit. Better than my retro
| consoles. Only real downside is that I just don't have the time
| to use it much :(
___________________________________________________________________
(page generated 2022-09-18 23:00 UTC)