Jump to content
IGNORED

FPGA Based Videogame System


kevtris

Interest in an FPGA Videogame System  

682 members have voted

  1. 1. I would pay....

  2. 2. I Would Like Support for...

  3. 3. Games Should Run From...

    • SD Card / USB Memory Sticks
    • Original Cartridges
    • Hopes and Dreams
  4. 4. The Video Inteface Should be...


  • Please sign in to vote in this poll.

Recommended Posts

I hope they fixed that shimmering effect they talked about on mylifeingaming youtube channel.

Yep I fixed this (this is "interpolation" you can turn on and off)

 

I hope there will be a way to replace the menu font and the boot screen at least on the jb fw. (I like the approach with the built-in boot screen a lot actually, but I might want a super famicom logo screen or something too :))

And yes there's two fonts. the default and an alternate

  • Like 5
Link to comment
Share on other sites

 

I think when the Z3K is out it shouldn't really be marketed towards lay people. It should be marketed to collectors who already have a bunch of consoles as perfect replacement hardware for most if not all of their consoles. A collector should be able to look at a wall sized entertainment center full of consoles, A/V switch boxes, lots of wiring, etc. and think,"This little box can perfectly replace everything on that wall and if I wanted to I could sell everything on that wall to pay for it." For a device that would make me think that I would consider $500 cheap and think Kevtris was ripping himself off.

 

The NT Mini did this for me in a certain way. I sold a significantly amount of my NES and Atari libraries because of the Jailbreak firmware & the NT Mini Smokemonster Rom pack. With all of those cores and a huge amount of games available at my finger tips, I didn't know where to start. Then I sifted through the High Score Clubs here on Atariage. Its a great way to experience games you never played or to revisit others. Particularly, I am enjoying the Atari 2600 HSC. The new season starts at the beginning of January if anybody is interested. Highly recommended.

  • Like 1
Link to comment
Share on other sites

 

The NT Mini did this for me in a certain way. I sold a significantly amount of my NES and Atari libraries because of the Jailbreak firmware & the NT Mini Smokemonster Rom pack. With all of those cores and a huge amount of games available at my finger tips, I didn't know where to start. Then I sifted through the High Score Clubs here on Atariage. Its a great way to experience games you never played or to revisit others. Particularly, I am enjoying the Atari 2600 HSC. The new season starts at the beginning of January if anybody is interested. Highly recommended.

I agree. If I end up ever selling all of my non-modern gaming stuff, my CRTs, my BVM etc, I definitely know the one thing I'll keep around is my NT Mini (and future Super NT).

Link to comment
Share on other sites

I also hope the jailbrake can add save stats somehow for all the cores including the snes core.

This is very very unlikely to happen. An FPGA isn't a normal computer where there is an operating system that has full access to system memory and can just dump the program state of an emulator and reload it.

Link to comment
Share on other sites

Not gonna happen. Save states are possible in emulators because everything is done with a single CPU and it can halt (and record) it's internal state at any time.

In FPGAs there isn't a single CPU but multiple items running in parallel; that's a boon for some things (e.g. no lag at all) but it means it's inherently impossible to reliably save states generically.

 

It isn't a problem of capacity or speed, but rather a consequence of FPGA being close to real hardware. You can't save state a real console :)

Edited by Newsdee
Link to comment
Share on other sites

My n8 can save state that isn't a computer or a emulator. I dought it will happen just want to give him idea's.

From what I hear the N8 save state functionality is a bit of a hack, and I know from first hand experience that it doesn't work with all games. IIRC, Kevtris mentioned that he could have done it in the Nt Mini for NES games, but it would have required a significant rewrite because of how he did the mappers.

 

For SNES I think part of the problem is that the save state would need to include the internal state of the cartridge, which is only possible if the cart (with all special chips) is simulated as well.

Edited by cacophony
Link to comment
Share on other sites

I also hope the jailbrake can add save stats somehow for all the cores including the snes core.

 

Just putting the idea out there.

 

Can't happen. Would take too much resources.

 

This is very very unlikely to happen. An FPGA isn't a normal computer where there is an operating system that has full access to system memory and can just dump the program state of an emulator and reload it.

 

Not gonna happen. Save states are possible in emulators because everything is done with a single CPU and it can halt (and record) it's internal state at any time.

In FPGAs there isn't a single CPU but multiple items running in parallel; that's a boon for some things (e.g. no lag at all) but it means it's inherently impossible to reliably save states generically.

 

