Kismet

I thought it had a way to customize the palette. As for "what are the correct colors" that depends on the equipment. Take for instance the color palette on the WiiU virtual console. If you look at your HDMI screen, it will almost certainly be too dark because Japanese games were NTSC-J, while North America games were NTSC-M. Then look at the WiiU controller screen and notice the color doesn't even match what is on the HDMI screen. From wikipedia: https://en.wikipedia.org/wiki/NTSC-J That is why NES/Famicom games look really off on the HDMI screen, because the HDMI monitors sold in North America are calibrated to sRGB, which is roughly 74% of NTSC colorspace. Plus you have the 16-235 vs 0-255 (which is another reason for dark pictures or over-saturated ones.) A TV is calibrated to do Rec. 601 (SDTV) Rec. 709 (HDTV, and sRGB) and/or rec.2020 (UHDTV) You can not be sure the NT Mini produces correct output over the HDMI connection primarily because you can't rely on the HDMI monitor or TV screen to be setup correctly. Capture equipment will typically switch to Rec.601 over Composite/S-Video but will switch to Rec. 709 over RGB/YPbPr. So the question about "what is the correct color" is really a question of "what color do I see?" Let me take my own images for examples: Real NES, NTSC-J, Composite Real NES NTSC-M, Composite WiiU - Bypass BT.709 WiiU - Expand BT.709 WiiU - Shrink BT.709 Thing to note, the WiiU Tablet shows the sky as Blue. So there is something certainly different going on here, and this is typically why the WiiU's NES emulation gets put down frequently for being so dark. All captured on SA7160 ( micomsoft sc-512n1-l/dvi ) See http://www.firebrandx.com/nespalette.html(updated two days ago) about NES Palettes on the NT Mini

Eh, no. Consider the following: 1. A student with little money is going to university, packing three of their childhood consoles to school and the games probably fills an entire suitcase, that suitcase costs $50 to take on an airplane. Plus there is the risk of it being lost, stolen or damaged in the process. The solution here is to replace all of that with one device. My sister did this with her music collection, she ripped all the CD's and then took only the computer to university. She left the Playstation and SNES at home. For the "travelling light" person, being able to store everything in one small box (even if the emulation is poor) is better than trying to take all the original equipment. 2. A collector of classic games, the convenience if being able to play games (usually from an expensive flash cart/FPGA cart) is worth being able to preserve the original cartridges and reduce wear on taking them out. Only when you're doing preservation efforts do you take the physical carts out (eg dumping or recording, taking apart to photograph.) Likewise a FPGA console that can play the games exactly like the original hardware is preferable to a software emulation that is hobbled by the processor power, or lazy one-size-fits-most solutions like libretro. So the collector will likely buy most of these emulation devices just to have and compare, but they will ultimately only use the ones that work the best, and "hybrid emulation" seems like snake oil to them. If someone comes out with a new libretro system every year, the collectors will get rightfully mad over seeing the exact same thing in a different shell over and over again. 3. The pirate. The pirate owns little to no games, doesn't care how they acquire them, and has no way of verifying the accuracy of such games, because they've never played on real hardware. These are the kinds of people these software emulation devices are targeted at, because they know the pirate will just side-load their own games. The physical cartridge slots or cd-rom drives are just there to give it a look of legitimacy. The Pirate is most likely going to invest in their PC, or invest in a stand-alone emulator device regardless of the accuracy just so that they can use their computer for other things. 4. The LP/Youtuber/Streamer. From a legal perspective, you should only be recording games that you own the physical media for. In practice most people play them on a software emulator because hardware FPGA emulators have not been available until last year. Even then the recorder is more likely to play a game from a flash cart if they are just casually playing the game so that they can save-state the SRAM to avoid having to backtrack through the game if they make a mistake. One of the things you do to prep a LP or a stream is pre-play the game and make copies of the save game at various points so that if you screw up, you don't have to redo the entire recording. If you're reviewing a game, you make need to make multiple takes and thus it's easier to pre-record the video rather than live. In theory a software emulator that supports save-states is preferred to do video recording, but unless the emulator is high accuracy (eg Higan) in the first place, it will be immediately obvious when a video is recorded from an emulator, and hence these libretro devices. The real risk that is going to happen sooner than later is that people will record video of games, and not cite how it's played (to avoid DMCA takedowns), thus it will be up to people with the real hardware to upload their own videos of how the game is supposed to look and sound. Preservation is going to become more important than ever. It's too bad there are too few people who know how the games are supposed to look AND how to record video properly. 5. Electricity is expensive. The final, and least justified use of these devices are to save energy. The FPGA IIRC uses less energy than the Retropie, but the Retropie uses less power than the desktop, in which a desktop PC might consume 70 to 300 watts just to emulate one device. The Retropie might be between 1 and 10 watts, and the FPGA would depend on what size the FPGA is. The original device's power bricks might be around 20 watts. These are estimates as I have yet to see a controlled test.

