Here's Another Look At Taki Udon's Game-Changing $150 Handheld MiSTer

I'm not interested in this particular product. I am interested either the barebones parts he is doing, or the console. Depending on what exactly that entails, and how much more it is.

Well, I'm interested in this handheld. I know the twin analogue sticks will be essential for some but I'd prefer a variant without them if there's a vertical option.

Does it play the original carts? I'm struggling to see how this is an Analogue Pocket competitor if it doesn't play the carts...

Are people seriously buying an Analogue Pocket and then NOT playing any carts?! Isn't there a thousand devices, each year, that can play roms for a fraction of the cost of the Pocket?! I find this odd lol

@Bonggon5 Actually "Funny Playing" has an FPGA handheld too. You do have to put it together yourself, but it's super simple. It's just a few pieces and no soldering required.

@nocdaes as @Bonggon5 said, those other handhelds you are talking about are just emulators or in some cases a NOAC 😬. I am in a similar boat as the other guy. I have been playing NES games so long, I am super sensitive to lag, and most emulators are unbearable for me, especially ones that run on top of Android, as that OS introduces significantly more lag.

I did have an Analogue Pocket for a while, but I sold it because the Dpad is not accurate (it was designed by 8bitdo and this is a common issue with them). I did put Pokemon Red in at first, but then I decided I didn't want to potentially mess up my cartridges, and used it exclusively with the SD card.

Another advantage is lightgun support. I don't know if Analogue ever got their dock and DAC to work together with light gun games, but I know they said they were going to add that feature at one point. I have used lightguns with other FPGAs in the past though. Not gonna happen on an emulator.

Since there are so many myths about emulation and lag that get perpetuated, I determined the lag myself on Android compared to a Linux PC both using Retroarch. I actually gave the Android tests an extra disadvantage by using two different Bluetooth controllers. The result was exactly the same, typically one or two frames of lag depending on the emulator core. This surprised even me because of the Bluetooth, but I wasn't surprised otherwise as I've seen testing that shows, in most cases, there is no additional lag. Provided there's enough CPU headroom, the lag can easily be mitigated to under a frame even with Bluetooth.

I do find it plausible other emulation software on Android would have the lag described, but I have verified it is not an issue on Retroarch, which really is miles better than anything else anyway.

@Bonggon5 It's a DE-10 inside the handheld, it's a MiSTer. It has CRT, LCD and color correction options and its FPGA based for $150. It's made by the same company that has been producing those $99 DE-10 clones.

@sdelfin The dude mentioned in this article, Taki Udon actually has a video on his YouTube channel where he does an input lag test. The NES emulator he checked on Android had 75ms of lag. Frankly that is unbearable on its own. But the test was done on an Android handheld game device… meaning the input was hard wired to the board and there wasn’t as many background processes going on as a normal Android device. Most people emulating on Android are using a phone and a controller grip that has USB or Bluetooth lag to add in as well.

Greater than 30ms total input lag I can easily feel on NES games I am super familiar with. Greater than 60 ms and I just won’t even bother playing, because it messes up my muscle memory and at that point I am not having fun anymore.

Input lag on emulation is definitely not a myth. It has been verified through thorough tests for years. On top of that you are playing on USB or Bluetooth controllers which both add a lot of lag, and you are playing on modern TVs which also add lag, so add all that to the overhead of whatever OS you are on and the emulator’s own lag, and you end up with a totally different gaming experience for many people who are sensitive to input lag.

For action games I prefer FPGAs that I can connect to a CRT, but even in a handheld its noticeably faster than emulation.

@DestructoDisk I did not say input lag is a myth. I said myths are being spread about it as you are doing and you are disregarding my previous reply where I explained how lag can be reduced. I reduced lag on Android to under a single frame while using a Bluetooth controller just to make it more interesting. I verified this myself and it is easy to reproduce those results. I am well aware of Taki Udon's video as that is also my main source that Android does not add any additional lag in most cases. Yes, the NES emulator he shows added an extra frame(half, actually). But you have conveniently left out that the other emulators he tested showed no difference whatsoever and that his conclusion doesn't support your assertion. If it was as simple as Android adding lag, they would have all shown that.

