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

On the topic of input lag, I have a question for Kevtris about USB HID input, as I only have a basic understanding of it.

 

Between the poll rate, usb data being serial and I assume encoding/decoding processes, how wide of a window (at worst case) should we expect between input and that input being available to the system core to read?

I've been told with Windows' DInput API this is somewhere between 4 and 5ms, while this value is managable and I would imagine the Z3K would have less overhead, it's still good to know, as it determines the possibility of "missing the input window" for precise inputs.

 

---

 

As a seperate but related curiousity, would a generic port that uses passive adapters for real controllers without any kind of protocol conversion (each core having the recreated system's input stage) be a reasonable feature, or would that be getting too complex when having to deal with both that and USB? I'd imagine there would also be the issues of either sourcing connectors or making people make thier own adapters.

I do not understand why anything below a single frame is important unless combos in fighter games need to be activate within 1 or 2 frames (17-33 msec) and they have like 10 pieces to them.

With 5 msec you have time for 200 sequential presses per second, which is 3 per frame (at 60 frames), is it not enough?

The Hadouken in SF2 is 3 directions (low, low&forward,forward) followed by one button -> 4 total sequential presses. At 5 msec each sequentially it would take 1 frame + 2 msec .... would that be too slow?

 

Outside combo sensitive games, anything else seems to be content with 1 detection per frame (even if it is multiple buttons).

On a USB2 at 480Mbits, even if we halve it a 240Mbit -> ~24MByte per sec so throughput cannot be an issue, so however many buttons you press it's fine, and if it takes 1 whole frame to detect a totally different set of buttons you should also be fine because none of the effects can be in the very same frame you're looking at [again this excludes combo driven games that may require more than 3 distinct detection per sec].

 

Am I missing something here?

Edited by phoenixdownita
Link to comment
Share on other sites

I do not understand why anything below a single frame is important ...

The question is primarily for my own educational purposes, rather than real world concern, since I'm not a high level player of anything.

 

The mention of "missing the input window" is thinking about a (theoretical) high level player's point of view, to whom needing to readjust to make inputs a third of a frame sooner than they're used to may be a big deal.

 

That said, 5ms adds up if you're using the HDMI output board, although we don't know how many lines the Z3K's HDMI stage needs to buffer yet.

Edited by Asbrandt
Link to comment
Share on other sites

 

So out of curiosity and excluding the outer casing, if say you had to work with a BOM+profit of 250US$ (factor in whatever profit you see fit, if 20% for example it means you only really have 200US$ to spend on parts), what system do you think you can pull off?

I mean, how many FPGAs? 1 or 2 and how big? LE count, type.

How much memory do you think you can slide in, how many connectors [uSBs or otherwise]?

Finally what kind of system do you think it can support? I understand pretty much all 8bits you have already nailed them, but which 16 bits do you think it is reasonable/believable with that BOM?

 

I believe it is more important to get a more powerful FPGA as long as it is not a waste, no need to put a Ferrari engine on a Kia Rio, rather than 20 AVs etc.. etc..

 

Anything specific you have in mind?

 

Well I'm hoping to hit the 16 bit pipe pretty hard. I designed the last hardware specifically to step up to the 16 bit challenge.

 

The list of things I really want to add would be (in order):

 

* SNES

* genesis

* Neogeo (this might even supersede genesis)

* TG-16

* Super Acan

 

The other things I wanted to add would be (not really in order):

 

* Vectrex

* 5200

* Atari 8-bit (same as 5200 and would be the same project)

* C64 (probably would be one of the first computers I added)

* some arcade stuff, like Robotron- this would be my 6809 proving grounds before I attempted vectrex, so I only have to wrangle one thing at a time vs. vectors AND CPU.

* Astrocade (not sure why I haven't added this yet. It's Z80 based and fairly simple so I could probably knock it out fairly quick)

 

The FPGA doing all the heavy lifting will be a Cyclone V 49K LE part. There might/will be a second cheaper and smaller one no bigger than 25K LE's. Cyclone V maybe, or lesser like a IV depending on cost. This secondary part would do all the housekeeping and general care and feeding. There's also a PIC32 to do USB (ewwwww) and other things if I do 'em like ethernet, though I honestly doubt the ethertubes will make it to the final cut.

 

I was expecting to have two card edge connectors on there, one for the video output board and then another for cartridge adapters. Unlike the Retrode/Retron 5 method of dumping and playing, I really want to execute the actual cartridge code on the cartridge in real time. This is very easy to do, the cores I have right now are basically TWO things: the system and then the "cartridge emulator' portion. So theoretically I just have to break it apart and connect up the cartridge to the FPGA and let it supply the data and the FPGA simply runs that. Also, by running the code off the real cart, I can support powerpak/everdrives (not sure why you'd want to though with SD card support built in), and that ARM based mapper 2600 cart doodad (sorry can't remember the name of it). A cartridge dumper method unfortunately can't support any of those. Also if the cartridge's CRC is not in some kind of database (ewww) then it most likely cannot be dumped at all. That's the problem with the retron. Oh sorry, you can't play that homebrew NES game. or that translation. or that powerpak.

  • Like 6
Link to comment
Share on other sites

On the topic of input lag, I have a question for Kevtris about USB HID input, as I only have a basic understanding of it.

 

Between the poll rate, usb data being serial and I assume encoding/decoding processes, how wide of a window (at worst case) should we expect between input and that input being available to the system core to read?

I've been told with Windows' DInput API this is somewhere between 4 and 5ms, while this value is managable and I would imagine the Z3K would have less overhead, it's still good to know, as it determines the possibility of "missing the input window" for precise inputs.

 

---

 

As a seperate but related curiousity, would a generic port that uses passive adapters for real controllers without any kind of protocol conversion (each core having the recreated system's input stage) be a reasonable feature, or would that be getting too complex when having to deal with both that and USB? I'd imagine there would also be the issues of either sourcing connectors or making people make thier own adapters.

 

I am not really 100% sure myself, to be honest :-) Though if I can do a similar polling rate (4-5ms) it would be more than adequate. Since my output has mere scanlines of lag (I think I calculated 6-8 maximum for an NTSC NES to HDMI) a few milliseconds on the controller isn't going to matter. It's already better than i.e. a framemeister can do which has a mandatory 1-2 frames of lag, apparently.

 

On the topic of lag, the lag is different depending on what part of the screen is being rendered. Basically what I am doing is locking the i.e. NES frame rate to the HDMI frame rate, so at the top of the screen there's zero lag, and at the bottom of the screen there's maximum lag. i.e. at the top there's 0 scanlines of delay, and at the bottom it's 6-8. This is because the NES outputs data slightly faster than the HDMI can consume it. This is non-cumulative, though. At the start of the next frame it's back to 0 scanlines again, and so on. PAL is slightly worse- 50fps HDMI emits pixels much slower than the PAL NES PPU can generate them, so again it has 0 scanlines of lag at the top of the screen, and 32 at the bottom. That's why my adapter has small black bars on the top and bottom. I didn't have any more memory to make it totally fill the screen.

 

Someone asked how I was going to handle this for Atari 2600 games. I haven't fully worked it out yet but I have several ideas. HDMI relies on exact frame timing, and some 2600 games can... let's say stretch this somewhat. If the frame rate is constant, I can match it up fairly easily, but if the frame rate changes during rendering, it will require a frame buffer. What I will most likely do is have an "intelligent" mode where it uses the frame buffer but aligns the 2600 frame to the HDMI frame as closely as possible. The down side of this vs. a "dumb" frame buffer is if the game stops rendering video or does anything else that changes timing, it will cause the picture to "roll" as the HDMI and 2600 re-synch. This would look kinda crappy so that's why I was thinking of making it optional. Standard frame buffer is probably the best I can do if you want a "general purpose" 2600 mode. Unfortunately HDMI is very very very very unforgiving of ANY kind of variance in the frame rate, unlike analog TVs were.

 

Fortunately most of the other systems have a fixed frame rate that never varies, making it fairly easy to synch it up with the HDMI output.

 

When I get into the 16 bit stuff though things will be slightly messy. The SNES and genesis games were MOSTLY 240p, but some of them (at least on genesis) used interlaced mode, i.e. the 2 player at once sonic game. I will definitely need a frame buffer for this, there's no getting around it. But what I might do is just assume it's going to be 240p and do the zero lag method, unless detected otherwise. In that case I can switch to the full frame buffer mode. I am not sure how many games use interlaced on the two systems but it can't be very many.

 

I have worked out timing for the existing cores and how I'd HDMI-ize them, and it looks to be pretty trouble free except for 2600 as described above.

  • Like 1
Link to comment
Share on other sites

I am not really 100% sure myself, to be honest :-) ...

