It is currently Sun Aug 25, 2019 8:38 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 51 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
PostPosted: Sun Aug 11, 2019 11:19 am 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 160
rainwarrior wrote:
93143 wrote:
Good luck emulating a fully accurate Super Accelerator System with sub-pixel latency (ie: "none"), or even a few scanlines of latency, on any modern system. A Raspberry Pi isn't powerful enough, and a full-scale PC isn't real-time enough (I'm not sure it's powerful enough either). Just using a framebuffer adds a whole frame of latency by itself. You'd basically have to completely take over a powerful PC at the hardware level, bypassing the OS and drivers, and probably write parts of the emulator in shader language, to get anywhere near what an FPGA could do if properly programmed.

This is kind of a bizarre statement. What is "sub-pixel latency" supposed to mean?


If an Atari 2600 is feeding video to a black and white television set, the time between a store to one of the color registers and a corresponding change in the intensity of signal output by the beam could be less than 280ns (the approximate time required to show one pixel). Typical color television sets of the 1970s and early 1980s would add about a pixel worth of latency in their color decode circuitry. If a game were to include a loop like:
Code:
lp: ; Total loop time 76 cycles==1 line
    lda INP0 ; 3 cycles
    sta COLUBK ' 3 cycles
    ... another 10 repetitions of that, for 66 cycles total
    lda 0 ; Waste 3 cycles
    lda INTIM ; 4 cycles
    bmi lp ; Assume 3 cycles

then pressing the button would cause the beam's output intensity to change between about 3-6us later if the beam would be in the displayed part of the frame at that time.

In one particular weird corner case on the Atari 2600, a pixel can be split between multiple colors, though I don't think this could be very well exploited because the exact effects seem to vary with conditions like temperature. If the screen is programmed to switch color registers at the midpoint of each scan line, the switch isn't synchronized with the same pixel boundaries as everything else. If memory serves, the pixel where the split occurs would be shown as about 1/4 the old color, about 1/4 the logical AND of the old and new colors, and about 1/2 the new color, though as noted this is probably not consistent enough to actually be useful. While I wouldn't fault any hardware recreation that omits this quirk (it was certainly not intentional), a recreation that is trying to match the original hardware as precisely as possible should include it.


Top
 Profile  
 
PostPosted: Sun Aug 11, 2019 11:42 am 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 160
psycopathicteen wrote:
Wow, I never knew CMOS inherently took more transistors than NMOS.


A CMOS gate that produces an inverted function of any combination of AND and OR gates with separate inputs will generally require two transistors (one each P-type and N-type) per input. An NMOS gate will require one N-type transistor per input plus one passive pull-up. As process technologies get smaller, passive pull-ups don't shrink nearly as nicely as active transistors, because they need to be able to dissipate heat. There are a few situations where the passive-pull-up approach can be "win", however.

In NMOS, a 64-input NOR gate would be no problem operating quickly because it would have 64 N-type pull-up transistors wired in parallel with one passive pull-up opposing them. The passive pull-up might need to be larger than for a two-input NOR gate, but not outrageously so. In CMOS, the low-side network would be the same as for NMOS, but the high-side network would need to have 64 P-type transistors in *series*. That might be workable for something like an interrupt-detect circuit which needs to be able to respond rapidly to a rising edge on any of 64 inputs, but wouldn't need to react quickly to a falling edge. In general, however, a 64-input NOR gate would need to be implemented with sixteen four-input NOR gates feeding four four-input NAND gates which in turn feed a 4-input NOR gate. Although that would involve three levels of logic rather than one, the time required for a signal to propagate through a sequence of N transistors in series increases with time proportional to the square of N as N gets large (and for these purposes, anything over 10 would definitely qualify as "large"). If a NOR gate were implemented in one level of CMOS logic, the time required to react to a falling edge on the input might be about 30 times the time required for a 10-input gate to do likewise. Using three levels of logic would require a little more circuitry, but would likely be an order of magnitude faster.