I think decapping the chip crosses a copyright line that you don't want to cross if you don't have to. With the SNES, decapping is required on the expansion chips (that's how the DSP roms were acquired), but part of the fun of a FPGA is figuring out how exactly to reproduce the output from the inputs.

The same can be said about "romsets" for game consoles, as I've seen twice now in other threads references to NES romsets. My personal opinion is split down the middle about piracy. If piracy didn't exist, all these games would just vanish, and when commercial entities go bankrupt and their assets sold off, some of these companies don't even realize they are sitting on something valuable. This is the rather backhanded moral imperative to pirate everything. That is why working "romsets" end up being created for computers, consoles and arcade games, otherwise there is no viable way of re-implementing the hardware if there is no known-good version of software. I will lose no sleep over seeing pirated ROM's as long as the original company isn't selling a license to use the ROM's themselves. What we learned from the mp3 race to put music online, is that the casual piracy doesn't even hurt sales, and the opposite is true, not making the software/music/film able to be accessed is what increases piracy of low-quality copies. When you offer a convenient alternate (eg Wii Virtual Console) that imperative to pirate the game goes away until that console is no longer able to use the alternative, and then it's back to the race to preserve software again. I'm sure half the Wii/WiiU/Xbox Live/PSN titles that were download-only are going to be lost. The kinds of software we will rarely ever see resurrected are licensed titles (eg movie/tv licences) as the original license holder will not see any value in resurrecting old software and arcade machines (I've seen this exactly twice so far) and if someone else holds the license, that old software is likely to never see the light of day again. Going back to my original example and adding one. The "Scott Pilgrim" game is a movie license, it's since been pulled and the game is no longer available, the only way you can get this game (and all the DLC) is by finding someone who bought it on their xbox 360 or PS3 when it was out and borrowing the entire console.) A similar thing happened with "The Simpsons Arcade game", where Konami re-released it for Xbox/PSN and then pulled it, where EA created a new game inspired by the original game for mobile. The Ducktales NES game got completely re-engineered by Wayforward which involved both Capcom and Disney, and they remanufactured 150 of the original NES carts (gold with new label) for a promotion for it. I kinda wish there was the same level of enthusiasm for licensed video games as there are for licensed comics. Obviously the IP holders know the IP has value, but still seem soured on licensed games (due to their bad reputation overall.) Which goes back to the original question about the purpose of emulation. If emulators are released under permissive licenses (BSD, not GPL) then the original IP holder has zero reason to just sit on the IP, when they can quite literately get a pirate copy of their own game that was preserved by the pirates, and a working emulator, package it in some kind of GUI wrapper or GUI+steam-achievement wrapper and sell it again. People are more than happy to buy something again and again on their newer devices as long as the IP holder isn't sueing their fans.

I think the main obstacle for doing arcade systems in FPGA is the lack of being able to sacrifice a PCB to get the exact timing mechanics from the chips. Some chips like the 6502 and Z80 are closer to off-the-shelf models because the arcade boards are not produced in large quantities (other than hardware which are essentially the console/computer hardware with a different boot configuration or clock speed.) But you still have custom chips on 8-bit and 16-bit systems. So in theory, at least, some of the less complicated 8-bit/16-bit games could be done on the Z3K just by virtue of the game being identical to the home-console/computer version save for the coin interface (eg Puzzle Bobble/Bust-a-Move comes to mind) but I think trying to do these in FPGA would require a more open platform where the CPU/GPU/APU cores already done can be wired correctly to the ROM's used. It would still require reverse engineering the actual arcade boards, but I doubt any single person can do it except for some standardized boards like the Sega/Taito/Konami/Namco boards that had multiple games used on otherwise identical PCB's