Yeah by my understanding it's not so much the poll rate, which on a HID device capable of the maximum 1000hz poll rate is ofcourse only 1ms, unless the Z3K itself can't do that high.

 

The other 3-4 come from the data encoding/decoding processes and any other stuff the OS does with it, this is the part I'm mainly curious about. Obviously there's no OS here to throw in overhead, so it's mostly the encode/decode stuff and whatever handles button mapping.

 

... The SNES and genesis games were MOSTLY 240p, but some of them (at least on genesis) used interlaced mode, i.e. the 2 player at once sonic game...

Is it not possible (with the way you handle HDMI) to buffer a field instead of a whole frame, pulling in the previous field's lines (or black lines if there isn't one) as necessary to construct the full frame, or do you not want to use the "naive" deinterlacing method? (I think it's called that anyway.)

 

I've been curious about a possible improvement to the very noticable appearance (on modern digital panels) of that method, but I've not had the ability to test it; darken the "old field" lines vs the "new field" ones to mimic phosphor decay to some degree.

Edited by Asbrandt
Link to comment
Share on other sites

 

I am not really 100% sure myself, to be honest :-) Though if I can do a similar polling rate (4-5ms) it would be more than adequate. Since my output has mere scanlines of lag (I think I calculated 6-8 maximum for an NTSC NES to HDMI) a few milliseconds on the controller isn't going to matter. It's already better than i.e. a framemeister can do which has a mandatory 1-2 frames of lag, apparently.

 

