FPGA Based Videogame System

[Andromeda Stardust]

What's the input lag for a CRT? Is it the same for all CRTs or does it vary?

Zero. The input signal is amplified by the electronics and it becomes the beam hitting the phosphors as it strobes across the screen. If any processing delay exists, it is microsends not milliseconds. The only exception is the few HD CRTs manufactured at the end of life cycle for tube telivisions. They didn't work with lightguns as they upscaled 480i/240p to 1080i, but generally handled analog signals better than newer sets, and still had gorgeous display and fairly low latency compared to early flat panels.

[Andromeda Stardust]

you must not own a console post 2007 then. ultra wide is perfect for the switch.

 

looks like the asus I referenced is a "TN" model, the colors do look really nice particularly on the switch but I can see how they leave a little to be desired. input/output lag is priority #1 for me though.

 

the 1ms response time is indeed grey to grey, need to just test it with 2 monitors in 240p test suite i guess.

I don't know of any current gaming console besides PC that supports 64:27 displays (21:9 is an annoying misnomer since the actual resolution is 2560x1080). The console will output 1920x1080p and the display will either pillarbox it or stretch it. 4:3 or 64:27 screens can cause modern PC games to either crop or pad the display output resulting in stuff that should not display to be rendered or stuff that should display to get cropped. It was a big issue with older games which were designed for 4:3 ratios like 1600x1200, and now we are experiencing it again with these bastardized resolutions. Even many Bluray Players do not yet have the option to crop the black bars on ultra wide movies to take full advantage of the screen. You'll either get stretching or window boxing. So recommending an ultrawide display for gaming purposes is IMO a bad idea at this time, until they get widespread support.

[Tusecsy]

I don't know of any current gaming console besides PC that supports 64:27 displays (21:9 is an annoying misnomer since the actual resolution is 2560x1080). The console will output 1920x1080p and the display will either pillarbox it or stretch it. 4:3 or 64:27 screens can cause modern PC games to either crop or pad the display output resulting in stuff that should not display to be rendered or stuff that should display to get cropped. It was a big issue with older games which were designed for 4:3 ratios like 1600x1200, and now we are experiencing it again with these bastardized resolutions. Even many Bluray Players do not yet have the option to crop the black bars on ultra wide movies to take full advantage of the screen. You'll either get stretching or window boxing. So recommending an ultrawide display for gaming purposes is IMO a bad idea at this time, until they get widespread support

 

hmm thats interesting. this is the first monitor i've bought in about 12 years so didn't know about all this. I actually thought this was 16:9 (said so on the box), guess i'll just switch out one of my ancient 4:3 pc monitors. why do these monitors say 16:9 then? confusing.

 

what's the best true 16:9 low latency monitor out there these days for 200 or under?

Edited July 22, 2017 by Tusecsy

[Andromeda Stardust]

hmm thats interesting. this is the first monitor i've bought in about 12 years so didn't know about all this. I actually thought this was 16:9 (said so on the box), guess i'll just switch out one of my ancient 4:3 pc monitors. why do these monitors say 16:9 then? confusing.

 

what's the best true 16:9 low latency monitor out there these days for 200 or under?

I have no idea. I was in Walmart the other day; they had a 24" monitor on sale for $199. Then I looked closer and it was the horrible ultrawide type which is currently useless for gaming.

 

The monitor I referenced is 16:9. Don't really know what you're going on about.

ultra wide is perfect for the switch.

You were the one who mentioned "ultrawide". AFAIK, most current "ultrawide" monitors are 2560x1080. No game console I know of currently on the market has built in support for this aspect ratio.

[Tusecsy]

I have no idea. I was in Walmart the other day; they had a 24" monitor on sale for $199. Then I looked closer and it was the horrible ultrawide type which is currently useless for gaming.

 

You were the one who mentioned "ultrawide". AFAIK, most current "ultrawide" monitors are 2560x1080. No game console I know of currently on the market has built in support for this aspect ratio.

 

