FPGA Based Videogame System

[tcdev]

Ah, no, this is far different from emulation.

 

No. Not it is not. An FPGA implementation is no less an emulation than a software emulator.

 

It is arguably easier to make (most aspects of) an FPGA implementation more accurate than a software implementation. But that doesn't take away anything from the fact that it is still an emulation.

[tcdev]

I was under the impression the VDP was similar in design with obvious changes done for BW operation. I am aware of the CPU differences, but those chips are well documented.

Much like how the Coleco , MSX and SG1000 play parts round robin.

If the VDP tech wasn't somewhat similar in design then I am misinformed. Not the spec's exactly but their design.

 

You've been misinformed.

 

As you mention the Colecovision, MSX & SG1000 (as well as others) all use the the same VDP from Texas Instruments.

 

The Gameboy doesn't use the same VDP, nor anything derived from the design of that VDP. The similarities end with their basic purpose.

 

You could not leverage anything off either the Gameboy or NES implementations in order to produce the other.

Edited June 3, 2016 by tcdev

[RupanIII]

 

No. Not it is not. An FPGA implementation is no less an emulation than a software emulator.

 

It is arguably easier to make (most aspects of) an FPGA implementation more accurate than a software implementation. But that doesn't take away anything from the fact that it is still an emulation.

 

Nope, it's hardware running electrical signals implementing a design which accomplishes the same functions, reverse engineered, in a general purpose re programmable processor.

No original code is being fed into software to be translated into a non native format for processing and returning translated results.

It's a hardware processor which can be reconfigured for simulation of various hardware designs. It's running the code native.

[tcdev]

 

Nope, it's hardware running electrical signals implementing a design which accomplishes the same functions, reverse engineered, in a general purpose re programmable processor.

No original code is being fed into software to be translated into a non native format for processing and returning translated results.

It's a hardware processor which can be reconfigured for simulation of various hardware designs. It's running the code native.

 

There are so many things wrong with your explanation I don't know where to start. Perhaps the most glaring (and telling) is your description of an FPGA as being a "processor". And what you completely fail to recognise is that the FPGA implementation, described in a high level design language no less, is an emulation. For the most part, the resultant logic barely even resembles the original hardware design at the gate level. I suggest you read up on HDL synthesis and FPGA architecture.

 

And your statement about a "non native format" and "translated results" is just gobbledygook. The only difference between a software emulation and a hardware emulation are levels of abstraction. How do you class, for example, a processor that uses microcode to implement its instruction set? How is implementing a state machine in HDL any different from one implemented in software on a processor? There is absolutely nothing inherently more accurate (or more "pure") with hardware (FPGA) emulation as opposed to software.

 

But then again I'm only an electronic design engineer with a decade of experience in FPGA design, as well as 20+ years playing around with software emulation and about 8 years playing with FPGA emulation of retro computer/videogame systems - so what would I know...

 

A little knowledge is a dangerous thing.

[RupanIII]

Your typical "I'm a hardware engineer" mentality shows through in your innate need to show the most technical breakdown while not conveying anything to a lay person.
Again, yes, it's capable of being various things aside from merely being a 'processor' according to the design implemented by the HDL loaded.
however, it is being accomplished by programmable, or re-configurable, hardware which can perform functions like a processor, memory, etc..., and not through software creating the environment the software requires on incompatible hardware.

You are taking the engineering standpoint which is that since it's not a final ASIC it's still emulating or simulating the platform.

What your failing to recognize is the question itself asks us technical persons to draw the distinction for others on how this is different from emulation.
That is what myself and others have been answering.
Through this wonderful, ever advancing FPGA tech, hardware provided can be configured to work at the original speeds with the original hardware resources as the target platform.

These microchips allow for the software to execute as if they were running on original hardware. Whether the design meets that standard is often at issue.
If TI decides to take their VDP Circuit Diagram and precisely encode it as an HDL file, then the FPGA executes precisely as the VDP would.
I suspect you may allow me the statement that an FPGA design can often take a more direct approach to solving certain hardware issues. Or you may not to continue your point.

 

As to Intel taking up the methods original ascribed to say Transmeta or certain other earlier purveyors of flexible microcode, RISC versus CISC designs and whether they are on hardware or software levels, we come back to the basic element that

the software is looking for the right hardware. Whether it's using LongRun or LongRun 2 based tech licensed to Intel or whoever is not the concern of most anyone on this forum or someone buying a computer.
They want to know if this chip runs Windows basically and how well. That VLIW technology has been integrated into chips since the time which you exclaimed accomplishing your doctorate in computer engineering is inconsequential to them.

 

