FPGA Based Videogame System

[rezb1t]

 

Thanks, do you know if it does RGB in Full Range or Limited Range?

Oops, just realized I misread your question. It displays in full range RGB

Edited February 11, 2018 by rezb1t

[Andromeda Stardust]

Whoa, UPS is deciding to deliver to me today. I am not sure I've ever had UPS ground delivery on Saturday.

I wish I had this problem LOL. My Super NT arrived in Shreveport this morning at 3am, but it looks like it's going to sit in the warehouse until Tuesday. Could they not deliver it a day in advance on Monday instead? I work 8-5 and have dates planned Tuesday and Wednessday with my significant other, which means it will be at least Thursday before I get to play with it. #1stworldproblems

[Andromeda Stardust]

That is an excellent idea, but the menu won't let you save an invalid combination or a single button as a hotkey. It will allow you to set either Up or Down and either Left or Right with Select, Star, B and/or A, so you can get a combination you are unlikely to press with three to six buttons required to trigger the reset.

I was thinking about this one and A/B/X/Y/St/Se for reset is about damn near impossible to press by accident. You need to move your left thumb completely off the Dpad to register Start +Select. It's a slightly better solution than LRABXY because I tend to do that sometimes almost as a reflex when I rage quit a game. Then again the "rage quit" position of the entire diamond plus the triggers might be perfect for me, though I see myself accidentally hitting them during a heated button mashing SFII match.

 

IIRC, A+B+St+Se is default soft reset in most Gameboy and Turbo / PCe games. Fortunately though, it's disabled when using standard pads in SFII:CE.

[F34R]

I wish I had this problem LOL. My Super NT arrived in Shreveport this morning at 3am, but it looks like it's going to sit in the warehouse until Tuesday. Could they not deliver it a day in advance on Monday instead? I work 8-5 and have dates planned Tuesday and Wednessday with my significant other, which means it will be at least Thursday before I get to play with it. #1stworldproblems

I posted a few posts back about the same thing happening to me before. 4 days, my package sat in a warehouse for UPS, 20 miles from me. They wouldn't deliver it early and wouldn't let me just come pick it up.

[Beer Monkey]

 

Yeah I usually keep it on too. It was very obvious looking at the PVM vs. flat panel during development that the flat panel was too dark.

 

 

I cannot output a 60.09fps hdmi signal if that's what people are asking. I can't lock the two PLLs together (system and video) so it's a non starter. Also, I don't want incompatibility issues with monitors that cause it to not work. i.e. someone turns that mode on, without knowing what it does, then after that, the monitor goes dead and they get no video any more.

 

They are locked together in the unbuffered mode at 60.00hz though? Otherwise I don't understand the unbuffered mode as well as I thought.

 

If the video PLL is locked to 60.00, that I can understand. Is the video PLL an ASIC?

 

Just trying to understand the architecture and its' limitations better.

 

Do all the jailbreak cores on the NT Mini run at 60.00hz? As opposed to 59.92 for 2600, 59.72 for Gameboy, etc.?

[Andromeda Stardust]

I posted a few posts back about the same thing happening to me before. 4 days, my package sat in a warehouse for UPS, 20 miles from me. They wouldn't deliver it early and wouldn't let me just come pick it up.

Yeah that's just being assholish. USPS typically puts it out on the truck six days a week if the package hits the warehouse in time. Sometimes it misses however because our town is a regional hub and it has to go from the regional post office to the neighborhood beanch office before it can go out for delivery. Shipping estimates account for the delay so occasionally they surprise ne by getting the pacjage a day early.

 

But UPS sitting on stuff until scheduled delivery time is annoying. Yeah we got your box but you can't have it yet. I've had stuff sit at the warehouse for 3 days before going out, never happens with USPS. USPS has other issues though. Living in the south, if I get a package in the winter time shipped from California, it typically routes through Ohio. If the weather is nasty, I get snow delays. UPS takes a more direct route through Texas so blizzards, ice, and snow in Ohio or someplace in colder climates is a non-issue.

[cacophony]

Yeah that's just being assholish. USPS typically puts it out on the truck six days a week if the package hits the warehouse in time. Sometimes it misses however because our town is a regional hub and it has to go from the regional post office to the neighborhood beanch office before it can go out for delivery. Shipping estimates account for the delay so occasionally they surprise ne by getting the pacjage a day early.

 

But UPS sitting on stuff until scheduled delivery time is annoying. Yeah we got your box but you can't have it yet. I've had stuff sit at the warehouse for 3 days before going out, never happens with USPS. USPS has other issues though. Living in the south, if I get a package in the winter time shipped from California, it typically routes through Ohio. If the weather is nasty, I get snow delays. UPS takes a more direct route through Texas so blizzards, ice, and snow in Ohio or someplace in colder climates is a non-issue.

 

