zeromus

Wrong! It's in the "Continue Playing" section. The "Favorites" section contains four entries only: Henshin engine, Caverns of Death, SM All Stars, SMW. The person behind the camera asks, "these are backed up games onto the system?" while the cursor is on "favorites". The cursor now goes down to "continue playing" when the answerer replies "yeah, *these* ones are" with distinction. It's impossible to know exactly what he was referring to--perhaps what the questioner was effectively pointing at when he asked. But the retroblox guy hastens to add "there's a breadth of content here and something about the UI", perhaps distinguishing the backed up games from everything else which is the "breadth of content". So despite your poor ability to discern fine details, you might be right. I think everything in the top three categories has been backed up, and "continue playing" is just the same as "recently played". However, we can't conclude anything from this. We know it does scan the disc to see what's in there (tekken 3 pops up after some time on 'Now Playing') so it may as well run from the disc (if it has that capability indeed) when you play the high-level conceptual "game" entry and it knows that disc is inserted. Honestly, I don't even see what's so amazing about running a PSX game from a disc drive through software which has already proven it's connected to said disc drive by virtue of responding when it's inserted, considering PSX emulators have been able to do that since always. Even the least charitable interpretation of what these guys are doing should include the possibility that they've gone through no more trouble than is required to connect a USB disc reader and use an emulator core capable of reading it.

It's about the tactile feel of a cherished possession. It's about showing your reverence in a ritual way (try to set aside any scoffing at reverence undergird by emulation. That's a theological subject.) Rituals are supposed to be inconvenient. It's the out-of-the-wayness that makes it special. It's about following the same steps youve stepped every day since you were a child, inserting the disc and reading the manual while the game spins up. All your talk of convenience amounts to "wouldn't it be more more convenient to look at pictures of mecca for a couple of hours"? or "hey punk rockers, you could sweat a lot less if you just put a tape in a boombox and let that play". Museums and TBs of isos preserve. These guys re-enact. All that is a separate question from how he knows what the market is, which is a good question. That there's a demand is indisputable. The rest is questionable.

No, you can clearly see that Tekken was listed as a "continue playing" which I guess means it was savestated. When you launch that 'tile' it'd have to tell you to insert the matching disc (which it couldn't efficiently positively confirm, thus permitting the possibility of later dysfunction). This isn't how I would have done the UI.. I'd prompt you to load the state (if there was one) when you launch the game, and the "now playing" (not yet playing) "tab" that they launch tekken from definitely doesn't offer that option. So I can fault them for poor choices in UI design, but this evidence isn't automatically damning. It's worth pointing out though that the "hybrid emulation" would preclude some games from running from savestates. For instance, NES mappers almost universally have a bunch of volatile state which can't be known to the "hybrid emulator". So if we see this thing savestating NES games, we'll know it's just vanilla emulation. Notably, I did not see any NES games savestated, or in pictures, etc. in their UI. If these guys arent making a more clear distinction between "hybrid emulation" and vanilla emulation from backups, then they're either over-hyping hybrid emulation or confusing their users with bad UI. If it's bad UI, I'd suggest they have a separate "hybrid mode" which whisks away the other UI and just shows what's inserted, and only what you can do with it. Which would include dumping. It is notable that tekken doesn't show the PSX bios splash stuff. Seems like that would have been an awful lot of work for some busy guys who should actually be thrilled to show an actual boot splash there to have hacked an LLE bios (necessary for anything like good compatibility) to skip the splash. So I guess it's only running with someone else's HLE'd bios now, which should in turn tell you something about which emulators it's using and what their compatibility level is.

I'm more interested in supposing they're not flat-out lying about "hybrid emulation" and figuring out how they might can pull this off, instead of figuring out why they can't. "Synchronization is hard" doesn't cut the mustard, and "systems timing is unreliable" doesn't make sense. Are you telling me you can't setup a realtime kernel and configure an ARM system to run code out of a non-cached region, or alternatively, reconfigure the cache to be TCM instead and run out of there? Nintendo's made a lot of games that run at 60fps steady on ARM systems, including emulators! First of all, "Full hardware compatibility" is obviously a lie. So reckoning backwards from that to the impossibility of doing what it would take to achieve full hardware compatibility isn't useful. So let's stipulate that they're not beholden to USB timing shenanigans for reading their pads, because why not GPIOs? That's how it works on the game consoles, approximately. And it doesn't matter anyway: simply have one thread continually reading the pad input and parking it in buffers for the main emulation thread to pick up at the moment it needs it. That doesn't introduce any latency beyond the GPIOs (nobody can detect it) or beyond USB (only wizards can detect it). They could do all this without compromising their claims of low latency, because marketers have that power. Wait states on GPIOs for reading the cart -- I'm not an expert about this, but a few minutes of googling show ARM advertising GPIO "operating speed in excess of 150mhz" so this is almost sounding negligible. How about having to turn the emulator inside out in order to be able to mix the rendering with the main thread cpu emulation? My answer is: don't. Read/evaluate the PPU and ship the bytes off to another buffer, to be rendered all at once or even pixel by pixel truly in parallel. Now, the latter isn't the easiest synchronization in the world, but it's still a relatively simple pattern since it's simply a reader and a writer. We do have problems with situations where the cpu can read data back from the PPU or APU. Consider that the bulk of the novelty in this emulator. In both cases only a subset of the emulation needs to be done on the CPU thread (on the NES, only sprite 0 at a limited level; and the APU.. well.. maybe about 80% of it needs to be done there. That's starting to feel like enough logic that it may need to be broken into a several-stage state machine with only one stage ticked per clock out to the cart. Now's a good point to mention that this isn't such mad science that you couldn't prototype it on a workstation and IDE of your choice, thus accelerating development. You would only need to make sure you weren't busting your CPU time budgets once the code compiles and runs for ARM. What's more, they could have developed it before even having the hardware ready, given certain assumptions. Any of us could make this emulator right now as a proof of concept before dedicating our careers to getting it put in HW. Business considerations making all of these emulators in time -- ahh, but they can slip on shipping a few modules and as long as the product is real and proven, they can take some heat and survive. That's the real power of the modular design. What concerns me more is why a system built this way would have any provision for dumping and storing ROMs. Or even how it would do that -- it can't be reliably, and it adds an unneeded piece to their mountain of tasks. Maybe it's a value-add for convenience, but their userbase likes plugging carts, so I don't get it. Maybe it's so they can support patches, translations, etc.