FPGA Based Videogame System

[Pixelboy]

I know it sounds like I'm just praising emulators right now but I'm really excited about the FPGA SNES. There are some visual options for the Nt Mini; so naturally I'm curious as to what Super Nt will offer or is even capable of offering.

I think the above illustrates the main difference between software emulation and FPGAs: An FPGA can provide high accuracy (if the core is crafted with love and patience) but it usually doesn't offer much in terms of extras, mostly because of FPGA hardware limitations. On the other hand, what software emulation loses in emulation accuracy it gains in extra bells and whistles (savestates, advanced display filters, etc.).

 

FPGAs have been around for over a decade, but only now are they starting to show some serious muscle. Note that the key word here is "starting". It's going to take several more years before affordable FPGA solutions have enough meat to them to support the stuff that we take for granted with software emulation today.

[Andromeda Stardust]

 

(as for the core store I just hope there will be a way to, for example, run any SA-1 game while an SA-1 cart is plugged in the Supter NT, but if such a feature were worked on, I'd understand that you can't talk about any of that right now)

 

I'm aware due to contractual obligations Kevtris cannot comment on any "core store" or jail breaking ability, but I was thinking if the system is ever allowed to run SNES ROMs off of the SD card, would it be feasible to use a "donor" cart for the FX, SA-1, and others? These are the two big ones (because DSP1 is easy) and still not fully supported in any flash cart. Due to complexity the FPGA may or may not have enough room to simulate these chips, if not, a "donor" game would be the next best thing. Most of us have at least one FX or SA-1 game floating about.

 

I am wondering if it would be technically feasible for an FPGA console to access the enhancement chip on a "donor" cart to run a different game (preferably without jacking up the SRAM on the donor PCB).

 

Thanks. Also looking forward to getting my ass kicked at Super Turrican when my Super NT arrives. That's just icing on the cake for me...

[AtariNerd]

 

 

I am wondering if it would be technically feasible for an FPGA console to access the enhancement chip on a "donor" cart to run a different game (preferably without jacking up the SRAM on the donor PCB).

 

...

 

Maybe create something like an Super-NT-XM module, in the fashion of the Atari 7800 project...*(?... ...)* , that plugs into the cart port and includes implementations of some of the more common chips...

[Keatah]

I think the above illustrates the main difference between software emulation and FPGAs: An FPGA can provide high accuracy (if the core is crafted with love and patience) but it usually doesn't offer much in terms of extras, mostly because of FPGA hardware limitations. On the other hand, what software emulation loses in emulation accuracy it gains in extra bells and whistles (savestates, advanced display filters, etc.).

 

A very balanced summary of the main differences.

 

FPGAs have been around for over a decade, but only now are they starting to show some serious muscle. Note that the key word here is "starting". It's going to take several more years before affordable FPGA solutions have enough meat to them to support the stuff that we take for granted with software emulation today.

 

I have some electronic test equipment from the early 1990's that have Xilinx FPGAs in them. So more than 20 years. 1-time Programmable Logic Devices came about in the early 1970's. And FPGA as we know them came on the market in the late 1980's.

 

I think a different style of core has to be created, one that allows internal probing and output of each LogicElement. One that allows for each element's state to be viewed and saved. Each LE's state would consume around some number of bits in the save-state file. I could guess about 50 bits per element. It will be different for each element depending on the functionality assigned to it. Essentially this would copy the current state of the truth table and save it in the file. Then you would need to do the same for the various memory arrays.

 

Then to restore, the core will need to accept the save-state data. Each LE will need to be set to what it was according to the SaveState file. And then the various memory arrays need to be put back. All this is very similar to imaging a traditional hard disk.

 

But the cores as they are written today do not support that sort of spying and restoring. The size of the resulting SaveState file would be large, as big as all the RAM + the data for each LE. With today's storage devices it isn't an issue. Just pointing out what needs to be done.

 

Think of all this as setting up a chessboard. First you draw the chessboard on paper. Akin to setting up the FPGA by bitstreaming the core into place. Then you look at each of the 64 positions and place the pieces according to your last game, the SaveState data.

 

An outboard CPU or another FPGA would be of help here. The chessboard itself can't automagically place pieces. It has to be set-up from outside.

---

 

Alternatively a differently designed core would output key variables from the simulated CPU and other logic chips and perhaps result in a smaller SaveState file. Think of it as a partial backup of critical information. Or there may be other more efficient ways of taking a snapshot.

 