Top
 Profile  
 
PostPosted: Sun Aug 11, 2019 1:06 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7568
Location: Canada
supercat wrote:
rainwarrior wrote:
This is kind of a bizarre statement. What is "sub-pixel latency" supposed to mean?

In one particular weird corner case on the Atari 2600, a pixel can be split between multiple colors...

Sub-pixel accuracy is very easily accomplished by emulators, that wasn't my question. There are lots of sub-pixel effects like that emulated already for many systems. My question was what the purpose of "sub-pixel latency", i.e. why would you ever need the video signal to physically display that fast? 93143 subsequently explained that they thought someone had said emulators can have "zero latency".

Also, as tepples pointed out, despite Analogue's claim of "zero latency" for their FPGA products, only the original NT (no longer available) had a composite output. The rest have HDMI output only with a very small amount of latency, small enough that I would say is fair to call zero in a causal sense, but 93143 clearly would not. Not really a fair comparison if we're talking about FPGA clones that are currently available.


Top
 Profile  
 
PostPosted: Sun Aug 11, 2019 8:31 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1076
rainwarrior wrote:
93143 wrote:
Of course, but the claim I was responding to was that an emulator could have no latency.

You said this twice now, but nobody claimed this.

Right here:
Oziphantom wrote:
An I could have an FPGA that has 20 frames latency, and an emulator that has none.

That is the post I was replying to. Obviously it's somewhat rhetorical, but I'm not good at letting things by just because of that.

Quote:
93143 wrote:
The human brain compensates for its own signal acquisition and processing lag. You can't just add it to the lag from the computer, because it doesn't do the same thing to the experience.

I completely disagree with this.

Humans perceive our own reaction time as a lag between sensing something and being able to do something about it - a delay between stimulus and responsive action. We do not perceive any delay between doing something and seeing the thing being done. When pushing a button on a controller, the lag between action and perception is automatically eliminated from our consciousness, so we can accurately perceive simultaneity of action and consequence - you feel and hear the button being pushed exactly at the moment you push it. But the lag between that button being pushed and Mario actually jumping is of course not handled that way, so it registers as a delay between action and consequence. Which it is.

These two types of latency have totally different perceptual effects.

Quote:
The human response is absolutely part of the interaction feedback loop

Again, not every game can be reduced to a series of quicktime events. The ability to precisely control a videogame requires the ability to schedule fine motor activities with a speed and precision far beyond human reaction time. And a perceived action-response delay adversely affects the play experience well before it reaches the level of preventing timely reactions to unexpected stimuli.

A long running jump in a Super Mario Bros. game might have a window of only a few frames for a successful maneuver. You can do it because you see Mario approaching the hole and realize that you'll have to jump when you get there. Imagine trying to make a jump like that without knowing you had to jump at all before the input window arrived...

Or take Mario Golf. The gameplay has virtually nothing to do with reaction time at all. You push the button, the cursor starts moving left on the swing meter, you push the button again exactly as it reaches the end, it starts moving right, you push the button again exactly as it returns to the start. Nice Shot! Your inputs basically have to be frame-perfect, and all of it is scheduled ahead of time by watching the cursor move and figuring out exactly when you should move your thumb based on where you predict the cursor will be. Added lag is very noticeable and makes the game harder. In fact, even with a real N64 on a CRT, there's enough lag to be bothersome.

If there's any reaction time involved in Mario Golf, it's in noticing that you botched the power side of the swing and hurriedly compensating with the accuracy side and/or adding spin with the Control Stick. You have the entire traverse of the swing meter to notice the problem and make that decision, and then do a frame-perfect input at the end of it.

Quote:
the amount of lag that TV has is completely relevant to the discussion. ... The total amount of latency in the loop is relevant.