I've noticed that Amazon does a similar thing with free shipping if you're not a prime member. They'll sit on the item for a week and then when they finally ship it will arrive the next day. All their warehouses and routes are so heavily optimized that the only way they've found to differentiate the shipping levels is to not ship for awhile.

[Kismet]

 

I've noticed that Amazon does a similar thing with free shipping if you're not a prime member. They'll sit on the item for a week and then when they finally ship it will arrive the next day. All their warehouses and routes are so heavily optimized that the only way they've found to differentiate the shipping levels is to not ship for awhile.

 

That's probably just prioritization. Remember that they ship mostly-empty boxes all the time because it better fits the back of a truck.

[cacophony]

 

That's probably just prioritization. Remember that they ship mostly-empty boxes all the time because it better fits the back of a truck.

 

If it was just prioritization then the amount of time would vary, but it always seemed pretty consistent.

[Jagasian]

What video settings for the Super NT do you all prefer? I prefer:

 

- 1080p at 60hz

- no buffering (fraction of a frame timing difference is unnoticeable, I prefer not adding lag)

- no lag mode

- no interpolation (like my edges sharp)

- 5x height, 6x width (my CRTs aspect ratio was not perfect either and I prefer no shimmer with integer scaling)

Edited February 11, 2018 by Jagasian

[RabidWookie]

In a low fps game, like say Starfox running at 15fps, would input lag be more or less detrimental than in a game running at 60fps?

[Andromeda Stardust]

In a low fps game, like say Starfox running at 15fps, would input lag be more or less detrimental than in a game running at 60fps?

Starfox was never meant to run at 60hz. It didn't run at 60hz on original hardware, so why would you expect it to run any different on the super nt? Emulators are so cycle inaccurate they basically perform all the calculations at once then idle until a new frame starts. So Starfox might as well feel like ludicrus speed in an emulator. If you've never played the real hardware version you might be disappointed or pleasantly surprised. I dunno, it's kinda hard game. I can't even beat the first stage on the SNES Classic to unlock Star Fox 2. Perhaps the slowdown on real hardware actually makes it more playable?

[Shadowgate]

What video settings for the Super NT do you all prefer? I prefer:

 

 

- 720p 60hz

- zero delay mode

- interpolation left on

- 8:7. I was using 4:3 for a 16:9 screen but I think I prefer 8:7. I'll dial it in when not feeling lazy.

- Hybrid scanlines with gamma boost with the default 120 thickness.

 

The 1080p settings from the my life in gaming video look good as well.Based on their 20L5 PVM

Width: 1365

Horizontal Position: 38

Height: 1149

Vertical Position: 42

 

I couldn't get scan lines looking right in 1080p no matter what I did and the scan lines made text look like crap. On 720p they look just right and the text comes through perfectly clear.

Edited February 11, 2018 by Shadowgate

[kevtris]

 

They are locked together in the unbuffered mode at 60.00hz though? Otherwise I don't understand the unbuffered mode as well as I thought.

 

If the video PLL is locked to 60.00, that I can understand. Is the video PLL an ASIC?

 

Just trying to understand the architecture and its' limitations better.

 

Do all the jailbreak cores on the NT Mini run at 60.00hz? As opposed to 59.92 for 2600, 59.72 for Gameboy, etc.?

no, the video is all generated internally to the FPGA. There's several PLLs on the FPGA itself, and I am using those to generate the various clocks. There's around 22 clock domains on the design as it stands. The problem is I would need some non-integer N/M ratio to get the right clock for the HDMI stuff from the 21.47Mhz domain. Right now video gets a clock that varies depending on video mode. i.e. it's 148.5Mhz in 1080p mode. There's no easy way to lock the two PLLs together (the one generating 21.47Mhz and the 148.5Mhz one) in the proper ratio to offer 60.09 hdmi.

 

The video always runs at 60.00 fps and it will cause cycle stealing on the snes side to make it stay in synch with the hdmi for the zero delay mode. If you run full/single buffered, the cycle stealing is turned off and is allowed to free run.

[Wolf_]

no, the video is all generated internally to the FPGA. There's several PLLs on the FPGA itself, and I am using those to generate the various clocks. There's around 22 clock domains on the design as it stands. The problem is I would need some non-integer N/M ratio to get the right clock for the HDMI stuff from the 21.47Mhz domain. Right now video gets a clock that varies depending on video mode. i.e. it's 148.5Mhz in 1080p mode. There's no easy way to lock the two PLLs together (the one generating 21.47Mhz and the 148.5Mhz one) in the proper ratio to offer 60.09 hdmi.

 