On the topic of lag, the lag is different depending on what part of the screen is being rendered. Basically what I am doing is locking the i.e. NES frame rate to the HDMI frame rate, so at the top of the screen there's zero lag, and at the bottom of the screen there's maximum lag. i.e. at the top there's 0 scanlines of delay, and at the bottom it's 6-8. This is because the NES outputs data slightly faster than the HDMI can consume it. This is non-cumulative, though. At the start of the next frame it's back to 0 scanlines again, and so on. PAL is slightly worse- 50fps HDMI emits pixels much slower than the PAL NES PPU can generate them, so again it has 0 scanlines of lag at the top of the screen, and 32 at the bottom. That's why my adapter has small black bars on the top and bottom. I didn't have any more memory to make it totally fill the screen.

 

Someone asked how I was going to handle this for Atari 2600 games. I haven't fully worked it out yet but I have several ideas. HDMI relies on exact frame timing, and some 2600 games can... let's say stretch this somewhat. If the frame rate is constant, I can match it up fairly easily, but if the frame rate changes during rendering, it will require a frame buffer. What I will most likely do is have an "intelligent" mode where it uses the frame buffer but aligns the 2600 frame to the HDMI frame as closely as possible. The down side of this vs. a "dumb" frame buffer is if the game stops rendering video or does anything else that changes timing, it will cause the picture to "roll" as the HDMI and 2600 re-synch. This would look kinda crappy so that's why I was thinking of making it optional. Standard frame buffer is probably the best I can do if you want a "general purpose" 2600 mode. Unfortunately HDMI is very very very very unforgiving of ANY kind of variance in the frame rate, unlike analog TVs were.

 

Fortunately most of the other systems have a fixed frame rate that never varies, making it fairly easy to synch it up with the HDMI output.

 

When I get into the 16 bit stuff though things will be slightly messy. The SNES and genesis games were MOSTLY 240p, but some of them (at least on genesis) used interlaced mode, i.e. the 2 player at once sonic game. I will definitely need a frame buffer for this, there's no getting around it. But what I might do is just assume it's going to be 240p and do the zero lag method, unless detected otherwise. In that case I can switch to the full frame buffer mode. I am not sure how many games use interlaced on the two systems but it can't be very many.

 

