Jump to content

Photo

FPGA Based Videogame System

FPGA

2398 replies to this topic

Poll: Interest in an FPGA Videogame System (406 member(s) have cast votes)

I would pay....

  1. > $100 (31 votes [7.64%] - View)

    Percentage of vote: 7.64%

  2. $100-149 (54 votes [13.30%] - View)

    Percentage of vote: 13.30%

  3. $150-199 (128 votes [31.53%] - View)

    Percentage of vote: 31.53%

  4. $200-299 (119 votes [29.31%] - View)

    Percentage of vote: 29.31%

  5. Sky's the Limit (74 votes [18.23%] - View)

    Percentage of vote: 18.23%

I Would Like Support for...

  1. 8 bit era games (344 votes [46.49%] - View)

    Percentage of vote: 46.49%

  2. 16 bit era games (336 votes [45.41%] - View)

    Percentage of vote: 45.41%

  3. Blip (60 votes [8.11%] - View)

    Percentage of vote: 8.11%

Games Should Run From...

  1. SD Card / USB Memory Sticks (350 votes [55.64%] - View)

    Percentage of vote: 55.64%

  2. Original Cartridges (250 votes [39.75%] - View)

    Percentage of vote: 39.75%

  3. Hopes and Dreams (29 votes [4.61%] - View)

    Percentage of vote: 4.61%

The Video Inteface Should be...

  1. RGB (148 votes [18.07%] - View)

    Percentage of vote: 18.07%

  2. Composite (137 votes [16.73%] - View)

    Percentage of vote: 16.73%

  3. S-video (75 votes [9.16%] - View)

    Percentage of vote: 9.16%

  4. Component (108 votes [13.19%] - View)

    Percentage of vote: 13.19%

  5. HDMI (351 votes [42.86%] - View)

    Percentage of vote: 42.86%

Vote Guests cannot vote

#1901 phoenixdownita OFFLINE  

phoenixdownita

    River Patroller

  • 2,413 posts

Posted Fri Mar 10, 2017 2:37 PM

well the problem with PCE is the cartridges can run at over 7MHz access rate which is a bit too fast for the SDRAM.  there's plenty of blockram to do the 64K worth of VRAM (this goes for SNES, and genesis too).  But bulk storage for the game ROM needs external memory since 256K+ worth of it is too big for BRAMs.  I had a funny idea with the PCE though where I might be able to do 2 or 3 read bursts depending on the instruction the CPU is executing to make it work but I would need to mull it over more and get more technical information.  PCE tech information seems pretty hard to come by, at least with the couple hours I wasted on google searching.  lots of dead links and dead ends

 

One can always ask for an Nt Mini ++ with a 5CEA9 at 301K LE and 12Mbit of block RAM (that's > 1MBytes) for just 350$ extra (that's the full price of the FPGA)

If memory serves aside SFII (2MBytes) all PCE card games are <= 512KBytes .... and can fit ..... just saying.

 

The 5CA7 at 150K LE seems to be running at 200$ for 6Mbits (that's > 512K), so maybe it can be used in the Nt Mini ++ (not sure it's a drop in replacement as it may have different pinout/packaging, but if it is it would not even required any change on the HW manufacturing side with the exception  the "sarcastic note" below).

 

<sarcasm>

I can see a platinum case for the Nt Mini ++, with a diamond encased on the power button!!

</sarcasm>



#1902 atmn OFFLINE  

atmn

    Space Invader

  • 49 posts
  • Location:Sweden

Posted Fri Mar 10, 2017 3:22 PM

Maybe this is related? Some retrogamingcables have had issues.

 

I actually am still getting issues even without the retrogamingcables, but it's something to check out

 

Something that could help narrow it down would be to try the composite, component, or rgb video cables from monoprice. My NT Mini came with an issue where it won't output composite, in component the R-Y signal is missing, and in RGB the R signal is missing. Turns out they all come from the same pin (pin 1). It could also be an issue with one of the other pins, not sure.

 

I had to contact customer support and sent my NT Mini in, due to this.

 

Unfortunately, I found one more report of the same issue on twitter, so perhaps there are more consoles out there with the issue.

 

https://twitter.com/...902281772466176

 

 

 

As for detection, if Pins 4 and 5 are connected then the NT Mini will know to output composite video

 