The video always runs at 60.00 fps and it will cause cycle stealing on the snes side to make it stay in synch with the hdmi for the zero delay mode. If you run full/single buffered, the cycle stealing is turned off and is allowed to free run.

So in basic terms the clock speed will always be adjusted to 60fps regardless of what the native clockspeed was, but all this will change is the playback speed imperceptibly slightly and the only people that could possibly care about that are speedrunners who have two additional modes to pick from to get native clock speeds with their choice of tradeoff between a dropped frame and screen tearing with a single frame of lag?

[leods]

So in basic terms the clock speed will always be adjusted to 60fps regardless of what the native clockspeed was, but all this will change is the playback speed imperceptibly slightly and the only people that could possibly care about that are speedrunners who have two additional modes to pick from to get native clock speeds with their choice of tradeoff between a dropped frame and screen tearing with a single frame of lag?

nope. the zero lag mode slows down the system. The buffered modes run at original clock speeds. Kevin just can't replicate the original out of spec behaviour with HDMI. So it's either the half buffered, that is also basically lag-free, but has tearing, or the "vsync" mode that will drop a frame every so many cycles.

 

No one, including speed runners should be able to perceice the 0,15% slower system. The problem is, if the system is "underclocked", speed runs won't be legal, cause they're tampering with the game. That's why the other modes are required, because they run the system at original speed.

 

What I understand from the half buffered mode is that it writes to the buffer at original speed, but your TV will fetch the buffer at HDMI speeds. So you gettearing from the desync between read and write to the buffer, exactly like a PC game with vsync off. That mode has at worse less than a single frame of lag. If you had an "original" mode with no buffer, running at 60.08hz the end result would be very similar, with the disadvantage it's out of spec.

[Wolf_]

nope. the zero lag mode slows down the system. The buffered modes run at original clock speeds. Kevin just can't replicate the original out of spec behaviour with HDMI. So it's either the half buffered, that is also basically lag-free, but has tearing, or the "vsync" mode that will drop a frame every so many cycles.

 

No one, including speed runners should be able to perceice the 0,15% slower system. The problem is, if the system is "underclocked", speed runs won't be legal, cause they're tampering with the game. That's why the other modes are required, because they run the system at original speed.

 

What I understand from the half buffered mode is that it writes to the buffer at original speed, but your TV will fetch the buffer at HDMI speeds. So you gettearing from the desync between read and write to the buffer, exactly like a PC game with vsync off. That mode has at worse less than a single frame of lag. If you had an "original" mode with no buffer, running at 60.08hz the end result would be very similar, with the disadvantage it's out of spec.

You literally repeated what I said but said I was wrong at the start.

 

The lagless mode adjusts the clock speed and only speed runners will care about it.

The alternatives for speed runners add a frame of lag and either drop a frame or has tearing.

[leods]

You literally repeated what I said but said I was wrong at the start.

 

The lagless mode adjusts the clock speed and only speed runners will care about it.

The alternatives for speed runners add a frame of lag and either drop a frame or has tearing.

The full buffered mode ads variable lag UP TO a frame. The half buffered mode adds LESS than a frame of lag at any given time.

 

Full buffered has no tearing, but a droppes frame, half buffered has tearing. I guess I didn't understand what your wrote in the first post I was answering to. You know, it's a bit convoluted being 3 lines long with no punctuation whatsoever...

 

I was saying no to the beginnign of your post: "So in basic terms the clock speed will always be adjusted to 60fps regardless of what the native clockspeed was". No. The clock speed is intact on the buffered modes and slowed down for the lag free mode.

[Wolf_]

The full buffered mode ads variable lag UP TO a frame. The half buffered mode adds LESS than a frame of lag at any given time.

 

Full buffered has no tearing, but a droppes frame, half buffered has tearing. I guess I didn't understand what your wrote in the first post I was answering to. You know, it's a bit convoluted being 3 lines long with no punctuation whatsoever...

 

I was saying no to the beginnign of your post: "So in basic terms the clock speed will always be adjusted to 60fps regardless of what the native clockspeed was". No. The clock speed is intact on the buffered modes and slowed down for the lag free mode.

"Always" was referring to on the lagless modes across the various cores.

[RabidWookie]

Starfox was never meant to run at 60hz. It didn't run at 60hz on original hardware, so why would you expect it to run any different on the super nt? Emulators are so cycle inaccurate they basically perform all the calculations at once then idle until a new frame starts. So Starfox might as well feel like ludicrus speed in an emulator. If you've never played the real hardware version you might be disappointed or pleasantly surprised. I dunno, it's kinda hard game. I can't even beat the first stage on the SNES Classic to unlock Star Fox 2. Perhaps the slowdown on real hardware actually makes it more playable?

 

