FPGA Based Videogame System

[aloram]

Hi. I've been following this thread for a while now. Thanks for all the really interesting insights, I've learned a lot.

 

FYI, I'm in the "name your price" crowd, as long as it has a composite option and a way to connect the original controllers.

[Keatah]

I'm also in the name your price crowd as long as it tops out at $500.

[Newsdee]

@Keatah I liked Kevtris' idea of having a pluggable board to change the video output. Personally I'd rather have HDMI and SCART because that carries conposite, svideo and RGB signals (and so is trivial to adapt to whatever is needed).

 

@tcdev

Yes there is room for all approaches. As long as the results are documented and available for all, everybody benefits. Yes it means you have the risk of copycat systems, but those don't seem to have fared extremely well in the long run.

[RupanIII]

@Kevtris

I'll totally be interested in your Zimba 3K ... Z3K for short I guess.
I have the Retron 5 in one room, and I got the Retro Freak for my Turbo Grafx games (may give the Retron to someone after I take it apart and see if there's anything worth reinforcing, maybe i'll see from your vid. ).

 

The Retro Freak is great. I'm detecting no appreciable , or actually discernible, lag on it sofar. I was just playing TMNT: HH for the MegaDrive earlier and nada.... and I actually love the USB controller they included.

It's quite responsive AND i see no lag. I haven't tried the multi classic port USB adapter yet.

The way it's all in a tiny box that plugs into essentially a cartridge bay dock is wonderful IMHO.
I know you won't want to do that for cost savings, but, I simply thing they struck gold on that design for them. And of course you really by default dump all of your games to microSD out of the box.. yeah, they didn't kid themselves, lol!

 

So, onto the Z3K

I was wondering if you will make the video connector section a user replaceable module?

Something which you have all of the connections on the motherboard and perhaps it sockets into the board from a daughter board, much like any old chip replacement, EPROMS, etc. How many pins do you need? I'm sure some standard sockets would so it (just for the sake of balance and ready availability. )

You know better than me, but, do you need different HDMI chips for Pal/NTSC/SECAM?

I figure RGB HsVsCs Comp Vt1 Vt2 lines get it started etc.

 

Just socket in and screw into the external housing to secure maybe?

 

I don't really have much to add on how an FPGA simulation/emulation differs from a PC one, except in the following ways:

 

An FPGA will have no lag in the best case, and minimal lag in the worst case (i.e scaling to HDMI, etc). A software emulator, on the other hand, will have lots of sources of lag built in. There will be the controller interface aspect, the CPU/processing part, and then the video rendering portion. Some of these can be minimized possibly, but if there's an OS running underneath, I think lag will be unavoidable.

 

As a ferinstance, my NES core has a "real NES" video output mode where it recreates the exact same voltages and transitions using a DAC to recreate the video signal. There's no lag involved- it is generated in the same way a real system generates its video signal, complete with the same steps and transitions. I guess the lag, if you can call it that, will be a few nanoseconds for the data to propagate through the DAC and be presented on the output pin. My "real NES" video is an exact reproduction (well it looks like that on a scope and on a monitor using direct A/B testing) of what a real system outputs. You'll have trouble making a software emulator do this. As a bonus, I provide an S-video version of this signal too. Unlike a real NES which has composite video only, S-video is easily possible while maintaining everything else exactly the same.

 

