FPGA Based Videogame System

[+kevtris]

re: supported modes, it will support at least the 6 I already support now on the Hi Def NES adapter which is 720p (50fps/60fps), 1080p (50fps/60fps), 480p60, and 576p50. Mode support will probably be implemented in a similar fashion to how it's done on linux with "mode lines". That's basically how I have it supported now. Maybe I can make it pull them from a text file? The scaling system I have now basically allows any resolution video coming in and going out with optional things like HQX scaling on top of it. (i.e. video is HQX scaled first and then pulled up with interpolation in the next step.) That'd make pulling gameboy up from middle of the screen to full screen for example (or anywhere in between).

 

Fortunately I don't think 1080p (or 720p, or even 480p) will be going obsolete any time soon even on 4K and higher TVs. It's digital so they will just scale it to fit- the danger will be the HDMI connector itself disappearing I think. Anything else is no problem because the panel will just upscale whatever you feed it. I was doing tests with some monitors and some of them will eat just about anything you feed it.

[Keatah]

Another great way to bring old classics to the newest display technologies.

[Newsdee]

You know what would rock with a high res screen? The ability to run two (or more) gameboys at once and implement the link cable betweem them. Basically two player mode :-)

[MaximRecoil]

4K is pointless unless you have a massive screen. For example, the two most recent Star Wars movies, which were released in 2002 and 2005, were shot on less-than-1080p video (1920 × 817, which is what you get when you crop 1080p down to a 2.35:1 aspect ratio), which were shown in theaters at the same resolution they were shot in. How big is a typical movie theater screen? 50 feet? However big they are, they utterly dwarf your home TV. If 1080p is good enough for a big budget Hollywood movie intended to be viewed on massive theater screens, it is good enough for your living room on your comparatively tiny TV.

 

By the way, tons of big movies, even today, are shot or mastered on 2K video (2048 × 1080), which is an ever-so-slightly higher resolution than 1080p (1920 × 1080), or slightly under 3K. The enormously popular professional movie camera, the Arri Alexa, is just under 3K for example (2880 × 1620); it was the main camera used to shoot Avengers: Age of Ultron, just to name one of about forty-eleven thousand recent examples, and the DI master for that movie was only 2K (which is typical), which means 2K is what was shown in theaters.

 

But with regard to classic ~240p video games, there is only one type of display that's good enough for those: a ~15 kHz CRT. Anything else is a downgrade/kludge.

Edited October 25, 2015 by MaximRecoil

[Schizophretard]

You know what would rock with a high res screen? The ability to run two (or more) gameboys at once and implement the link cable betweem them. Basically two player mode :-)

This man speaks the truth. That rocking is an objective fact.

[roland p]

Two linked gameboys (or other linkable consoles) on one screen would mean that we finally have some good use for wide-screen tv's.

[Schizophretard]

Two linked gameboys (or other linkable consoles) on one screen would mean that we finally have some good use for wide-screen tv's.

I agree. I never got to link handhelds because idiots designed the idea around everyone owning a copy of the game.

[Pixelboy]

Two linked gameboys (or other linkable consoles) on one screen would mean that we finally have some good use for wide-screen tv's.

Are there any Game Boy emulators today that do this on a PC screen?

[some_canuck]

Are there any Game Boy emulators today that do this on a PC screen?

 

not that i know of. visualboy advance can do link cable, but it requires two instances of the emulator, or a internet connection.

Edited October 25, 2015 by some_canuck

[Andromeda Stardust]

You know what would rock with a high res screen? The ability to run two (or more) gameboys at once and implement the link cable betweem them. Basically two player mode :-)

That may or may not be a problem depending on the game. By all means support dual screens if you can, but this requires the FPGA be beefy enough to support two simultaneous GAme Boy cores. Handheld multiplayer titles were designed with the expectation that players only view their own screen. For instance you wouldn't play a game of poker with your cards face up. Maybe include a link port on the Game Boy cart adapter.

[Newsdee]

FPGAs are good at parallelizing; but the challenge would be sharing the same RAM and video between the two cores.

[Andromeda Stardust]

FPGAs are good at parallelizing; but the challenge would be sharing the same RAM and video between the two cores.

Well Game Boy uses a 160x144 window. Scaled 5x, it would fit nicely side by side with small boarders in a 1080x1920 frame with 160 HD pixels between the two pictures and 80 HD pixels buffer on each edge. Or scaled to 6x without borders, assuming the HDTV has no overscan. This would leave the Game Boy picture filling 720 out of 1080 vertical pixels (2/3 filled @ 5x scaling) or 864 of 1080 vertical pixels (4/5 filled @ 6x scaling). Player one would probably be the left player and player two the right.

 

I would imagine if the entire Game Boy, including the display kernel, took up less than half the total space on the FPGA, then doing a link cable for Game Boy /Color would be doable.

 

Do emulators even support this mode yet?

[Andromeda Stardust]

I had a thought occur to me regarding comparisons between the RetroVGS and the Zimba 3000. Perhaps the Zimba 3000 could use a custom homebrew core as a spiritual successor to the failed RetroVGS project. It obviously won't be strong enough to support modern indie titles developed on Unity or elsewhere, but may allow kickass homebrew to be developed for the system with little effort. From the RetroVGS thread:

 

 