Another misconception is that those numbers you cite, such as 75ms, are purely input lag. That's total lag. Even original hardware on a CRT has a tiny bit of lag. The games themselves have a certain amount built into them too. The 75ms is the total of all sources of lag.

As I have said previously, I tested the lag in Retroarch myself on both Linux and Android. It has the ability to advance frame by frame. I literally counted the frames of lag. In most of the emulators I tried, the additional input lag was a single frame, meaning that an action happened on the second frame(between 16ms and 33ms additional). You might find that uncomfortable to play and that's fine, but it's not heavy. It was also the same on Android with Bluetooth. Some emulators that had two additional frames. But the "run ahead" feature can eliminate it. This has been verified by many people for years as the feature is not new. I did it myself. To be absolutely clear, using an Android tablet with Retroarch(SNES, NES, Genesis, Arcade) and Bluetooth controllers I was able to reduce the lag(which was typically one additional frame, or two in some cases which was the same as desktop Linux with USB) to under a single frame, meaning that the input action would happen on the very next frame of video. That's under 16.6ms and can't be any lower unless you're using a CRT and the game polls inputs a specific way. Again, everything I said is completely verifiable. This is why I refer to myths.

I want to be clear on something else. I have no issue with you personally. I think FPGA is a great option for people that want it. I don't want to try to convert you or anyone else from it. I used to be interested in it as a concept. But it's also not magic. I think there are some that might be steered towards it solely because of misinformation regarding software emulation. I don't want people to think they need hardware they don't otherwise want because of misconceptions on this topic, and I have demonstrated that this is a huge misconception. The real surprise to me here was that my Bluetooth controllers, two early 8bitdo controllers from 2015 and 2016, added no additional lag whatsoever. Now, we both know they have some lag, but it's clearly under 16.6ms since the only thing that matters for this is number or frames, so effectively they are zero lag. Even if they weren't, any additional frames could be removed with the "run ahead" feature. There's really not more to say other than try it for yourself if you won't take my word for it. Or go see it demonstrated in a video. You'll see that I'm correct in what I have said.

Another bloody handheld.
No thanks. ill pass, i'd rather hook one of these up to a screen.

@Bonggon5 There's that FPGBC thing.

@DestructoDisk I bought one of those kits and got a defective board. I exchanged it and the second board wouldn't load games. It's so annoying. I ended up getting a refund but I really wanted to love it.

@nocdaes I want the accuracy of FPGA without needing to spend tons of money on carts. Software emulation on other devices is not the same.

@SteveFox Why aren't you interested?

Wake me up when there's a picture of the actual thing, rather than Tinder-esque ultra-zoomed shots of tiny parts of it. I'm interested in the product, but I'm not going to ooh and aah over pictures of rendered buttons.

I bought an LG oled TV, and the burn-in and color degradation was terrible. Micro-LED is the next step in technology. Retro games especially will destroy this screen quickly. It's not if, but when. When will you first see it? When will it no longer be tolerable?

@KitsuneNight There is really only 2 current FPGA handhelds that I know of currently available. Unless you mean handhelds in general, which would be odd since this is a specific niche. Would someone say the same when a new phone comes out? Another bloody handheld.. plays games too. Or a PS6 comes out? Another bloody Roku.. streams videos..

FPGA handhelds are a tiny device lineup. I realize you may not care about the differences of an FPGA and an emulation device, but that still is a weird take.

I still don't know where I can preorder these things. If I don't get that Information soon, I'm just getting a retroid Pocket 4 Pro with a dock and loading with Arcade roms.

@Bonggon5 The 1500$ model... The only tech I ever got buyers remorse with. I just read and article that apparently they claim to have fixed the blue OLED problem, and OLED monitors should be coming and brightness is fixed with no burn_in. I don't trust it. I'm getting micro-led still.