I prefer grabbing the whole shebang and calling it a day. I'd also like to see a traditional general-purpose CPU that assists in other tasks like conducting user interface activities, managing files, doing savestates, managing loading of the cores. In fact, take it a step further, and have the FPGA play slave to the PC. The sky's the limit when you have all those resources doing the care and feeding.

 

You'll gain all the advantages, features, and versatility of software emulation while at the same time using the FPGA to enforce the strict timing it seems to be so good at.

[Guspaz]

Many advances in retro gaming related hardware these days is thanks to FPGAs or CPLDs. Video adapters like the GCVideo, RGB/HDMI mods like the NESRGB, N64RGB, Hi-Def NES, UltraHDMI, scalers like the OSSC and Framemeister, flash carts like the Everdrive and SD2SNES, clone consoles like the Nt Mini, AVS, and Super Nt, even emulation boxes like the RetroN 5 (which IIRC uses a CPLD to drive the cartridge interface).

 

EDIT: I think even the gscartsw-lite uses an Altera CPLD for the sync processing and auto-switching logic.

Edited October 24, 2017 by Guspaz

[Keatah]

I'd rather hope to do away with adapters and converters. Unfortunately they're still a necessary evil. If we have to have complexity, keep it hidden in the chips and code. Out of sight.

[retro_fan]

One large problem with SNES save states from a cartridge (i.e. the game saver+) is they can't save the state of the SPC. This causes all sorts of problems with games. I am not going to support them since it's a huge pain to do so, and there's a lot of RAM to back up (VRAM, WRAM, sound ram) and there's no way to save the state of expansion chips in the carts. This makes it fairly unworkable.

 

[...]

 

 

Regarding save states and other features that we may miss from emulators such as more advanced shaders/filters, rewind, network gameplay, fancy menus etc. Do you think kevtris that incorporating something like an ARM processor into the Zimba 3000 design might allow for implementing some of this stuff? There are FPGA boards where an ARM processor seems to be really well integrated with the FPGA part, check out this discussion, for instance (you even have been mentioned there ): Has anybody used Zynq for FPGAgaming?

 

Can you see any drawbacks of such a solution?

[Riptide]

Got to admit the timing of the Super NT announcement was a bit annoying since Analogue hadn't managed to ship the last batch of the NT Mini preorders yet. That said I didn't cancel my Mini preorder since the Super NT doesn't have analog video out and the core store is not confirmed. I'll likely order one later on once we have more info; despite the lack of analog video out, a genesis and/or neo geo core would put me over the edge.

 

I think there was some debate a few pages back about whether they had plans for another version that had the extra video outputs, heres the email response I got from support when I asked:

No plans have been made whether or not to release a variation of the Super Nt with additional video capabilities. You can follow our newsletter (found at the bottom of analogue.co) to be updated on any of our future projects or announcements. Let me know if you have anymore questions.


[mrnarse]

Thanks for the info about save states and cartridge solutions, Kevtris.

 

Does anyone know how often the FPGA chips are used on flash carts (especially the SD2SNES)? Are they only used when they need to emulate a special chip, or are they used when playing all games?

 

If its the latter, I wonder if the extra memory freed up on the flash carts FPGA would make emulating the SA1 and Super FX chips easier for the SD2SNES. It would be in a situation like my earlier unworkable idea about save states, where it would only work as a special chip core when plugged into the Super NT while the NT runs games off of its own internal SD card.

 

Thats if Kevtris hasnt secretly tackled all the special chips on his own, of course. Well find out in a February!

[Kismet]

 

 

Regarding save states and other features that we may miss from emulators such as more advanced shaders/filters, rewind, network gameplay, fancy menus etc. Do you think kevtris that incorporating something like an ARM processor into the Zimba 3000 design might allow for implementing some of this stuff? There are FPGA boards where an ARM processor seems to be really well integrated with the FPGA part, check out this discussion, for instance (you even have been mentioned there ): Has anybody used Zynq for FPGAgaming?

 

Can you see any drawbacks of such a solution?

 

I actually don't see any logical reason why save states are impossible. It's a FPGA, it can be halted and dump the state of the ram and registers. How do you think the FPGA is programmed in the first place?

 

As for enhancements, other than game-genie type of hack-ability, it's unlikely that anything else will ever exist because that is outside the scope of what the SNES could do. My personal opinion of shaders/filters is that people don't use them and don't like them, except in a few edge cases where it's taking advantage of the GPU to scale up 1080p, 2160p and beyond where otherwise the CPU of the emulator would not keep up. I'm one of those people who have no love for CRT filters, and think most de-pixelizing filters (xBRZ) are barking up the wrong tree, and look exceptionally bad. If you want this kind of thing, stick with the laggy software emulators.

