FPGA Based Videogame System

[Newsdee]

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.

Yeah, at least HDMI won't (shouldn't) degrade the image so we wouldn't have to go back to tapping RGB to feed whichever new standard comes afterwards. I might eat my words later, but migrating all machines to HDMI seems a safe bet right now.

[SnoopKatt]

Yeah, at least HDMI won't (shouldn't) degrade the image so we wouldn't have to go back to tapping RGB to feed whichever new standard comes afterwards. I might eat my words later, but migrating all machines to HDMI seems a safe bet right now.

"Shouldn't" is the key word haha. We should be ok as long as hw manufacturers keep in spec with the current digital interface.

[+kevtris]

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

no can do. that's cheating :-) I do not use any one else's cores or complete systems, because then I'm on the hook via licenses and stuff. (not to mention the point's kind of to make it all myself).

[+kevtris]

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.

Unfortunately the telstar used custom game ASICs and doesn't really run code, so there's no way to do anything but a simulation without decapping and tracing out the circuit on the chip itself. The microvision might be possible but I dunno- I did think about it. Guess who dumped a number of the games for that system. hehehe. (yah I did that)

[Pixelboy]

The microvision might be possible but I dunno- I did think about it. Guess who dumped a number of the games for that system. hehehe. (yah I did that)

Cool. A quick Google search revealed that you worked with Sean Riddle in his endeavour to make a Microvision simulator, and there seems to be several such projects out there.

[Keatah]

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.

 

I'd like to see the C380 done, but that is also hardwired IIRC.

 

 

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.

"Shouldn't" is the key word haha. We should be ok as long as hw manufacturers keep in spec with the current digital interface.

 

With the rate tech changes today, just for the sake of change, do you think HDMI will be around in 10 years? There's MHL, DP, Lightning, and some wireless initiative from intel. All competing against HDMI.

Edited October 27, 2015 by Keatah

[SnoopKatt]

With the rate tech changes today, just for the sake of change, do you think HDMI will be around in 10 years?

HDMI 2.0 does use the same connector as HDMI, and it's already been implemented in different source/display mediums so HDMI may stick around a while. But it might change after the next jump from 4K. And even if it does, it won't really be a big deal as far as scaling goes since it would still be digital to digital.

 

I quoted you before you updated your post, whoops!

 

With the rate tech changes today, just for the sake of change, do you think HDMI will be around in 10 years? There's MHL, DP, Lightning, and some wireless initiative from intel. All competing against HDMI.

True, you never know. HDMI is still dominating TVs, and 4K-BluRay will use HDMI 2.0. That alone probably seals HDMI 2.0 over the other ones.

Edited October 27, 2015 by SnoopKatt

[Pixelboy]

True, you never know. HDMI is still dominating TVs, and 4K-BluRay will use HDMI 2.0. That alone probably seals HDMI 2.0 over the other ones.

I'd say that's pretty long-term anyway. By the time the Zimba's basic HDMI connector becomes a problem (which will probably take longer than 5 years) Kevtris should be able to deal with that problem with the tech solutions available to him at that time. Since his design is modular, hopefully he can make a new TV output board and people will be able to unscrew the Zimba's casing and swap the boards easely. If the problem is more complex than a simple board swap, FPGAs will probably be more advanced and perhaps Kevtris will develop a Zimba 4000 just for the sake of keeping up with upcoming standards that will become as current as HDMI is today. However, if I were in Kevtris' place, I wouldn't bother. I would just tell people to find an "old" HDMI TV and use it with the existing Zimba 3000, just like many people still use CRT TVs to play with their old classic consoles today.

 

By the way, bringing back one of Kevtris' posts:

 

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)

So a Game Boy Advance core is not in the cards? Not really a huge problem (although the GBA does have a large library of excellent games) but I'm just curious since you did make cores for the Game Boy and Game Boy Color.

[some_canuck]

So a Game Boy Advance core is not in the cards? Not really a huge problem (although the GBA does have a large library of excellent games) but I'm just curious since you did make cores for the Game Boy and Game Boy Color.

 

GBA has an ARM core, a little more advanced than the GB/GBC era hardware.

[Andromeda Stardust]

 

GBA has an ARM core, a little more advanced than the GB/GBC era hardware.

Fun fact, GBA and GB/C use entirely different architecture. Even the voltage levels are different. Each backwards compatible GBA console has a lever inside that is activated by older Game Boy carts but GBA carts have a groove in the cartridge which does not depress this lever. DS and GBA micro lack this backwards compatibility and physically block GB carts from being inserted.

[Guspaz]

 

I'd like to see the C380 done, but that is also hardwired IIRC.

 

 

 

With the rate tech changes today, just for the sake of change, do you think HDMI will be around in 10 years? There's MHL, DP, Lightning, and some wireless initiative from intel. All competing against HDMI.

 