I literally just said I was misinformed. The box and product description say 16:9. You don't know which monitor is good? I thought you said you had one....

Edited July 22, 2017 by Tusecsy

[Great Hierophant]

The everdrive is super duper flaky and was extremely hard to get working. It isn't just flash cartridges; the powerpak works great always in contrast. The ED doesn't even work on some famicoms. The timing on it is very critical and it is barely on the edge of working. If the NES/fami one is this bad, I dunno what to expect on the other models. The ED is basically nightmare fuel for me. Sorry, but IMO it's pretty crappy. I have probably spent 3-4 weeks of my life trying to get it to play nice with the hi def and NT mini where literally everything else worked fine, and the stuff looked the same on the oscilloscope.

I believe Krikzz stated that he pushed the timings of the chips in the EverDrive hard to maximize the loading speeds from the SD card. Bunnyboy used Compact Flash for his NES PowerPak because the transfer speeds were better with the parallel bus of the CF cards. Do you think the optimizations Krikzz used for the SD-card loading on EverDrive N8 were part of the reasons you experienced so much difficulty getting the design to work with the Nt Mini?

 

If I have to wait for the Z3K to experience a Kevtris flash cart at more affordable prices, I am content to wait.

Edited July 22, 2017 by Great Hierophant

[Tusecsy]

nevermind I was confusing "ultra-wide" and "true HD" for some reason, the monitor I referenced is indeed 16x9 I believe. sorry to clutter up this thread i'll stop now.

[Andromeda Stardust]

nevermind I was confusing "ultra-wide" and "true HD" for some reason, the monitor I referenced is indeed 16x9 I believe. sorry to clutter up this thread i'll stop now.

No worries. I contributed to it as well. It's only like the 20th time the thread has derailed into the merits of CRT displays and or lag in flat panels.

[kevtris]

I believe Krikzz stated that he pushed the timings of the chips in the EverDrive hard to maximize the loading speeds from the SD card. Bunnyboy used Compact Flash for his NES PowerPak because the transfer speeds were better with the parallel bus of the CF cards. Do you think the optimizations Krikzz used for the SD-card loading on EverDrive N8 were part of the reasons you experienced so much difficulty getting the design to work with the Nt Mini?

 

If I have to wait for the Z3K to experience a Kevtris flash cart at more affordable prices, I am content to wait.

No it was timing of the mapper code. I never had a problem with the SD card part. It wasn't every mapper, either, just certain ones. The way I had to slow the clock down slightly to make the NES match timing with the HDMI also threw it through a loop. I have to steal clocks so it really didn't like this and I had to do some insane stuff to get it working. Interestingly no other carts had problems with this.

[Great Hierophant]

No it was timing of the mapper code. I never had a problem with the SD card part. It wasn't every mapper, either, just certain ones. The way I had to slow the clock down slightly to make the NES match timing with the HDMI also threw it through a loop. I have to steal clocks so it really didn't like this and I had to do some insane stuff to get it working. Interestingly no other carts had problems with this.

There was a complaint regarding Necronomfive's VRC7 FM audio mappers not working in the AVS. Bunnyboy indicated that the mapper's timing was likely the issue :

 

 

 

"VRC7 is likely the same problem that the initial everdrive mappers had and must be fixed on that end. They were using poor FPGA design which couldn't handle the variable clock needed for HDMI systems. Changing the bus timing to fix one version would break another. That is why it changed with every beta firmware."

 

Original source : http://krikzz.com/forum/index.php?topic=3374.msg51433#msg51433

 

Of the systems/cores the Nt Mini unofficially supports, Krikzz's EverDrive GB, EverDrive-GG and Master EverDrive could also feasibly work in the Nt Mini. I'm not sure there is really any reason to use one of these when there is a built-in flash cart function that can run everything they can run, but I wonder if you tried using them with your cartridge adapters.

[retrorgb]

Are the controller and cartridge adapters still planned to be sold?

[Andromeda Stardust]

