shmups.system11.org

The MiSTer will likely always be an evolving device until the moment it is not being developed for and then the next board will be an evolving device until it is no longer being developed for and ect into infinity. In terms of hardware though here is my take:
De10 nano fpga dev board - going to be in use for years.

128mb ram - probably going to be around for awhile. The Neo Geo is one of the most demanding consoles the de10 nano is capable of replicating and was just released so on the off chance we get something more advanced it probably won't be for awhile

Io board - probably going to lose the sync on green switch as that can be done via an ini file and I would imagine a version without analogue video out will hopefully exist as that can be done via dac and looks much neater.

Controller boards - BliSTer is probably finalized and LLCJ will probably be out in the next few months.

Cartridge & cd reading components - I saw a pic of a prototype MiSTer case that included a disc drive. I have no eta on this or confirmation it will ever actually be released and wouldn't suggest using a disc drive or cartridge slot anyways. Just pick up an external harddrive and play backups. This will be less headaches and preserve your game collection.

Case - Probably going to be updated as new revisions of the io board and a new controller board comes out (not that it matters if you are using the BliSTer board)

So if you're okay with the BliSTer controller board and don't mind a physical sync on green switch and analogue video out ports then the current fpga board, ram board, io board, controller board, and case should all be something you can use until a new fpga board gets selected in the distant future. If you want to wait for the LLCJ then you will need a different bottom half to the case. And if you want a neater looking io board with no SoG or potentially analogue ports that will be a little while and require a new top half of the case.

Isn't a low latency mode for standard USB boards being already coded so that LL Cool Joy or Blisster aren't needed anymore (if you use a low latency USB controller)?

That is true but adapters have yet to be created to plug analogue controllers into usb ports in this mode (as far as I know anyways) so you are limited to usb controllers. Also it is only working with native controllers for the core in use when you are playing (and only a few cores have the option to enable it) and Blissbox allows you to use any controller you want with very low latency and has adapters for pretty much everything under the sun available for purchase right now. The LLCJ prototype board has a analogue connection designed for arcade sticks as well. So they both offer things you can't get with just low latency usb.

I'm certain in the future you will be able to use usb low latency modes with non-native controllers and it will be enabled on all the cores and not just a select few but as it is very much in beta right now I wasn't going to count it as ready to be used for gaming as opposed to just testing it out. Although like all things MiSTer I expect now that it is in beta it will develop rapidly in the next few weeks. Fingers crossed for a wide variety of adapters.

Most of the time when software emulators use game specific patches the reason is for speed. If they implement cycle accurate logic then a powerful cpu is needed to run it.

With FPGAs there is no need for this and logic is implemented at a cycle level anyway. When a bug is found then the logic is changed which affects everything and not just a single game.

Most emulators are made from studying the behavior of original hardware. Including the FPGA emulators by Kevtris.

Only a select few are made from copying the transistor logic from the original chips. The MiSTer Neogeo core by Furrtek was made from transistor logic except for the CPU and sound chips.

They're not.
Using a hack is different from coding an approximation of what the hardware does. There's an important difference.

All emus use code which approximately reproduces the original hardware behavior.
Some, we might say, are close to perfect, where perfect means that their output matches what the original hardware does, down its own very logic.



We have schematics of most videogame boards and most chips used were off the shelves ones which come with complete documentation and the custom ones are being studied. If you're into this kind of research, you'll probably enjoy the read: http://arcadehacker.blogspot.com/2018/0 ... licon.html
And they studied many more, they really did god's work.



FPGAs are acceptable approximation and that's why I'm really interested in the MiSTer development.



I'll give this the benefit of the doubt.



This was true... uh, 10 years ago, if not more.



Again, this was true ~20 years ago and I could still object on using such hacks, but I guess that it was the kids you're talking about raging and crying on the internet that they wanted to play Super Mario 64 on their PCs which pushed developers into making speed hacks instead of telling them to go out and buy the console and game and stop pirating.
My own opinion of course. HLE emulation and dynamic recompilers are what got us to have more power hungry consoles to run on our own computers so it's still an important development in the history of emulation.



I wish I were still a kid, unfortunately I'm 33. I started on an 8Mhz 80286 when I was 8yo and marveled at playing games like Monkey Island and Prince of Persia.
So yeah, I know about hardware limitations probably better than most people around those days.
You can go patronizing someone else, thank you very much.