HDMI used essentially the same video signaling as DVI before it, meaning we're 16 years in on HDMI video, over which period the standard has evolved and been upgraded, but still maintains that common compatibility. There is no reason to think that HDMI is going to be unseated by anything in the near or distant future, because the standard can (and has) been updated to accommodate upgrades over time.

 

As for MHL, DP, and Lightning, MHL is a failed standard that never managed to be anthing but niche, DisplayPort is focused on computers rather than televisions and that doesn't appear to be changing any time soon, and Lightning doesn't support video in the first place (Lightning video adapters are just wired AirPlay video streamers).

 

If anything, there is a trend towards replacing various connectors with USB-C, with rumours that DisplayPort may eventually migrate to using USB-C as their primary connector. MHL also seems to be planning to support USB-C alt mode, although it's not clear if they want to adopt it as their primary connector too.

[Andromeda Stardust]

 

HDMI used essentially the same video signaling as DVI before it, meaning we're 16 years in on HDMI video, over which period the standard has evolved and been upgraded, but still maintains that common compatibility. There is no reason to think that HDMI is going to be unseated by anything in the near or distant future, because the standard can (and has) been updated to accommodate upgrades over time.

 

I would imagine, should the HDMI standard need to be superceded for whatever reason (ie need more data pins, etc) then straight wired adapters will be available to connect HDMI signal to future standards without any actual signal conversion.

 

My main pet peeve with HDMI devices is connecting them to DVI equipment or anything that doesn't pass analog audio out to an external sound system. It's annoying to be forced to buy HDMI pass through dongles just to siphon off the audio feed.

[Guspaz]

I think the occasional inconvenience to support uncommon setups like that is far outweighed by the convenience and simplicity gained by having everything on a single cable. The fault there lies more on the source (for not having S/PDIF output) and destination (for not supporting audio) devices. HDMI even makes accommodations for audio going in the reverse direction via ARC (Audio Return Channel) in the scenario where you have something like a TV with a built-in OTA tuner that needs to send audio back through the input to the AV receiver. I'm not sure how HDMI could have done anything differently to address your scenario.

 

That said, it'd really be nice if HDMI supported having more than trivial amounts of power (it only requires a minimum of 55 mA on the +5V pin) on the cable, which would enable things like the S/PDIF splitters that you need without requiring external power bricks. About the only thing that I've seen bus-powered on HDMI are equalizers and range extenders like the RedMere chips. You can't do much with 55 mA.

[MarkVI]

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.

 

This would be great to see. I'd also drool if you ever posted a video on reverse engineering any part of the SNES logic. Also, maybe some of the people here can point me to a good resource or first project to start with for getting into replicating consoles on FPGAs. I am familiar with programming in Python/C++, but mostly in the context of scientific programming and mathematics.

[Newsdee]

I do not use any one else's cores or complete systems, because then I'm on the hook via licenses and stuff. (not to mention the point's kind of to make it all myself).

 

Maybe you could do the ipposite, create one core and open source it with a license you choose. That way you show developers how to port to the Zimba 3000?

 

Unless you don't plan to allow third party cores (I don't see any downside but as you say there could be licensing issues).

[Newsdee]

maybe some of the people here can point me to a good resource or first project to start with for getting into replicating consoles on FPGAs.

 

Have a look at the MiST Git repository, it has the source for plenty of cores (and links to more):

https://github.com/mist-devel/mist-board/wiki

[Pixelboy]

Maybe you could do the ipposite, create one core and open source it with a license you choose. That way you show developers how to port to the Zimba 3000?

 

Unless you don't plan to allow third party cores (I don't see any downside but as you say there could be licensing issues).