I have worked out timing for the existing cores and how I'd HDMI-ize them, and it looks to be pretty trouble free except for 2600 as described above.

If you go the framebuffer route and the buffer is sync at the proper HDMI (60p) then you'll have some tearing here and there as no console is exactly 60.

I have a Framemeister and I need to put it in sync off mode [ties HDMI at 60p] or my TV cannot compensate for small variation on the framerate, some consoles with my TV can be set to sync auto [in which Framemeister matches the HDMI freq to the console freq, so 59.8 or 60.1 etc..] but in general it's not so smooth sailing [my TV loses sync and I see nothing at all].

 

You could use a triple buffer: one for HDMI display, one for console display and one to sync the 2.

1 buffer for the HDMI out, 1 buffer for the core out, and 1 buffer in between to switch whichever is ready. If the HDMI is done but there's no new frame then it can serve the old again, when the core is done it always swaps between its finished buffer and whichever the HDMI is not rendering at that point and marks it ready (so next frame HDMI picks it up and marks whatever it used so far as available).

This avoids all tearing but causes stuttering (repeated frame if the core is behind) or missed frame (if the HDMI is behind and the core swaps a buffer that never got displayed by the HDMI).

I am not sure there's a better way to do it with only 2 buffers because you can't really stall the core until the HDMI is done with displaying its buffer.

 

In fact I am not entirely sure how you could do it with no buffer at all. If the console is 60p but I ask for a 50p you must have a buffer of sorts, but then again that is true even if the console is 59.1 unless HDMI itself allows such tolerance. NeoGeo MVS and some arcades hit those levels, in fact the AES has a slightly different freq to MVS to be closer to NTSC [still not perfect] and NeoGeoCD really solved it once and for all, which also means those games runs slightly faster on AES (and CD if you ignore the load time that is and the fact that many have less animation frames lol)

MVS is 59.2 vs AES is 59.9 -> 0.8 out of ~60 -> 1.3% which is 13msec faster each sec by the way or almost a full frame

Edited by phoenixdownita
Link to comment
Share on other sites

With the HiDefNES he adjusts the system's clock to make it exactly 60hz.

I think HDMI has a 50hz mode after some googling, no indication of what support for that is like in 60hz areas though.

Sure you can change the cores clock to match the generated video to the HDMI spec, but that would make the games playing slightly differently (and sound too) ... you really can't have it all.

As I showed above AES to MVS adds almost 1 full frame per sec [for sure 1 each 2 secs]. I am pretty sure for most players it would not matter much but it is noticeable on a side by side comparison [the SD2SNES lesson when implementing the CX4 was that a slightly different frequency made the game different enough that most noticed it]

 

Regarding 50p support my Vizio LCD TV can take 1080p50 but NOT 720p50 .... the p50 are a MUST for games that were PAL optimized or they would be unplayable or broken : Xenon 2 on Genny is too hard at 60hz, much better at 50Hz, Xenon 2 [i know, got a thing for Bomb The Bass] on SMS is buggy at 60Hz (I suspect because the VDP cannot keep the pace at all) with garbled gfx that kills you.

 

So tweaking the speed of the cores to match the HDMI frequency (or half of it and whatnot) is only a partial solution, but it does not require buffering (or much of it ... maybe few lines as Kev suggested).

 

EDIT: I personally would not have tried to change the cores clock but would have gone the way of the buffer supporting either HDMI lock (60p) or console lock (whatever freq that may be) and be a choice for the user (like the Freimemesiter has done), but optionally a way to change the core freq to better align it with HDMI freq would have been a nice addition (another slider on a settings page)

Edited by phoenixdownita
Link to comment
Share on other sites

I know there's a lot of talk about SID/c64 here, and it's surely a great system that I'd like to get to know better. Back when the c64 dtv sticks were all the rage I want to say I remember talk about it not sounding quite right all the time, because of some analog bits between the SID and the output that weren't on the chip to replicate. I don't know c64 hardware very well at all, but maybe somebody who does could chime in on how correct that statement sounds.

 

