Kismet

The MAX 10 development kits cost 125$ but has pretty much nothing on it, they're typically used for DSP's, that's why kevtris likely suggested that for the video FGPA on the z3k. The thing to keep in mind that the development kits have a lot of extra stuff on them that are not useful at all for a FPGA console or computer. So even if you get a dev board, only a few of the very expensive ones have video and usb to allow it to be anything like a full console/computer.

There's two issues for doing that: a) How many LE/blockmemory is available b) Recompiling Cyclone III FPGA to Cyclone V I believe the latter is easy to do, but you'd still need to know what to connect the pins from the emulated cpu to. Like you can't just download the MiST core and run it in the NT Mini's core list, because there are differences beyond just the FPGA itself (see https://github.com/mist-devel/mist-board/wiki/Pinsfor the pins on the MiST.) The HDMI is implemented on the FPGA in the NT Mini, while the MiST uses an ARM cpu for SD card and i/o (joysticks, midi, etc) This is what I meant in an earlier post about standardizing on a PCB. MiST doesn't have HDMI, ZXUno doesn't have HDMI or USB, FPGA Replay doesn't have HDMI (has DVI though) but it seems abandoned. There's also Mega65 (A C64 FPGA) The Terrasic development boards also tend to have worse issues with the onboard i/o (take note that every student project that has tried to emulate a console has to make a compromise to work with either the onboard VGA/HDMI or AC'97 codec) DE0 - Cyclone III 15,408 LE, VGA(4-bit), no USB, no HDMI, $120 DE0-CV - Cyclone V, 49000 LE, VGA (4-bit), no USB, no HDMI, $150 DE1 - Cyclone II, 20,000 LE, VGA(4-bit), no USB, no HDMI, $150 DE2-115 - Cyclone IV, 114480 LE, VGA, USB, GigE, DVI available on separate HSMC card (This Development board is designed for prototyping smartphones apparently) $495 Cyclone V GX starter- 77000 LE, HDMI, USB $180 The Arria and Stratix III/IV/V FPGA's are out of the price range for pretty much everyone. On Xilinx side Artix-7 35T Arty - $99, 33208 LE, 10/100 Ethernet, no video output at all (arduino support), USB Digilent Artix-7 XC7A100T Nexys 4 - 101440LE, VGA, Ethernet, USB, SD-card, $320 Spartan 6 SP601 - 14579 LE, Ethernet, USB, no video output (HSMC cards available,) $395 As you can tell, there is no standard set of i/o between anything. Anyway, what kevtris has proposed in the z3k thus far is more flexible as an 8-bit or 16-bit FPGA-based console or computer with lag-free HDMI output, it just depends on the ability to connect original carts/controllers or not. The key feature with two FPGA's is one of those can always run a line-by-line scaler. Most of these Development boards supply basic VGA (even on MiST's board) at most, so you're not going to get a lag-free output since most LCD screens are going to run that through their upscaler/framebuffer. The development boards don't have enough i/o pins to interface with cartridges, especially something like the NeoGeo which has 240. Even right now I'm not sure how kevtris would be able to do it short of some kind of serialized i/o. When people start suggesting 32-bit systems, that starts going outside the scope of what I believe kevtris is trying to do. Sure something like a 68060 or 80386 could be done, but then we end up at cross-purposes like what happens with DOSBOX, where people ask how to get Windows 95 running, when that was always beyond the scope of emulation (DOS software because it emulates a DOS environment) or trying to emulate the control interface for industrial SCADA interfaces from it. Basically, yes, stuff like this could be done, but that really calls for a different project entirely. As someone mentioned about emulating the Amiga, it's entirely possible to get a 68060's performance out of the 68000 core on a FPGA, but then you'd break all the software that expects it to run at the stock clock speed. And for what it's worth, I doubt a 32-bit system could be built cheaply as a single FPGA.

Neither of those have HDMI and also fall pretty short of being able to emulate half the 16-bit systems unfortunately. MiST (Cyclone III, 25K LE) was designed for emulating an Atari ST, while ZXuno was meant for emulating the ZX Spectrum. IMO a lot of these single-target solutions are barking up the wrong tree when they don't include HDMI on the board, nor do they provide any meaningful way of connecting generic USB controllers/keyboards/mice to devices that are primarily computers and just work. With consoles, at least you can get away with "any 2 button controller" for pretty much all the 8-bit systems. This is why I think the Z3K is actually what people want, and if everyone working on FPGA-based computer/consoles could focus on one standard FPGA PCB, we could bring down the costs of the FPGA's in quantities.

Long post ahead Most of that is impossible for various reasons. I'll divide them into two categories A) Stuff that can be implemented in FPGA (now) B) Stuff that can not be implemented in a single FPGA A - Systems that could be implemented in FPGA now: All 8-bit systems are theoretically doable up to the PCE I believe on the NT Mini. 6502-based (Atari 2600 (is a 6507 but otherwise the same), Atari 5200, Atari 400/600/800/XL/XE, Atari Lynx, Apple I/II/IIe/iic+, NES/Famicom, Commodore VIC20/PET/C64/CBM-II, BBC Micro, KIM-1, Acorn Atom, Acorn Electron, and the PCE/TG16) There are quite literately 27 computers alone on Wikipedia, not including hobbykits. The *T65 core is maybe 1200 LE Z80-based (Amstrad CPC 464/664/6128/+,Bally Brain/Astrocade,Lynx(UK),MSX, Coleco Adam, Colecovision,Exidy,MattelAquarius,Microbee, NEC PC-8801, Tandy TRS-80, Sinclair ZX80/ZX81/Spectrum,Timex Sinclair 1000/1500/2048/2068, Sharp MZ/X1, Sega SG-1000/3000/SMS, Gameboy/Gameboy Color), 51 systems listed with Z80. Plus there are arcade games, good luck (I've seen Galaxian (3100 LE and Galaga 8000LE) The *T80 core is maybe 1600 LE Other 8-bit CPU types would of course require more engineering. Pretty much the limitation to doing them on the NT Mini is connecting a keyboard and mouse, which could probably be done with the USB port on the back, but that would require a hub too, and there goes more FPGA programming space. The 16-bit CPU's would require the Z3K as even if you could emulate them on the NT Mini, you'd not have enough RAM in the FPGA to do anything with video and sound. Plus the computers often require FPU's, MMU's, Serial port controllers, floppy/hard drive controllers and such. The *TG68 core requires about 3100 LE A Sega Genesis(Megadrive) requires a Z80 and a 68K (and the VDP and a sound chip) A NeoGeo requires a Z80 and a 68K (and I wouldn't know where to begin describing the video, and a sound chip) an Amiga (Minimig) needs at least *14000 with All three (68K, Z80 and 6502.) A Sharp X68000 requires a 68K An Atari ST requires a 68K A Super Nintendo requires a 65816 which is abourt 2200 LE for the CPU alone. 7100 for PPU1, 400 for PPU2, 13500 for the APU based on one project fitting report. A 8088 (Tandy 1000/IBM PCjr/IBM 5150/XT) requires about *4500 LE, systems based off the 8088 like the V20/V30 (used in the PC9801 and the Wonderswan) *geez I wish publicized FPGA cores would list the fitting reports for their cores, I pretty much cribbed these numbers from projects using them talking about what dev board to use. Add into the equation the need to output HDMI, and the FPGA is going to be full. The NT Mini has a 25K LE FPGA, and it swaps out the 6502 and Z80 cores (AFAIK) to switch emulators instead of having all of them in the FPGA at boot. That leads us to 32-bit CPU's, and the Z3K is not going to reach that far IMO. At 49K target FPGA, that might squeak in a SNES or Neo Geo, but kevtris would need to actually have working cores for those + expansion chips in the SNES before you could just straight up say it will fit those. One FPGA SNES project requires 28500 LE alone for the SNES, forget expansion chips and HDMI. Sega CD uses a faster 68K and could likely be emulated within the Z3K, given a cd-emulator. The CD-i also uses a 68K (the vast majority of MPEG decoder chips for computers and multimedia boxes assume a 68K host CPU as well, even ones that weren't on a Mac or Amiga.) The Commodore CDTV (basically an Amiga) also used a 68K An Atari TT requires a 68030, a FM Towns requires a 80386sx B - Systems that could theoretically be implemented in FPGA now, but so far nobody I know of has successfully got that far: From what I researched, most 32-bit cpu's can be done in FPGA, but you're looking at 33Mhz, maybe 50Mhz at most, which might be enough to do the PS1, but nothing later or more complicated (like the N64) as the length of the internal wires becomes hard to deal with However once you're doing the PSX or N64, those are already framebuffered(eg it draws using 3D geometry,) so you don't really need the FPGA-based emulator for the entire thing, as you may be able to use off the shelf HDMI and SD-card cores, maybe even find stand-alone GPU cores that can be loaded into a second FPGA. (There is one student N64 project out there that built a minimal CPU, audio and framebuffer on a 101K LE FPGA, they didn't build a full N64, and didn't touch the RCP. $165 FPGA. Another student project tried to build a PSX but couldn't fit it on a DE2-115 (160%) and the GPU would only run at 5Mhz and then they ran out of time. Neither of these projects would be considered more than "hello world" level.) The Dreamcast (SH-4), 32X (2 x SH-2) and Saturn (2x SH-2) use SH-series CPU's. The N64 and PSX, PS2, and PSP use MIPS cpu's, The PS3, Xbox 360, Gamecube, Wii and Wii U use PPC cpu's, These also likely have patents to deal with GBA, DS, 3DS, 3DO, PS Vita all use ARM cpu's, and are likely cheaper to just get a ARM SoC+FPGA to build. The GPU parts on all of these are what is likely to require a second FPGA, and even then, I don't think there is much point, as a modern GPU is far more programmable than these old fixed-function GPU's, so it may be viable to actually use an existing GPU by the time those become viable, if ever. You mainly need the FPGA to run the program code, the GPU doesn't care about what CPU is connected to it. That said, all of these consoles also have BIOS and/or OS's that might think otherwise. At this current point in time, I don't see FPGA emulation of any of those being viable by one person, let alone with existing FPGA tech. Other stuff requested: Ethernet or Wifi - probably won't happen due to licencing, May be viable to just use an off-the-shelf part. NAS support - Unlikely as that requires both ethernet, and a full TCP/IP stack, thus requiring being able to manage the state of it. To give you an idea, usable NAS devices cost at least $800, and they all run embedded Linux or FreeBSD, so configuring something to connect to it would be a huge pain in without it's own OS. I suppose it's possible to just create a filesystem bridge (which is what some external hard drives do over ethernet) which just talks directly to the data link layer (non routing.) Bluetooth - probably won't happen due to licencing, most BT chips in computers are USB bridged anyway, so what you're really asking for is a USB port Blissbox - Hmm, this actually looks dangerous because they chose to use HDMI connectors, as the adapter to a USB box. I suppose supporting the USB end might be something viable, but if you start putting HDMI-that-isn't-hdmi ports all over the place, someone is going to fry that PCB when the controller gets plugged into the real HDMI port. 2tb SDcard - Probably a nope. 64GB due to licencing requirements of the exFAT filesystem. Submarine patent http://www.google.com/patents/US20140149344 expires around 2030 4Kp60 HDMI support - As far as I can tell, this is viable, but requires a very large FPGA to pull off. That said, it's only likely to be useful for the systems before the PS1. The PS1 and later all use framebuffers, so "zero lag" isn't a viable target as the games were designed to have that 1-frame buffered. Basically half of these things would require a SoC with it's own OS so FPGA space isn't wasted on implementing things like ethernet controllers. Unless you're going to connect 4 of these systems together for local player, there's not much point trying to implement ethernet in FPGA. Not even the PS2 (conexant) or Gamecube (maconix) used proprietary Ethernet solutions, they just used basic Ethernet parts on their own expansion bus. TL;DNR version (omg sorry this is so long): IMO... The 8-bit machines seem all possible with the NT Mini, the Z3K based only on what we already know is likely going to be able to do all 8-bit and 16-bit machines. 32-bit machines are very likely out of the question for various reasons including the cost of the FPGA. Some of the features you suggested kinda go into "nobody would have to time to develop that, even if we wanted to." Many of the student projects that I read (SNES, Sega Genesis, PSX, N64) FPGA projects only had about a weeks worth of time and none of them get more than half of the console working, and they even use existing CPU cores. Past a certain point, you have to be realistic and remember that the entire point of these devices is to play old stuff on HDMI monitors and televisions, not a be-all-end-all game console. FPGA's have limits, and anything that isn't at least 20 years old is still likely protected by patents. So realistically kevtris has to draw the line at equipment older than 1997 to be clear of that, putting the PS1 and N64 right on the edge of that.

This is my opinion. Where I grew up, two family friends owned Amiga's, one relative (whom we got all the hand-me-down PC parts from) had a PC, thus everyone in the family had a PC-compatible at some point. Nobody owned an Apple II, but the schools had them from 1989 to 1992, and IBM XT's from 1990 to 1998, even when they replaced two computer labs in the high school with 486's and Pentium's respectively. However the only computers in the schools with multimedia capability were... the two Amiga's (one A2000 with the Video Toaster, one A500 that ran the TV announcement system.) The high school also had an Atari Falcon, a DX7 and a MT32 and nobody knew how to use it. Ultimately the lack of any standardization, even at school, resulted in a lot of "who could get the best deal", and the school's wound up with XT's, which were later replaced with 386's in 1992, 486's in 1994, or Pentium's in 1996, but the XT lab stuck around the longest. The Amiga was just too expensive, and it was seen mainly as a video-editing hardware. I would have loved to have had an Amiga, but instead had a Tandy 1000. The Tandy was good for other things (color video and three channel sound, therefor putting it at NES-level capability.) But the Amiga 500 was better than the Sega Genesis and was comparable to the SNES, and when you look at computer that costs several hundred dollars, and see a $200 console blow it out of the water, you kinda reconsider investing in that. And that IMO is what tended turned people away from everything that wasn't a console in the end. So, the Atari ST, and Falcon - MIDI machines. Amiga - Video Toasters, Mac - Graphics workstations, PC - Word Processors. Ultimately I think the Amiga got stuck in a position between competing with the Mac and the PC after Atari withdrew from making computers, and Commodore's incompetence in the US, and Apple's incompetence under John Sculley sent the home computer market into highly-specialized over-priced devices. So the PC wound up "winning" that because it didn't have it's uses dictated by a single manufacturer. However a few things became death-knells for the Amiga. The Amiga and the pre-PPC mac were in competition for the same CPU's. When Apple switched to PPC, that left Amiga's with no upgrade path so they decided to go PPC in 1995 too, and well the rest is history. So if a few different things happened in the Amiga's history, we might have had AmigaOS ported to PPC and x86/x86-64 and ARM by now and the OS would have survived even if the unique hardware ultimately fell by the wayside (interesting how computers now have separate CPU, GPU and Sound chips, much like how the Amiga had right at the beginning.)

Hmm so the NT mini uses a Cyclone V E - 5CEBA2U15C8N (25K LE) or about $40. The Z3K suggested so far needs 49K LE (which would be about $68.) The RetroUSB AVS uses a Xilinx Spartan-6 XC6SLX9 (9K LE, and costs about $20) That still has me wondering what the BOM (Bill of Materials) on the NT Mini is.

I'm looking at this and can't really see the point. On one hand, being able to dump carts you own, dump the sram, fix the battery on the cart and then reload the sram has some value. However I have SNES games that the battery from 1990 still works, and I probably could salvage the save game, so while I think this isn't novel, it may provide 1/2 of a solution for something like the Z3K in the other thread, where the cart can be dumped legitimately to an SD card and then played on the physical FPGA system. That said, as soon as I saw "libretro" my interest vanished. If you see "libretro" that means software emulators, and more to the point, libretro is a just a collection of out-of-date emulator cores much the same way FFMPEG is a collection of out-of-date video codecs. It may mean well, but because there is no way to actually guarantee performance out of the target device, you get really foolish things like N64 emulators running at 2fps on original Raspberry Pi hardware. Unless you can gaurantee 60fps from every emulator in the backend, for all games, remove backends that clearly will never work. My interest in this lies entirely on the ability to use original cartridges/joysticks, but connecting those by USB doesn't add any value and adds latency that otherwise wouldn't exist on a FPGA hardware emulator. In some ways I feel too many "I wanna be a clone too" systems are being made without any understanding of the nature of the hardware they are supposed to be emulating and are instead blindly using libretro and don't care if it really doesn't feel like those original consoles. This is why people often inquire about flash/sdcard support, because they don't actually own many or any original carts.

That's because: 1) That's CGA, the emulator isn't running in CGA mode 2) The PCjr/Tandy 1000 mode was better. Oh, I'll just play and upload that. Anytime you see a pastel MSDOS game, it's because the computer or emulated computer isn't in CGA or Tandy mode that would display it correctly. The NES version was superior to most home computer ports just by virtue of being able to scroll the screen. Only the Amiga, Atari ST, FM Towns and X68000 versions were good computer versions, and the FM Towns was 1991, same with the X68000 also 1991. The EA DOS PC version was rather terrible considering they also did the Amiga version. The NES version was made by Milton Bradley in 1989.

IMO, displaying the bezel, and pixel-degrading effects like scanlines or other effects for LCD require more FPGA space, and is not a good use of kevtris's time. The ideal mechanism for dealing with the bezel is to have a bmp/pcx/gif file that can be swapped out, otherwise we're better off maximizing the integer scaling. It needs to be said that if you play games for a long period of time, you are going to create image retention problems on OLED screens if you use any static image.

I think Mario Odyssey is more in the realm of Mario 64, less platformer, more exploration. If it's really a world that can be wandered around without pausing to load levels or change zones, that will make it the largest Mario game ever made. However that is not a trademark of Mario, that's a trademark of the Zelda series. People keep mentioning GTA, but the trademark of GTA was having a free-roaming environment that would normally be found in a RPG game, without the RPG grind. GTA is actually more restrictive than RPG games when it comes to things you can actually do inside the world, but since there is no grind involved, it relies on skill to get through missions. At any rate I'm not sold on it yet. Every time I hear about another "open world, sandbox" I hear "80 hours of crafting nonsense"

This is just my opinion, but it's hard to say which one is best or favorite, because it depends how old you are. If you grew up with a NES, SNES and/or N64, your favorite is likely going to be SMB3, SMW and/or Mario 64 But if you didn't have a NES or SNES and maybe instead had a GB/GBC it's more likely that Super Mario Land 2 ranks about the same as SMW for the SNES. If you started with the GBA, then the revised versions of Super Mario 2 (Mario Advance), Super Mario 3 (Mario Advance 4) and Super Mario World (Super Mario Advance 2) might be preferred over the NES versions but equal to the Mario All stars/SNES versions. Here's why I like certain games more than others: Mario 64 knocks it out of the park for music, and I wish Nintendo would have stuck to this music design for all titles. 3D land and 3D World are a good blend of platforming and 3D elements. SMB3 and SMW had worlds that went in all directions, but SMB3 let you store a variety of items. Super Mario World however let you find multiple paths through the levels with two exits in some. I found Super Mario 3D World to be the right balance of what I want in a 3D Mario platformer, and hope Nintendo sticks with this for whatever they have planned for the Switch (4 player, multi-directional, items that let you take alternate paths and so forth.) But what I would love to see is Nintendo going back to the Super Paper Mario (which was more of a Metroidvania game than a RPG) and make it take place in a Mario world we haven't seen for some time (eg Sarasaland from SML, Super Mario 2 dreamland)

I guess I should have said double-buffering. I'd buy the z3K in a heartbeat even if it cost as much as the DE2-115 development board. If it costs $200 or less it's still a viable replacement. I'm only worried about companies like Nintendo or Sega trying to shut down these projects instead of trying to license them to build their own stand-alone virtual console version.

To FPGA or not to FPGA, that is the question. I signed up just to comment/vote, I read the entire 45-page or so thread to get here. Admittedly, I didn't really know that much about FPGA's until last year when I saw the AVS and the NT Mini. Since then I've done significant research on the viability of certain consoles, computers and some other hardware. I've been using software emulators since the late 90's, and remember how awful many first generation free emulators were. Suffice it to say, there is never going to be a one-size-fits-all-everyone-happy solution. So lets break this down: A modular/upgradable system makes the most sense as it requires the least investment in parts that people don't want or don't have an investment in. However a modular system ultimately costs the most, as everyone isn't subsidizing all the parts. The benefit here is that kevtris doesn't need to build all the modules, someone else can. 8-bit computer's and consoles can currently be emulated accurately enough on high end computers, so the market for the AVS, NT Mini, and various other FPGA-based systems is smaller than that of 16-bit. So I feel the Zimba 3000 should focus on being able to run all 16-bit consoles and computers. Emulating 16-bit consoles and computers has never been accurate enough, even on the highest-end computers. There is an entire generation of people who grew up without the SNES, Sega Genesis, Amiga, and have no idea that things like the Nintendo Virtual Console and PC-based computers aren't supposed to look, sound or have that much latency. I feel that ARM-based emulators (eg Raspberry Pi, Retron 5, Retro Freak and such) are a cop-out, as they rely on the inaccurate hacky/laggy emulators, and the crapshoot of TV compatibility (let's not assume TV manufactures care, and just side-step them by putting the scaler in the console,) providing no ability to use your existing game investment accurately. So the goal for the Zimba 3000 should be to "replace all 8-bit and 16-bit consoles, and their add-ons/expansion devices", while still allowing people who have a great investment in those games and accessories to use them, and save them from the landfill. The last argument is input and output. I think everyone is on the same page about the need for HDMI and SD card support in "this version" of the Zimba 3000, but I think many people are barking up the wrong tree about what is really viable on a FPGA while keeping the costs low. 4K TV's and monitors are available today, the 4k monitors are "gaming", but the TV's so far are pretty terrible. 8K TV's are around the corner, so planning for that today should be done, but maybe not in the current version of the Zimba 3000. These are going to be HDMI/Displayport over USB-C. It's entirely possible to drive 1080p from the FPGA (the NT Mini does this AFAIK,) but right now, even FPGA systems that support 4K, are often paired with HEVC decoder/encoders with the intent of being used for SmartTV's. So it's likely that the FPGA needed do to 4K/8K over DP/USB-C exceeds that of what kevtris wants to use. However, why not toss access to the main FPGA's output to the video expansion header so that at some point a "4K" or "8K" usb-c based complex scaler output could be built without having to put it into the onboard HDMI? Maybe leave the onboard HDMI as only a simple integer scaler. VGA, DVI, RGB(SCART/PVM), JAMMA, and so forth could be put on their own video boards. Original cartridges should be on an expansion bus. I'm not sure how kevtris wishes to do this as the number of address and data pins on the systems range from 24 pins on the Atari 2600 (13 address lines, 8 data, +5V and 2 ground), to SNES (16 address A bus, 8 address B bus, 8 data bus, 8 expansion bus, 16 SNES-specific pins, 2 Vcc, 2 ground, Left analog audio, right analog audio. ) From images seen, I don't see any 240 pin connector (Neo Geo MVS), so I get the feeling that a third FPGA might need to be involved, where this third FPGA sits on the end of the voltage shifters. Original controllers, keyboards, mice, joysticks should be on an expansion bus. This is likely best done by combining it with the cartridge expansion bus. EG (Z3K = Expansion bus - controller bus) or (Z3K - controller bus), thus allowing one to swap their Sega/Atari DB-9 with the NES/SNES controller bus if that's what they want. USB-C or USB connectors can be used for onboard USB HID, Xbox 360/Xbox One/PS3/PS4-style controllers, or HID USB-bridge (SNES, PSX, PS2, gamecube.) I don't think the Zimba 3K should even bother with wireless controllers. If it's modular enough, third parties can support computers (MSX, PC9801, DOS, etc) , obscure expansion cards, music devices (eg MT-32, midi devices) using the Zimba 3000 base hardware, and thus being able to justify lowering unit costs with higher quantity orders of parts. But if it's too flexible, it becomes aimless, and kevtris's time doesn't get used efficiently. In many ways, this feels a lot like the early 80's microcomputer era where people were building their own computers from kits. kevtris should probably make it clear that current generations of FPGA will not be able to do certain things and still be affordable. Like I've talked to people casually about what is possible in software, FPGA, dynamic recompiling, and so forth, and people are under the impression that everything can be done in FPGA. From what I understand, the highest-end CPU (alone) that can be emulated on a FPGA is the PS1, 32X/Saturn, 68020, Pentium (x86) @50Mhz but emulating these with a single FPGA today might be too expensive, and would require a multi-chip solution. One thing that frequently becomes the unwanted focus in every emulation scene I've been to, is that people get extremely pedantic over the developers intent. In the PC/MSDOS emulation, it's incredibly difficult to get correct aspect ratio emulation since all the emulators have to use a framebuffer, thus one frame is buffered in system memory, and then it has to be integer sampled up and then rescaled down, sometimes at the expense of 3 frames of latency. But most DOS era games didn't use framebuffers (ISA bus is slow,) they wrote directly to the video cards memory. In the console emulation communities, we again get into the same arguments about "should it look pixeled" and again come back to the aspect ratio. Even in this thread. It is my belief that you shouldn't second-guess the developers intent. So integer-scaling should be the default, and only if the user opts to, let them override the aspect ratio and scaling. Not everyone wants to experience "the CRT effect" because as much as we want to say the CRT was better to play the games on, it was never good for your eyes, and no two CRT's have the same focus, color and brightness as they change with age, even if they all use the same phosphors. Referring back to kevtris's block diagram, if it's made so that a "Zimba 3K" base unit can emulate most 8 and 16 bit systems, using USB and the SD-card, over HDMI, that solves about 50% of the needs of the people who would be willing to pay $200 for it. The other 50% would be willing to spend the extra money to get whatever expansion bus to enable 100% compatibility with real cartridges and controllers for a system (most NOAC/GOAC things are $20-40USD each by comparison, and they use the SNES as the base unit.) Then I think this is a solid direction. If at some later date a Zimba 3K2 or 4K (for 4K TV) comes along and also adds the ability to play something else that was impossible with the existing FPGA, all the existing expansion parts could still be used, and the previous generation Zimba3K is doesn't lose any value. I do express a bit of reservation about the games being stored on a SD-card or being able to support copier/flash drives, since that encourages piracy, but if you're going to spend $200-$500 on an accurate FPGA console, you likely have the money to buy the games off eBay to have an accurate experience. TL;DNR version: I look forward to seeing this. While I think 98% accurate software emulators might be good enough for people to just nostalgia trip (eg the Virtual Console service.) Those are not the intended audience of FPGA systems. I've looked at things like the MiST board, I feel these are not powerful enough, and make no attempt to address the need for upscaled HDMI connections.