No it was timing of the mapper code. I never had a problem with the SD card part. It wasn't every mapper, either, just certain ones. The way I had to slow the clock down slightly to make the NES match timing with the HDMI also threw it through a loop. I have to steal clocks so it really didn't like this and I had to do some insane stuff to get it working. Interestingly no other carts had problems with this.

 

 

There was a complaint regarding Necronomfive's VRC7 FM audio mappers not working in the AVS. Bunnyboy indicated that the mapper's timing was likely the issue :

 

 

Original source : http://krikzz.com/forum/index.php?topic=3374.msg51433#msg51433

 

Of the systems/cores the Nt Mini unofficially supports, Krikzz's EverDrive GB, EverDrive-GG and Master EverDrive could also feasibly work in the Nt Mini. I'm not sure there is really any reason to use one of these when there is a built-in flash cart function that can run everything they can run, but I wonder if you tried using them with your cartridge adapters.

So slowing down the NES clock by a tenth of a percent was enough to bork the Everdrive? Does the Everdrive not read from the system clock signal located on the cart bus for relevant timings? Any mapper that syncs with the system clock should have no issue with this.

 

Also the PAL system is slower than NTSC, but Everdrives work on PAL too, and the difference in clock speed to NTSC is a lot more than .1%.

[mr_me]

As the same console is used for both tests input lag should be irrelevant because it remained constant constant in both tests.

One test measured the controller button to the console, out of the component video port to a crt.

The second test measured the controller button to the console, out of the component video port, to a wii2hdmi converter, to a (most likely) tn panel.

So from the console's component output port to a digital display through a converter resulted in minor enough difference in lag to still be the same frame as going directly to a crt.

 

In other words... whatever distinction you're trying to make is irrelevant.

That video showing the console/controller lag on a crt brings up a question. How would the lag compare between different emulation and fpga systems. For example, keeping the display the same (eg. CRT) compare lag between a real NES, an FPGA NES, and a software emulation NES. I would like to think the real NES and FPGA NES would be the same but it would be nice to see actual test results.

[kevtris]

Are the controller and cartridge adapters still planned to be sold?

 

Yes I think so... but I haven't touched them in awhile due to being too busy.

 

 

 

 

So slowing down the NES clock by a tenth of a percent was enough to bork the Everdrive? Does the Everdrive not read from the system clock signal located on the cart bus for relevant timings? Any mapper that syncs with the system clock should have no issue with this.

 

Also the PAL system is slower than NTSC, but Everdrives work on PAL too, and the difference in clock speed to NTSC is a lot more than .1%.

 

It's because I remove a clock periodically to keep the timing. For some reason, the ED hates this, even though it shouldn't matter. Nothing else seemed to care except the FDS. The FDS had a panic and would emit FF's instead of data bytes periodically, causing crashes. The fix I did seemed to make both work though. It's a very delicate balancing act.

 

That video showing the console/controller lag on a crt brings up a question. How would the lag compare between different emulation and fpga systems. For example, keeping the display the same (eg. CRT) compare lag between a real NES, an FPGA NES, and a software emulation NES. I would like to think the real NES and FPGA NES would be the same but it would be nice to see actual test results.

 

There should be zero difference between the FPGA and real NES on a CRT... except maybe a few clocks worth of pixel delay. i.e. a few hundred ns, because the FPGA's video pipeline is a lot longer than the real NES', but we're talking a few pixels of delay.

 

Software emulation is at the mercy of the OS it's running on, and the controllers connected to it (i.e. USB) and the drivers and translation needed to decode it, and the frame rate isn't going to be the exact rate, it will probably be a standard one like 60.0Hz or 59.97Hz or something.

[Andromeda Stardust]

It's because I remove a clock periodically to keep the timing. For some reason, the ED hates this, even though it shouldn't matter. Nothing else seemed to care except the FDS. The FDS had a panic and would emit FF's instead of data bytes periodically, causing crashes. The fix I did seemed to make both work though. It's a very delicate balancing act.