Almost correct. Cycle accuracy is referred to the set of inputs and outputs given in a single cycle.
In laymen terms, if I input "1" into a SNES and it outputs "2" in a single cycle, a cycle-accurate emulator will behave exactly the same, down to single cycle timing.



Most of the time when software emulators use game specific patches the reason is they got most of a console's library to play (mostly) right and know that fixing some games will screw up hundreds others, so they take the easy way out, put a couple "ifs" for those games and call it a day.

Glad to hear this is not the case with how MiSTer's SNES core is being handled, hopefully this is the case with all the others.

486. DOS. NESticle. All you need, really.

Great times indeed, except that we couldn't afford a 486 at the time, so we kept using our 286 and then, when my dad finally saved up enough money, we got us a Cyrix 166Mhz with MMX extensions which was cheaper than a pentium and a fucking headache for lots of games due to compatibility issues

Alright, not so great times, but that's what we got back then.

That depends on your definition of a hack. How close does it have to be for you to call it legitimate? And, obviously, your definition of "close enough" changes with every passing day. Who has time to constantly churn a hobby project?


Yes. So, we agree the research isn't done.


That's not what I said, though. You said transistor level emulation and that's not feasible today. Something tells me the goal posts of "acceptable" will move as time goes on. (They always do.)

That's my issue with this. Intentional or not: you suggested we can make a magic hardware recreation by just plugging the schematics into an off the shelf FPGA. The barrier? "Lazy" devs?

That's not true. What is close enough, anyhow?


Well, I'm old.

We got flamed in Mame for worrying about accuracy and letting the hardware catch up. On the other side, hitting frame rates on real machines today is penalized with a dismissive "you're just lazy" tomorrow.

Very few people have time to pour into infinite iteration. At some point, there just isn't any spare time and energy to keep going.


UltraHLE was important, but the dev never wanted to make a long term commitment to an emulator--or take on Nintendo. It was a tech demo. I can't speak for the other N64 emulation options. With Mame, it was possible to work on games that couldn't hit frame rate on the hardware, but if you tried that with a console emulator, all you would get was flame.

A hack is a modification of how your own code works in order to make something run, which otherwise wouldn't.
This means you've basically messed it up somewhere along the road and you're doing a (highly likely) very bad patch to make the problematic game run.
So instead of doing it properly, by doing research on where's the flaw in your logic/code is, you just lazily make a change just for that game in order to have it working.



That's the 1 billion dollar question and it's not just me, but all the people looking at the emu scene since it all started.
To some, legitimate = I personally can't tell a difference between emu and real hardware, to others it has to be graphically identical and then there are those who go beyond and want the game code to run exactly like on original hardware, even if there are changes that they can't see or feel.
Your call.

For me, I don't necessarily need to go down to circuit level, like emulating the picoseconds of delay cause by a trace length. That's way too much and absolutely useless.

But this is something which I always wanted to see being made: a FPGA where you can put in whatever components you have on hand and let the FPGA handle the rest of the logic.
For example, Mega Drive FPGA, you have your own 68000 CPU, Z80 and YM2612. You put those on, the FPGA recognizes them and turns its own emulation of those ICs off and use them. If you don't have them, then the FPGA will emulate them.
That's my little utopia, emulation wise, but I feel we're nearing a stage were it won't be needed because...



...enough research has been already done.
It's not complete, like every single IC on the every console or arcade board, but parts like the motorola 68000 CPU, Z80 and others are at this point well known and perfectly emulated, down to cycle accuracy. And those have been used in god-only-knows how many consoles and arcade boards.



It will in time. Having the foundation ready it's a good thing. MAME should have taught you this.



I'm not suggesting anything, I'm not an FPGA developer, that's more of a question for the likes of Jotego or paulb.
The barrier is knowledge and motivation. Today we have the means to create motivation through donations, Patreons and so on.
MiSTer itself is a fantastic starting point and it's going to get better and better as time passes, so we basically just have to wait.



You know I wasn't on that part of the fence, I always cared more about accuracy (except, maybe, when I was a kid and just wanted to play Metal Slug, but good ol' NeoRageX got me covered on that)



It is not, it's never been about speed, it's been about making stuff work through hacks.
The whole "speed" topic was brought up by you and I didn't buy into it.
There have been hacks to make games run at full (or acceptable) speed, but I wasn't addressing those and you'd known if you've read my posts.
I never talked about speed, I always talked about accuracy.



And that's true, I agree and it's why open source software has been the real revolution in emulation, so that when someone doesn't have any more time, someone else can pick it up and continue.
And it's why I have really high hopes for MiSTer.