They'd probably prefer to hear something constructive like, if Mike Kennedy had a competent engineer and waited 2 years (well, he had a competent engineer in Kevtris, but, the rest of it...) the tech would have easily caught up with their aspirations and price.

They may also like to hear that this chip can be reconfigured as any of a number of older platforms, with the right hardware description file to make it so, and do so without worry of an emulator crashing due to an unstable environment, or using very little power compared to a machine doing emulation.

Emulation often makes many more things possible and as such is also quite worthy. Much of that is making Player 2 or greater a networked player, saving score data, and other fantastic tweaks people have worked out over the years.

 

I have a degree myself, so, since you said a little knowledge is dangerous, i'll say this:

I deal with your kind all of the time as well.

Now stop trying to be 'right' and remember there are non engineers on this forum, try to communicate with people in a friendlier and less condescending manner while you are at it.

That attitude in general is just highly destructive.

 

I do hope that your mostly annoyed that this conversation has occurred in your off time and that your not having such issues affect you during more important hours,

because I've seen just this cause the younger crowd, you know, fast tracked younger crowd who end up

in charge of companies these days, to cause you issues.

 

I'm done, feel free to blast me back, vitriolically, with all your might, irate or otherwise sure of any perceived superiority, and feel victorious in your conquest, as I'm done interacting on this subject with you.

 

If you felt I was attacking you at all in the previous statement, for that I apologize. I just want to give people the understanding they seek, and with my experience in the tech industry,

aside from my IT degree which doesn't cover it all, and as a former trainer for another career in my life, that's my take on it.

 

 

There are so many things wrong with your explanation I don't know where to start. Perhaps the most glaring (and telling) is your description of an FPGA as being a "processor". And what you completely fail to recognise is that the FPGA implementation, described in a high level design language no less, is an emulation. For the most part, the resultant logic barely even resembles the original hardware design at the gate level. I suggest you read up on HDL synthesis and FPGA architecture.

 

And your statement about a "non native format" and "translated results" is just gobbledygook. The only difference between a software emulation and a hardware emulation are levels of abstraction. How do you class, for example, a processor that uses microcode to implement its instruction set? How is implementing a state machine in HDL any different from one implemented in software on a processor? There is absolutely nothing inherently more accurate (or more "pure") with hardware (FPGA) emulation as opposed to software.

 

But then again I'm only an electronic design engineer with a decade of experience in FPGA design, as well as 20+ years playing around with software emulation and about 8 years playing with FPGA emulation of retro computer/videogame systems - so what would I know...

 

A little knowledge is a dangerous thing.

Edited June 4, 2016 by RupanIII

[Andromeda Stardust]

IBTL.

Edited June 4, 2016 by Kosmic Stardust

[Newsdee]

Dudes: the FPGA turns on immediately, uses extremely little power, and in principle could act exactly like the original machine, to the point of plugging natively to the original hardware and peripherals without extra interfaces. Put a good one inside a case and you wouldn't be able to tell it's not the original machine.

 

Computers like the RPi rely on a heavy OS that needs to boot for a bit. It needs a lot more power than the original because it has to run things in sequence. It can also act faithfully and bring additional features (such as saving a snapshot of the current state to continue later). It is completely overkill if you just want to play some games simply, but will do the job.

 

FPGAs are fun. It is arguably a more efficient version of the original, and makes you wonder what could have been if people had access to all the information today. I am a huge fan of the recent open source HDL efforts going on.

Edited June 4, 2016 by Newsdee

[fiddlepaddle]

Hey, you defenders of intellectual honor... look up the definition of "emulate" and you will see that ALL methods of duplicating behavior is, in fact, emulation.

 

Here, we're just talking about different ways of symbolically describing electronic behavior, and the purpose is to reproduce identical results as much as possible. Just because the term "software emulation" is commonly used to denote simulation of hardware via software does not preclude less popular meanings from being perfectly valid.

 

By the way, I am finding this discussion of FPGA very interesting.

[RupanIII]

For the most part, i could give no fecal deposit about the conversation given the passing of Muhammad Ali a few hours ago.

Back to the main party,

Waiting for Kevtris!

[roland p]

The only difference between a software emulation and a hardware emulation are levels of abstraction. How do you class, for example, a processor that uses microcode to implement its instruction set? How is implementing a state machine in HDL any different from one implemented in software on a processor? There is absolutely nothing inherently more accurate (or more "pure") with hardware (FPGA) emulation as opposed to software.

Could software emulation work/interface in realtime with a cartridge? Edited June 4, 2016 by roland p

