8 ms·

If anyone in unaware you can buy the very impressive Pocket. https://www.analogue.co/pocket https://www.analogue.co/pocket The current list of what it can do w

• jonny_eh 3y ago
  I also recommend the official dock. It basically turns it into an easy to use Mister.
• gchadwick 3y ago
  There's also the MiSTer project: https://github.com/MiSTer-devel/Wiki_MiSTer/wiki https://github.com/MiSTer-devel/Wiki_MiSTer/wiki. Not hand-held (yet...) and hardware is less slick but a bunch more systems and also fully open source.
  • phendrenad2 3y ago
    MiSTer makes me kind of sad, the DE10-nano board it's based on is 7 years old at this point, and the actual FPGA chip on the board is probably over twice as old as that. And this is still the peak of hobby FPGA chips. I wonder why Moore's Law is hitting the FPGA industry particularly hard all of a sudden.
    • willis936 3y ago
      There are better FPGA options, they're just more expensive. The DE-10 Nano was strategically chosen as "powerful enough to meet most wants while still being within a reasonable budget". No one's going to plunk down $10k for a 19 EV Zynq UltraScale+ with 1.1M LEs, but they will spend $200 on a Cylcone V with 210k LEs.
      • fooblaster 3y ago
        There are mpsoc ultra scale+ chips that are under 100$ these days, so I think that's not true anymore. Even low end mpsoc ultrascale fabric is way better than that old altera stuff, with lut4 clbs, ultraram, and better dsp blocks. I've had the fabric run at 500 mhz in my designs. https://www.avnet.com/wps/portal/us/products/avnet-boards/avnet-board-families/zuboard-1cg/ https://www.avnet.com/wps/portal/us/products/avnet-boards/av...
        • rtkwe 3y ago
          The issue with any other board is that the boards aren't going to have all the same ports and compatibility so you'd have to have potentially two largely separate forks of the cores and accessories which would be tough in a relatively small community like the Mister. For example your board doesn't have the large pin headers used by basically every Mister accessory so at a minimum you'd need an adaptor to go from some other port on your board to the pinouts that the mister ecosystem is built on.
        • phendrenad2 3y ago
          What kills that board (and many like it) is the absolutely proprietary SYZYGY connector, which is surface-mount (so hobbyists won't develop a board ecosystem for it, and aliexpress circuit cloners won't do their thing unless there's a proven ecosystem), and probably $10 in high quantities (if it's even in stock). RIP. I'm not even sure that board has enough overall I/O to connect a VGA output, controller inputs, and a SDRAM chip (all of which are essential to a viable MiSTer replacement - note that no one has figured out how to use DDR RAM for emulation yet, too much seek latency).