[Andromeda Stardust]

A very balanced summary of the main differences.

 

 

I have some electronic test equipment from the early 1990's that have Xilinx FPGAs in them. So more than 20 years. 1-time Programmable Logic Devices came about in the early 1970's. And FPGA as we know them came on the market in the late 1980's.

 

I think a different style of core has to be created, one that allows internal probing and output of each LogicElement. One that allows for each element's state to be viewed and saved. Each LE's state would consume around some number of bits in the save-state file. I could guess about 50 bits per element. It will be different for each element depending on the functionality assigned to it. Essentially this would copy the current state of the truth table and save it in the file. Then you would need to do the same for the various memory arrays.

 

Then to restore, the core will need to accept the save-state data. Each LE will need to be set to what it was according to the SaveState file. And then the various memory arrays need to be put back. All this is very similar to imaging a traditional hard disk.

 

But the cores as they are written today do not support that sort of spying and restoring. The size of the resulting SaveState file would be large, as big as all the RAM + the data for each LE. With today's storage devices it isn't an issue. Just pointing out what needs to be done.

 

Think of all this as setting up a chessboard. First you draw the chessboard on paper. Akin to setting up the FPGA by bitstreaming the core into place. Then you look at each of the 64 positions and place the pieces according to your last game, the SaveState data.

 

An outboard CPU or another FPGA would be of help here. The chessboard itself can't automagically place pieces. It has to be set-up from outside.

---

 

Alternatively a differently designed core would output key variables from the simulated CPU and other logic chips and perhaps result in a smaller SaveState file. Think of it as a partial backup of critical information. Or there may be other more efficient ways of taking a snapshot.

 

I prefer grabbing the whole shebang and calling it a day. I'd also like to see a traditional general-purpose CPU that assists in other tasks like conducting user interface activities, managing files, doing savestates, managing loading of the cores. In fact, take it a step further, and have the FPGA play slave to the PC. The sky's the limit when you have all those resources doing the care and feeding.

 

You'll gain all the advantages, features, and versatility of software emulation while at the same time using the FPGA to enforce the strict timing it seems to be so good at.

You are overcomplicating it. To do save states on an FPGA machine, you need two copies of the core, including all RAM and logic states. Of cource in a modern emulator with hundreds of Mb up to Gb or RAM, you could hold a thousand state machines if you wanted.

 

FPGA needs a separate copy of the core for each state. State zero is your working game. State one is your back up. Designate a single hotkey for save and resume. Hitting "save" copies the contents of the working core state zero to the static core state one. Hitting "resume" copies the static state to the working state. Execution would be temporarily halted during the copy operation, which should take no more than one frame considering how massively parallel the FPGA is. So an SNES running on on a 25k LE would require a 50k LE for save state support, and even then may be buggy or crash with real carts, if any logic state exists inside the cartridge that cannot be directly read and manipulated from the system bus. This excludes pretty much all expansion chip games.

 

Even with an FPGA state machine, you get barebones functionality. No 10+ states, record, replay, pause, rewind, etc of game play. You can't beat the game then save and then play other games and then show your buddy the replay when he comesover the following weekend. The state is volatile so it is gone when you change the game or power down the system.

[mrnarse]

A couple of features I’m hoping/expecting to see on the Super NT:

 

- Power on/off via controller (the Mini NT can do it)

- SPC player (Kevtris has already written an FPGA SPC player in the past)

 

Back when the Mini NT and AVS were announced, the articles that covered it did a really terrible job of explaining the difference between software emulation and FPGA. This time around they’ve done a much better job, and most of the articles I’ve read have explained it well. Good to see that general knowledge of the benefits of FPGA has increased over the last year.

[Schizophretard]

I think if it had some kind of sleep mode that keeps the game paused would be a good compromise for lack of save states.

[brentonius]

That FPGA based portable SPC player Kev put up on YouTube is really cool. I wish Kevtris would sell those hehe. I'd so buy one!

[brentonius]

Two years ago Ikari said he'd start on save states for sd2snes after 0.1.7. We are n 0.1.7e now I believe. So it might be soonish as we are nearly there...

[Wolf_]

Two years ago Ikari said he'd start on save states for sd2snes after 0.1.7. We are n 0.1.7e now I believe. So it might be soonish as we are nearly there...

Also IF the super nt covers fx chips that would probably strongly motivate Krikzz to add save states as that would keep his product relevant.