If we're nitpicking, the 15pin VGA connector is DE-15, while the 15-pin gameport/famicom/neogeo port is DA-15 As for the naming scheme https://en.wikipedia.org/wiki/D-subminiature Basically, anything called "DB" is actually wrong from the original naming scheme because the second letter is the shell size. So the technically correct name for VGA is DE-15. The connectors we all call DB-9 are actually supposed to be DE-9. Source Wikipedia: Basically, only the DB-25 connector is the right naming scheme. If we're only considering cost, apparently D-sub connectors are more expensive than others. Just manually looking at digikey, the PCIe connector is the cheapest "card edge" at 15 cents (36 contact). The cheapest D-sub that can be mounted to a PCB is 1.19 (cheaper available if you order several hundred and have 10 weeks to wait), 19-pin HDMI connectors are 35 cents. USB-C has 24 contacts and are 88 cents. Hmm I wonder if it would be reasonable to use a usb-c connector that detects if it's connected to USB or something else. Might be bad practice to do that, though it would be more "futureproof" if that's what's used for USB. It's considered bad practice (just like using the HDMI connectors for non-HDMI things) because someone might confuse the proprietary-use ports with the one actually meant to be used for that purpose. I can't really think of any other connectors that aren't expensive and widely available that people won't accidentally confuse for something else other than the SATA-power connector, and the last thing you need is someone plugging in a SATA power connector and frying things with 12 volts.

Depends on the context but here goes: Board games: Monopoly, I'm too good at it and my sister will not play it with me Video games: Mario Party if one of your friends (the person who owns the console) is good at it and everyone is awful at it Also applies to fighting games like Smash Bros MMORPG's: Trust me when I say this, but if are really friends with someone, you play the game together, and don't run ahead of each other. I've gone through at least 4 MMORPG's where friends I made in one, wanted to play something else for a while, but the person who was good at MMORPG 1, is also good at MMORPG 2 and has run circles around us by the second time we play that game. Repeat with 3 other games. Suffice it to say, if you want to enjoy a MMORPG, play it solo and just treat everyone you meet in it as a stranger. That said, the only thing worse about destroying friendships with games, is destroying your employment opportunities with it. If you know your boss or co-worker plays a game, and is good at it, don't play it with them, don't even acknowledge that you know they play it. When WoW came out, it started destroying peoples social lives at the first place I worked at, and I had no idea what game they were playing but eventually I did figure it out and I made sure I steered clear from it because my boss also played it and would bring it up with some other employees. The preference with party games (eg Monopoly, Mario Party, etc) is that they are supposed to be short games that you can complete in like 2 hours. People won't get too upset over it unless the same person always wins, and then people are no longer having fun.

Adding yet another box. Why not use the original device then? The ideal setup for most people is you plug your HDMI devices straight into the TV, and if you have a home theater, the TV routes that audio to the theater setup. If you can replace 30 consoles, computers, and hdmi switcher/upscaler/splitters with one box, that is the right solution. However the TV and Monitor manufacturers don't care about legacy support, so anything you can do to reduce latency, including bypassing the upscaler is beneficial. If you have kids and you don't want them wrecking your classic computer/console equipment, that is where you hand them the Z3K and an after-market wireless SNES controller so they don't send the console flying when they throw the controller. I'll use an analogy here. Those "Kodi" devices people are selling on nvidia shield (also $200) can do a lot of stuff, including playback of HD video, but it has no native games for it. You're not going to buy it just to get the same experience you get on the Retron5 ($160) or even a desktop pc. These are expensive gadgets that do everything poorly or just passible. kevtris took a Retron5 apart and noted that it had over 140ms of latency with the wired controller. If I want a passable experience, I'll just play the emulated console or computer, on my $2000 PC with my Xbox 360 controller. I'm not putting down the MiST, I am however saying that device falls way too short of a zero-latency HDMI solution that you would want for playing games. It's good enough if you are playing on CRT VGA screen. That FPGA computer is capable of good output, but only with a CRT. If you have to run it through an upscaler then you're back to the original question of why not just use the original hardware with an upscaler.

I find the tradeoff with the MiST unfortunately is that it uses the VGA and not HDMI, so even if it was powerful enough to emulate a SNES or NeoGeo, it doesn't solve the primary problem in common with emulating all CRT-era computers and consoles, and that's the inability to use a LCD screen, bypassing the screen's useless upscaler and the latency that comes with it. The RetroUSB AVS and the NT Mini solve that (at least if you use a 720p or 1080p screen respectively) but we're now coming around to the 4K screens which require HDMI 2.0 or Displayport (or Displayport/HDMI over USB-C) which is going to begin yet another cycle of "my monitor doesn't have that connector"