[Andromeda Stardust]

For the most part, i could give no fecal deposit about the conversation given the passing of Muhammad Ali a few hours ago.

Back to the main party,

Waiting for Kevtris!

Muhammad is gone!?

https://www.bostonglobe.com/2016/06/03/muhammad-ali-remains-hospitalized-for-serious-issues/Rm8NoskfuoBBmOKnq55VkL/story.html

 

FPGA flies like a butterfly; stings like a bee.

EMULATOR is KO.

[Andromeda Stardust]

Could software emulation work/interface in realtime with a cartridge?

No. Retron / Retro Freak are glorified ROM dumpers...

[tcdev]

Could software emulation work/interface in realtime with a cartridge?

 

Yes, definitely. You just need the right hardware to support it.

[tcdev]

1) Your typical "I'm a hardware engineer" mentality shows through in your innate need to show the most technical breakdown while not conveying anything to a lay person.

2) You are taking the engineering standpoint which is that since it's not a final ASIC it's still emulating or simulating the platform.

What your failing to recognize is the question itself asks us technical persons to draw the distinction for others on how this is different from emulation.

3) These microchips allow for the software to execute as if they were running on original hardware. Whether the design meets that standard is often at issue.

4) I suspect you may allow me the statement that an FPGA design can often take a more direct approach to solving certain hardware issues. Or you may not to continue your point.

5) I deal with your kind all of the time as well.

6) Now stop trying to be 'right' and remember there are non engineers on this forum, try to communicate with people in a friendlier and less condescending manner while you are at it.

7) If you felt I was attacking you at all in the previous statement, for that I apologize. I just want to give people the understanding they seek, and with my experience in the tech industry,

aside from my IT degree which doesn't cover it all, and as a former trainer for another career in my life, that's my take on it.

 

 

1) Actually, my first degree was in Computer Science (software) and my first 8 years of employment was as a software engineer. It wasn't until I returned to uni to study Electrical Engineering that I moved into hardware and FPGA design. So I would argue that I'm not your "typical" hardware engineer, whatever that entails.

 

2) There is no distinction between an FPGA and a "final ASIC" with respect to the subject of emulation, so you're way off track there. And whilst the question may comprise drawing a distinction between FPGA's and "emulation" - and I agree that there is a distinction between FPGA implementation and software emulation - the fact remains that they are both emulation.

 

3) Just like software emulation allows the software to execute as if it was running on the original hardware. That's the whole point of emulation.

 

4) You may make that statement, and I would even agree. Doesn't change the underlying facts though.

 

5) "Your kind"... I very much doubt it.

 

6) I could say the same. Being told twice that you're simply wrong tends to rub the wrong way.

 

7) I understand that that you want to 'give people the understanding that they seek'. You more or less admit you have little first hand experience in this area, yet you state simply that others (myself) are wrong. Apologies if I come across as unfriendly and condescending, see above. I'm not interested in a personal slanging match either. But I have formal qualifications in both software and hardware engineering, direct experience in emulation in both software and FPGAs, so I feel I've got a pretty good handle on the concepts here - perhaps, trying not to sound too pretentious, better than most on this forum. I'm only trying to give people understanding as well. I just don't want (what I perceive as) misinformation being spread.

 

In closing, no-one can deny that FPGA emulation is different to software emulation. But underneath it all, the simple fact is that they're both emulation. But there's nothing inherently superior or more accurate about FPGA emulation; however it is arguably easier to make a more (consistently) accurate emulator using current technology with an FPGA.

[Keatah]

Could software emulation work/interface in realtime with a cartridge?

 

Of course. There was a project with a PC and a VCS cart slot and control panel some time ago. It was stuffed into a 5.25" bay. I do not recall if it dumped the cart like Retron does, or if an emulator accessed the cart on the fly, or if it was a complete real-hardware VCS stuffed in alongside the PC. Anyhow, there is no technical reason why a software emulator cannot access a hardware ROM.

[Keatah]

I also believe software emulators still have a bad rap with stuttering and glitching. This is a notion carried over from the early days when emus were not optimized and they were running on underpowered machines like Pentium 2, 3, and 4 and in conjunction with a lot of background tasks. Virus scanners would be the worst offenders.

 

These background tasks would get in the way and cause framerate and stuttering problems that were distracting as all hell. But with today's rigs (and how they're configured) this issue has largely disappeared.

[brentonius]