Maybe a custom Kelvin Zimba 3000 core including a kick ass 480p sprite engine paired with either a massively overclocked retro core (for instance 68k or 6502) or a simplified ARM core, may provide an outlet for future homebrew development using a modern dev tool chain, without relying on knowledge of assembly language or worrying about the crippling memory and CPU constraints of classic 8- and 16-bit consoles. Should the Zimba 3000 garner enough of an install base, I could see this taking off. Homebrew games using the new homebrew cores could either be loaded via the SD card or as custom carts that plug directly into the cart adapter port.

[some_canuck]

Perhaps the Zimba 3000 could use a custom homebrew core as a spiritual successor to the failed RetroVGS project.

 

 

I was chatting with kevtris a couple weeks ago about possibly using his hardware for "custom" hybrid configurations, things like multiple sound cores and custom memory layouts. He said it would be physically possible, but he wants to get the Zimba out the door first with stock console configurations.

[Newsdee]

Definitely focus on the main features first. This has the potential to be the reference in console FPGAs covering the Retron5/Retro Freak niche.

 

Computers are covered by other boxes; and anyway are more fiddly to setup/debug, so you'd have much more support questions on them. These can be added later by porting cores.

[+kevtris]

Was thinking about doing a small interim project before doing the new PCB- adding another system to the current hardware and documenting how it was done. This will be the APF MP1000. I didn't even know it existed until a little while ago. Looks really easy to add- a 6800, some kind of video chip and not much else. I can do a little series on reverse engineering it using a logic analyzer, then recreating the timing on the FPGA side and matching the two. I kinda wanted to add the bally astrocade too; maybe if the response is good to the APF stuff I will add that and document it in a similar way? Both of these don't look terribly hard and I have most of the pieces already to do them. I will have to obtain a bally system, however, to figure out the exact timing.

[+grips03]

Astrocade would be great

[some_canuck]

Was thinking about doing a small interim project before doing the new PCB- adding another system to the current hardware and documenting how it was done. This will be the APF MP1000. I didn't even know it existed until a little while ago. Looks really easy to add- a 6800, some kind of video chip and not much else. I can do a little series on reverse engineering it using a logic analyzer, then recreating the timing on the FPGA side and matching the two. I kinda wanted to add the bally astrocade too; maybe if the response is good to the APF stuff I will add that and document it in a similar way? Both of these don't look terribly hard and I have most of the pieces already to do them. I will have to obtain a bally system, however, to figure out the exact timing.

 

I would be interested in seeing this process.

[+Tarzilla]

Astrocade would be great

I second this

[Newsdee]

Astrocade is available for the Arcade Replay and was ported to the MiST. You can check out that source code for a port.

[BigO]

Was thinking about doing a small interim project before doing the new PCB- adding another system to the current hardware and documenting how it was done. This will be the APF MP1000. I didn't even know it existed until a little while ago. Looks really easy to add- a 6800, some kind of video chip and not much else. I can do a little series on reverse engineering it using a logic analyzer, then recreating the timing on the FPGA side and matching the two. I kinda wanted to add the bally astrocade too; maybe if the response is good to the APF stuff I will add that and document it in a similar way? Both of these don't look terribly hard and I have most of the pieces already to do them. I will have to obtain a bally system, however, to figure out the exact timing.

I'd watch that video.

(I'd also send you an Astrocade, if I had one.)

[SnoopKatt]

Since UHDTVs are becoming more and more common, I believe you should provide 2160p60 output (4:4:4) to "future proof" the video output. TV manufacturers are phasing out 1080p in favor of 2160p. Unfortunately most UHDTVs do not do a very good job of upscaling 1080p graphics to 2160p. It's been incrementally improving each year, but in most cases 1080p60 is chroma sub-sampled when upscaled, resulting in ringing on both horizontal and vertical edges.

 

The only exception thus far has been from Panasonic, as they provide a 1080p by 4 pixel mode that does the "correct" scaling from 1080p to 2160p. Unfortunately the input lag on these sets are not very gaming friendly (high). Hence, I believe it would be worthwhile to include a 2160p capable FPGA to handle the upscaling.

That's surprising that there's sets that don't have the option for integer scaling. But I'd imagine there are probably (or will be) inexpensive external scalers that would do it.

[Pixelboy]

Remember the Coleco Telstar Arcade with its triangular game cartridges? If it wasn't for the "custom" controllers, it could be an interesting project to add to an FPGA core to-do list. That and also the Milton Bradley Microvision.

[Newsdee]

That's surprising that there's sets that don't have the option for integer scaling. But I'd imagine there are probably (or will be) inexpensive external scalers that would do it.

 

I have TVs where the composite input is much worse than upscaling composite via an XRGB-Mini Framemeister. You'd think a basic input like that wouldn't be hard to handle, but I really suspect companies are being super cheap in supporting "legacy" inputs. Not surprisingly, newer sets seem to only support HDMI now.

[SnoopKatt]

 

I have TVs where the composite input is much worse than upscaling composite via an XRGB-Mini Framemeister. You'd think a basic input like that wouldn't be hard to handle, but I really suspect companies are being super cheap in supporting "legacy" inputs. Not surprisingly, newer sets seem to only support HDMI now.

I can understand how it'd be poor quality on the analog side since ADC converters can be quite complicated and there's so many ways to do it (including a lot of crappy ways), as seen with audio DACs and ADCs but a digital to digital scaler shouldn't be a big deal. Theoretically an integer scaler shouldn't have any quality degradation since the digital signal just needs to be replicated, and any snazzy effects should be able to just be disabled.