I think this just means that the cartridge bus only emulates the minimum required to NOT identify a flash cart. When people use FPGA-based NES multi-carts the cart emulates some functionality of the cart, the address pins on the cartridge will only let it see the 64KB or whatever is mapped into the NES memory space. Hence it can't copy a game from a multi-cart because there is no way for the emulation device to bypass the cart-selection screen and select a cart directly as only one cart will ever be emulated. Likewise with any other system. So it's not that they detect an Everdrive, but rather that the cartridge bus only ever shows the PRG and CHR to the device with a NES. That is a design mechanic often done using RAM on the flash cart, there is no way to address anything that is physically stored on the cart. Like in theory you could select the game on the everdrive, and then bring up the menu on the emulator and say "dump now" and it will make a half-assed attempt at dumping the game if the everdrive emulates the mapper correctly. But in practice, "hybrid emulation" is not hybrid anything. It's simply yet another libretro thing, and the experience will not be any better than previous attempts like RetroFreak and Retron5

Using the VGA (not DB25 (which is the serial or parallel port)) connector is what I suggested two pages back http://atariage.com/forums/topic/242970-fpga-based-videogame-system/?p=3699492 The main concern when using a cheap and available connector for a non-standard purpose is that there will be an inevitable person who tries to plug the wrong thing into it. That's the same reservation I have with using the HDMI connectors that the Blissbox uses. If someone plugs in the wrong thing (you can't key-pin a HDMI connector) then you either burn the PCB in the controller, or you burn the PCB in the Z3K if it shorts or supplies power on one of those pins. Fortunately the VGA connector only expects power on pin 9 for DDC on a newer monitor, so you could either plug this pin (thus only OLD VGA monitors that do not expect power could accidentally be plugged in, pin 4-8 are all ground or n/c on these, as well as 11, 12 and 15 for indicating superVGA) or use this as +5V for all devices connected to it. Likewise with the PCIe connectors, but this is a much easier thing to prevent connecting PCIe cards since the Z3K has the "card edge" connectors and there is no way you are plugging a Z3K into a i7 motherboard. However just the same in case someone is really trying hard, you'd still want to key voltage pins to the same pins and n/c anything that would burn the PCB if over voltage is returned on it. The VGA connectors on digikey are 75 cents to 1.50/ea, the DB15 (gameport) style are 2.50/ea. Buy them in large quantities and the price goes down pretty quick Female version http://www.digikey.com/product-detail/en/amphenol-fci/ICD15S13E4GX00LF/609-5181-ND/1536501 Male version http://www.digikey.com/product-detail/en/assmann-wsw-components/AHDS15A-KG-TAXB/AE11036-ND/1241909

Basically you are either capturing for "archival" (museum footage, source videos for compilations) or capturing for "editorial" (youtube, streaming), the latter is usually done with USB capture devices that use cheap h.264 fixed function cores, so you get the best quality out of them by making sure the compression aligns on the same block sizes. The former you want to retain the maximum quality without sacrificing compressability. So you need to have an even-multiple capture (eg 1x,2x,4x) if you're capturing it pre-scaled from the NT Mini. If this means the source video is captured with pillarboxes or window boxes, you'd crop those out. MPEG video codecs prefer even-sized frames and power of 2 blocksizes. Other codecs (eg ZMBV (dosbox), lagarith, huffyuv and so forth) don't use block-based compression, so they will compress a solid black area as if it were one pixel per scan line. MPEG video codecs on the other hand will treat "blank space" as non-moving space in the compression, so if you have pillarbars or windowsboxes, those are still treated as if the entire screen is filled regardless of what is in it.

I think this would just duplicate the OSSC's efforts. That said, this is essentially what the second FPGA in the Z3K is supposed to be doing. It would not be a big stretch to have a RGB input (either through a VGA or SCART connector) and a HDMI output. Hey maybe the Z3K analog board could also work in reverse and accept an input and send an output over the HDMI.

