I was thinking about the FPGA thing - rather than making a bunch

interesting

perhaps because if you have a non-fossil PC with pci-express port you can emulate.

and ppl just want a clone with SD input that plays the games, a minimalistic and standalone hardware seems more organized.

but i guess this thing plugged into some tiny low profile case with a 90 degree adapter for case width you could have an adaptable "clone" VG that outputs analog/digital, multitaps/wireless controller and can have player4 playing over internet

It's kind of a wash.

If you have a modern PC with a PCIe-based mobo, chances are that you can emulate the same systems that would be available via FPGA (which for now only go up to the 16-bit generation because of cost) with the same degree of low-level accuracy and at full speed.

>>3427781
>which for now only go up to the 16-bit generation
what really?

they can only clone 20 Mhz ish snes/genesis ans such?

i thought the deal with FPGA was that it wouldn't be emulation of another architechture in x86 which ends up requiring clocks in the 200MHz range

so i thought a couple FPGAs would actually clone the circuitry in a saturn os ps1 and run as a clone console

>>3427161
>FPGA
Next major intel core comes with a section of fpga that can be setup for specific uses.

File: cirno_baka.gif (875KB, 250x226px) Image search: [Google]

875KB, 250x226px

>>3427161
A couple of reason actually.
First, the only real advantage of what you describe would be accuracy, and I doubt taht people would be willing to pay that much just for the added accuracy, especially since the system we know enough to use FPGA for now are 99% accurate more or less.

FPGA consoles bring with them several other advantage that are:
plug and play easy mode
no input lag
the first is self explanatory, really.
The second point is important, since your idea would make it worse than current emulation.
to get an input you would have to read a current input API (like current emulators), but then your driver should send them through the PCI-bus, which has a certain extra latency, and then the board would need to decode the stream making it finally available to the console chipset.
Then, once you have the image, you would have to send it back, with encoding/BUS-decoding again, and this should still go into your video-card for final processing and output (same round as your emulator).
Those problem could be circumvented by having a direct video output from the card for a separate monitor, and having the controllers plug directly in the board.
But at this point the thing is the same as the current idea, with only a PCI-input for the ROMs. At that point you can make a flashcart or a USB loader for the ROMs and be done with it.

>>3427947
>i thought the deal with FPGA was that it wouldn't be emulation of another architechture in x86

It's not translating to x86, but the more complex the simulated system's architecture is, the more logic gates are needed to duplicate its functionality in an FPGA.

An FPGA is defined by having reprogrammable circuits, not a fixed ASIC like typical clones. That is what allows platforms like MIST to use several system "cores" (Amiga, Atari ST, etc) that can be swapped in and updated. This flexibility comes at the expense of chip size and cost.

Right now the sweet spot is implementing 8-bit consoles and computers (relatively simple machines) at about the ~$150-200 range, with newer 16-bit platforms pushing the upper limit of what is currently affordable in an FPGA platform.

If you're interested, there's an ongoing discussion of kevtris's development of his multi-system Zimba 3000, where he hopes to go as far as having a full Neo-Geo core.

http://atariage.com/forums/topic/242970-fpga-based-videogame-system

>>3428195
nice, so if got it right, its a logical gate limit, and not clock is the issue, couldnt one 100MHz and several cheap 50MHz FPGA clone a saturn in theory? as long as they are connected via some fast enough common bus

>>3428106
Good points, I was assuming latency over PCIe would be super small but obviously looking at stats like 250 MB/s for bandwidth doesn't necessarily translate into how it would work in a real life situation - especially i guess when syncing it up with something effectively running at 5MHz

>>3428195
This looks pretty cool, here's hoping it gets into proper production

>>3428874
>I was assuming latency over PCIe would be super small but obviously looking at stats like 250 MB/s for bandwidth
I don't want to sound pedantic, but confusing bandwidth with latency is a common error people do.
Bandwidht gives you how much data you can transmit at the same time. PCIe has an insane bandwidth. It isn't a problem getting back the screen status from the card in a single time frame, and the same it's true for control inputs. I mean, it's made for transmitting vertex and texture data for real time rendering. The problem is that it's not directly hard wired like a controller on a old console to the USB controller, you have to shuffle your data from a place to another, and drive intermediate ICs to get the stuff on the bus. The bus is also regulated, so there is always a delay before your transmission starts. Everything is very fast but it adds up. That's why your videocard has video exit on it, to reduce latency.