Why develop a game for a custom core when you can develop the same game on an existing core? Using a custom core means you must have access to the technical documentation of this new core, and this documentation may not be as complete as the developer needs (it's a universal truth that hardware guys hate to write docs). On the other hand, using an existing core that mimics a known console/computer means that you can use the documentation available for the original hardware, and more importantly, you can ask questions to people who previously developed games for that original console/computer.

 

I would tend to see custom cores as a niche segment, which homebrewers could have fun with, but with the understanding that their creations would run exclusively on the Zimba. If the customer base of the Zimba were to go into the thousands, then it may be worthwhile for homebrewers to seriously sink their teeth into a custom core, but even then, it would be easier if such a custom core was simply an extension of a "regular" core. For example, a "Super ColecoVision" core would be the same as the regular ColecoVision core, but would offer additional graphic modes not available on the original ColecoVision console. Any homebrewer who knows the original ColecoVision well enough could get started immediately and would only need to write some test software to familiarize themselves with the new graphic modes.

[Andromeda Stardust]

I think the occasional inconvenience to support uncommon setups like that is far outweighed by the convenience and simplicity gained by having everything on a single cable. The fault there lies more on the source (for not having S/PDIF output) and destination (for not supporting audio) devices. HDMI even makes accommodations for audio going in the reverse direction via ARC (Audio Return Channel) in the scenario where you have something like a TV with a built-in OTA tuner that needs to send audio back through the input to the AV receiver. I'm not sure how HDMI could have done anything differently to address your scenario.

 

That said, it'd really be nice if HDMI supported having more than trivial amounts of power (it only requires a minimum of 55 mA on the +5V pin) on the cable, which would enable things like the S/PDIF splitters that you need without requiring external power bricks. About the only thing that I've seen bus-powered on HDMI are equalizers and range extenders like the RedMere chips. You can't do much with 55 mA.

Didn't the gamestick and tvstick plug directly into the hdmi port on the back of the TV? Or did those need a microUSB to supply power, either from the TV itself or a wallwart?

 

And the issue of getting analog audio to a stereo amp with custom AV setups can be a pain for devices with only a single HDMI out port. The HDTV or monitor and a quality HiFi system are separate devices. Sometimes you don't want a single pipeline for both signals.

 

Also, In my bedroom, I got a record player, and a 3-piece CD stereo with old Jensen JP-500 speakers. Tube TV and an HD monitor. In the living room we got a Sony stereo amp and Polk Monitor 40s. I don't even miss the old 5.1 surround sound we used to have with tinny speakers and overpowered sub. The "downgrade" with two quality speakers instead of 5 tinny boxes sounds so much better!

 

We don't even have "digital" sound anymore. Way too crispy. I actually like the sound of analog RCA cables better than SPDIF over coax or optical. HDTV in the living room is nice though.......

[Guspaz]

Most HDMI sticks require external power, typically supplied by USB. Some televisions have high-power HDMI ports, since the HDMI standard doesn't define a maximum amount of power that can be supplied, only a minimum.

 

I believe that HDMI ports intended for connecting MHL devices may be able to supply more power, although most HDMI stick devices (like the chromecast) don't support being powered over HDMI even when the port can supply enough power.

[Andromeda Stardust]

Why develop a game for a custom core when you can develop the same game on an existing core? Using a custom core means you must have access to the technical documentation of this new core, and this documentation may not be as complete as the developer needs (it's a universal truth that hardware guys hate to write docs). On the other hand, using an existing core that mimics a known console/computer means that you can use the documentation available for the original hardware, and more importantly, you can ask questions to people who previously developed games for that original console/computer.

 

I would tend to see custom cores as a niche segment, which homebrewers could have fun with, but with the understanding that their creations would run exclusively on the Zimba. If the customer base of the Zimba were to go into the thousands, then it may be worthwhile for homebrewers to seriously sink their teeth into a custom core, but even then, it would be easier if such a custom core was simply an extension of a "regular" core. For example, a "Super ColecoVision" core would be the same as the regular ColecoVision core, but would offer additional graphic modes not available on the original ColecoVision console. Any homebrewer who knows the original ColecoVision well enough could get started immediately and would only need to write some test software to familiarize themselves with the new graphic modes.

Well if the Zimba becomes popular enough and generates a sizeable install base, homebrewers may have motivation to write software for it. That's why I think a kick-ass 480p sprite engine with massively overclocked retro CPU (or simplified ARM) with a modern tool chain (C+ coding) would be great.

 

But first, the Zimba would need a sizeable install base. But the sprite engine would allow greater creativity without the crippling RAM and CPU constraints of the original consoles.

 

I would also love to see an Uzebox core. That would be very easy to do. One single 28Mhz 8-bit CPU handles the video, audio, and physics. 4kb RAM, 64kb ROM. Very lean homebrew console.

[Newsdee]

By "core" I mean the binary file that configures the FPGA into a system. Earlier I didn't mean inventing new systems, but rather implementing an existing machine (say the Astrocade) in open source HDL code.

 

This shows other developers how to port their cores to the Z3000, if they want to do so. And it removes any licensing issues from porting a core from somebody else.

 

But I get that publishing one's code is not everybody's cup of tea. Maybe release it under a pseudonym then :-)

[Newsdee]

One system I'd like to see is the V-Tech V-Smile (console for kids) since there aren't any emulators. But it seems 16-bit so might be too much work.

[roland p]

One system I'd like to see is the V-Tech V-Smile (console for kids) since there aren't any emulators. But it seems 16-bit so might be too much work.

True, V-Smile Hardware breaks too easily by the way.

Edited October 28, 2015 by roland p

[some_canuck]

One system I'd like to see is the V-Tech V-Smile (console for kids) since there aren't any emulators. But it seems 16-bit so might be too much work.

 

if you're gonna go the v-tech route, might as well add the socrates.

[Newsdee]

It doesn't have the funky controller though

 

Back on topic, HDL is pretty tough... it takes both some programming and EE knowledge. I can read the code but I'm at a loss at to how to put things together. Anybody has a good book to recommend for EE but applied to FPGAs?

Edited October 29, 2015 by Newsdee