No idea off hand, but on some dev boards, it's actually done by the PIC microcontroller, not the FPGA. http://opencores.org/project,usb_phy, 111 LUT's ( Spartan II XC2S50), (PHY means the physical interface, doesn't include HID driver) I suppose the driver would have to be written to wrap whatever is physically plugged in against the CPU computer core being used. Information out there is kinda sparse as to what it would entail, but I imagine that using the FPGA resources is the more ideal mechanism, but it might not be suitable for the NT Mini, but something plugged into the 15-pin famicom expansion port could be since done on a cheap microcontroller. eg http://www.hobbytronics.co.uk/usb-host-keyboard Anyway, I imagine a Z3K would have more resources to do a computer. Also note on the MiST you can't plug in two mice, as only one is supported. So a two player game that would use it like Lemmings or Marble Madness on the Amiga would be impossible. So it may be desirable to plug in a USB mouse into the controller ports anyway for console/computers that had mice setup that way (like the Amiga and the SNES) but on the NT Mini that's not likely to happen. That kinda leads me to another question that I hadn't thought of till now. I wonder if 8bitdo would make a "classic computer" keyboard ala amiga/c64/atari/etc layout for the NT Mini or Z3K

IMO, the entire modules thing is something that independently could have been thought of, since that is pretty much a throwback to how 8-bit systems were designed (console+keyboard, or keyboard+optional console carts) like the Atari/Coleco, Commodore 64 and a few others. That said, I'd rather see the "emulator device" separate the cartridge bus and controller bus in any hardware emulator. Like with the Z3K, The video bus and the expansion (cartridge/controller bus) are the modules. The RetroFreak moves the expansion bus into a separate pieces but they're connected by two USB ports (and a PC can see the cartridge bus segment as "PCB".) But the end result is that none of these things are compatible with each other, even when they use USB ports. The reason the Retrofreak gets a fair amount of hate (less than Retron5) goes back to what it is, it's a fork of libretro. The Retron and Retrofreak only differ in their packaging, but the emulation part is no different than any ultra-cheap Raspberry Pi. So you're paying for packaging but not getting any reliability guarantee out of it, no warranty. If someone wanted to do something sane, the thing to do would be to make a multiplexed cartridge bus adapter (or multiple adapters) that has a single cartridge slot and you daisy-chain them together with controller-bus devices. Then you put a the emulation box on one end via USB or your PC if you are going to use a software emulator, or you plug a hardware emulator into the other end of the bus. Saves space, makes replacements easy, and if the bus is simple enough, other people can make their own adapters using off-the-shelf parts. But I digress, I don't think there needs to be any more libretro-type of devices. They've been done, they're not very good and are reflecting very poorly on the "emulation scene", and thus we get companies like Nintendo releasing their own essentially identical single-purpose device and going "nobody is going to care about a few bugs as long as it works", 5 years from now most of those software emulators on an ARM box will be in closets collecting dust or landfilled because they don't work or something else will be a better experience.

It's a question about saving space on the FPGA. Right now, we don't really know what can be plugged into the USB port as it's only listed as "charging" on the FAQ. If it's only able to charge, then it's not useful. If it it's addressable by the FPGA then it still needs a HID driver.

Yes but look at the schematic for it. It's very likely a USB/AT/PS2 to Famicom expansion port would be easy to make, and then the FPGA NT Mini wouldn't need to have that logic in the FPGA to do Family Basic or C64 Basic, Apple II basic, etc.

I would suggest considering your target playback device. If you are only targeting widescreen 1080p then leave the footage as-is. It's considered bad practice to add pillar boxes or other "filling" imagery unless you are editorializing (eg youtube) to mix it with content that is 16:9 ASR. Otherwise it just makes the data larger and lowers the compress-ability. The reason is, if you are simply playing the footage back, there are 4:3 devices out there (Eg iPad's) that adding this padding will make less of the playback screen available. If you are actually capturing at 16:9 from the NT Mini, then you would want to reduce the zoom to 4x and crop the entire windowbox.

Now that I think about it, there is a "relatively" easy way to get a keyboard on the NT Mini. Emulate the Famicom Family Basic keyboard through that i/o connector on the back. I say relatively, because I have no idea if that port is mapable to anything outside the famicom.