For a very long time, it was the only real option and opened the doors for High Level Emulation (that's what HLE stands for) to other platforms. Dynamic recompilers then came out and made the Playstation emus make huge leap forward and so on.



I know too well but trust me, MAME got a huge amount of flak for this even back in the days.

And let me add just a little remark: for once, it feels really good to actually have a goddamn civil discussion without resorting to personal attacks and non sequiturs.
If you feel like discussing it further, I'd be absolutely okay with that, although this might not be the best thread.

How sure of you are this? Do we have information on the cycle penalty of accessing VRAM on Atlus 68000, "Toaplan 2" GP9001 hardware, and other systems of this era? How about during blanking vs active display? Does MAME even support the concept of asserting /DTACK for n cycles as necessary?

The two aforementioned platforms also are filled with hacks to make things "work" (e.g. the Atlus 013 sprite IC's serial configuration register is completely ignored and isn't understood; Dangun Feveron's screen shake that changes the sprite raster area doesn't work; GP9001 sprite/layer priority is based on some experiments and isn't still fully understood). The maximum draw bandwidth for the GP9001 and 013's sprite framebuffer isn't emulated either, so it is able to overdraw where the hardware would simply drop sprites.

Those individual common components like CPUs, sound ICs, etc. are mostly understood well, but the glue logic connecting them is part of what makes each machine configuration different, and these are important elements in making an emulated system perform accurately. It's easy to scoff at this kind of thing, but many games (unfortunately) have their playability somewhat tied to the execution speed, and slowdown has not been right for many of these arcade games.

You tell me.

And without quoting all of your post, just to reply to the question above, I'll just highlight this:



And that's what's been investigating recently, including the dreaded wait states in the 68k emulation which make lots of games in MAME run at incorrect speed, mainly thanks to the effort of many people who are also working on the MiSTer cores.

https://twitter.com/topapate

This is a guy I've been keeping an eye on. He's going places and working really hard, gathering knowledge and applying it to try and replicate the original hardware behavior.

And there are many more.

I wouldn't be surprised if in 4-5 years we'll get to a point where we'll have all the main consoles and the most well known arcade boards cracked open and perfectly replicated on FPGAs.

Do these two particular aspects cause a tangible difference between MAME and the original PCBs? Just curious.

Well... Dangun Feveron is simply missing the screen shake in MAME, and when sprites should drop out and disappear, they don't in MAME. One good example is ESP Ra. De. after most bosses die; you can expect part or all of the energy stock bar to disappear momentarily on real hardware.

This is a case of "but the emulated one looks better!", and while that might be agreeable, I think that should be a conscious choice, not a benefit through coincidence of inaccurate emulation.

My worry with MiSTer is that the acceptance criteria will be "the players think it looks good", and so the cores will seldom go beyond that - I fear for reimplentations of MAME's understanding of the hardware dominating the developmental focus.

Interesting, thanks. Totally agree as well, of course - I kind of tried to make that point here yesterday indeed.


Edited - Does PS4 Feveron have the screen shake? Anybody compared it with MAME?

I went to update my MiSTer for the first time in months and ran into issues. I have the USB board (v1.2), an extra SDRAM addon, a RTC addon, and the IO board (v4?). Apparently now the Mister.ini file sits on the root of the sd card. When I updated (really just flashed a new SD) the video ports will only work occasionally. It takes a while to lock video on HDMI and I couldn't get the VGA to my switch at all, said unsupported resolution. I tried playing around with the INI file, but couldn't really get anything reliable. TBH I never even had an INI file before, it was just running without it.

Ideally I'd like the HDMI and VGA out both active for no reason other than testing. I've seen a video where you can switch INI files on the fly, which is fine, but I couldn't get it working. I'm back to the main MiSTer core from August 2019 until I can figure out how to update properly without losing video. The online "guide" is sort of outdated and doesn't really cover my specific setup. Any advice?

You should be able to get video from both HDMI and I/O VGA simultaneously with the standard configuration with the current MiSTer binaries and menu core. On the ini file the only recommended change would be to set the HDMI output to 1080p, since the default is 720p. You only need to switch INI settings for output when you're getting direct video analogue from the HDMI out, which some people do to avoid needing an I/O board for analogue.

For those who haven't updated for a long time, it's often recommended to backup your games folder as well as configs for controllers if you want, and do a brand new install on the SD card using the latest SD card installer (or using the script on Linux or MacOS) and then running the updater script on MiSTer.

Also take note that the method of handling arcade cores and loading arcade ROMs has changed and has been made much more convenient and simple (using .mra files). I'd recommend looking into this.

Right, but it doesn't work. Is the Mister meant to power up completely even if there's no video cable connected? Because mine doesn't, and only occasionally does with just HDMI connected. I thought maybe the IO board was shorted or otherwise bad soldering causing problems, but wouldn't know how to begin checking that.

When I upgraded from my June 2019 working setup, I backed up the micro SD and flashed a completely new most recent build with their flash utility. I couldn't get anything to work reliably (HDMI, VGA) after hours of trying connections, INI settings, etc so I just flashed back my June build. Now HDMI works 100%, but still nothing on VGA. I don't know if this was before the INI file had to be in the root of the SD, but I don't even have an INI on this build. From August would that go in root of the card or in the "config" folder?

It is quite important to set vsync_adjust=2 so you have zero lag and no stutter. Otherwise you get 2 frames latency.

The arcade cores are a bit harder to deal with because they’re unique but most of the console cores have used rea hardware as reference and rely on the feedback and bug reporting of thousands of users. Few things will ever be perfect but at the point where the bug reports disappear, I’m not sure how to progress past that.

If you want 100% hardware accuracy, then original hardware is the only solution. But if you are okay with a solution that approaches 100% accuracy, has active development, receives new cores, and uses a unified frontend, scaler, input, etc then MiSTer is the device for you

The accuracy will always depend on the developer, of course.

Just wanted to chime in: Jotego's arcade cores are made by using a logic analyzer to check what each custom chip is doing by reading the inputs and outputs, which means he's "brute forcing" the chips to understand what they do and replicate exactly their behavior.

His cores should be perfect, save for some minor mistakes he can easily figure out and correct if anyone finds them and report to him.

For those using MiSTer on a 15khz CRT, has the GBA core the option to display at the native resolution and refresh rate (240x180 at 59.7275, or 240x240 with borders, for what it's worth)?

Yes, it does. You may need to set "sync core to video" and/or some other setting on to get stable video via the direct video/IO analogue output.

Thank you.

Speaking about picture quality. What is your preferred scanline configuration for 1920x1080 non-crt screen?

I found comfortable with 50% horizontal scanlines and sometimes combined with 15 or 20% vertical scanlines (yes you can combine them) to emulate 14”crt tv

Still looking for a final config

Is vsync_adjust = 1 an acceptable compromise if your TV doesn’t like 2?

speaking of it, can someboy line out the difference between vsync 1 and 2 ? I don't think that I fully grabbed the difference from reading into it on the github.

From what I understand: contrary to Analogue's implementation, the cores themselves on the MiSTer always run at original speed, so there's no speed alteration to a straight 59.94 or 60Hz output, right? Vsync 0 performs a framerate conversion on the digital output, so you a recording friendly signal with slight hiccups due to inserted or dropped frames.

Vsync 1 or 2 both give you the original framerate on the HDMI output, but with slightly different signal timings due to the methods the timings are generated. I'd appreciate it, if somebody could elaborate on this one.

vsync_adjust=0 triple buffered (2 frames), 60hz (compatibility mode)

vsync_adjust=1 triple buffered (2 frames), native system's refresh (smoother)

vsync_adjust=2 single/sub-single buffer (0-1 frame), native system's refresh, synced

https://twitter.com/smokemonstertwi/sta ... 84?lang=en

Vsync 0 & 1 use a triple buffer so it they have 2 frames of latency where Vsync 0 sets the clock to the set video mode and Vsync 1 sets the refresh rate output as close to the source as possible for the least dropped frames.

Vsync 2 uses a single buffer but the scaler is constantly adjusting the HDMI clock to stay at most 5 lines away from the source so there are no dropped frames and there is at most 5 lines of latency.

So Vsync 2 is actually framelocked, while Vsync 1 imitates a framelock by setting the refresh as close to the original as it can without actually running framelocked ?

Where is the increased compatibility of vsync 1 over 2 coming from?

Yes so there are still dropped frames with Vsync 1 but not often of course.


The constant HDMI clock adjusting of Vsync 2 I would say. Maybe some devices are more tolerant against the varying clock speed.

My old Sony 40W4000 works fine with Vsync 2. Most devices should not have any problem with Vsync 2 vs Vsync 1 but there are dropouts when loading games in most cores.