FPGA Based Videogame System

[kevtris]

 

In context:

 

You took that sentence too literally. I meant never originally on TV. My point was that if it is playing Game Boy, Game Gear, Atari Lynx, etc. then I don't want a simulated border on the screen that looks like one of those systems with a tiny screen in the middle or a tiny screen in the middle of a black void. I have some reasons for this preference:

 

They are only like that because I lacked the RAM to do proper scaling. I fully intend to have a "stretch to screen" option. I was more concerned getting the hardware to function and debug it :-)

[Keatah]

Idk all the details of your system, it's over my head as I just ordered a dev board to Begin learning this stuff.

 

But I would try to make everything as smooth as possible, all aspects. Especially monitor drop outs, and SD/USB handling. If that means a month extra work and $50 more in parts, do it. I vote 2.

 

One other thing, is there going to be a standard CPU somewhere on this board? Or is everything done in FPGA?

[Schizophretard]

They are only like that because I lacked the RAM to do proper scaling. I fully intend to have a "stretch to screen" option. I was more concerned getting the hardware to function and debug it :-)

That's excellent and I'm glad you cleared that up because without proper scaling I may be tempted to buy an empty Jaguar case instead of the Z3K.

[kevtris]

Idk all the details of your system, it's over my head as I just ordered a dev board to Begin learning this stuff.

 

But I would try to make everything as smooth as possible, all aspects. Especially monitor drop outs, and SD/USB handling. If that means a month extra work and $50 more in parts, do it. I vote 2.

 

One other thing, is there going to be a standard CPU somewhere on this board? Or is everything done in FPGA?

 

There's probably going to be a PIC32 but it will just run "BIOS" type code that does the menus, some SD card work, file system and USB. Any other CPU will be synthesized inside the FPGA. On the HDMI NES adapter there's a synthesized 65C02 core that is doing all the menu/system upkeep stuff and my other cores probably won't be an exception to this, and most will have "helper" CPUs (probably the 65C02 since it's fun to program).

[tcdev]

First of all, this pretty much describes my dream piece of kit. My only disappointment is that I didn't get to design it myself. Though if you do release this and it is actually called Zimba 3000, I'm not buying one!

 

Something I'd very much like to see on here is the option for a JAMMA interface. Given that the audio/video will be broken out onto a separate video PCB, I'm thinking that extending that to JAMMA would perhaps not impact the main design much at all? Even if you needed a cheap micro on the JAMMA board reading the inputs and spitting them at the FPGA in a SPI stream so you're only using a few extra pins on the FPGA/connector? I guess another option with little-to-no impact on the design would be a cheap USB device chip on the JAMMA board that plugged into one of the main USB ports on the mainboard?

[kevtris]

First of all, this pretty much describes my dream piece of kit. My only disappointment is that I didn't get to design it myself. Though if you do release this and it is actually called Zimba 3000, I'm not buying one!

 

Something I'd very much like to see on here is the option for a JAMMA interface. Given that the audio/video will be broken out onto a separate video PCB, I'm thinking that extending that to JAMMA would perhaps not impact the main design much at all? Even if you needed a cheap micro on the JAMMA board reading the inputs and spitting them at the FPGA in a SPI stream so you're only using a few extra pins on the FPGA/connector? I guess another option with little-to-no impact on the design would be a cheap USB device chip on the JAMMA board that plugged into one of the main USB ports on the mainboard?

 

Yeah I had thought about jamma. You could just plug in a board that outputs RGB and then adapt that. I don't see a problem with it. Use USB for the buttons and stuff and then use 15KHz RGB and it should work.

[sunteam]

 

 

hah niiiice. I like that artwork a ton :-)

 

The picture was pinched off Asteroids. The logo I made to look stupidly 80s.

[Pixelboy]

This all sounds great.

 

By the way, what are the physical dimensions of your current prototype board, and do you expect the next prototype to be smaller? Just curious.

[Lost Monkey]

...HDMI monitors might blip out for awhile during the clock drop as well. I don't know how big of a problem that will be on today's monitors.

 

My PS3 does that...

[TheRedEye]

Is there enough horsepower under the hood to theoretically run something equivalent to an emulator front-end off of the SD? Maybe even in 1080p?

[+Tarzilla]

 

Yeah I had thought about jamma. You could just plug in a board that outputs RGB and then adapt that. I don't see a problem with it. Use USB for the buttons and stuff and then use 15KHz RGB and it should work.

Having gone thru the experience of setting up an Original Xbox to Jamma with this kind of solution (which works great):

http://www.ultimarc.com/xba.html

 