It isn't a problem of capacity or speed, but rather a consequence of FPGA being close to real hardware. You can't save state a real console :)

 

Oh, it can be done via FPGA. You'll need a halt command and at least two copies of the entire state machine built into the FPGA. With the exception of the display upscaler and a few other minor things, essentially you would need to duplicate the entire CPU, RAM, bus, and cart logic in the FPGA memory, at least doubling the space required for the game. So for instance you need a 25k LE FPGA to store console B, you'll need at least a 50k LE FPGA to add save states. Given that on the current market doubling the size of the FPGA more than doubles the cost of the chip, adding save states would be an expensive proposition.

 

PC emulators do this effortlessly because of the nearly unlimited memory resources provided by the PC. Most console emulators allow ten save states per ROM but you could easily store thousands of states if not tens or hundreds of thousands on a modern PC with 4Gb RAM or more. So halting and shifting the state machine in PC RAM is nearly effortless from a programming perspective. This would be a huge hurdle to cross in the FPGA world, like I said allowing one additional state to the one the console is currently running effectively doubles the complexity of the core and the space required to execute it.

 

And it will not easily work with cartridges that employ any type of bankswitching, or have virtually any volatile memory or special chips inside the cart in addition to the ROMs themselves.

 

Give it five or ten or twenty years and when FPGAs have almost unlimited space to dick around with much like the current state of affairs with PC emulators, save state machines (only when using ROMs instead of carts) may be feasible. But for the time being, it isn't going to happen, and will likely never work with direct cartridge bus interface. And no, dumper-crapulation consoles like Retron5, Rfreak, et al don't count. Yes, I made a compound word with both dump and crap, because that's normally what comes out when you dump. :lolblue:

Link to comment
Share on other sites

Oh, it can be done via FPGA. You'll need a halt command and at least two copies of the entire state machine built into the FPGA. With the exception of the display upscaler and a few other minor things, essentially you would need to duplicate the entire CPU, RAM, bus, and cart logic in the FPGA memory, at least doubling the space required for the game. So for instance you need a 25k LE FPGA to store console B, you'll need at least a 50k LE FPGA to add save states. Given that on the current market doubling the size of the FPGA more than doubles the cost of the chip, adding save states would be an expensive proposition.

 

 

I have a feeling this is not quite what the poster asked for. "Saving stats" (eg high scores) vs, "Saving states" which require saving the ram, registers, etc of everything. It might be a trivial thing to preserve the state of the RAM for games that don't use SRAM when the core is shut down, thus preserving the present state of the high score table, as if it were an arcade machine always powered on. However you'd have to know when to overwrite the RAM when it boots up again, otherwise you don't have the other chips state to synchronize. The SNES would be much harder since the entire sound hardware and external chips may have their own states to preserve.

 

But for older games (eg Atari, Coleco, NES, etc) there's no SRAM in most carts, so you can pretty much snapshot the system ram and then assuming the game doesn't initialize the memory, overwrite it once it gets to a "booted" state. This would of course not work for anything you want to actually preserve the game state (eg a paused screenshot.) Like it would make more sense to save the state of the battery backed RAM in those games, and then be able to bring up a menu that lets you preserve the state of the SRAM so you have unlimited save slots (eg most RPG games) instead of two or three. It could even be done blindly. eg the FPGA just journals every write to the SRAM, so every time you save the game, it saves the SRAM as a new file, and you could bring up a menu and delete the nth oldest ones, or just go back to the previous save by date-time.

 

But saving "state" of all chips is generally not doable, certainly not like a software emulator. I don't see why you'd need two copies of the FPGA to do it, you just need one copy, and a way to log changes to ram/registers, which is slow and bandwidth intensive. Two copies also doesn't permit RNG to work as intended, which is why I don't think that would be the right tree to bark up. I'll give you one example of save state-scumming that fails. When you record a game by logging the input and state of the ram only, if something is generated by RNG, the "state" stack gets smashed, and thus all input past that point is useless. Hence, saving the state in a hardware device gives you the option of freezing the state, and logging the registers, ram, and so forth, but it would still need a companion watchdog chip to do this (eg what runs the GUI), the FPGA couldn't do it itself, because it's in a halted state.

Link to comment
Share on other sites

Megadrive 6-button controllers use 8 buttons plus Dpad. The 8th button is the select button on the upper edge which can substitute for select on the SNES controller.

 

 