Think my problems are more like your, retrogamingcables seems to have fixed their issues. Mine is connected like above mentioned. And it seems like its the red that is missing from tje rgb signal Its not flickering like in the youtube clip.. Contacted Analogue and they said they only supported cables from monoprice.

 

Strange since I followed a Analogue tweet how to get cables..

 

which cable from monoprice should work,? rgb to euroscart.


Edited by atmn, Fri Mar 10, 2017 3:23 PM.


#1903 TheRedEye OFFLINE  

TheRedEye

    Moonsweeper

  • 339 posts
  • Location:Berkeley, CA

Posted Fri Mar 10, 2017 3:24 PM

Bug Report:

 

Game Gear audio for Terminator 2: Judgement Day is very messed up, it's obvious as soon as the music kicks in on the title screen. I've never played it on real hardware but I'm comparing it to this video: 



#1904 kevtris OFFLINE  

kevtris

    Moonsweeper

  • Topic Starter
  • 370 posts
  • FPGA Whisperer
  • Location:Flyover, USA

Posted Fri Mar 10, 2017 4:26 PM

Got my Nt Mini yesterday, awesome system.

 

Having trouble with the analogue output, dont know if anybody else have issues like me.

Ordered a cable from retrocables.uk, they have a breakout converter to euro-scart. The colors are greenish, like the red-signal is missing. Also the RGB-blanking signal seems to be missing.

 

Checked the analogue nt mini specification for the analogue output, pin 5,10,15 is labeled "detection", what is that?

Euro-TV:s that supports RGB depends on a RGB-blanking signal (+5v with a 180ohm resistor) to scart pin16 (RGB blanking).

 

The RGB-blanking does not seem to be connected, is there any +5V out on the DB-15 from the Nt Mini?