I think a lot of people would like something more plug and play with Jamma. I'd like some kind of dummy-proof Jamma adapter, but can do without it. I'm personally more concerned about connecting Intellivision and ColecoVision controllers (regular/Super Action/Driving) directly.

[kevtris]

Is there enough horsepower under the hood to theoretically run something equivalent to an emulator front-end off of the SD? Maybe even in 1080p?

Yes, I am going to have a front end on it... I am not sure how fancy it'd be though since I'm a total non-artist. Doing all sorts of effects and things is no problem. Getting the graphics for it, however might be a bit out of my reach :-)

[some_canuck]

if it looks anything like the menu screen on the neshdmi, i'd say it's adequate.

[Keatah]

Yes, I am going to have a front end on it... I am not sure how fancy it'd be though since I'm a total non-artist. Doing all sorts of effects and things is no problem. Getting the graphics for it, however might be a bit out of my reach :-)

 

Ask for volunteers to make the graphics.

 

ADDED:

However, in spirit of keeping things simple and non-bloated. A texty-looking interface with simple outlines and boxes is good enough. And I'd rather see time and effort going into the functionality and richness of the UI as opposed to spiffing things up.

Edited October 1, 2015 by Keatah

[dylbob42]

so when you set up a store to sell this, are you going to call it the Core Store?

[Andromeda Stardust]

Yes, I am going to have a front end on it... I am not sure how fancy it'd be though since I'm a total non-artist. Doing all sorts of effects and things is no problem. Getting the graphics for it, however might be a bit out of my reach :-)

 

 

 

Ask for volunteers to make the graphics.

 

ADDED:

However, in spirit of keeping things simple and non-bloated. A texty-looking interface with simple outlines and boxes is good enough. And I'd rather see time and effort going into the functionality and richness of the UI as opposed to spiffing things up.

All of the good flash carts don't have any fancy graphics. A simple logo on the boot screen made up of a few tiles will do. Use the bog standard NES font or similar console for text data.

 

The china made ones with the fancy menus generally suck bad. There was a GBA flash cart and I was interested at first but couldn't get past the cheezy rips they did from Star Wars and Super Mario artwork that looked like it was scanned strait from game manuals. Blech!

[+Random Terrain]

Can't wait to buy a Core 3000.

[kevtris]

yah, I usually like to keep things neat and simple, but I do like add some flair (just not 37 pieces of it). I don't want to make the menus look all "next gen" but I don't want it to be some simple text thing either. There will have to be chiptunes playing and some kind of copper bars and things going on at the least. Probably some lissajous patterned sprites and things as well.

 

First pass will be very simple and text based without anything like that, just to get it working and debugged. All the more "fun" frills come last after basic functionality is implemented. I am definitely going to be focusing on getting everything working first before spending time on the chrome.

 

Might be possible to have more than 1 motif, but I won't attempt to add multiple skins or anything until the base functionality is done. The good news is since most of the resources will be sitting there on the SD card, updating it will be a breeze- just dump the new files onto the card and you're done.

 

I am still working out how best to do the functionality on swapping cores and things, but it looks like I will end up needing a smaller helper part like a MAX 10 to keep the lights on during reconfiguration as well as handling the scaling duty and SD card things for maximum loading speed. I don't want the HDMI to blip out when it reloads.

[Asbrandt]

That and handling the USB stuff will be the two biggest bug-a-boos.

I might be the only one interested, but I hope that as you work on the USB side, you let us know what the latency looks like from start-of-usb-poll to replicated-system-can-use-input-data, perhaps at best (one controller?) and worst (keyboard, mouse and 2 controllers?) cases for the sake of information.

I'd imagine most of this would be fixed based on supported data transfer rates over usb and between the input controller and main FPGA, but some would improve as your keymapping code matures.

 

In a IRC discussion on USB input, it was suggested to use more controlled polling at specified points during a frame instead of polling at max speed to help keep control of the polling latency variable.

But this ultimately doesn't reduce it at all, just makes it more predictable, to some degree, as firmware optimization of the input device itself can have an effect, too.

EDIT: However, consistency of input latency is still an improvement for most users, and the same input device should always present the same latency.

Hopefully, homebrew optimized USB-HID uC's/Firmwares rise in response to the Z3K's existence.

 

Looks like the cost of my target FPGA dropped a little so that's gonna help.

If I may ask, just how big and expensive of an FPGA is being put toward this project?

Edited October 1, 2015 by Asbrandt

[kevtris]

I might be the only one interested, but I hope that as you work on the USB side, you let us know what the latency looks like from start-of-usb-poll to replicated-system-can-use-input-data, perhaps at best (one controller?) and worst (keyboard, mouse and 2 controllers?) cases for the sake of information.