I'm not talking about the Super NT or emulators, I'm wondering in general how input lag effects low fps games like Starfox compared to 60fps games.

[Beer Monkey]

no, the video is all generated internally to the FPGA. There's several PLLs on the FPGA itself, and I am using those to generate the various clocks. There's around 22 clock domains on the design as it stands. The problem is I would need some non-integer N/M ratio to get the right clock for the HDMI stuff from the 21.47Mhz domain. Right now video gets a clock that varies depending on video mode. i.e. it's 148.5Mhz in 1080p mode. There's no easy way to lock the two PLLs together (the one generating 21.47Mhz and the 148.5Mhz one) in the proper ratio to offer 60.09 hdmi.

 

The video always runs at 60.00 fps and it will cause cycle stealing on the snes side to make it stay in synch with the hdmi for the zero delay mode. If you run full/single buffered, the cycle stealing is turned off and is allowed to free run.

 

OK, I mostly understand this. Thanks for sharing!

 

We've been talking about this over on RetroGameBoards.com and in our associated Discord. We spun off from the Retro A/V topic on NeoGAF after the implosion. We're basically a bunch of CRT nuts who also like the FPGA consoles and the OSSC for differing degrees of accuracy.

 

Anyhow, tonight, I made the assumption after your post that maybe everything on the NT Mini also ran at 60.00hz. My tests revealed interesting results to the contrary, over analog.

 

NES runs (according to OSSC) at 60.08hz

Atari 2600 runs at 60.07hz

Gameboy runs at 60.08hz

SMS runs at 59.91hz

(Edit: This was all 240p mode)

The biggest surprise was 2600/7800 as they originally ran in 59.92hz in NTSC-land.

SMS is pretty close as I think it was 59.92hz for original hardware.

Do they also run at this rate over HDMI? I have no way of measuring this.

Does NES also run at 60.08 (~68.09) on the NT Mini over HDMI? Are there are compatibility issues?

Just trying to learn more. Some of the community emphasizes accuracy re: refresh rate but I'm not a purist in that respect.

Anyhow, finally got my shipping notification from Analogue and I'm probably getting my Super NT on Tuesday. I'm pumped! Yeah, it could have been faster, but that's not too bad.

Edited February 11, 2018 by Beer Monkey

[leods]

"Always" was referring to on the lagless modes across the various cores.

Oh. That isn't an issue to most cores. I think the NES core also needs that, but the other cores run correctly at 60hz for the most part. 60.08hz isn't the old standard. NES and SNES output out of spec signal. Old CRTs will lock to that for the most part, but modern displays will have more trouble because of how HDMI is processed with lower tolerance.

 

The Game boy cores also need some kind of magic I guess, because those were outputting video out of spec too, since they didn't need to follow any spec, using an internal display. I forgot how Kevtris dealt with that, but he probably did speed up the clock of the GB a bit.

[Wolf_]

Holy shit! The Super Nt has the option to change the color of the led to the color of the current center pixel! That means with a device that can compare the color of your led against the color of that pixel you would just need to figure out what the delay is (if any) between the center pixel and the led changing and add that number to the difference between the led changing and the center pixel changing on your display to match that color and you could use this to measure the input lag of your display.

That's a neat little extra!

https://twitter.com/twitter/statuses/962498022763630592

Edited February 11, 2018 by Wolf_

[kevtris]

So in basic terms the clock speed will always be adjusted to 60fps regardless of what the native clockspeed was, but all this will change is the playback speed imperceptibly slightly and the only people that could possibly care about that are speedrunners who have two additional modes to pick from to get native clock speeds with their choice of tradeoff between a dropped frame and screen tearing with a single frame of lag?

This is exactly it. The change amounts to around 1 second over the course of 10 minutes.

[kevtris]

Holy shit! The Super Nt has the option to change the color of the led to the color of the current center pixel! That means with a device that can compare the color of your led against the color of that pixel you would just need to figure out what the delay is (if any) between the center pixel and the led changing and add that number to the difference between the led changing and the center pixel changing on your display to match that color and you could use this to measure the input lag of your display.

 

That's a neat little extra!

 

https://twitter.com/twitter/statuses/962498022763630592

haha I didn't think of that. It updates pretty fast, several Khz. It updates whenever that pixel is drawn. The pixel is latched when it flies thru the scaler, and the led is instantly updated. Oh yeah, forgot to add. that pixel is captured on the *input* of the scaler, so it won't show the true speed after scaling. Sorry 'bout that. I guess I could make it do that though. If I get time I will change it to monitor the "output" end of the scaler. That would be a cute way to do lag testing.