So instead of fractionally slowing the pulse by a tenth of a percent, the "heart" merely "skips a beat" every now and then to keep pace. That makes sense I guess.

 

There should be zero difference between the FPGA and real NES on a CRT... except maybe a few clocks worth of pixel delay. i.e. a few hundred ns, because the FPGA's video pipeline is a lot longer than the real NES', but we're talking a few pixels of delay.

Will these few pixels delay change the horizontal position of the Zapper detection enough to cause a miss in certain situations?

[Great Hierophant]

Yes I think so... but I haven't touched them in awhile due to being too busy.

 

It's because I remove a clock periodically to keep the timing. For some reason, the ED hates this, even though it shouldn't matter. Nothing else seemed to care except the FDS. The FDS had a panic and would emit FF's instead of data bytes periodically, causing crashes. The fix I did seemed to make both work though. It's a very delicate balancing act.

 

Apparently the FDS RAM Adapter is something of a problem prone device. Many of the early DRAM based RAM Adapters are now requiring 4.7KOhm pull down resistors to be soldered onto the data pins to keep sprites from glitching. Apparently it is an aging thing with the hardware, SRAM based RAM Adapters do not require this : http://www.famicomworld.com/forum/index.php?topic=10607.45

[Andromeda Stardust]

I believe Krikzz stated that he pushed the timings of the chips in the EverDrive hard to maximize the loading speeds from the SD card. Bunnyboy used Compact Flash for his NES PowerPak because the transfer speeds were better with the parallel bus of the CF cards. Do you think the optimizations Krikzz used for the SD-card loading on EverDrive N8 were part of the reasons you experienced so much difficulty getting the design to work with the Nt Mini?

 

If I have to wait for the Z3K to experience a Kevtris flash cart at more affordable prices, I am content to wait.

Powerpak uses parallel flash. Everdrives use some sort of series/parallel circuit to speed up reads. In essence, the serial data on the SD card is being accessed at much higher speed than the console bus, then data is saved to parallel RAM for access by the console. With the Powerpak, the NES bus controls the Compact flash access so the parallel data is written to the internal parallel RAM and NES bus speed. Because the Everdrive streams serial data off the SD card more than 8x faster than the NES bus, it appears to load data faster than the PowerPak.

 

For the record, Powerpak came out in 2009. Everdrive N8 came out in 2013. A lot of technology has advanced between the release of the PowerPak and the Everdrives, hence fast loading from serial SD cards became possible. Using the same tech the PowerPak employed, it would take 8 times longer to stream data from an SD card using the clocks from the NES bus, compared to Parallel compact flash.

 

Also PowerPak still has NSF playback and superior expansion audio for most mappers compared to the Everdrive, but the Everdrive has better support for save files like autosave, etc. There are merits to owning both and I am glad to have them in my arsenal, the NES PowerPak and the Famicom Everdrive. Mine was the original launch Everdrive with gold finish and serial #007.

[Great Hierophant]

Powerpak uses parallel flash. Everdrives use some sort of series/parallel circuit to speed up reads. In essence, the serial data on the SD card is being accessed at much higher speed than the console bus, then data is saved to parallel RAM for access by the console. With the Powerpak, the NES bus controls the Compact flash access so the parallel data is written to the internal parallel RAM and NES bus speed. Because the Everdrive streams serial data off the SD card more than 8x faster than the NES bus, it appears to load data faster than the PowerPak.

 

For the record, Powerpak came out in 2009. Everdrive N8 came out in 2013. A lot of technology has advanced between the release of the PowerPak and the Everdrives, hence fast loading from serial SD cards became possible. Using the same tech the PowerPak employed, it would take 8 times longer to stream data from an SD card using the clocks from the NES bus, compared to Parallel compact flash.

 

Also PowerPak still has NSF playback and superior expansion audio for most mappers compared to the Everdrive, but the Everdrive has better support for save files like autosave, etc. There are merits to owning both and I am glad to have them in my arsenal, the NES PowerPak and the Famicom Everdrive. Mine was the original launch Everdrive with gold finish and serial #007.

 