Given the systems we're talking now--I can certainly imagine that I'd spend well over what I answered in the survey. This project sounds like something that would likely become priceless to me.

Link to comment
Share on other sites

...because of some analog bits between the SID and the output that weren't on the chip to replicate...

Indeed it was missing the filters, and Kevtris mentioned having an issue with them on the Z3K because they would be system-specific hardware components.

Personally I think we can make an exception here because it's a huge part of the C64 that can't be replicated on the FPGA, but not everyone would agree.

  • Like 1
Link to comment
Share on other sites

The SID is an incredible subtractive analog synth; technology branched to digital and the depth of it's phat sound can't be emulated or replicated with an FPGA without those analog filters. The Electron SID station is coveted by modern composers and uses a real SID.

 

I like to boot up my c64 to listen to the high voltage SID collection, but I use an emulator on my ipod (rockbox) when I'm on the go :)

 

There's a custom portable SID player around somewhere, but it's not in production or I would buy one :)

 

Jeron Tel and Hubbard are some of the awesome classic SID composers but LukHash is doing tremendous SID compositions today:

https://www.youtube.com/watch?v=WIuHSp3NmtE

Link to comment
Share on other sites

Re: interlace handling- yes, I was going to have a buffer and just emit at 30fps, so frame doubling basically with two buffers in a ping-pong fashion. I will probably try a few things actually. But right now my first pass is going to be to have two buffers and just ping pong them- filling buffer 0 while displaying buffer 1 then switch to displaying buffer 0 and filling buffer 1.

 

Re: tearing- if I do it the way I am doing NES already, tearing is not an issue. The videogame system will be exactly synchronized to the HDMI frame so tearing cannot occur. I might have to pre or post buffer some video data to match data emission rate to the display device. To do this, I make the target system run at exactly 60.00000 or 50.00000 fps. This is fairly easy to do using some hardware trickery and I am already doing this on the Hi Def NES adapter to make the NES run at exactly 60.000 fps (or 50.000 fps for PAL). The Cyclone 5 has fractional-N PLLs which will make it child's play.

 

Modern HDMI monitors almost always support both 60fps and 50fps frame rates. Every monitor I've tested so far support both.

  • Like 1
Link to comment
Share on other sites

The FPGA doing all the heavy lifting will be a Cyclone V 49K LE part. There might/will be a second cheaper and smaller one no bigger than 25K LE's. Cyclone V maybe, or lesser like a IV depending on cost. This secondary part would do all the housekeeping and general care and feeding. There's also a PIC32 to do USB (ewwwww) and other things if I do 'em like ethernet, though I honestly doubt the ethertubes will make it to the final cut.

And how does the basic system BIOS fit in that design? I figure you need a standard splash screen when you turn the console on, and if no cartridge adaptor is detected, the console will look at the SD card reader, and the SD card could contain any directory structure so you need some built-in software to browse through the directories with the game controller and select a ROM (and the FPGA core to use with it).

 

 

I was expecting to have two card edge connectors on there, one for the video output board and then another for cartridge adapters. Unlike the Retrode/Retron 5 method of dumping and playing, I really want to execute the actual cartridge code on the cartridge in real time.

That' a good idea, as the savegame chip in certain carts will be used properly. :)

 

EDIT: Will I have to hold the reset button on your console when I turn it off, in order to avoid erasing the savegame chip in my Legend of Zelda NES cartridge? :P

Link to comment
Share on other sites

Re: interlace handling- yes, I was going to have a buffer and just emit at 30fps, so frame doubling basically with two buffers in a ping-pong fashion. I will probably try a few things actually. But right now my first pass is going to be to have two buffers and just ping pong them- filling buffer 0 while displaying buffer 1 then switch to displaying buffer 0 and filling buffer 1.

 

Re: tearing- if I do it the way I am doing NES already, tearing is not an issue. The videogame system will be exactly synchronized to the HDMI frame so tearing cannot occur. I might have to pre or post buffer some video data to match data emission rate to the display device. To do this, I make the target system run at exactly 60.00000 or 50.00000 fps. This is fairly easy to do using some hardware trickery and I am already doing this on the Hi Def NES adapter to make the NES run at exactly 60.000 fps (or 50.000 fps for PAL). The Cyclone 5 has fractional-N PLLs which will make it child's play.

 