So, if software emulation can theoretically be as good as hardware emulation, why hasn't anything come into existence which is actually good? The closest I've come to playing good emulation via software would be the SNES emulation on the Wii U and the Mega Man emulation on PS4 (although the audio was terrible, everything else was great).

 

Thoughts?

[RupanIII]

Well, it's precisely what you have stated:
You cited two examples of Emulation software written by the original designers.
Nintendo can whip out the real hardware description and write a proper emulator and Capcom likely either got their emulation from Nintendo or have enough data to make their own. Or, well, like you said, it had audio glitches, so it's not as good as it could be if it were from Nintendo, probably.

 

Without the original schematics of the chips, the aftermarket has had to reverse engineer things and they don't end up bit for bit perfect, sometimes introducing issues.

Some issues, like esoteric clocks, are better dealt with by installing a discrete hardware clock matching said esoterica and eliminating that issue which might present itself with a convoluted issue in software.

So, if software emulation can theoretically be as good as hardware emulation, why hasn't anything come into existence which is actually good? The closest I've come to playing good emulation via software would be the SNES emulation on the Wii U and the Mega Man emulation on PS4 (although the audio was terrible, everything else was great).

 

Thoughts?

[Andromeda Stardust]

 

2) There is no distinction between an FPGA and a "final ASIC" with respect to the subject of emulation, so you're way off track there. And whilst the question may comprise drawing a distinction between FPGA's and "emulation" - and I agree that there is a distinction between FPGA implementation and software emulation - the fact remains that they are both emulation.

Assuming the "Final ASIC" is equivalent to the original console, if not from a logic gate level then at least from a functional standpoint, then who cares if the "Final ASIC" is implemented as discrete logic gates on a custom die, or an FPGA chip? You claim both are emulation, but the FPGA/ASIC is operating on the hardware level in a way that is equivalent to original chips. The software emulator tries to compute the logic of every part on a command/ASM level, by converting ASM from one CPU architecture to another. And the results of emulation are not realtime yet the results of logic gate emultaion via the FPGA, or an entire clone chip, are.

 

Surely you see the folly of using the blanket term "emulation" to describe both processes? I cannot imagine how the software emulation could possibly be superior to going the hardware route.

[+5-11under]

An FPGA is programmed. Someone needs to write the program. For video games, usually this is not by re-engineering a chip's schematic. Usually this is done by investigating data sheets and/or making note of the operation of the original. In this case, an FPGA solution is essentially emulation, that is, it is not a direct copy of the original schematic, but instead, it's an interpretation, and prone to needing revision based on comparison to the real thing (just like software emulation).

 

Take a microprocessor, for instance a 6502. I'm pretty sure any FPGA solution for this chip was programmed using the data sheet, and following that by comparing the operation to a real 6502. People normally don't refer to the schematic of the chip to obtain a program. Also, usually schematics of the chip internals are not available.

 

tcdev's got it right, here.

[Andromeda Stardust]

An FPGA is programmed. Someone needs to write the program. For video games, usually this is not by re-engineering a chip's schematic. Usually this is done by investigating data sheets and/or making note of the operation of the original. In this case, an FPGA solution is essentially emulation, that is, it is not a direct copy of the original schematic, but instead, it's an interpretation, and prone to needing revision based on comparison to the real thing (just like software emulation).

 

Take a microprocessor, for instance a 6502. I'm pretty sure any FPGA solution for this chip was programmed using the data sheet, and following that by comparing the operation to a real 6502. People normally don't refer to the schematic of the chip to obtain a program. Also, usually schematics of the chip internals are not available.

 

tcdev's got it right, here.

I would imagine schematics are definitely useful for emulator authors and FPGA programmers. Of course the real masterminds like Kevtris are poking around the internals with logic probes to see every high and low logic signal and what they are doing. The schematics only tell you which traces go where, not the signals they possess.

[tcdev]

Assuming the "Final ASIC" is equivalent to the original console, if not from a logic gate level then at least from a functional standpoint, then who cares if the "Final ASIC" is implemented as discrete logic gates on a custom die, or an FPGA chip? You claim both are emulation, but the FPGA/ASIC is operating on the hardware level in a way that is equivalent to original chips. The software emulator tries to compute the logic of every part on a command/ASM level, by converting ASM from one CPU architecture to another. And the results of emulation are not realtime yet the results of logic gate emultaion via the FPGA, or an entire clone chip, are.

 

Surely you see the folly of using the blanket term "emulation" to describe both processes? I cannot imagine how the software emulation could possibly be superior to going the hardware route.

 

Who cares indeed - that's my exact point.

 