That mode select button doesn't do anything except switch it between 6 button and 3 button mode except when a 32X is used. Also only about 19 games supported 6-button mode. Hence my point still stands about trying to run SNES games with a MD controller. Assuming a SNES mode using MD controllers, still requires assuming that the 6-button controller is used, as SNES games typically use all the buttons. If people only have the three button controllers, then they can't play those games. Presumably you could make the FPGA use that select button as the select button for the SNES, but I think it would still be freaking awkward without being able to define the controller mapping at a per-game level.

 

I almost think there is room for 8bitdo to actually produce master-system/mega-drive/atari compatible 8/18 button controllers if that ever gets developed. For the SNES, the only purpose of an 18 button controller would be to play those other cores, not that I think it wouldn't be useful in other contexts, just those number pads are ridiculously bad design (IIRC the coleco actually had a plastic insert overlay for the buttons.) It's a bit ironic that the touch-screen on the WiiU, DS, and 3DS basically are an evolution of that use.

Link to comment
Share on other sites

You can read out the select button as an input on six button genesis controllers. The Super Retro Trio does exactly this as the SNES inspired controllers function as six button Genesis and are Genesis compatible. Select is mode on these things and holding select at power on or while plugging it in forces three button compatibility mode. So perhaps the SRT clone controllers would be an ideal controller for running the SNES core on the Mega NT.

 

Just saying that an alternate button config may be wise depending upon the game. For Super NT running a hypothetical Genesis core, you could use the fight mapping for six button games and the platform mapping for 3-button games (B, Y, A on Snes = A, B, C on Genesis; L, X, R, Select on the snes controller would do nothing if the game calls for 3-button mode). Mapping could be smart detected by analyzing how the game polls the controller.

Link to comment
Share on other sites

Not gonna happen. Save states are possible in emulators because everything is done with a single CPU and it can halt (and record) it's internal state at any time.

In FPGAs there isn't a single CPU but multiple items running in parallel; that's a boon for some things (e.g. no lag at all) but it means it's inherently impossible to reliably save states generically.

 

It isn't a problem of capacity or speed, but rather a consequence of FPGA being close to real hardware. You can't save state a real console :)

 

It's really a matter of seeing what each logic element is set at. That, plus the memory snapshot. This is enough work for an entirely separate outside core so to speak. OR even a special supervisory cpu. So you'd need a way to probe the state of each simulated gate. That in and of itself would require almost double LE. Each LE would need another LE (or more) to shadow and capture the state its in. At the very least, each core would need to be re-written with special I/O for each targeted gate. And there's a lot.

 

Think something like a top-down photograph, or a satellite photograph. You have to see the whole thing, at the same time. If you don't have a satellite or a camera. Well, you're not out of luck. You can have each item of interest (LE) report its current state to you. And you synthesize the photo based on what you're told. What's reported to you. Like setting up a chess game.

 

With software emulation, you have easy and instant access to all the memory, stacks, registers, and more, of both the simulated CPU and the real CPU. Since we're interested in the simulated CPU, we can simply save the variables which represent the "stuff" of the real-life vintage CPU.

 

That's how I see it. Maybe the boss can comment further.

Edited by Keatah
  • Like 1
Link to comment
Share on other sites

 

Tusecsy's self worth is too huge to be contained just to Atari Age. I was on the epforums recently checking on Everdrive pack updates and you'd never guess who was there pissing in Smokemonster's cornflakes regarding his recent "career" change.

 

Because I'm the only person who uses multiple forums, lol. I said smokemonster getting rid of his packs basically means the project is dead, which is true...

 

Time to buy the SD system 3 extension since Kevtris just confirmed the Super NT can't handle it.

 

And to those who continue to think "NT" doesn't mean Nintendo, roflcopter.

Edited by Tusecsy
Link to comment
Share on other sites

He doesn't think they're not going to pay Kevtris, I think he's a fulltime employee now. He thinks Analogue will pay Kevtris for months to write a Genesis core, which will probably be completed months after the release of the Super NT and all of the initial excitement about it. After the people most excited about it have already bought it. He thinks that after all these months of work, they will just plop the core out for free, and not create another product tailored for a different market segment, because this will increase sales of the Super NT more than a Mega NT would sell. He thinks a company who has stated that their mission is to preserve video game history and give it the respect it deserves will just handle one of the most successful and popular consoles of all time by just plopping out a core for it on a system designed around its rival platform, which will not work with original controllers or consoles, nor will it work with the 2 add-on consoles, the Sega CD and 32X.

 