I have both and never did an A to B loading comparison, but the loading times of the PowerPak are not substantially longer than the EverDrive. I note that the EverDrive appears to have an Altera CPLD in addition to an Altera FPGA, perhaps the former is used for the serial SD card transferring.

 

The NES PowerPak came out on June 11, 2007 and I bought one of the first ones. I don't recall if I got a serial number, there are none on my cart. Mine is a rev. C board and I had to send it back for the resistor pak fix. I know that there are at least rev. E boards out there.

[kevtris]

So instead of fractionally slowing the pulse by a tenth of a percent, the "heart" merely "skips a beat" every now and then to keep pace. That makes sense I guess.

 

Will these few pixels delay change the horizontal position of the Zapper detection enough to cause a miss in certain situations?

Well this only happens on HDMI. In any analog mode it runs at the exact NES frequency, to less than 1Hz accuracy. I would've loved to subtly slowed the system down to match, but unfortunately this is outside the capability of today's FPGAs. I mean, I *can* slow the system down the exact amount with the PLL, but there will be long-term drift over time I cannot compensate for. i.e. it would run open loop. I still have to steal cycles at some point to make things stay together I think. HDMI is extremely unforgiving of these types of things, so you usually can't steal/add cycles in the HDMI video or else the monitors will lose synch and try to reacquire. They generally require very rigid timing frame over frame to function right. So that leaves all the time correction to the NES side.

 

Getting that stuff to work at all was a huge task and I spent many hours on the problem.

 

 

 

Apparently the FDS RAM Adapter is something of a problem prone device. Many of the early DRAM based RAM Adapters are now requiring 4.7KOhm pull down resistors to be soldered onto the data pins to keep sprites from glitching. Apparently it is an aging thing with the hardware, SRAM based RAM Adapters do not require this : http://www.famicomworld.com/forum/index.php?topic=10607.45

 

That's pretty interesting. I guess it was kind of on the edge of working even back in the day. Maybe the timing of the FDS RAM pack is designed for the no rev CPU? The FDS was sold up until what, 87 or so? I think the E rev parts started coming out around then or a bit later. So it's possible it was designed for the no rev and/or E rev CPU models and it doesn't work too hot on a G rev. Wild ass theory, but wonder if this contributed to them cancelling it, along with the other reasons like piracy and the fact that 32K of RAM just wasn't enough for games any more.

 