I'd imagine most of this would be fixed based on supported data transfer rates over usb and between the input controller and main FPGA, but some would improve as your keymapping code matures.

 

In a IRC discussion on USB input, it was suggested to use more controlled polling at specified points during a frame instead of polling at max speed to help keep control of the polling latency variable.

But this ultimately doesn't reduce it at all, just makes it more predictable, to some degree, as firmware optimization of the input device itself can have an effect, too.

EDIT: However, consistency of input latency is still an improvement for most users, and the same input device should always present the same latency.

Hopefully, homebrew optimized USB-HID uC's/Firmwares rise in response to the Z3K's existence.

 

 

If I may ask, just how big and expensive of an FPGA is being put toward this project?

 

It's a cyclone V 49K part, specifically the 5CEBA4F17C8N.

 

http://www.digikey.com/product-detail/en/5CEBA4F17C8N/544-3001-ND/3879661

 

It's about 50 bucks all on its own.

 

Re: USB latency.... I still don't know much about it yet and probably won't until I get it working. Though aligning the polling with the screen refresh (or a multiple thereof) is an idea I didn't think of and I might give a go when I get that far. Remapping the keys will incur no time penalty except maybe a few hundred nanoseconds to a couple microseconds so that shouldn't be an issue.

[Asbrandt]

It's about 50 bucks all on its own.

Huh, I didn't expect to guess that right.

 

Remapping the keys will incur no time penalty except maybe a few hundred nanoseconds to a couple microseconds so that shouldn't be an issue.

This surprises me since I'm accustomed to huge amounts of software overhead with USB and has me hopeful for the final numbers, if data transfer and encode/decode is similarly quick.

EDIT: By software I mean the OS, so really the wrong word to use in that case, I should have used API.

I guess I just have to wait and see, and should probably stop trying to engineer vicariously, haha.

Edited October 1, 2015 by Asbrandt

[kevtris]

Huh, I didn't expect to guess that right.

 

 

This surprises me since I'm accustomed to huge amounts of software overhead with USB and has me hopeful for the final numbers, if data transfer and encode/decode is similarly quick.

EDIT: By software I mean the OS, so really the wrong word to use in that case, I should have used API.

I guess I just have to wait and see, and should probably stop trying to engineer vicariously, haha.

 

eh it's fine :-)

 

I was probably going to let the FPGA do most of the remapping work. I'll just send over a "cooked" packet and let it figure it out. There's probably going to be some kind of standard interface for all the cores though, to make life easier and so I don't have to reinvent the wheel each time a new core is made. Ideally I want it easy enough so other people can make cores for it.

 

More ramblings on how it will probably work...

 

File handling will work similar to what I already have done on my last chiptune player. The file extension determines what core is loaded, basically. I have a text file list that sits on the card, which maps file extension to core filename. This way, multiple extensions can map to a single core if need be. It also contains an int that is sent to the core so if say Coleco and SMS share a core (which they do) the core can properly set itself up for the proper system.

 

This might not be good enough in the end but this will be a good "first pass". For some systems like Atari 2600, I was thinking of using subdirs to select mapper number, and then the menu system will collapse them into a single list, so you can do something like this...

 

/2600/F8/file1.bin

/2600/F8/file2.bin

/2600/F6/file3.bin

 

Then the menu collapses it down into this:

 

Contents of /2600/

file1.bin

file2.bin

file3.bin

 

 

If subdirs by letter is desired, it'd still work OK.

 

/2600/A-D/F8/file1.bin

/2600/A-D/F8/file2.bin

 

etc.

 

There's not much of an other way except using a CRC style database which I really really really do not want. CRC databases are kind of a copout and it makes it a pain in the ass to add new ROMs. It miiight be possible to do heuristics but I don't really like the sound of that one either.

 

Fortunately, most things have headers on them so it's not a problem.

[Andromeda Stardust]

Harmony loads 2600 ROMs without a CRC check. Maybe you could use a similar algorithm.

[leods]

It's all fine and Dandy, you seem to have half your Project done with boards and Software, but what colours are you making the Kickstarter Shells? I can't Support you if your Project has no transparency. I want a transparent ruby Shell please. Thanks for your Attention.

[tcdev]

It's been quite a few years since I worked on USB, but IIRC HID operates via Interrupt transfers and unless you can strong-arm the USB host controller the polling is scheduled by the controller at the frequency requested in the endpoint descriptor in the HID device. For low/full speed devices that's minimum 1ms, for high speed it's 125us. I don't know what typical HID devices set as their polling frequency, but the spec allows it to be up to 255 times longer. So as far as I know, you can't synchronise a host interrupt transfer poll to an external event, nor mandate a particular polling frequency, without having some control over the host stack (and possibly breaking the standard in the process).