pins 5, 10, and 15 when grounded in various patterns (I think it's listed.  if not I will list it here) selects between RGB, composite/svideo and component modes.

 

the nt mini does not output 5V on any pin of that connector.   When I designed it, I didn't know scart needed it, since scart is a unicorn connector here.  I have never seen scart in real life on any tv or monitor.



#1905 kevtris OFFLINE  

kevtris

    Moonsweeper

  • Topic Starter
  • 370 posts
  • FPGA Whisperer
  • Location:Flyover, USA

Posted Fri Mar 10, 2017 4:32 PM

Bug Report:

 

Game Gear audio for Terminator 2: Judgement Day is very messed up, it's obvious as soon as the music kicks in on the title screen. I've never played it on real hardware but I'm comparing it to this video: 

hah so it is.  they are using the periodic noise mode but for some reason it didn't switch into periodic noise mode.   I will put it on the todo.  thanks for the report.



#1906 kevtris OFFLINE  

kevtris

    Moonsweeper

  • Topic Starter
  • 370 posts
  • FPGA Whisperer
  • Location:Flyover, USA

Posted Fri Mar 10, 2017 4:55 PM

It's that time again.  Firmware friday!  This week it's Atari 7800.   I made a lot of internal changes so I hope nothing broke.   This was required, because the 7800 can output 320 pixels across, while my scalers and video pipeline were limited to 256 before.  This has been rectified for the future so stuff like C64 will be scale-able now.

 

I added the ability to set horizontal width per system (this was limited before for NES/SMS/GG/coleco) and 1080p height (4x/4.5x/5x) as well.   I don't know if anyone ever really noticed this, but I fixed it now.

 

Other than that, I added 7800.  It is complete and supports pokey audio (Ballblazer, etc).   The .a78 headers are used to determine mapper, RAM, and pokey status.  

 

There is a minor issue with Xenophobe and the diagnostic cartridge which I believe are related.  They both seem to stem from the DMA "memory hole" which was NOT present on the maria chip schematics I had, so I had to guess at it from logic traces and deduction.  I thought I had it licked but apparently there is a little more to it.  This causes DMA to run slightly long which I believe is the source of the problem.   Apparently there's updated schematics available but I haven't seen them anywhere.

 

Anyways, enjoy!

 

http://blog.kevtris....re_verJB1.5.zip

 

Here's the updates from the readme:

 

V1.5 update:

* Added Atari 7800 core.
* Each core will now save 1080p height selection (4x, 4.5x, 5x).
* Each core will now save its X width and offset.
* Added a new scaler for 7800 since it is 320 pixels wide.
* Retooled scaling calculations to accommodate systems wider than 256 pixels.  I hope I didn't break anything.
 



#1907 Fafner OFFLINE  

Fafner

    Space Invader

  • 41 posts

Posted Fri Mar 10, 2017 5:15 PM

Oops

Edited by Fafner, Fri Mar 10, 2017 5:16 PM.


#1908 Fafner OFFLINE  

Fafner

    Space Invader

  • 41 posts

Posted Fri Mar 10, 2017 5:15 PM

It's that time again.  Firmware friday!  This week it's Atari 7800.   I made a lot of internal changes so I hope nothing broke.   This was required, because the 7800 can output 320 pixels across, while my scalers and video pipeline were limited to 256 before.  This has been rectified for the future so stuff like C64 will be scale-able now.
 
I added the ability to set horizontal width per system (this was limited before for NES/SMS/GG/coleco) and 1080p height (4x/4.5x/5x) as well.   I don't know if anyone ever really noticed this, but I fixed it now.
 
Other than that, I added 7800.  It is complete and supports pokey audio (Ballblazer, etc).   The .a78 headers are used to determine mapper, RAM, and pokey status.  
 
There is a minor issue with Xenophobe and the diagnostic cartridge which I believe are related.  They both seem to stem from the DMA "memory hole" which was NOT present on the maria chip schematics I had, so I had to guess at it from logic traces and deduction.  I thought I had it licked but apparently there is a little more to it.  This causes DMA to run slightly long which I believe is the source of the problem.   Apparently there's updated schematics available but I haven't seen them anywhere.
 
Anyways, enjoy!
 
http://blog.kevtris....re_verJB1.5.zip
 
Here's the updates from the readme:
 
V1.5 update:

* Added Atari 7800 core.
* Each core will now save 1080p height selection (4x, 4.5x, 5x).
* Each core will now save its X width and offset.
* Added a new scaler for 7800 since it is 320 pixels wide.
* Retooled scaling calculations to accommodate systems wider than 256 pixels.  I hope I didn't break anything.
 

Woot!!!!
Loading it now!

#1909 Radfoo OFFLINE  

Radfoo

    Chopper Commander

  • 109 posts

Posted Fri Mar 10, 2017 5:47 PM

 

 

Other than that, I added 7800.  It is complete and supports pokey audio (Ballblazer, etc).   The .a78 headers are used to determine mapper, RAM, and pokey status.  

 

 

Thanks, will have a go tomorrow evening. Still not tried all the other cores but looks like a few good titles on the 7800.

 

So far had a play on NES, Colecovision, Atari 2600 and the Master System.  Spent ages on the Atari 2600, is really good. Need to find some more PAL games for the full nostalgia effect as NTSC pallete is all wonky to my British memory, lol. 



#1910 roaringchicken OFFLINE  

roaringchicken

    Space Invader

  • 16 posts

Posted Fri Mar 10, 2017 5:48 PM

It's that time again.  Firmware friday!  This week it's Atari 7800.   

 

Awesome, excited to check this one out.  I never spent much time with the 7800 back in the day due to its relative release date so close to the NES.  So most of the original titles for the system are pretty much unknown to me.    



#1911 phoenixdownita OFFLINE  

phoenixdownita

    River Patroller

  • 2,413 posts

Posted Fri Mar 10, 2017 5:53 PM

To all the people new to the 7800 pay attention that the audio is pretty abrasive, before complaining with kevtris make sure to find a youtube video of the game you're playing and compare.

Especially grating are the DK and Mario titles among the rest. TIA at its best .... NOT!!!



#1912 kevtris OFFLINE  

kevtris

    Moonsweeper

  • Topic Starter
  • 370 posts
  • FPGA Whisperer
  • Location:Flyover, USA

Posted Fri Mar 10, 2017 6:12 PM

quick note: be sure your 7800 ROMs have the 128 byte header on them.  It appears the files at atari7800.org do not have the headers, so running them will cause the BIOS to throw you into 2600 mode which has no TIA graphics, so you might hear a TIA grumble from the audio, but a black screen otherwise.   This will be evident because there won't be the usual atari rainbow while it does the crypto check.

 

The files here on atariage appear to have the headers, however.   Another clue is you want files that have .a78 and not .bin extensions.



#1913 elmer OFFLINE  

elmer

    Chopper Commander

  • 117 posts

Posted Fri Mar 10, 2017 7:42 PM

And the contents of a CD doesn't fit onto an SD card? If one can't play the real thing, then perhaps reading the CD data from the SD card could be a good compromise?


IMHO, reading the CD data from SD card would be the only sane solution.

The main point is to remove the need for fully-working original hardware, and that includes all of those pieces of spinning-plastic that have become scratched over the decades.

The entire PC-CD library (and most others) is available on sites-that-should-not-be-named as perfect bin/cue rips.

Anyone that wants to can rip their own PCE-CDs, and compare the results against a database of known-good copies.

 

Low level CD-ROM access is a huge pain to emulate, even in software emulators, and it's often why you're forced to rip the disc instead, but when you rip the disc, you typically lose access to the redbook audio. Even cd-emulators tend not to emulate redbook audio, even if the image has it.


Really???

I've been working on game translations for the last couple of years, and Mednafen seems to have absolutely no problem emulating and playing CD audio from a .bin file, and it even did a great job of matching 5th-generation video-playback limits when I tested it against real-hardware.

 

In the case of the PCE, I think the cd-rom is just a regular off-the-shelf NEC SCSI drive, and the expansion interface board is just a bridge+sram.


Basically, yes, but with a few important wrinkles, like the ADPCM subsystem.

As a first generation SCSI CD-ROM drive, there are a few proprietary undocmented SCSI commands that it responds to.

Nothing that Kevtris couldn't figure out, especially since open-source software emulators already exist to use as reference for the commands themselves.

 

The SegaCD likewise appears to use off-the-shelf Sony cd-rom units and JVC manufactured units using the same Sony IC's, except the entire "segacd" unit is the interface and bridge board.


IMHO the problem with the SegaCD would be less with the CD unit, and more with the fact that it's a totally different 4.5th-generation SuperAmiga-type computer that runs in parallel to the base MegaDrive, and just DMAs data to the MegaDrive's VDC for actual display ... while the original MegaDrive can still access the VDC to add some of its own work to the mix.

It's one of the first multiprocessing systems that developers had to deal with, and one heck of a kludge of a design.

 

One can always ask for an Nt Mini ++ with a 5CEA9 at 301K LE and 12Mbit of block RAM (that's > 1MBytes) for just 350$ extra (that's the full price of the FPGA)
If memory serves aside SFII (2MBytes) all PCE card games are <= 512KBytes .... and can fit ..... just saying.


PCE HuCards go up to 1MB (except for the bank-switched SFII with 2.5MB).

PCE ArcadeCard games allow for 2.25MB of RAM.

There's probably no need for more block RAM (even with the 128KB video memory on the SuperGrafx and the 64KB of ADPCM RAM, and, say another 32KB for CD read-ahead).

I suspect that Kevtris has already hit upon the solution for the PCE's fast memory access speed ... it may only a real issue on instruction reads (1..7 consecutive bytes).

AFAIK, the minimum non-consecutive memory accesses would be the 3-cycle PHA/PHX/PXY instructions, with a 1-byte read, and 1-byte write all in 3 cycles ... followed by the next instruction read.

But ... at the end of the day ... everyone here is benefiting from Kevtris's personal-passion-and-drive in creating these things for fun. He's put far more time-and-effort into these than anyone could even expect from a fully-paid-employee.

He can choose what he wants to work on, and the rest of us are just along for the ride, and enjoying the wonderful results.

#1914 genfuyung ONLINE  

genfuyung

    Space Invader

  • 37 posts

Posted Fri Mar 10, 2017 7:55 PM

Wish I could figure out where you guys are finding gamemate and gameking games...



#1915 rezb1t ONLINE  

rezb1t

    Star Raider

  • 53 posts

Posted Fri Mar 10, 2017 8:14 PM

 

Think my problems are more like your, retrogamingcables seems to have fixed their issues. Mine is connected like above mentioned. And it seems like its the red that is missing from tje rgb signal Its not flickering like in the youtube clip.. Contacted Analogue and they said they only supported cables from monoprice.

 

Strange since I followed a Analogue tweet how to get cables..

 

which cable from monoprice should work,? rgb to euroscart.

I used the BNC 5 connector with a friend's Sony pvm to check rgb, analogue has it listed here: https://support.anal...ith-the-Nt-mini

 

Weird though, they also recommend retrogamingcables on the same page..



#1916 Fafner OFFLINE  

Fafner

    Space Invader

  • 41 posts

Posted Fri Mar 10, 2017 8:26 PM

7800 is worth having just for Basketbrawl and Ninja Golf!

#1917 cfillak OFFLINE  

cfillak

    Combat Commando

  • 7 posts

Posted Fri Mar 10, 2017 8:57 PM

Wish I could figure out where you guys are finding gamemate and gameking games...

PM me



#1918 Kosmic Stardust OFFLINE  

Kosmic Stardust

    Princess Rescuer

  • 13,181 posts
  • Location:Milky Way Galaxy

Posted Fri Mar 10, 2017 8:59 PM

 

I think the limitation was actually the size of the FPGA, because a smaller FPGA would require PSRAM/SRAM and not just DRAM to make up for the lack of block memory. Hence bandwidth comes into play.

 

Like if you physically look at a SNES and the PCE, they sometimes use the exact same PSRAM. https://console5.com...Kb:_32K_x_8-bit

But the PCe bus was clocked twice as fast as the SNES bus.



#1919 Kismet OFFLINE  

Kismet

    Star Raider

  • 83 posts

Posted Fri Mar 10, 2017 9:03 PM

Really???

I've been working on game translations for the last couple of years, and Mednafen seems to have absolutely no problem emulating and playing CD audio from a .bin file, and it even did a great job of matching 5th-generation video-playback limits when I tested it against real-hardware.

 

 

Virtual CD-reading is kludgey, redbook audio can be off by entire seconds, and this goes back to the entire issue about timing. The software may say "Seek to track X" which is fine, but if it wants to seek to an exact minute-second, to sync with animation, it may miss the mark, especially if the disc image compressed the audio. Games that use the cd redbook audio for speech may miss the mark if it can't cache the entire disc image to memory.

 

There are Windows "cd emulators" that will not play redbook audio, and then there is DOSBOX where the problem I mentioned above exists too.

 

Most software emulators that let you use a disc image don't actually emulate the cd-drive, they translate the commands, thus you get a smoother experience. If you actually try to use your real disc drive, the drive tries to read too fast, and thus constantly tries to re-seek.

 

Anyways, my point was that FPGA systems try to emulate all the exact hardware, and I think this might be something that works against it, since you can't exactly buy a "bare" CD unit with no PCB in order to emulate the exact mechanics of a 1X or 2X CD drive. The choice comes down to either emulating the drive, and using something like a ramdisk in it's place, or listening to the expansion bus and trying to map that to physical blocks on a SD-card, which then relies on the characteristics of the SD card.


Edited by Kismet, Fri Mar 10, 2017 9:04 PM.


#1920 Pixelboy OFFLINE  

Pixelboy

    Quadrunner

  • 7,479 posts
  • Location:Montreal, Canada

Posted Fri Mar 10, 2017 9:33 PM

Anyways, my point was that FPGA systems try to emulate all the exact hardware, and I think this might be something that works against it, since you can't exactly buy a "bare" CD unit with no PCB in order to emulate the exact mechanics of a 1X or 2X CD drive. The choice comes down to either emulating the drive, and using something like a ramdisk in it's place, or listening to the expansion bus and trying to map that to physical blocks on a SD-card, which then relies on the characteristics of the SD card.


Seems like this would require an FPGA console specialized in CD-based gaming, with a large RAM disk integrated into the motherboard that would contain an entire CD. Then the FPGA core would read off the RAM disk at the required speed. This would certainly be an expensive FPGA console...

#1921 kevtris OFFLINE  

kevtris

    Moonsweeper

  • Topic Starter
  • 370 posts
  • FPGA Whisperer
  • Location:Flyover, USA

Posted Fri Mar 10, 2017 10:09 PM

I don't think I am going to be working on CD anything any time soon, but if I did, it'd be easy to simply spool data off the SD card.  The CD drives were so sloooow.  150K/second for 1x and 300K/second for 2x with access times measured in seconds.  There's plenty of time to get data ready to go from an SD card.  In fact I think there's some CD ROM emulator devices for various systems already that do this.  So there's no reason an FPGA system cannot do it too. 

 

The big problem is as others have said is the huge amount of work/stuff needed for say sega CD.  The CD based system I would do first most likely though would be the playstation 1 since it looks fairly straight forward and it isn't clocked excessively fast.

 

Before that though, I have a whole freight train of systems that would be first in line, like SNES, genesis, tg-16, super a'can and others.  The amount of work for all these is staggering.  I am going to be doing some paid projects in the near future so core development will probably slow down for awhile until those are done, but I hope the 18 or 19 that I release will keep everyone busy for awhile.  lol



#1922 phoenixdownita OFFLINE  

phoenixdownita

    River Patroller

  • 2,413 posts

Posted Fri Mar 10, 2017 10:13 PM

....
PCE HuCards go up to 1MB (except for the bank-switched SFII with 2.5MB).

PCE ArcadeCard games allow for 2.25MB of RAM.
...


PCE ArcadeCard only makes sense paired with a CD, wrt PCE HuCards there's like 15 games (+3 US TG16) > 512K (excluding the 6 SGX and SFII that as you said is 2.5MB).
I was just throwing in the "NEED" for a bigger FPGA hence an NT mini ++.

I don't think 300K LEs are warranted, but hey ... if money is not really an issue replacing a 60US$ part (5CEA2) for a 350US$ part (5CEA9) should be no brainer .... what do you say keatah?

 

EDIT:

12Mbits of block ram (5CEA9) is 1.5MB so aside SFII everything else will fit and leave 512K for mainRAM/videoRAM (there's plenty for the SGX). Obviously one could go cheaper and use an 8/16MB PSRAM (Cellular RAM) but at that point but it'll require a new motherboard.



#1923 Kosmic Stardust OFFLINE  

Kosmic Stardust

    Princess Rescuer

  • 13,181 posts
  • Location:Milky Way Galaxy

Posted Fri Mar 10, 2017 10:15 PM

It's that time again.  Firmware friday!  This week it's Atari 7800.   I made a lot of internal changes so I hope nothing broke.   This was required, because the 7800 can output 320 pixels across, while my scalers and video pipeline were limited to 256 before.  This has been rectified for the future so stuff like C64 will be scale-able now.

Nice. How do games like Tower Toppler perform? These games required Chroma blending for color rendition. I'm not sure if they would appear correct on any output higher than composite.

 

Also 320 divides evenly into 960 and 1280 pixels, so 3x3 pixel mode in 720p would make a perfect 4:3 aspect screen size.



#1924 phoenixdownita OFFLINE  

phoenixdownita

    River Patroller

  • 2,413 posts

Posted Fri Mar 10, 2017 10:28 PM

Nice. How do games like Tower Toppler perform? These games required Chroma blending for color rendition. I'm not sure if they would appear correct on any output higher than composite.

...


Funny I just posted something about Tower Toppler here

...
Tower Toppler on 7800 DOES NOT LOOK LIKE THIS
 
Tower_Toppler_1.png
 
....
This video at around 47 secs shows what it should look like:
 


Somehow I sense HDMI would look like 1 above while composite like 2, SVideo/RGB have to look also like 1.
Let's not forget the Nt Mini has all the outputs (take that MK and Carlsen "Power goes in, Video comes out" guy aka "we can use a std Genny 2 AV connector and video cables for all analog signals"-except-you-can't)



#1925 kevtris OFFLINE  

kevtris

    Moonsweeper

  • Topic Starter
  • 370 posts
  • FPGA Whisperer
  • Location:Flyover, USA

Posted Fri Mar 10, 2017 10:48 PM

Nice. How do games like Tower Toppler perform? These games required Chroma blending for color rendition. I'm not sure if they would appear correct on any output higher than composite.

 

Also 320 divides evenly into 960 and 1280 pixels, so 3x3 pixel mode in 720p would make a perfect 4:3 aspect screen size.

That's right, it doesn't unless you use the analog outputs.  I don't know why they chose to make the game this way unless it was a bug.  I thought there was a bug in my implementation for awhile until I watched some youtube videos, then realized that nope that is how it is supposed to look.  even with composite it's still kinda ugly.  jinx is another game that does this too, but only on the title screen.







Also tagged with one or more of these keywords: FPGA

10 user(s) are browsing this forum

3 members, 7 guests, 0 anonymous users