The no rev CPU has vastly different timing behavior from the E and up revs of the CPU. (AFAIK there's no A-D revs of the CPU- it seems to jump from no rev to E rev). I do have A, B, C, E, G, H revs of PPU though. and blank, E, G, H revs of CPU. I suspect there is a no rev PPU as well, but this was the defective PPUs that were in the recalled systems. So far I have never seen one.

[Great Hierophant]

That's pretty interesting. I guess it was kind of on the edge of working even back in the day. Maybe the timing of the FDS RAM pack is designed for the no rev CPU? The FDS was sold up until what, 87 or so? I think the E rev parts started coming out around then or a bit later. So it's possible it was designed for the no rev and/or E rev CPU models and it doesn't work too hot on a G rev. Wild ass theory, but wonder if this contributed to them cancelling it, along with the other reasons like piracy and the fact that 32K of RAM just wasn't enough for games any more.

 

The no rev CPU has vastly different timing behavior from the E and up revs of the CPU. (AFAIK there's no A-D revs of the CPU- it seems to jump from no rev to E rev). I do have A, B, C, E, G, H revs of PPU though. and blank, E, G, H revs of CPU. I suspect there is a no rev PPU as well, but this was the defective PPUs that were in the recalled systems. So far I have never seen one.

 

I have read a comment that the rev A PPUs were the ones that caused the freeze bug, and it wasn't until HVC-CPU-05 that you could rely on getting a fixed PCB. You are missing a D rev PPU, but there does not seem to be any rev F CPU or PPUs or A-D CPUs floating around. The only board pics of a HVC-CPU board without a revision number show rev A PPUs.

 

The FDS was released on February 21, 1986 and was being manufactured until at least 1988. By 1989 even Nintendo got the memo that the Disk System was not the future, but official games were still being made for the unit until mid 1992. The release of SMB3 on October 23, 1988 seems to be the unofficial abandonment of the FDS. Given that it was probably in development for the six-to-nine months preceding its release date, it could have been targeted to the revisionless CPU. Nntendo seems to have transitioned to the rev E CPU sometime in late 1984. The relatively solid E CPU seems to have been its mainstay for quite a while, it appears most often in the pre-VCI/GPM Famicoms and is also quite common on the Twin Famicom and can be found in early front loaders. I have also read a comment that some Japanese users stated that their FDS RAM Adapters degraded and did not originally show sprite glitches.

[bikerspade]

How many FDS RAM adapters typically have issues with the FDSStick on the NT Mini? Any suggestions for purchasing them (anything specific to look out for)?

[Eicar]

I'm wondering about this as well. I've just gotten the FDSStick and I'm going to buy the RAM adapter. Is it just plain old hit and miss, or should I look for something special? I know that the actual FDS drives comes with different controller chips (3206 and 7201), do the RAM adapters differs as well?

[Wolf_]

It occurs to me that Kev is almost certainly working on a fpga for someone because if he wasn't he probably would have said so by now and been like "guys, it isn't happening right now, move along", BUT if he was working on one and they had him sign a Non-Disclosure Agreement then he couldn't say he was working on one.

So imo if he was bound by an nda (or just asked to keep it under wraps) that is the only time he would be working on a fpga and not talk about it AND also not tell us to move along when we theorized about it for like 30 posts.

So in my mind I'm thinking the odds he is working on a fpga for someone is nearly 100%. If that is Analogue or RetroArch or some other company though is up for debate. I will say that Analogue seems like they would have ndas as a standard business practice but other popular choices for hiring Kev I would view as less likely to be that professional.

[ccovell]

I'm wondering about this as well. I've just gotten the FDSStick and I'm going to buy the RAM adapter. Is it just plain old hit and miss, or should I look for something special? I know that the actual FDS drives comes with different controller chips (3206 and 7201), do the RAM adapters differs as well?

 

I think it is hit and miss. I have 2 FDS RAM adaptors, HVC-02, and HVC-FMR-04 (one with SRAM and one with DRAM) and both of them crash early during disk loading, no matter whether it's from a real disk or FDSStick. Looks like it might be a lack of filtering for the IRQ line in the NT mini... (Let's hope you are lucky.)

[cacophony]

It occurs to me that Kev is almost certainly working on a fpga for someone because if he wasn't he probably would have said so by now and been like "guys, it isn't happening right now, move along", BUT if he was working on one and they had him sign a Non-Disclosure Agreement then he couldn't say he was working on one.

 

So imo if he was bound by an nda (or just asked to keep it under wraps) that is the only time he would be working on a fpga and not talk about it AND also not tell us to move along when we theorized about it for like 30 posts.

 

So in my mind I'm thinking the odds he is working on a fpga for someone is nearly 100%. If that is Analogue or RetroArch or some other company though is up for debate. I will say that Analogue seems like they would have ndas as a standard business practice but other popular choices for hiring Kev I would view as less likely to be that professional.

 

I 100% agree with the first two sections of your post.

 

But I think the chances that he's working on something for Libretro (makers of RetroArch, etc) are close to zero. He has a long working relationship with Analogue and the timing of this work fits perfectly with Analogue's development cycle. Plus, Libretro wouldn't have a reason to require an NDA (they don't sell anything) nor would they likely have the funds to hire kevtris (their patreon page is only making $1084/month and that money goes to other purposes*).

 

* "All this costs money, especially the servers used for the libretro buildbot and the one used to build Lakka. This is why we need your help."

Edited July 29, 2017 by cacophony