More resources are required to do HDMI. The MiST only does a resistor-ladder VGA which is the same thing that VGA on cheaper development boards do. (They're only capable of 4-bits per channel, so they can only do 4096 colors), MiST apparently can do 6-6-6. But in order to do DVI/HDMI you need to either do it on the FPGA, or you offload it to a framebuffer/scaler HDMI ASIC, which defeats the purpose of trying to eliminate latency. A C64 Games System (eg the console version of the C64) should be completely doable since it's the same CPU as the NES, however the SID emulation is likely more complicated than that found in the NES.

My opinion here, on a 'final' board, you would want to either: a) Use all USB ports on-board and do something like this with the pcie-connector expansion bus (eg, daisy-chain a controller bus from the expansion bus), so that you can have just the controller ports, just a cartridge port, or both, and could mix and match controllers.) And thus it's an additional thing to build. Or use the 8bitdo BT/USB connectors on the USB ports. b) Use 4x DB-15 connector (that covers essentially all known pre-USB joysticks, including the NeoGeo and PC) and have a DB15 to DB9 pin converter for DB9-based joysticks, Making sure that +5V is never electronically connected (pin 8 on neogeo, 11,8,9,15 on PC) until the joystick is identified. DB9 +5V is pin 5 for Sega, Pin 7 for Atari and Amiga, Pin 2 for Apple II. NES, SNES and PSX use proprietary connectors, where the PSX uses +9V(rumble) on pin 3 and +5/+3.3V on pin 5. The SNES has +5V on pin 1, +5V on pin 7 for NES, and apparently the NES and SNES controller bus are identical. The drawback to using DB-15 is that it's dongle-mania. On the plus side, DB15 are also used for JAMMA units and thus such converters may already exist using the NeoGeo pinouts. c) Use a different 15-pin connector (eg the VGA connector (which is what Red Octane did with the DDR metal pads http://www.ddrgame.com/metpadparts.html)) and use a pin-adapter box with DB15, DB9, NES, SNES, PSX or whatever else on it. Then you just buy as many pin-adapters as needed. This makes it impossible to accidentally plug something in that will fry the z3k or the controller (Pin 9 of a VGA has +5v, so to prevent someone plugging in a monitor, might want to plug pin 9.) As for a keyboard, you would need to use USB, although some people would probably want a PS/2 connector, you could provide the PS/2 connector over one of the "game port" bus connectors. The main consideration most of the time for keyboards is that with the exception of macro keyboards, the USB keyboards and mice haven't changed since the 1998. Macro keyboards would not be support since it would be unlikely to select a keyboard HID protocol other than boot (6KRO), so the z3k would need to support multiple HID's and that starts getting into complexities that might be better off ignored.

They have almost the same hardware inside. I made a post about this on a different site at some point but basically the only difference between the two machines is how the cartridge board are being used. The RetronN5 has a Rockchip 3066 for a SoC and has a Xilinx Spartan 3 (XC3S50A or 1584 Logic Elements) on the cartridge board. The Retrofreak uses the same Rockchip 3066 but has a nuvoton nuc220ve3an microcontroller on the cartridge board. The Nuvoton chip is likely used because it can directly use 5V to interface with the cartridges. Both systems are basically dump-and-run libretro type of systems. For all practical purposes, the Retron5 and the Gamefreak are no different from a Raspberry Pi running the same Libretro binaries. The difference is how they're packaged. That FPGA firmware on the Retron5 or the microcontroller firmware on the gamefreak are the only things that make them different, and I speculate that those chips are just interfaced to the cartridge bus and present something similar to the Retrode to the underlying OS (eg a rom and a sram file) and hence that's why expansion chip games still don't work on these devices.

From a historical perspective, Emulators were primarily meant to interface one thing with another thing (eg a terminal emulator replaces a terminal, a cpu emulator replaces a several chips that make up the system core) From a modern perspective, video game emulators are one part preservation and one part piracy. If it was only about preservation there would not be enough people working on them to justify the expense in dumping the roms. If it was only about piracy, then emulators would stop at "good enough" and we wouldn't have things like Higan and FPGA-based emulators which aim for perfect accuracy. Flashcarts/copiers and so forth were all originally about piracy until it became practical to homebrew a game, but primarily it's been an excuse for piracy. The fact that the emulators exists at all, has been a boon to commercial software being able to be re-released with a price tag (Sega, Nintendo, Square-Enix, Electronic Arts, Atari, and so forth have all done this) even if the emulation has been only about getting a few bucks, that revives interest in those IP's. The people who program emulators (especially FPGA versions) are usually doing so as personal challenge, and indeed if you search "FPGA" and some console or computer, you will usually find that some comp-sci or EE project about making an emulator. Software and Hardware emulators go hand in hand, and sometimes in order to create the FPGA you need a software emulator on a computer to step-through what a certain software does. Preservation ultimately means being able to play a game exactly (or as exact-as-it-will-ever-get see CRT vs LCD) as it was intended by the developer, no cheats, no hacks, no intros, just the original cartridge and the original hardware. What drives faster preservation efforts are when old systems start dying by the hundreds or thousands (see the SNES CPU plague, or even the the oxidation of the plastic.) So when the original hardware stops being practical to use, re-engineered hardware (eg FPGA systems) and software emulators become the only way to play the original games. That said, the number of people who legitimately own games they play on an emulator is pretty low. Format shifting arguments aside, the law is pretty clear that you can only backup software you purchased yourself, hence acquiring them from a friend, or over the internet, or video rental store is not going to fly. Since floppy discs and cd's will not last forever, there is a more legitimate preservation argument. For arcade PCB's and old computers, those CRT monitors only have a life span of about 30 years before they are too dim to be useful, and the power supplies are often proprietary designs. So preserving things like the Arcade machines are a race against time and poor documentation. Old computers are well documented, so it's just being able to salvage cartridges, disks and CD's before they rust/rot. Like a lot of us may have a lot of old kit hanging around, but we have not yet begun to reach a time period where this stuff will be lost to us for good. We still do not have any permanent means of storing media (Flash memory actually decays if left untouched, magnetic media is slowly erased, cd's are made of plastic and warp or the recording layer rots) so there will be a need to keep preserving these things from the original media as long as possible to ensure there's no bit rot. From the educational front, there are alternative ways of teaching people how old computers work (see "Human Resource Machine") in addition to just sitting someone down at an emulated 6502 or Z80. It's too bad that every computer didn't come with a version of BASIC still, on the 8-bit and 16-bit machines this was the best way of learning what that hardware actually does. Obviously on 32-bit machines BASIC becomes inadequate due to not being able to access low-level parts of the machine anymore. Most millennials and younger have never used a real 8-bit machine. So they don't have the nostalgia factor required to preserve such machines. If you look around you'll typically find that 8-bit emulators are written by people in their 40's or older. Kids born after 2000 will look at things like the PS2 and go "wow is that ugly, how did you ever put up with those chunky graphics" and might not even be able to recognize the graphics on an Atari 2600 as being graphics. Much in the same way right now people look at low-resolution retro-inspired games and go "ew, why are they blocky looking" (my DAD, of all people did this, and I was playing the Scott Pilgrim game on the Xbox 360.) If anything preservation efforts will become harder (it's currently not possible to play Xbox 360 or PS3 games on anything other than the original hardware) going forward. So all these Xbox Live games are going to vanish.

1. The thing about ethernet is you still need a TCP/IP layer, and for MMO games you need a server, and that goes well beyond this. As it is Phantasy Star Online 2 is available in English... in Asia. I've played it in Japanese. Unfortunately when MMORPG's die, they die and they're difficult to reverse engineer without having analysed the working game when it was working. Similar issues exist for the original version of FFXIV, there is only enough data to fool the game client into loading the world, but the world is empty. 2. Bliss Box, I imagine there is some inherent latency going through the box, but since it connects via usb ultimately, it's probably just a HID device. 3. Bluetooth, it's very likely that any wireless tech would be a complete radio part, and they are normally USB bridged anyway. 4. 2TB hard drives either use NTFS (Windows) or UFS (MacOSX), or any number of file systems on Linux or FreeBSD. You can't support all of them in a FPGA, it's hard enough to get working file system drivers in Linux. You would be better off dividing collection's up into 64GB using FAT32 or partitioning a drive/sd-card in such a way. 5. 4K and beyond - From what I understand, the latency increases the larger the screen is because 240p upscaling is 720p is 3X, 1080p is 4 or 4.5X, and 4K is 9X and 8K is 18X. So if you look at the FPGA size, if a 9K LE can only do 720p, and a 25K LE was needed for 1080p, it would likely need a 50K LE just for 4K. The limitation is the blockram.

I got the quotes off Digikey.com, keep in mind the prices fluctuate. From kevtris's teardown the AVS is Xilinx Spartan-6 XC6SLX9 TQG144 , but the speed grade digit isn't mentioned (it will be a 2 or a 3) but the difference at most is $4USD. C or I at the end determines the operating range. So an "I" Industrial version can do -40C to +100C where the C is 0C to 85C. So unless you're playing it outside it's inconsequential. The NT Mini has a Cyclone V 5CEBA2U15C8N (Family 5C, Varient E, B ?, Member code A2, Package Type U, Package code 15 (484 pins), Operating temp ©: Commercial, Fabric speed 8, N RoHS)