FPGA Based Videogame System

[atmn]

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/gamespite/status/839902281772466176

 

 

 

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 March 10, 2017 by atmn

[TheRedEye]

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:

[kevtris]

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.

[kevtris]

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.

[kevtris]

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.org/blogfiles/ntm_firmware_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.

[Fafner]

Oops

Edited March 10, 2017 by Fafner

[Fafner]

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.org/blogfiles/ntm_firmware_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!

[Radfoo]

 

 

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.

[roaringchicken]

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.

[phoenixdownita]

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!!!

[kevtris]

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.

[elmer]

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.

[genfuyung]

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

[rezb1t]

 

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.analogue.co/hc/en-us/articles/115000923948-Using-Analog-Video-output-with-the-Nt-mini

 

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

[Fafner]

7800 is worth having just for Basketbrawl and Ninja Golf!

[cfillak]

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

PM me

[Andromeda Stardust]

 

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/wiki/SRAM_256Kb:_32K_x_8-bit

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

[Kismet]

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 March 11, 2017 by Kismet

[Pixelboy]

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...

[kevtris]

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

[phoenixdownita]

....

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.

[Andromeda Stardust]

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.

[phoenixdownita]

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

 

 

....

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)

[kevtris]

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.

[phoenixdownita]

Question to kevtris.

Does the CV core also encompass the Super Game Module? (32K RAM + AY-3-8910)