It is currently Mon Nov 18, 2019 9:32 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 51 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
PostPosted: Tue Aug 06, 2019 1:53 pm 
Offline

Joined: Mon Jul 01, 2019 3:15 pm
Posts: 6
As the title implies, I'd like to ask everyone's opinion on the use of FPGAs, more specifically, on the use of FPGAs for the creation of devices such as the AVS and Analogue products like the NT and the Mega SG. My reasoning for this question is because I've seen these being mentioned a lot on the Internet and I've found quite a plethora of opinions across the internet, some of those being on positive light for these devices and others not so.

Do you think they are important in any meaningful way? Do you think they can "preserve" history as some people or magazines put it? Are they important or just optional/non-essential tools for homebrew developers? Is this going to be a temporary trend that will fade away? input would be welcome.


Top
 Profile  
 
PostPosted: Tue Aug 06, 2019 2:38 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4231
Modern FPGA clone consoles have a distinct target audience: People who really want to play original cartridges, and don't want to settle for devices which dump-then-emulate instead (Retron 5), which tend to have inferior quality emulation, and lots of input lag.

It's another way to try to recreate the original hardware. FPGAs are very good at what they do, and that is simulation at a hardware level. Operations can happen quickly in parallel with zero latency between various different components. An emulator can be just as accurate at running the games as the original hardware, but a FPGA system can try to mimic the original timings of the hardware, and thus support the original cartridges and peripherals as well.

If the source code for the FPGA is kept private, nothing is being "preserved". It may preserve a specific binary for a specific model of FPGA chip, but not much else.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Tue Aug 06, 2019 11:53 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7747
Location: Chexbres, VD, Switzerland
I think they're great, but alas hard to use. Once you have a working setup, it's easy to get what you want done with it.

Also, a great problem is that no matter what FPGA you pick, tools are always coing to be proprietary. This means the company has the control as to when their product becomes obsolete, and you can't do much once they decide to remove their support for a device. There was a GNU version of FPGA tools for a Lattice iCE40 FPGA but I think it's still incomplete and extremely hard to use - in particular programming the FPGA seems almost impossible without proprietary tools, and there's not much point of being able to place&route your design if you can't programm it anyway. Not to mention the GNU tools are totally incompatible with proprietary tools so if you wanted to do part of the development with proprietary tools and part with GNU, this is probably not going to be possible.


Top
 Profile  
 
PostPosted: Wed Aug 07, 2019 12:40 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 766
most of the arguments come down to cargo cult garbage.

Oh but that just code running on a CPU, where as this is almost like real hardware its a pure truer source of emulation... if it runs on a computer or an FPGA or is physical bits of silicon arranged on a die, if the output is the same it doesn't matter, none is better or more pure than the rest.

FPGAs make it easier to do things with actual hardware, but given a proper CPU for the job then there is no reason why an CPU can't just handle a cart as well. ARM processors don't seem to handle bus timings very well, but if you switch to something like the Sitara with its PRUs then probably job done. or you put some custom chips to handle logic.


Top
 Profile  
 
PostPosted: Wed Aug 07, 2019 10:09 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8686
Location: Seattle
Bregalad wrote:
in particular programming the [iCE40] FPGA seems almost impossible without proprietary tools
The existing devboards use proprietary flashing tools, but all a novel design has to do is put the generated fusemap in the serial flash. (Unless you're talking about the OTP PROM inside the FPGA, in which case your point stands as is)

It's not a nice Complete Solution, but there's at least one reverse-engineered flashing tool for at least one devboard.


Top
 Profile  
 
PostPosted: Wed Aug 07, 2019 12:21 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 632
Location: Central Illinois, USA
Oziphantom wrote:
most of the arguments come down to cargo cult garbage.

Oh but that just code running on a CPU, where as this is almost like real hardware its a pure truer source of emulation... if it runs on a computer or an FPGA or is physical bits of silicon arranged on a die, if the output is the same it doesn't matter, none is better or more pure than the rest.


I've beat Mike Tyson's Punch Out on real hardware with a CRT. Never managed on an emulator ever. Maybe that's just anecdotal, but it convinced me that in some cases, there IS a difference in emulation. (and I mostly DO play on emulators these days, so I'm not saying that as a hardware purist)

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Wed Aug 07, 2019 12:24 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7634
Location: Canada
Dwedit covered the main points I think, but I want to elaborate just a little:

There's also a third option, i.e. dedicated ASIC, that should be included here. For NES/Famicom clones these are sometimes referred to as NOAC (Nintendo on a Chip), but in general this is a single purpose non-reprogrammable chip.