ya cuz the NT mini didn't do that...

Link to comment
Share on other sites

 

Instead of being grateful for the hard work he had done over the last few years, you told the man his future plans were pointless unless roms were actually included, and nobody would care.

 

Stay classy. icon_thumbsup.gif

Yea, the man and his team put hundreds of hours into giving us the best possible gaming experience where everything we want is easily available at the tips of our fingers and the only way the packs could be more sorted would be to come with a built in god damn google search and the guy that did all this doesn't want to have his life ruined for it so he leaves it up to some fans to host anonymously while he gives them all the tools they need to do so and this shit stain comes in having contributed absolutely nothing of value to the community and tries to shame him into feeling bad. That is the kinda person that gets punched in the throat a lot irl.

Edited by Wolf_
  • Like 3
Link to comment
Share on other sites

 

Because I'm the only person who uses multiple forums, lol. I said smokemonster getting rid of his packs basically means the project is dead, which is true...

 

Time to buy the SD system 3 extension since Kevtris just confirmed the Super NT can't handle it.

 

And to those who continue to think "NT" doesn't mean Nintendo, roflcopter.

Boy, you just keep doubling down on your bullshit, huh? Kevtris never said the Super NT "can't handle" a PC-Engine CD core. He just personally shut down your presumptuous wishful thinking that he has magical powers and unlimited time and resources by telling you he hasn't even started working on PCE or Genesis cores.

 

Edit: As 2shitty has rightly pointed out, I misread one of Kevtris' posts, where he did in fact say the PC-Engine CD could not be handled by the Super NT FPGA. But the good news is, 2shitty has provided me secret inside information about the GUARANTEED Gamecube core that will be available on the jailbreak Super NT firmware. This jailbreak firmware will come out BEFORE the Super NT is released.

 

ya cuz the NT mini didn't do that...

Ok I think you're now officially trolling. Kevtris literally posted addressing this, confirming that the flood of "free" jailbreak cores only happened because he spent years writing the cores before he was involved with Analogue in any capacity. Analogue did not pay him to write those cores. He said it would take the better part of 6 months to write a Genesis core. The two situations are not similar at all.

 

Oh, and as for the Smokemonster stuff, yeah maybe the project is dead to people who are too lazy to use google to find roms and learn how to run a Python script. It's totally understandable why someone wouldn't want to risk legal trouble by hosting shitloads of copyrighted material, especially when mean-spirited, entitled shitheads complain about all the free community work you do. Do you think the No-Intro and Redump projects are pointless because all they host is DAT files and hashes? These projects, and the people dedicated to dumping and verifying are keeping history alive, while staying safe by keeping the trading of roms to back channels.

 

I've never seen you say anything that didn't project an air of self-importance totally disproportionate to anything you've contributed to this thread, or anything at all, as far as I'm aware. Your name is Tushitsy now as far as I'm concerned, cuz you're full of shit.

Edited by cfillak
  • Like 3
Link to comment
Share on other sites

Oh, I almost forgot about the part where Tusecsy said the pack organization was too messy for his standards. :lol:

Yeah, and conveniently since the DATs are on github, Tushitsy can make his own fork of the smokemonster packs and show us his beautiful beautiful directory structures and filenames. I'm sure he'll do this and give something back to the community.

  • Like 1
Link to comment
Share on other sites

I doubt it. CD systems need a lot more resources (RAM especially) so probably not. If I were to do a genesis core for anything, it would not have 32x or the CD unit either. Both of those things are very complex and loaded with chips and things. The lack of RAM bandwidth is going to be the main problem with implementing stuff on the FPGA for the near and far future I think. That and how much time I have to write code. (hint: it takes a long time to write the code)

 

 

Boy, you just keep doubling down on your bullshit, huh? Kevtris never said the Super NT "can't handle" a PC-Engine CD core.

 

Lol...can you even read?

 

I never said Kevtris had started on or had finished Gen/TG16 cores as a matter of fact. Just that they would be available for the Super NT a few months after it's release. I say as a matter of fact the NT mini cores and a fully functioning SNES core (relevant chips anyway) will be available within the first couple of weeks, which they will.

 

But your hallucinations are noted.

Edited by Tusecsy
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...