I tried out a Retron 5 (there's a video about it actually... I will link it below) and it's total garbage. I didn't think I was very sensitive to lag in a videogame, but holy crap, that thing is useless. I tried to play Boulder Dash for NES on there and the lag was extremely terrible. I don't know how much it was but it has to be 4-5 frames at least. How anyone could play this, I don't know. Of course, lag issues CAN be minimized in software emulators, but I don't think they will ever be really conquered. One big issue is i.e. a PC has a fixed frame rate, and the system being emulated has a slightly different frame rate (i.e. 60Hz monitor refresh vs. 60.09Hz refresh for the NES) so there will be compromises made somewhere. Either by slowing the system down (what I do for HDMI) or by frame dropping/duplication.

 

Re: writing "code" for an FPGA, IMO writing HDL(hardware definition language... i.e. Verilog) isn't writing code. It may look like code and smell like code, but to me it's describing how a digital logic circuit is formed. It is basically a written implementation of a schematic. The big obvious difference is a piece of code executes sequentially, one instruction after another, while in HDL, every line of code "executes" at the same time.

 

Also, regarding if an FPGA implementation is an emulation or not, what about my 2600 and 7800? I basically reimplemented the chips used in these systems at the transistor level using the chip schematics, vs. actual black box reverse engineering. Since the chips are NMOS and use dynamic logic, some minor changes were made here and there to simulate this, because an FPGA cannot directly simulate dynamic logic.

 

The last thing about my FPGA cores is their accuracy. I strive for accuracy, and include many hours of my own research into this, involving making custom hardware and plenty of test fixtures, and logic analyzer time along with reams of custom code. Not many emulator writers can claim this. There's always going to be a "long tail" of bugs but I try to fix 'em all. Of course, software emulators can achieve this too, but that would require mucking around with hardware.

 

Whoops, forgot the youtube video:

 

[Andromeda Stardust]

 

Whoops, forgot the youtube video:

 

Off topic, but what are your thoughts on the Japanese Retro Freak console? I've got one and it's nice for what it does, despite it's flaws. The cart ports are actually solid unlike the Retron, and it only lags noticeably when you turn on the video filters.

 

Can't wait for your Zimba project to become reality! :cool;

[kevtris]

Off topic, but what are your thoughts on the Japanese Retro Freak console? I've got one and it's nice for what it does, despite it's flaws. The cart ports are actually solid unlike the Retron, and it only lags noticeably when you turn on the video filters.

 

Can't wait for your Zimba project to become reality! :cool;

I have not used it so I can't say much about it.

[kevtris]

@Kevtris

I'll totally be interested in your Zimba 3K ... Z3K for short I guess.

I have the Retron 5 in one room, and I got the Retro Freak for my Turbo Grafx games (may give the Retron to someone after I take it apart and see if there's anything worth reinforcing, maybe i'll see from your vid. ).

 

The Retro Freak is great. I'm detecting no appreciable , or actually discernible, lag on it sofar. I was just playing TMNT: HH for the MegaDrive earlier and nada.... and I actually love the USB controller they included.

It's quite responsive AND i see no lag. I haven't tried the multi classic port USB adapter yet.

The way it's all in a tiny box that plugs into essentially a cartridge bay dock is wonderful IMHO.

I know you won't want to do that for cost savings, but, I simply thing they struck gold on that design for them. And of course you really by default dump all of your games to microSD out of the box.. yeah, they didn't kid themselves, lol!

 

So, onto the Z3K

I was wondering if you will make the video connector section a user replaceable module?

Something which you have all of the connections on the motherboard and perhaps it sockets into the board from a daughter board, much like any old chip replacement, EPROMS, etc. How many pins do you need? I'm sure some standard sockets would so it (just for the sake of balance and ready availability. )

You know better than me, but, do you need different HDMI chips for Pal/NTSC/SECAM?

I figure RGB HsVsCs Comp Vt1 Vt2 lines get it started etc.

 

Just socket in and screw into the external housing to secure maybe?

 

Yes, that was the idea. I was going to use pcie connectors since they are cheap and high density and high quality. I was going to have HDMI as the standard and then sell other plug in boards most likely. I don't know how much they will cost though, probably $40ish range? THe idea was there would be some kind of thumb screws or similar holding the board in, and then it'd be fairly easy to undo them and slot in a new board with other IO on it. I was thinking possibly of JAMMA style plugins too. Since it is a pcie connector, there should be plenty of IO available if I so desire to hook it up.

[Schizophretard]

I have a question with software vs. hardware emulation coming out of a box into a CRT. Which, if either, would work with Duck Hunt and if both then which would work better?

[Newsdee]

I have a question with software vs. hardware emulation coming out of a box into a CRT. Which, if either, would work with Duck Hunt and if both then which would work better?

That depends. I don't think any emulator was written to support the Zapper light gun on a CRT, but there are USB light guns that would work like a mouse, and thus be compatible.

[aloram]

I've read through this whole thread, and I've read up a bit on FPGAs, but I'm still a bit unsure about a few things.

 

1. On the Zimba, would all games play, look, and sound exactly the same as they would on the original systems?

 

2. Any idea what the life expectancy of the Zimba would be? I'm assuming one reason for making it is because it'll (presumably) outlast the original systems. Is that correct?

 

3. Are there any expected "disadvantages" or weaknesses of the Zimba?

 

If anyone, Kevtris or otherwise, could shed some light on any or all of my questions I'd really appreciate it. Thanks.

[Keatah]

The shortest lived components will likely be any flash memory.

[Andromeda Stardust]

The shortest lived components will likely be any flash memory.

Yes, but if the flash chip loses it's code, wouldn't it be possible to simply reflash the firmware? Suppose flash chips have a life cycle of 10,000 writes, but each write is only good for about 20 years or so before it needs to be reflashed. So 30 years from now, the flash chip has suffered from bit rot, you can reflash it again, assuming a suitable USB-compatible device with appropriate drivers is still available for programming. And you'll still have another 9,998 or so write cycles. So you could keep it running for a thousand years or more with regular maintenance by reflashing the firmware every 20 years. Mask ROMs in carts will probably last even longer assuming the contacts hold up.

[Keatah]

Not exactly. Each re-write after a fail is going to be exponentially less long-lived. You might do it once or twice at best. And then the internal controller is going put a stop to it. But, in layman's terms, the insulated bucket that holds the data charge dissolves. It leaks. It's like the clearcoat on your car wearing away and the water doesn't bead anymore.

 

And for those of you thinking writes only cause wear, so do reads - albeit with 10,000x MORE endurance.

 

ADDED: You have TLC and QLC to thank for this. That continual push to shrink geometry. Thankfully they can back up a few sizes and use the 3D layouts to achieve even higher density. But these haven't yet trickled down into mainstream products in any meaningful quantity. That's why I keep saying 2017 is the year of the SSD. Larger geometry will be out in force, and we'll be stacking them 256 layers deep.

 

Samsung just started doing a 512GB SSD that operates at 1,500MBPS. It has onboard power regulators, the main controller, 512MB DRAM cache, and all the miscellaneous bus circuitry. All the size of a quarter. That's 0.2x of an M.2 stick. Expect it in consumer laptops before Christmas 2017!

 

And look for SOCs with these around the ass-end of 2018. This is only the consumer stuff in the pipeline already. Wait till you see what's on the drawing boards.

Edited June 6, 2016 by Keatah

[Schizophretard]

That depends. I don't think any emulator was written to support the Zapper light gun on a CRT, but there are USB light guns that would work like a mouse, and thus be compatible.

 

It was a hypothetical question. What I'm wanting to know is if an emulator was written to support the Zapper while running on a Raspberry Pi or something onto a CRT TV and if an NES core was written to support the Zapper while running on an FPGA then if a really good player of Duck Hunt were to take part in an experiment where they played it with both and an actual NES while not knowing which they are playing on each time then would there be something that is inherently different between software emulation vs. hardware emulation that would affect their average score so that they could tell when they are playing on each?

 

The point of the question is which could pass a kind of Turing test the best and I think testing with the Zapper or even R.O.B. would be a good test because those accessories would have to behave as if what is on the screen is an NES.

[Great Hierophant]

 

It was a hypothetical question. What I'm wanting to know is if an emulator was written to support the Zapper while running on a Raspberry Pi or something onto a CRT TV and if an NES core was written to support the Zapper while running on an FPGA then if a really good player of Duck Hunt were to take part in an experiment where they played it with both and an actual NES while not knowing which they are playing on each time then would there be something that is inherently different between software emulation vs. hardware emulation that would affect their average score so that they could tell when they are playing on each?

 

The point of the question is which could pass a kind of Turing test the best and I think testing with the Zapper or even R.O.B. would be a good test because those accessories would have to behave as if what is on the screen is an NES.

 

Unless your emulator and the hardware it runs on supports output to a 15KHz CRT screen, there would be no point to Zapper emulation, the Zapper just wouldn't work.

 

A Raspberry Pi has a composite video jack, so you could theoretically design a NES emulator that would output its video image to the right kind of TV. However, it is a software NES emulator and depending on the processing power of the CPU, there may be substantial input latency. That may throw off your Zapper aim. Please note that the Zapper is not the most precise device ever made.

[kevtris]

I have a question with software vs. hardware emulation coming out of a box into a CRT. Which, if either, would work with Duck Hunt and if both then which would work better?

I have already used an unmodified zapper on my FPGA NES and it worked fine. Of course I was using a CRT as well.

[Newsdee]

I don't know to what extent the video signal and the Zapper 15khz signals need to be aligned. Assuming it has to be the exact same clock it's a bit harder (but probably possible) to keep them in sync.

 

Basically it's much harder to do on an emulator and I doubt anybody would bother when you can easily use a mouse instead.

 

On FPGAs you can probably do both (Zapper and mouse) without much trouble, because you can easily customize it to make both signals use the same clock regardless of input method.

Edited June 7, 2016 by Newsdee

[kevtris]

I've read through this whole thread, and I've read up a bit on FPGAs, but I'm still a bit unsure about a few things.

 

1. On the Zimba, would all games play, look, and sound exactly the same as they would on the original systems?

 

2. Any idea what the life expectancy of the Zimba would be? I'm assuming one reason for making it is because it'll (presumably) outlast the original systems. Is that correct?

 

3. Are there any expected "disadvantages" or weaknesses of the Zimba?

 

If anyone, Kevtris or otherwise, could shed some light on any or all of my questions I'd really appreciate it. Thanks.

 

#1: The goal is a 100% "authentic" experience, and I think I achieve a pretty decent score here. Things like video frame timing are exactly the same as a real system, down to the number of scanlines and cycles per scanline even.

 

#2: Not sure what you mean. It's a piece of hardware like anything else, and since I design conservatively, the hardware should live a fairly long time. Since the systems are written in verilog, it means that they are pretty much immortal, and new hardware with new models of FPGA, etc. can be used. The resulting hardware should work and act exactly the same as any previous models.

 

#3: The only one I can think of is cost.

[Great Hierophant]

I find it particularly impressive that your FPGA NES will output identical waveforms with a real NES. If I read that correctly, it should put out the same video signal, warts and all, hopefully minus jailbars. In this case I am talking about the three-line stairstep effect that was intended to reduce the effect of composite color artifacting. The effect tends to make screenshots and video capture of the native NES signal look much more ugly compared to other systems of the 1980s that do not use this effect.

Edited June 7, 2016 by Great Hierophant

[Schizophretard]

 

Unless your emulator and the hardware it runs on supports output to a 15KHz CRT screen, there would be no point to Zapper emulation, the Zapper just wouldn't work.

 

A Raspberry Pi has a composite video jack, so you could theoretically design a NES emulator that would output its video image to the right kind of TV. However, it is a software NES emulator and depending on the processing power of the CPU, there may be substantial input latency. That may throw off your Zapper aim. Please note that the Zapper is not the most precise device ever made.

 

 

I don't know to what extent the video signal and the Zapper 15khz signals need to be aligned. Assuming it has to be the exact same clock it's a bit harder (but probably possible) to keep them in sync.

 

Basically it's much harder to do on an emulator and I doubt anybody would bother when you can easily use a mouse instead.

 

On FPGAs you can probably do both (Zapper and mouse) without much trouble, because you can easily customize it to make both signals use the same clock regardless of input method.

 

I can't tell if my questions and the point behind them is being understood or not. When I think of perfect emulation, rather through software or hardware, then what comes to mind is that someone could theoretically put the hardware in use into the shell of the console being emulated and I couldn't tell that it isn't original hardware because it works with all TV's, all accessories(original accessories and not things like mice for Zappers) and all games exactly as the original hardware would. I could sit it right next to the real deal with both hooked up to two identical CRT TV's and wouldn't tell the difference. In other words, a clone through emulation.

 

To put that another way, what is the ideal hardware setup with software emulation running on it that I could get today that would most closely match that ideal described above and if I bought it then later also bought the Z3K with all the extras like cart adapters and with all of Kevtris's goals with the cores and all the other plans he has for it then which of the two would likely pass my "clone Turing test" the best? Like a software emulated Z3K vs. a hardware emulated Z3K. Which would I likely declare the winner?

[Schizophretard]

I have already used an unmodified zapper on my FPGA NES and it worked fine. Of course I was using a CRT as well.

 

Do you have a video?

[Newsdee]

To put that another way, what is the ideal hardware setup with software emulation running on it that I could get today that would most closely match that ideal described above and if I bought it then later also bought the Z3K with all the extras like cart adapters and with all of Kevtris's goals with the cores and all the other plans he has for it then which of the two would likely pass my "clone Turing test" the best? Like a software emulated Z3K vs. a hardware emulated Z3K. Which would I likely declare the winner?

If I understand correctly your "clone turing test" would be putting it inside the original console box and check whether the electrical signals are exactly the same as the original on each port (video, controllers, etc).

 

FPGAs are much better suited for that than emulators and would consume much less power for an accurate rendition. Emulators can achieve accuracy too but with a much stronger CPU (see higan/bsnes) and higher power consumption. At least from what I've tested with my hardware (MiST FPGA, RPi, PC and a few consoles).

 

Also I do not think an emulator exists that supports all accessories natively. The Retro Freak (for example) doesn't output composite so can't support it.

 

If you goal is replicating accurately real hardware without embellishments or extra features then IMHO FPGAs are the way to go (to just play the games an emulator will do fine, or even better considering 3D upscaling).

Edited June 7, 2016 by Newsdee

[Keatah]

The perfect emulator capable of passing a turing test doesn't exist yet. It may never come to fruition either, because interest is likely to be lost as it approaches the +95% "done" mark. Happens with thousands of projects, they're close, but no cigar.

[Newsdee]

As to what can you get today that is close to the Z3K, check out the MiST FPGA.

 

Ongoing open source work so won't have all the refinements Kevtris has already in store, but for example there is a ZX Spectrum core with accurate timings.

[Keatah]

It will be interesting to see what amenities the proposed z3k offers. In the meantime I've been playing on software emulation so long now that it would seem foreign and even a step backwards if I was to start gaming on real hardware like from the 70's. Spoiled by too many conveniences and elimination of clutter.

 

One thing I want to see is a reduced-price z3k that ships as a bare board. Something I can incorporate into a custom PC case and not feel bad about stripping down a newly bought device.