An FPGA implementation based on a black-box reverse-engineering process, as 99.9% are, is not "equivalent to original chips". Far from it. It's an emulation described in a high level language whose outputs approximate those of the original chip given the same inputs - and nothing more. Just like software emulation. Again, there's absolutely nothing magic about the fact that it's implemented in hardware. It's a different design implemented with different logic - period. aka. an emulation. Why is that so hard to accept?

 

Why do you claim that software emulation isn't real-time? There are plenty of aspects of the timing within an FPGA design that are only approximations of the original chip. Some chips have analogue aspects to them (eg. SID) that can only ever be approximated in an FPGA. Some chips have non-specified or variable gate delays which can impact the original design and again, only be approximated in an FPGA. FPGAs themselves have clocking constraints that sometimes mean that implementations can only be approximated and are therefore known to be inexact. It's also sometimes possible to use much faster software emulation to mitigate these issues. If I can emulate a 4MHz Z80 CPU in software running at effectively 5x the speed, then how is that not "real time"? Because it's not tied to a PLL in the FPGA that is programmed to approximate the original clock? That's not a requirement of "real time".

 

Your argument about the process of "converting ASM" is completely and utterly irrelevant to the discussion. The mechanics of the process don't matter in the slightest. Simply because the software emulation is abstracted a few more levels away from the original design doesn't make an FPGA implementation any less of an emulation. Yes, you could argue that it's closer to the original design, but - as I seem to be repeating over and over again - it's still an emulation.

 

I've done plenty of FPGA implementations where I didn't even look at the schematics. I've used the exact same components for tilemap and sprite systems across many implementations that are completely and utterly unrelated. And you know what - no-one could possible know without looking at the source - because the function of that logic is to take values stored in registers and/or memory and render them as pixels on the screen as the raster scans the CRT and the output is indistinguishable from the original. How is that not an emulation? In what way is this superior to a software emulation? It's not. Therefore there is nothing inherently superior to an FPGA implementation.

 

I never once said or even implied that software emulation is superior to hardware. My preference is actually FPGA emulation. But again, and I'm sick of saying this, it is still an emulation.

[Andromeda Stardust]

^^ Did anyone fail to bring up the lag issues with traditional emulation? Many emulators lag badly. An FPGA implementation requires no screen buffer to render graphics to a display like a traditional CPU/GPU combo does. An FPGA can pump pixels out to the screen in real time, whether said display is a CRT beam or a 480p, 720p, 1080p, or even 4k display. Just the zero lag alone makes a huge difference to some gamers. 16ms of lag can mean the difference between defeat and victory in some games. No ARM or x86 implementation of a game console is going to be pumping pixels out to the sreeen in realtime. No way no how. and that is exactly what Kevtris intends to do with his Zimba 3000.

[tcdev]

An FPGA is programmed. Someone needs to write the program. For video games, usually this is not by re-engineering a chip's schematic. Usually this is done by investigating data sheets and/or making note of the operation of the original. In this case, an FPGA solution is essentially emulation, that is, it is not a direct copy of the original schematic, but instead, it's an interpretation, and prone to needing revision based on comparison to the real thing (just like software emulation).

 

And if even if you do implement the schematic, verbatim, in an FPGA (which can and has been done) - and even if we completely ignore the internals of the chips in the circuit - then it's STILL an approximation, it's STILL an emulation! Because an FPGA comprises a few basic building blocks that are configured together to behave like (aka emulate) the circuit which is described by the high level language.

[tcdev]

^^ Did anyone fail to bring up the lag issues with traditional emulation? Many emulators lag badly. An FPGA implementation requires no screen buffer to render graphics to a display like a traditional CPU/GPU combo does. An FPGA can pump pixels out to the screen in real time, whether said display is a CRT beam or a 480p, 720p, 1080p, or even 4k display. Just the zero lag alone makes a huge difference to some gamers. 16ms of lag can mean the difference between defeat and victory in some games. No ARM or x86 implementation of a game console is going to be pumping pixels out to the sreeen in realtime. No way no how. and that is exactly what Kevtris intends to do with his Zimba 3000.

 

Your comment is valid but not relevant to the core discussion here - whether or not an FPGA implementation is an emulation. We're not focusing on performance.

 

Besides, the requirement for a "screen buffer" is not strictly a "software requirement" but dictated by the operating environment. Programming at the bare metal on the right platform it would definitely be possible to write a software emulator that renders directly into the frame buffer of the video hardware. Just like the good old days of 8/16-bit computers.

 

EDIT: You'd need a high end (expensive) FPGA and a good design to pump out 4K video

Edited June 5, 2016 by tcdev