@sdelfin Just to be clear, you are using frame advance to try and measure the latency for a software emulator? Your methodology is completely flawed for a real-world representation and to be completely frank, it demonstrates a real lack of understanding of both how these things work and what you are trying to measure.

By using frame advance, you are:

1. Eliminating any measure of controller input lag, including any wireless delay and USB processing.
2. Giving your software emulator essentially unlimited time to process each frame, which is the opposite of what it seems you are trying to measure which is the ability to keep pace in real-time with original hardware
3. Eliminated any measure of the latency of the particular display you are using.

What you have actually “discovered” with your result of about 1 frame of latency is in fact the latency of the original system, which for those without an OS or framebuffer will be for all intents and purposes, 1 frame, or about 16.7ms for a 60fps system. This is also coincidentally the time it takes a CRT to draw from the top left to the bottom right corners of its screen.

Rather than just be critical, I can suggest a low cost, low-tech way for you to do this properly:
1. Wire an LED into a particular controller button, such that when the button is pressed, it illuminates the LED.
2. Get a camera which has a proper slow motion ability, preferably 240fps like on modern iPhone or equivalent Android.
3. Start filming both the controller and the screen in slowmo whilst playing an emulated game running at full speed and press the button.
4. Open your video file in any software. Count the number of frames from when the LED light is first visible on the controller until the action is performed on screen (Eg Mario initiates his jump).
5. Divide the result by 4 if using 240fps for a 60hz console (or the relevant number based on your slowmo fps), and this will be the total input latency of your system, including controller, software emulator and display.

Edit: A similar result can be achieved with slightly less accuracy but more way more easily. Instead of the LED, use your finger to tap the button once as quickly as possible. Instead of measuring from when the LED comes on, time it from when your finger hits the button on the controller. This method would also be far better for handhelds.

I think if you measure this way you will be unpleasantly surprised. 😦

@SlCKB0Y I've been anticipating a reply like that. The lack of understanding is entirely on your part. This is exactly the type of myth I am talking about.

To address your points:

1 - it's not eliminating any of that. The lag is there using frame advance when RunAhead is disabled. Enable it correctly, and the lag disappears. You can very much feel it at full speed too.

2 - It's not the opposite at all. Emulators process and display frames. Using frame advance in Retroarch might do it slowly, but it's the same number of frames as it would be in real time(edit for clarity: Retroarch will process frames the same way with frame advance as is does at full speed). That's why the lag is still there using frame advance without RunAhead. The amount of processing power to process frames in real time for the older systems is trivial for many modern-ish CPUs(most of mine are a decade old), in the range of 1-3 percent CPU utilization. This is not an issue.

3 - display lag is largely irrelevant here. This is a huge reach on your part. Plus, display lag would be the same for anything using the same screen, emulation, FPGA, original hardware. It is a non issue.

In your suggestions, you are making the same fundamental mistake as others have. Taki himself did the LED test(and busted a myth doing so, as he intended). Even the original hardware has lag in that method. GBA had two frames in that test. GBA emulation had an additional two frames. That's total lag. The only thing that matters for this discussion is additional lag. If original GBA hardware has two frames of lag with that method, it is essentially zero for the purposes of this discussion because it cannot have more lag than itself and all the games would be made with that in mind. That means emulation has an additional two frames, not four. There's no need to do the LED test because, one, it has already been done, Two, it is irrelevant. The only thing that matters is frames. GBA has two frames of lag? Cool. I can take them out. Response is next frame at full speed. The responsiveness is instant and the performance is consistent if you play through games that way. There's no mistaking it.

As I have already said, all of these assertions are moot. If I were to do your LED test(no need), and if I was unpleasantly surprised(fallacy), I could literally just subtract more lag out of the game. If you know how RunAhead works(do you?), then you know that is possible and you should know it's possible to actually subtract more lag than the emulation has(and as I'm properly set up, there's no additional lag left, further proving there's no "unpleasant surprise" to find). That would of course be bad as it would eliminate visible frames and create a noticeable jitter, but it is also proof of what I have been saying. In fact, that's an experiment I think you should do. You will "discover" that what I have been saying is correct. I know this because I have already done it in a practical application, and others have been doing it for years before I ever bothered to try it. It works, and works extremely well. Remember, I'm not arguing lag doesn't exist, though it's typically very low(1-2 frames most of the time), I'm pointing out it can be removed, which it very much can.