Modern HDMI monitors almost always support both 60fps and 50fps frame rates. Every monitor I've tested so far support both.

Sounds like a good plan, even in the NeoGeo case I doubt many would hold a grudge if you speed it up to 60Hz precisely.

For interlaced signal any choice is a good choice, if you can do 60p with no buffer I don't see why you couldn't do 30i, the same way, just that the lines are displaced (or there's an intervening black one in between). I guess I don't understand the need for the flip flop buffer but it sounds like you've got it figured it out anyway so it would mainly be for my own education.

 

If I was Capt Picard, I would say:

Engage!

Make it so!

 

EDIT: I stand corrected

http://atariage.com/forums/topic/242970-fpga-based-videogame-system/page-8?do=findComment&comment=3330227

Edited by phoenixdownita
Link to comment
Share on other sites

Astrocade and Vectrex, that's like bonus material to me! Because I'm not entirely happy with the state of software emu for those two.

 

Someone was talking about VCS framerates. I understand that some tiny fraction of all the VCS out there render at 30FPS sometimes. While the console itself would continue running at 60FPS, the game would do its output every other screen - and use the black in-between frames for computation.

 

Don't know if that's relevant, don't know what games.

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

I'd like to see something substantially different to hardware that already exists. I'd say there are three serious contenders in the FPGA arena today:

 

The Turbo Chameleon 64 started life as a C64 VGA upscaler and SD card adapter (emulating disks), and then grew to work as a standalone machine (i.e. without a C64). It has optional DB9 plugs via a docking station (sold separately). This also features a (propietary) C64 core with excellent SID implementation (to my ears compared to my C64 at least). Price-wise it's mid-range if you count the docking station, which also allows pluggin real Amiga or C64 keyboards.

 

The MiST FPGA is open hardware and attracted a large number of open source projects, with many mature cores; it comes with a case, and features DB9, USB, and optional MIDI ports. It started life as a cheaper version of the Replay (not available at the time) to develop an Atari ST core, and more recently has received the first open-source implementation of the Amiga AGA chipset. It's the cheapest of these three (comes with a case already), and has very good developer support.

 

The Arcade Replay boasts HDMI output and is designed to receive daughterboards e.g. for a 68060 chip or USB ports. It does not come with a case but fits mini-ITX format. It's the most expensive option of the three (if you count the case and necessary adapters) but it's probalby also the most upscale "no compromises" implementation. Unfortunately it's hindered by supply issues, about 100 exists but they struggle to build more quickly (whereas the other two above are widely available). Also has a very active developer community.

 

I've omitted mention of other systems which seem to be clones of the above (with elss cores), or are limited to one platform.

So what would I expect on a new machine that I'd be willing to buy at a similar price range ($200-$300)?

 

First of all I'd expect it to be open to developers to port cores to it. It doesn't mean that Kevtris' cores must be open source; but that at least there is good support for third-party developers and some documentation/APIs for developers to use. While open source is not everybody's cup of tea, and open source cores are behind compared to proprietary ones, it nonetheless remains an important way to preserve these machines and their games/programs. Many of the guys involved collaborate to improve common elements (such as the 68000 code), benefiting everybody.

 

Second is dealing with video - which is something Kevtris already touched upon. The three systems above have good video for most cores but not all modern TVs can cope with 50hz modes or non-standard timings in 60hz (especially outside of Europe). These are being worked upon on all three systems; in the interim they can be solved with an upscaler but needing a separate box for video is a problem if you don't already own one (they aren't cheap).

 

Third would be cartridges. The Retron5 in spite of is flaws is fun to use by plopping cartidges in. That's probably not hard to do but I'd advise to support both direct connections (to use multicarts) and also a "dump and run the ROM" method. The second would be useful to apply patches on the fly, which makes running a lot of Japanese games very fun. Save states you can just get people to use an Everdrive (which supports it for some NES games), but backing/restoring save RAM would be needed to play games to completion.

 