ASIC
  • Hardware compatible (can use original cartridges, peripherals)
  • No latency
  • Expensive to set up manufacture $$$$$$ (only larger companies can design these)
  • Very cheap unit cost when mass produced $ (appropriate for disposable toys)
  • Can't be modified or upgraded

FPGA
  • Hardware compatible
  • No latency
  • Development tools are less expensive $$$ (accessible to hobbyist)
  • Unit cost of FPGA is moderate $$
  • Can receive firmware updates

Software Emulator
  • Not hardware compatible, all aspects of hardware have to be simulated
  • Latency depends on qualities of the hardware and software
  • Development tools are free
  • Costs nothing to duplicate, easily runs on computers you already have, or cheap ones (you supply your own hardware)
  • Very easy to update

You may notice that I didn't list accuracy here, and that's because none of these systems are inherently an accurate or inaccurate reproduction of the original system. In theory all of these could have some perfect recreation, in practice there are a few factors that weigh strongly:

1. FPGAs became viable to hobbyists for this purpose only in the past few years. This means they can take advantage of years and years worth of existing documented emulation knowledge. Emulators and ASIC clones have been around much longer, and because of that many older less accurate ones are still available. Going for an FPGA system means you're getting a relatively "new" solution. For the other two, you may have to be more careful to find what you want. There are only a couple of viable FPGA products, but there's like a thousand NES emulators out there.

2. Platforms that can be updated have a lot better shelf life, and will ultimately get closer to that goal. Emulators can receive new versions as often as their author wishes, for the most part. FPGAs are reprogrammed every time they turn on, so they too can have a software upgrade. ASICs on the other hand, can't change. They don't get upgraded, they get thrown out, and setting up a new design for a new production run is massively expensive, so it will happen not very often at all. So, despite having some similar hardware properties as an FPGA, the ASIC's long term development is stifled by how difficult it is to upgrade.

3. The latency issue is something many emulators struggle with. Sometimes there is latency inherent in the PC hardware they're connected to, or the operating system, sometimes it comes from the software solution of the emulator. There exists very good, very low latency emulator solutions, but this is something that is difficult to engineer and not guaranteed. On the other hand, with an FPGA or ASIC solution, you have effectively no latency by default, much harder for anything to go wrong in that respect.

4. In general the current FPGA systems are for-profit. Emulator software generally is not. There are exceptions, but this is the norm. Even with something like the Retron 5, the emulator component was created from free emulator software and not written by Hyperkin. How much time a free emulator author wants to volunteer to support their software is a very individual thing, but overall this commercial aspect does have an impact on how much and how quickly support can be provided. ASICs in contrast are always for-profit and can't be supported anyway, only replaced.


Top
 Profile  
 
PostPosted: Wed Aug 07, 2019 1:42 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7634
Location: Canada
gauauu wrote:
I've beat Mike Tyson's Punch Out on real hardware with a CRT. Never managed on an emulator ever.

That game is kinda the poster child for latency. The time you have to react to what you see in that game is so miniscule any delay at all drastically cuts into your ability to respond. (I too consider it unplayable except on a CRT.)

Most other games give you more time to react than Punch Out does, though, so the effect there is much more slight. Definitely can matter for e.g. high level speedrun play, but for some games it's barely worth noticing. Depends on what you're playing, in most cases a few frames less of lag will feel a little better but probably won't be critical. (None of the Punch Out sequels rely on such short reaction times, and still play fine with a little bit of lag, IMO.)

3-5 frames of latency seem to be pretty common. In some setups emulators can definitely have less than that, but there's a bunch of issues here, many of which aren't under the emulators control (operating system, video drivers, monitor, etc.), and it's not the easiest thing for the average user to directly measure and diagnose.

Though at the same time if your monitor/TV has its own latency, even an FPGA isn't going to fix that. It for sure won't have any added latency at the source, at least, but the TV hardware is something you have to deal with separately.


Top
 Profile  
 
PostPosted: Wed Aug 07, 2019 3:10 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4231
Punch-Out's dirty secret is 2 frames of input lag baked into the game itself, plus at least 3 frames of additional before dodges and punches. Only Pressing Start to start a fight, and starting to dodge with Down have the lowest possible lag of 2 frames.

Fortunately, this means you can backdate input 5 frames into the past, and eliminate 5 frames of input lag from a modern system, and it will look about the same.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Wed Aug 07, 2019 4:43 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1103
I find that at least on my laptop, Super Mario World and Super Mario Kart are a fair bit harder to play because of the lag. Precision jumping is much harder in SMW, and I get pilot-induced oscillation in SMK. F-Zero isn't as bad for some reason, but it's still not great, and more importantly it trains me to compensate for the lag, which means I actually get worse at the real thing.