• MrHeather 3y ago
  The article says FPGAs are too power hungry for handheld devices. Did Analogue do anything special to solve this problem on the Pocket?
  • agg23 3y ago
    That's honestly not true at all; it all just depends on your platform. On the Pocket, the FPGA _is_ the processor (there are actually two FPGAs, one for the actual emulation core, and one for scaling video, and there's technically a PIC microcontroller for uploading bitstreams and managing UI). The FPGAs are still not much power compared to the display itself. With the in-built current sensor on the dev kits, the highest we've measured drawn by the main FPGA is ~300mAh. Now this sensor isn't going to be the best measurement, but it's something to go off of.
    • WhiteDawn 3y ago
      Personally I think this is the biggest selling feature of FPGA based emulation. The reality is both Software and FPGA emulation can be done very well and with very low latency, however to achieve this in software you generally require high end power hungry hardware. A steam deck can run a highly accurate sega genesis emulator with read-ahead rollback, screen scaling, shaders and all the fixings no problem, but in theory the pocket can provide the exact same experience with an order of magnitude less power. It's not quite apples to oranges of course, but the comfortable battery life does make the pocket much more practical.
      • agg23 3y ago
        When being nitpicky about latency is where FPGAs truly shine. You lose a good bit of it by connecting to HDMI (I think the Pocket docked is 1/4 a frame, and MiSTer has a similar mode) (EDIT: MiSTer can do 4 scanlines, but it's not compatible with some displays), but when we're talking about analog display methods or inputs, you can achieve accurate timings with much less effort than on a modern day computer. For a full computer like the Steam Deck, you have to deal with preemption, display buffers, and more, which _will_ add latency. Now if you went bare metal, you could definitely drive a display with super low latency, hardware accurate emulation, but obviously that's not what most people are doing.
• agg23 3y ago
  Not to draw attention to myself or anything, but if you're interested in learning to make cores for the Analogue Pocket or MiSTer (or similar) platforms, I highly recommend taking a look at the resources and wiki I'm slowly building - https://github.com/agg23/analogue-pocket-utils/ https://github.com/agg23/analogue-pocket-utils/ I started ~7 months ago with approximately no FPGA or hardware experience, have now ported ~6 cores from MiSTer to Pocket, and just released my first core of my own, the original Tamagotchi - https://github.com/agg23/fpga-tamagotchi/ https://github.com/agg23/fpga-tamagotchi/ If you want to join in, I and several other devs are very willing to help talk you through it. We primarily are on the FPGAming Discord server - https://discord.gg/Gmcmdhzs https://discord.gg/Gmcmdhzs - which is probably the best place to get a hold of me as well.
  • Willish42 3y ago
    This is awesome! Thank you for sharing and documenting this so ardently. I don't have a Pocket yet but look forward to trying this tomagotchi core when I do, and maybe learning more to become a contributor when I have some spare time. I've always wanted to get more involved in emulation and this seems like a perfect scene to get involved through
  • yakaccount4 3y ago
    Which would you recommend is better to get started with: MiSTer or Analogue Pocket (non dev edition)? The workflow of testing new cores on AP if you don't have Developer Pocket seems kind of nasty.
    • agg23 3y ago
      The workflow is actually the exact same for the dev and retail Pockets. Both have an exposed JTAG port, but for the retail Pocket, you just need to remove the "hump" on the lower back. You want to make sure you get an official USB Blaster (https://www.mouser.com/ProductDetail/Terasic-Technologies/P0302?qs=ePbE9GiMmvVJztTDlxPoAw%3D%3D https://www.mouser.com/ProductDetail/Terasic-Technologies/P0...), because they negotiate a lower voltage level with the Pocket (someone blew their JTAG port using a cheap one). For a beginner, the Pocket is definitely easier. With MiSTer, you're building a bunch of other framework code that isn't your own, and that adds a lot of iteration time. I also think the Pocket APIs are more refined, but also more limited. I've already written some info about this - https://www.reddit.com/r/fpgagaming/comments/1318jsr/tamagotchi_for_pocket_and_mister_now_out/jhzmbj6/ https://www.reddit.com/r/fpgagaming/comments/1318jsr/tamagot...
• sph 3y ago
  My mind is blown but I'm also wondering if this isn't some kind of incredible over-engineering? Surely CPUs are fast enough to emulate these kind of devices in software. If they aren't, they must be an order of magnitude simpler in complexity. I wouldn't ordinarily care about emulators, but actual hardware emulators is the craziest thing I've heard in a while. All that for a small handheld console? If only I was not so broke...
  • lprib 3y ago
    Sure it would probably be cheaper to chuck a cortex-A* or similar mid-range MCU in there. One advantage of FPGAs that it can achieve "perfect" emulation of a Z80 (or other) since it's running on the logic gate level. No software task latency, no extra sound buffering, etc. It can re-create the original clock-per-clock.
    • arein3 3y ago
      It's impressive as well
  • agg23 3y ago
    Software is orders of magnitude simpler in complexity, yes. The difference between a software emulator and a logic level emulator are immense. But take the example of the difficulties with a software NES emulator: In hardware, there is one clock that is fed into the 3 main disparate systems; the CPU, APU (audio), and PPU (picture). They all use different clock dividers, but they're still fed off of the same source clock. Each of these chips operate in parallel to produce the output expected, and there's some bidirectional communication going on there as well. In a software emulator, the only parallel you get is on multiple cores, but you can approximate it with threading (i.e. preemption). For simplicity, you stick with a single thread. You run 3 steps of the PPU at once, then one step of the CPU and APU. You've basically just sped through the first two steps, because who will notice those two cycles? They took no "real" time, they were performed as fast as the software could perform them. Probably doesn't matter, as no one could tell that for 10ns, this happened. You need to add input. You use USB. That has a minimum polling interval of 1000Hz, plus your emulator processing time (is it going to have to go in the "next frame" packet?), but controls on systems like the NES were practically instantly available the moment the CPU read. Now you need to produce output. You want to hook up your video, but wait, you need to feed it into a framebuffer. That's at least one frame of latency unless you're able to precompute everything for the next frame. Your input is delayed a frame, because it has to be fed into the next batch, the previous batch (for this frame) is already done. You use the basis of 60fps (which is actually slightly wrong) to time your ticking of your emulator. Now you need to hook up audio. Audio must go into a buffer or it will under/overflow. This adds latency, and you need to stay on top of how close you are to falling outside of your bounds. But you were using FPS for pacing, so now how to you reconcile that? ---- Cycle accurate and low latency software solutions are certainly not easy, and it's impossible for true low latency on actual OS running CPUs. Embedded-style systems with RTOSes might be able to get pretty close, but it's still not going to be the same as being able to guarantee the exact same (or as near as we can tell) timing for every cycle. I want to be clear that none of these hardware implementations are actually that accurate, but they could be, and people are working hard to improve them constantly