[gulps]

 

I ordered mine (to Europe) the first day they came out at May 31. I haven't news about the shipping yet..

 

Just wait! Long wait... Maybe they are full of work with the new Super Nt...

 

 

Just received today the shipping info (to Europe) at mailing

 

I will write when received!

[atmn]

 

As for which system I used for a model, it was indeed the 2 chip version since I had access to more state which helped during development (i.e. more outputs to monitor)

 

Thats great!

 

Also noticed on a clip from a youtuber that it should be built in bluetooth. Havent seen it been specified on the site tho...

 

Really looking forward to early next year. Figure there is ALOT to do from the Analogue team, the Nt mini was worked on up until christmas time last year I belive and they managed to ship it late january I belive?

[Wolf_]

 

Thats great!

 

Also noticed on a clip from a youtuber that it should be built in bluetooth. Havent seen it been specified on the site tho...

 

Really looking forward to early next year. Figure there is ALOT to do from the Analogue team, the Nt mini was worked on up until christmas time last year I belive and they managed to ship it late january I belive?

I'm betting what you saw was them using the Super Nt with the RetroReceiver 8bitdo makes so you can use bluetooth controllers with a snes. As they suggest buying one that confirms it won't have its own built in bluetooth.

[kevtris]

 

Thats great!

 

Also noticed on a clip from a youtuber that it should be built in bluetooth. Havent seen it been specified on the site tho...

 

Really looking forward to early next year. Figure there is ALOT to do from the Analogue team, the Nt mini was worked on up until christmas time last year I belive and they managed to ship it late january I belive?

Bluetooth is not built in. I saw that too but am not sure where that came from.

[PaulieORF]

I'm betting what you saw was them using the Super Nt with the RetroReceiver 8bitdo makes so you can use bluetooth controllers with a snes. As they suggest buying one that confirms it won't have its own built in bluetooth.

It was Rich at ReviewTechUSA. Not sure why, but he thought the Bluetooth was built in. Maybe he thought that because the price of the 8bitdo controller + retro receiver is only $40, when the controllers themselves usually sell for around that much. He should've read through the entire product page, as the retro receiver is clearly mentioned there.

[atmn]

Bluetooth is not built in. I saw that too but am not sure where that came from.

 

Ye, was surprised when I saw it, thanks for the confirmation regarding this.

[RadikusRLZ]

ANALOGUE NT MINI AND EVERDRIVE N8 FAMICOM PROBLEM

I have so many problems with my Analogue NT and now Analogue NT Mini, so I think this was my last product what Kevtris have done. Customer service does not know what cause this problem. And nobody knows what cause this problem.

So I think is better that I don't buy anymore products like this.

I got weird problem with my Analogue NT Mini with latest working Jail Break Firmware v1.7

When I use Everdrive N8 Famicom with latest software v16.

When I turn my tv or monitor off my game corrupted. This happens with the different HDMI cables. Everytime my game corrupted.

Is there somebody else have this same problem

 

[DadsGlasses]

ANALOGUE NT MINI AND EVERDRIVE N8 FAMICOM PROBLEM

 

I have so many problems with my Analogue NT and now Analogue NT Mini, so I think this was my last product what Kevtris have done. Customer service does not know what cause this problem. And nobody knows what cause this problem.

So I think is better that I don't buy anymore products like this.

 

 

 

I got weird problem with my Analogue NT Mini with latest working Jail Break Firmware v1.7

 

When I use Everdrive N8 Famicom with latest software v16.

 

When I turn my tv or monitor off my game corrupted. This happens with the different HDMI cables. Everytime my game corrupted.

 

Is there somebody else have this same problem

 

Does this happen if you use analog output cables? Or just hdmi?

[Toth]

ANALOGUE NT MINI AND EVERDRIVE N8 FAMICOM PROBLEM

I have so many problems with my Analogue NT and now Analogue NT Mini, so I think this was my last product what Kevtris have done. Customer service does not know what cause this problem. And nobody knows what cause this problem.

So I think is better that I don't buy anymore products like this.

I got weird problem with my Analogue NT Mini with latest working Jail Break Firmware v1.7

 

When I use Everdrive N8 Famicom with latest software v16.

 

When I turn my tv or monitor off my game corrupted. This happens with the different HDMI cables. Everytime my game corrupted.

 

Is there somebody else have this same problem

 

Have you tried a different power strip or a different power source or plugging the monitor into a different outlet? Like could there be something weird going on with the power like some sort of surge when you turn it off?

Edited October 25, 2017 by Toth