It's not just Punch-Out.

...

It seems to me (who has roughly a Wikipedia-level understanding of this matter) that perfect accuracy would be much easier to achieve in an FPGA. Given a decap of all the chips, you simply have to reproduce the circuit design, and all the quirks and edge cases will automatically be there. In a software emulator you have to model all that stuff explicitly, and some of it may be quite expensive in terms of CPU power. The SA-1, for instance, may never be perfectly emulated in software, but an FPGA could handle it fine.

Which brings up the matter of FPGA special chips. SD2SNES has proven the concept. If a homebrewer had written a game that used an expansion chip and wanted to produce a cartridge version, he would have basically three options: (a) destroy a bunch of irreplaceable originals to harvest their chips, (b) do an ASIC production run, or (c) use an FPGA.


Top
 Profile  
 
PostPosted: Wed Aug 07, 2019 6:17 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7634
Location: Canada
Dwedit wrote:
...you can backdate input 5 frames into the past, and eliminate 5 frames of input lag from a modern system, and it will look about the same.

That's an interesting work-around for Punch Out at least. I've heard of this kind of thing for network play to deal with the extra inherent latency there too, i.e. rewind and re-emulate a few frames when you find out input changed in the past.

93143 wrote:
I find that at least on my laptop... it's not just Punch-Out.

Punch Out is just the worst example I can think of. It affects everything, and it's a relative measure. If your setup has worse lag, then it affects everything more.

93143 wrote:
It seems to me that perfect accuracy would be much easier to achieve in an FPGA. Given a decap of all the chips, you simply have to reproduce the circuit design, and all the quirks and edge cases will automatically be there. In a software emulator you have to model all that stuff explicitly, and some of it may be quite expensive in terms of CPU power. The SA-1, for instance, may never be perfectly emulated in software, but an FPGA could handle it fine.

I don't really agree. An FPGA is not a transistor-for-transistor recreation. FPGA software is still written in a higher level language, and the way it implements things is different than the same stuff would be in an ASIC.

In theory you could have a decap, and in theory you could have a perfect mechanical analysis of the die photos that you could automatically translate into an FPGA program... in practice this is not done. Even projects like Visual 2A03 took a lot of careful analysis and understanding to correct the mechanical errors and get running correctly. But, even with some perfect netlist description, such a thing would probably be unfeasible to implement in an FPGA directly. It needs to be simplified into higher level constructs to be translated into something higher level that more efficiently fits the FPGA's capabilities. (Size and power and cost of the specific FPGA become relevant here.)

So ultimately, the way things are done, if you understand something enough to make a "perfect" FPGA recreation, the same thing could be done in an emulator. There's no free lunch here. Where the FPGA excels is at having several simple devices running in parallel that have timing that correlates, but these aren't an insurmountable problem for software emulation.

Cases of "it would be too much CPU to emulate this accurately" are pretty rare, IMO, at least until you get to systems that are out of scope for FPGA anyway. Usually stuff like that falls under analogue effect categories that an FPGA can't be a solution to either. Like obviously Visual2A03 is a very slow approach, but the FPGA consoles aren't doing what Visual2A03 does, they are higher level programs based on understanding of the logic, not some automated conversion of the decap.

I'd vaguely agree that it's probably easier to implement a more accurate FPGA than an emulator, but this is a very vague comparison. How much easier? I have no idea, but yes at least the digital logic and timing components of an FPGA are more similar to what the original hardware did internally, at least. I think whatever difference there is here is greatly outweighed by the developer's individual skill. (On the other side, I'd suggest that all the extra hardware tools and domain knowledge required makes it harder to develop for FPGA, just in general, even if maybe the "accuracy" goal might be vaguely easier?)

93143 wrote:
If a homebrewer had written a game that used an expansion chip and wanted to produce a cartridge version, he would have basically three options: (a) destroy a bunch of irreplaceable originals to harvest their chips, (b) do an ASIC production run, or (c) use an FPGA.

Well, there's another missing option here which is CPLD, which is kind of like a cheaper one-time-programmable FPGA. Those are pretty good for replacing a single mapper/expansion chip, and we've seen them used a lot already for this purpose. FPGA's specific advantage is that it can be rewritten with a new program, which you don't need for that purpose. It has a disadvantage in that it needs to be reprogrammed every time it powers on, which makes it less appropriate for a cartridge. FPGA is great for something like PowerPak that needs to simulate a hundred different mappers, or for an expensive console like the NT that needs a way to do firmware updates, and can afford to do some "setup" of the FPGA during boot.