Yes, but it's also important to separate out the causes so they can be thought about and dealt with separately. A computer monitor is actually better for lag than an HDTV, so why does a NES Classic have less lag than Nintendulator? Why is a real NES worse than either of them when using that same HDTV, and is there something wrong with the NES that makes it an inaccurate emulation of itself?

As far as I can tell the OP was asking a philosophical question, not a practical one. He wants to know if FPGAs are a Good Thing in general, not whether he should go buy a particular FPGA console to use with a particular TV.


Top
 Profile  
 
PostPosted: Mon Aug 12, 2019 12:21 am 
Offline

Joined: Mon Jul 01, 2019 3:15 pm
Posts: 6
My my, it seems like quite a few people got their input in, and I've seen a ton of good and interesting answers so thanks for filling those in! I'll address some of the doubts respecting the original objective of the thread.

Yes, it is correct that I was looking for input regarding the use of FPGAs on devices such as the Nt, AVS or Mega SG and I wanted to know how much impact they had on the market, on people and ultimately how important they are as a whole on the retro-gaming ecosystem in comparison to established platforms like emulators for example.

I am not looking or finding a way to get myself an FPGA device like those as I feel options like emulators and technical docs are ultimately what keeps or preserves older videogames and consoles along with the availability of them being possible to be played on a lot of devices. However, I cannot deny the seemingly important stance that FPGAs devices are taking nowadays and how popular they are getting as more and more they keep getting mentioned on the Internet. So I wanted to know if people felt that these devices ultimately contribute to something or will be just the kind of thing that appears for awhile and then disappears.

Lastly, and this is a bit offtopic, I'd like to agree with rainwarrior's point that high performance on emulators can be achieved with PCs and devices such as the Raspberry Pi. 93143 seems to have countered with the idea that Higan is a very slow emulator and not appropriate for hardware like those, however, there is a very good reason it is like that and is explained very well here http://mgba.io/2017/04/30/emulation-accuracy/ (This is Endrift, the author of the most accurate and one of the fastest GBA emulators to date)

I believe that if emulators are properly optimized, modified and customized to on performance/speed profiles while trying to maintain accuracy then it is entirely possible to do so. The author of this article goes about it very well in-depth. Ultimately, I feel like that as long as the user is able to enjoy their emulated game on the device they choose then they'll be happy and everyone else. Of course not everyone agrees with this point of view but I just wanted to let it be known.

Again, I welcome input for topics like these as I find them rather interesting.


Top
 Profile  
 
PostPosted: Mon Aug 12, 2019 4:27 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1076
byuu has said, IIRC, that higan could be about twice as fast if it were optimized for speed. He has also said (IIRC) that the SA-1 cuts the speed in half...

We'll see where Mesen-S ends up. Currently it's looking like it's tracking the former estimate pretty well, considering what it doesn't bother with.

My perspective is a little unique. I'm not primarily interested in emulating popular games at the moment, because I have a real SNES and a nice CRT TV (and a Super Everdrive, if it comes to that). But I'm developing a game that uses the Super FX as well as a lot of mid-scanline raster shenanigans, and even before I had any Super FX code running, the basic display engine didn't work on anything before higan accuracy core v095. (I also have an SA-1 game planned; at my current rate of progress I will never get to it, but who knows...)

I am a perfectionist. I won't be satisfied until it's possible to obtain a clone console and TV that will work properly with the Super Scope without hacks. I see no reason why the signal chain should need more than a couple of scanlines of latency end-to-end, and a CRT emulation running on the TV should be easily capable of handling a 240p/480i switch just as fast and seamlessly as a real CRT. This may very well never happen*, and most people won't care. That's fine. I do care, and that's why I plan to keep a real SNES and CRT around...

*Especially the Super Scope bit. It sounds like it relies on the raster spot being very bright, and I'm not sure it's healthy for any current flatscreen technology to try to do that.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 51 posts ]  Go to page Previous  1, 2, 3, 4

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group