Fourth - wide USB support. That has been done for the MiST and it supports remapping buttons for maximum flexibility (e.g. map "Up" to a button to jump in some games, or map to keyboard macros). Many wireless dongles work as well (not all, just those that use common protocols). This is great because if DB9 is not enough you can just map anything (or use a USB controller board to connect an arcade stick / whatever you fancy). Other nice features to have in USB would be connecting an external hard drive, and support some of the more exotic peripherals (e.g. Retrode to get the SNES pads connected).

 

Lastly - I'd recommend coming up with at least one exclusive core. Most 8-bit is widely available, TG16 has been done, Megadrive is around the corner (open source code exists), but not the Neogeo, the SNES, or any of the CD systems (PCE CD, Mega CD, etc.). Those will definitely get people's attention, even those who already own one of the other systems. :)

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

There are only a handful of SNES games that use high resolution 30Hz modes, and mostly for menus :

 

Dark Law (always)

Lufia 2 (credits)

RPM Racing (always)

Secret of Mana (menus)

Seiken Densetsu 3 (menus)

Super Bases Loaded 3 (always)

Smash Tennis (menus)

 

Also I should mention the SNES PowerPak with Ramsis' firmware and SD2SNES.

 

I cannot find any Sega Genesis games that use an interlaced mode except for Sonic the Hedgehog 2.

Link to comment
Share on other sites

First of all I'd expect it to be open to developers to port cores to it. It doesn't mean that Kevtris' cores must be open source; but that at least there is good support for third-party developers and some documentation/APIs for developers to use. While open source is not everybody's cup of tea, and open source cores are behind compared to proprietary ones, it nonetheless remains an important way to preserve these machines and their games/programs. Many of the guys involved collaborate to improve common elements (such as the 68000 code), benefiting everybody.

I'm certainly not against the idea of developing new custom cores, but that should come last in the list of proposed features. What is exciting about Kevin's prototype FPGA system is that it can run so many legacy games right out of the proverbial box, and many more will be playable on the machine once the 16-bit cores are up and running. That's the main draw for a guy like me, because having new cores is only a good thing if there are actual games that run on those new cores.

 

 

Third would be cartridges. The Retron5 in spite of is flaws is fun to use by plopping cartidges in. That's probably not hard to do but I'd advise to support both direct connections (to use multicarts) and also a "dump and run the ROM" method. The second would be useful to apply patches on the fly, which makes running a lot of Japanese games very fun. Save states you can just get people to use an Everdrive (which supports it for some NES games), but backing/restoring save RAM would be needed to play games to completion.

Why do we need the "dump and run the ROM" method if the system features a SD card reader?

 

 

Lastly - I'd recommend coming up with at least one exclusive core. Most 8-bit is widely available, TG16 has been done, Megadrive is around the corner (open source code exists), but not the Neogeo, the SNES, or any of the CD systems (PCE CD, Mega CD, etc.). Those will definitely get people's attention, even those who already own one of the other systems. :)

Super-NES and Neo Geo seem to be in the cards... :)

Link to comment
Share on other sites

What is exciting about Kevin's prototype FPGA system is that it can run so many legacy games right out of the proverbial box

 

The three systems are already in production and play all those games. Here's a few videos I captured with a MiST to give you an idea:

This is just a glimpse, and the cores aren't perfect. But their HDL source code is available and developers are slowly improving them (everybody's welcome to contribute).

With each improvement compatibility increases and new games become available.

 

So if we're going to have another FPGA system, IMHO it should feature something unique. Yes, very mature and optimized cores counts to that (and I'm sure Kevtris' NES core is better than the open source one), but given enough time one of the open source cores will catch up. Something like connecting cartridges would be a much better differentiator. I was skeptical about cartridges until I tried a Retron5 and yes, it is very fun to play the game you just physically put in the slot. Now they could just read the header of the ROM from the cart then load a ROM file from the SD card, for all I care. :)

 

Edit: also note that I'm talking assuming a 200-300 USD price point. If Kevtris pulls off a lot of cores for at a much cheaper price then I'd be fine with less features. As system under 100 bucks reading SD cards only would probably sell very well even with only 8-bit cores.

Edited by Newsdee
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...