I'm going to post this as a bit more reference material for those who want to get cute and tell me how wrong I am without actually knowing what they are talking about regarding emulation, lag measurement within emulators, and lag reduction.

-I just tested frame advance on a mid-range tablet using Bluetooth, just to stack the deck against me. I tested Metroid Fusion in mGBA, so a heavier 2D system compared to some others. Using the frame advance method, I got one frame of lag. I then set RunAhead to TWO frames of reduction which is one too many. While not always obvious with this incorrect setting, it introduced some jitter on scrolling due to how it works. This proves that using frame advance provided the correct measurement for full-speed emulation. There was no additional lag whatsoever at full speed. Bluetooth and the display added nothing in practical terms. If there was any additional lag at full speed, there would not have been any issues with scrolling. And if there was additional lag, it could still be taken out.

-Using frame advance is an established, accepted, and vetted way of measuring input lag in a practical way in this specific use case. Established by whom? Those who developed the RunAhead feature, and the emulator developers that implemented it. I think they have a pretty good idea of what they are talking about. It's been out long enough that if it did not work, that would have been demonstrated long ago. In fact, it has been demonstrated to work.

@sdelfin
I registered a new account because your smug know-it-all attitude really rubbed me the wrong way.

You got the fundamentals wrong. For some reason, you never thought about your frame of reference because you probably assumed that frame timings are universal across emulators, real hardware and FPGA solutions.

Your method only proves that frame pacing and lag are consistent on a) your device and b) your emulator of choice. Did you compare your results against real hardware or against FPGA devices? Of course you didn't.

FPGA solutions are cycle accurate implementations of retro hardware, something that the vast majority of emulators aren't. There's always potential for lag even if input devices are identical. Does it matter for the average Joe? Nope. Doesn't matter even for many speed runners, seeing as many a world record was set on the virtual console.

Are you wrong and did you shout your insolence into the wide web? Yes and that's really annoying.

@DasMiez The smugness is only because of people who are wrong insisting they know better. For example, the previous person's argument completely falls apart on point number one. Why? Because they assumed the input lag does not even exist using frame advance, when it absolutely does. There's no processing advantage whatsoever. That's the entire foundation of their position and it's a false premise. As for your argument, it is totally irrelevant. People say emulation adds lag, and I pointed out it can remove it. That's true.

You may want to check again how cycle accurate these FPGA cores are at the moment. Just recently on this site, an FPGA developer spoke about how his cores use hacks because they have to in order to work. I have no problem with that, just to be clear. But that's beside the point. People keep pushing this notion of emulation adding lag, which is true, but incomplete and misleading. I detailed how it can be subtracted after the fact. This is common knowledge as the feature has been around for at least six years. You do know that, right? Software emulation literally can provide next-frame response. Plug an FPGA into an LCD TV, and that's the best you can get.

Call me smug or whatever you want, yet you are no better. I already laid out in detail what my position is because of the persistent myths out there, and I detailed the procedure. You could go and verify it yourself because I know for a fact that it's correct. So you're just as smug and just as insolent. Except there's one difference. I'm right on this and everything you said here doesn't apply.

Edit: any perceived smugness comes from people talking at me instead of to me, with assertions that I have a "lack of understanding" while the entire basis for their claims is totally incorrect. Or they bring up things that are simply irrelevant to what I have posted such as different devices will have different lag, which only requires an easy change to the RunAhead setting to compensate and get next-frame response. The only thing I'm arguing is that lag can be removed in software emulation and I provided actual specifics on how that works in my previous points. The fact that people bring up totally unrelated things and seemingly don't verify what I have said, which is common knowledge now, I think speaks volumes.