Top
 Profile  
 
PostPosted: Wed Aug 07, 2019 8:02 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1103
Like I said, my understanding is pretty much Wikipedia-level. I've seen what an FPGA can do, and I've read descriptions of what they are, but I haven't engaged with the concept at a technical level.

It seems I wasn't entirely wrong, so that's something...

rainwarrior wrote:
Cases of "it would be too much CPU to emulate this accurately" are pretty rare, IMO, at least until you get to systems that are out of scope for FPGA anyway.

I did mention an application that's very demanding in a CPU power sense, which is the SA-1. It's not demanding in itself, but the way it interacts with the S-CPU is extremely fine-grained and difficult to emulate in software.

Quote:
Well, there's another missing option here which is CPLD, which is kind of like a cheaper one-time-programmable FPGA.

I knew I was forgetting something... Are there CPLDs that could manage an SA-1 or Super FX? Combined with an MSU1?

Are they programmable with the same tools? Could you port an FPGA design to a CPLD with minimal work? Or would you have to start from scratch if you wanted to (say) release a GSU2 game on cartridge without either shelling out for FPGAs (and making sure the game doesn't try to use the chip before it's ready) or going Aztec on a pile of Yoshi's Island and Doom carts?


Top
 Profile  
 
PostPosted: Wed Aug 07, 2019 11:55 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7747
Location: Chexbres, VD, Switzerland
With FPGAs il will be hard to model quicks like OAM decay, colour emphasis, audio DAC nonlinearity, and other analogue-related effects. Sure those can be somehow simulable, but it'll end up looking like a hack and an unelegant solution no matter whatr you do. For example to simulate OAM decay you'd need a lot of timers and write random data to OAM after some time not reading it.


Top
 Profile  
 
PostPosted: Thu Aug 08, 2019 1:33 am 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 712
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
They're no more harder or different to do than in software and nobody forbids you to bring out the signals for actual processing in analog domain either but if that's worth it is another question. You could probably do a fairly good job on sound related things that way.

Main thing for me is that you can do all these things in power efficient manner. Some of the very accurate emulators require you to have a machine that consumes hundreds of W of power for optimal experience, while the same logic on FPGA would not even reach 10, often you don't even need a heatsink on the chip.

In general I'm a big fan of the FPGAs but not so much because you can reimplement old things but you can also make completely new ones too ~

_________________
http://www.tmeeco.eu


Top
 Profile  
 
PostPosted: Thu Aug 08, 2019 2:29 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7634
Location: Canada
93143 wrote:
It's not demanding in itself, but the way it interacts with the S-CPU is extremely fine-grained and difficult to emulate in software.

Yes, this is the kind of thing that I would say might be, in a very vague way, easier in FPGA, but in the bigger picture I think it can be done just as well in software, even if it's a "harder" thing to do in software. (In a lot of ways doing a hard software task might still be easier than doing an easy FPGA task, if you know what I mean.)

93143 wrote:
Are there CPLDs that could manage an SA-1 or Super FX? Combined with an MSU1?

Asking whether there's a specific CPLD on the market that could implement a replacement for a specific ASIC is something that would require a bit of research and engineering to answer, but probably trivially the answer is yes on some level. CPLDs tend to be less powerful and less versatile than FPGA, but there's ranges of capabilities in available devices, and you can use more than one. I think this is more a question about cost than anything else?

93143 wrote:
Are they programmable with the same tools? Could you port an FPGA design to a CPLD with minimal work? Or would you have to start from scratch if you wanted to (say) release a GSU2 game on cartridge without either shelling out for FPGAs (and making sure the game doesn't try to use the chip before it's ready) or going Aztec on a pile of Yoshi's Island and Doom carts?

CPLDs and FPGAs have a lot of overlap. You can more or less write a verilog program and put it on either type of device. There are CPLDs and FPGAs available with various cost/size/features, and there are a bunch of nitpicky details (e.g. how low level logic actually gets implemented is different, even if they provide the same high level function), but they are somewhat interchangeable.

The main thing is just that FPGAs are more expensive and often more powerful, and normally have volatile program storage, so they are reprogrammable (big advantage if you need it, esp. for prototyping) but also require more supporting hardware to deliver that program every time they power on.

CPLDs on the other hand have non-volatile programs. They can start functioning immediately from power-on, and don't require the kind of extra support components an FPGA does. They're more or less a customizable replacement for an ASIC. However, reprogramming them is usually more difficult.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 51 posts ]  Go to page 1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group