Asbrandt
-
Content Count
30 -
Joined
-
Last visited
Posts posted by Asbrandt
-
-
For some systems like Atari 2600, I was thinking of using subdirs ...
There's not much of an other way except using a CRC style database which I really really really do not want. CRC databases are kind of a copout and it makes it a pain in the ass to add new ROMs. It miiight be possible to do heuristics but I don't really like the sound of that one either.
I would go with the subdirs, personally. It's the lesser of the evils here; added user effort.
It's been quite a few years since I worked on USB, but IIRC HID operates via Interrupt transfers and unless you can strong-arm the USB host controller the polling is scheduled by the controller at the frequency requested in the endpoint descriptor in the HID device. For low/full speed devices that's minimum 1ms, for high speed it's 125us. I don't know what typical HID devices set as their polling frequency, but the spec allows it to be up to 255 times longer. So as far as I know, you can't synchronise a host interrupt transfer poll to an external event, nor mandate a particular polling frequency, without having some control over the host stack (and possibly breaking the standard in the process).
By my understanding, Kevtris -is- scratch-building the USB Host controller and has full control over it here, and the poll rate set by the Device is only a request and/or informative of maximum capabilities, not a strict rule the Host has to obey, or else many low-speed devices wouldn't be able to have a USB Host. So he should be able to exert control over when polling occurs and do so at a slow rate.
-
It's about 50 bucks all on its own.
Huh, I didn't expect to guess that right.
Remapping the keys will incur no time penalty except maybe a few hundred nanoseconds to a couple microseconds so that shouldn't be an issue.
This surprises me since I'm accustomed to huge amounts of software overhead with USB and has me hopeful for the final numbers, if data transfer and encode/decode is similarly quick.
EDIT: By software I mean the OS, so really the wrong word to use in that case, I should have used API.
I guess I just have to wait and see, and should probably stop trying to engineer vicariously, haha.
-
That and handling the USB stuff will be the two biggest bug-a-boos.
I might be the only one interested, but I hope that as you work on the USB side, you let us know what the latency looks like from start-of-usb-poll to replicated-system-can-use-input-data, perhaps at best (one controller?) and worst (keyboard, mouse and 2 controllers?) cases for the sake of information.
I'd imagine most of this would be fixed based on supported data transfer rates over usb and between the input controller and main FPGA, but some would improve as your keymapping code matures.
In a IRC discussion on USB input, it was suggested to use more controlled polling at specified points during a frame instead of polling at max speed to help keep control of the polling latency variable.
But this ultimately doesn't reduce it at all, just makes it more predictable, to some degree, as firmware optimization of the input device itself can have an effect, too.
EDIT: However, consistency of input latency is still an improvement for most users, and the same input device should always present the same latency.
Hopefully, homebrew optimized USB-HID uC's/Firmwares rise in response to the Z3K's existence.
Looks like the cost of my target FPGA dropped a little so that's gonna help.
If I may ask, just how big and expensive of an FPGA is being put toward this project?
-
As a seperate but related curiousity, would a generic port that uses passive adapters for real controllers without any kind of protocol conversion (each core having the recreated system's input stage) be a reasonable feature, or would that be getting too complex when having to deal with both that and USB? I'd imagine there would also be the issues of either sourcing connectors or making people make thier own adapters.
To expand on this further, I'm curious to know if your cores are currently setup to allow this to work the way I would imagine it; does the i/o core output the replicated system's protocol to the main core, or does it use an intermediary format the main core deals with internally?
-
And some strange limitations pop up, such as the A8bit series core not supporting the controller port for some reason, instead requiring a 2600-daptor device to convert to usb.
-
...because of some analog bits between the SID and the output that weren't on the chip to replicate...
Indeed it was missing the filters, and Kevtris mentioned having an issue with them on the Z3K because they would be system-specific hardware components.
Personally I think we can make an exception here because it's a huge part of the C64 that can't be replicated on the FPGA, but not everyone would agree.
-
1
-
-
... In fact I am not entirely sure how you could do it with no buffer at all...
With the HiDefNES he adjusts the system's clock to make it exactly 60hz.
I think HDMI has a 50hz mode after some googling, no indication of what support for that is like in 60hz areas though.
-
I am not really 100% sure myself, to be honest :-) ...
Yeah by my understanding it's not so much the poll rate, which on a HID device capable of the maximum 1000hz poll rate is ofcourse only 1ms, unless the Z3K itself can't do that high.
The other 3-4 come from the data encoding/decoding processes and any other stuff the OS does with it, this is the part I'm mainly curious about. Obviously there's no OS here to throw in overhead, so it's mostly the encode/decode stuff and whatever handles button mapping.
... The SNES and genesis games were MOSTLY 240p, but some of them (at least on genesis) used interlaced mode, i.e. the 2 player at once sonic game...
Is it not possible (with the way you handle HDMI) to buffer a field instead of a whole frame, pulling in the previous field's lines (or black lines if there isn't one) as necessary to construct the full frame, or do you not want to use the "naive" deinterlacing method? (I think it's called that anyway.)
I've been curious about a possible improvement to the very noticable appearance (on modern digital panels) of that method, but I've not had the ability to test it; darken the "old field" lines vs the "new field" ones to mimic phosphor decay to some degree.
-
I do not understand why anything below a single frame is important ...
The question is primarily for my own educational purposes, rather than real world concern, since I'm not a high level player of anything.
The mention of "missing the input window" is thinking about a (theoretical) high level player's point of view, to whom needing to readjust to make inputs a third of a frame sooner than they're used to may be a big deal.
That said, 5ms adds up if you're using the HDMI output board, although we don't know how many lines the Z3K's HDMI stage needs to buffer yet.
-
On the topic of input lag, I have a question for Kevtris about USB HID input, as I only have a basic understanding of it.
Between the poll rate, usb data being serial and I assume encoding/decoding processes, how wide of a window (at worst case) should we expect between input and that input being available to the system core to read?
I've been told with Windows' DInput API this is somewhere between 4 and 5ms, while this value is managable and I would imagine the Z3K would have less overhead, it's still good to know, as it determines the possibility of "missing the input window" for precise inputs.
---
As a seperate but related curiousity, would a generic port that uses passive adapters for real controllers without any kind of protocol conversion (each core having the recreated system's input stage) be a reasonable feature, or would that be getting too complex when having to deal with both that and USB? I'd imagine there would also be the issues of either sourcing connectors or making people make thier own adapters.
-
I don't see why all NES games and their features cannot run? I wasn't aware Castlevania III was an issue on software emulation? The USA/PAL release won't run on most flash carts because of the mapper used, but the Japanese version runs fine, even with FM sound that the USA release never had.
US / PAL CV3 use the MMC5 mapper, albeit only partial features.
This chip seems to be handled fine in software emulation but it's been difficult on hardware recreation (FPGAs, etc) outside of the basic features CV3 used.
VRC6 is a much easier to impliment chip, even with the addon sound channels.
As a minor aside, VRC6 doesn't have FM synth, just waveform synth. You were thinking of the VRC7 used in Lagrange Point.
That all said, Kevtris did say "all expansion audio chips and all mappers" and I'd imagine he means that, full MMC5 support included. Else he would have mentioned anything with no or partial support.
-
So you cant do something like the do on rockband?
Games with this display lag calibration feature are designed and programmed for it, it's not something feasible to add on later.
-
Yeah "input lag" really feels like the wrong term, since that to me has to do with the input device, connectivity method and system software, and it is the part that you can't really do anything about anyway.
I personally use "display lag" for the tv/monitor's latency. Some include the rendering time for framebuffer-based systems as part of display latency, but that doesn't really need to be measured since it can be determined by framerate.
-----
Response Time ratings on modern screens are but one contributing component of overall display lag, however it -does- determine the general level of motion blur, so it is an important figure to know regardless.
With the DisplayLag website's reporting, you might see '10ms' and think "Yikes, that's almost a full frame and this is among the best?" however that value doesn't take into account that the modern Pixel Clock can be considered analogous to the CRT Beam Sweep for the purposes of display lag, a CRT running at 60hz should measure approximately 8.333~ms with thier reporting, so '10ms' can also be considered '2ms vs CRT'.
If I'm wrong about any of this, please correct me.
-
4. For retro nerds like myself hive the rgb option for our awesome crt, i dont like hd lag, so if its only hd, please have something to help calibrate the lag.
I would suspect that the output board plugged in would determine the video processing or lack thereof, but even if it doesn't, you probably won't have to worry too much about lag;
The cause of display latency in scaling devices, including the ones in modern TVs and Monitors, is that when scaling is needed it buffers and processes an entire frame before outputting it.
This is not the case with Kevtris' scaling on the HiDefNES board, iirc he buffers 35 lines at worst case, which is a latency of under 2.5ms (out of 16.666~ for a frame), which even with an added ~2ms of a -good- modern monitor vs a CRT, is still around 5/16ths a frame at worst.
And it's possible that he can reduce this even further when he has total control of the system's workings with the Z3K.
-
I had a couple ideas for reducing the costs while still trying to accommodate everyone I can reasonably. The first idea which seems to be good is to offload the video/audio hardware 100% onto a small add-on plug in board.
I'm surprised to see HDMI also be split off here, although if that makes the design simpler and easier, that's a good thing.
Would the VGA board be 31khz only, or would it also have 15khz (perhaps with csync over the hsync pin which appears to be a psuedo-standard)?
The only downer is you can't run HDMI + some analog output at the same time, but there's probably only a small percentage (< 5%) that would want such a feature. Having everyone pay so the 5% can have it is in effect subsidizing it, while driving up end user costs.
I'm ok with buying two or more output boards if it brings the price down for everyone else.
I'll be sincere, I think there is a flaw in the questionary, because there is a question about the Price Point, but it's not relating that to the Features People expect.
Yeah, more granular price questions are probably good;
1: What would you pay for what it can do now (before output board)?
2: How much more would you pay if 16bit systems were implimented?
3: How much more would you pay if home computers were implimented?
4: How long are you willing to wait for 2 and 3 above?
5: Which output boards would you purchase?
6: Would you buy real cartridge addons?
So on, so forth.
But that kind of granularity is what replying to the thread is for, atleast.
For my answers;
1: $250 without hesitation. Easy to justify by selling my NESRGBed AV Famicom.
2: Hard to answer without knowing addon capabilities. Sky's the limit if NeoGeo or the PCE's CD addon is possible.
3: Atleast the price of a MiST board, probably more than that.
4: As long as I have to, quality demands patience. And I will enjoy the existing cores in the meantime.
5: VGA at first, probably HDMI later.
6: Not unless I have to, after losing my collection once I don't really have any positive nostalgia for real cartridges anymore.
EDIT:
Yeah I was thinking selling 1000 units is the number I have to hit to make it worthwhile, though 500 might be doable these days. ... If I can cover costs of production and make some bucks at it, I'm all for it. There's no way I'm going to ever get paid back for the time I put into these cores, but again this is like the hardware version of a homebrew 2600 game. You do it because you love it and if a few bucks can be made to offset the costs, great!
This is probably why I am on the "take my money" side of this, because I know and appreciate what this represents above and beyond software emulation and wish I had some kind of expertise to contribute.
-
What I find interesting about the responses is that theres a wide variance not just in desired price/features but in the price:feature ratio.
That might make things tougher, since there seems to be a fair amount looking for less than the likely target price mentioned in the OP, perhaps influenced by the Retron 5's price even though this serves a much more specific niche.
-
If the effect that produces 'artifact colors' is predictable and consistent enough to be represented mathematically regardless of source system, it should be possible to simulate to a satisfactory level with minimal latency for the systems that call for it (alot but not all NES and Genesis, probably some home computers and alot of pre-NES but I have no experience with either of those) since it only occurs on the horizontal axis.
I would guess that plus scanlines would be the limit of "tube simulation" options, although that would definitely be more than enough for me.
HQX is something else entirely and to be honest I am not the biggest fan, even if it is interesting from a technical perspective that it was implimented on the HiDefNES.
-
The niche within a niche effect is a real problem indeed, but I think Kevtris is really looking for an idea of the best balance between price and features here before posting in more places for a much wider interest check to determine if it's a viable niche to fill.
I'm hoping for a favorable result ofcourse, having wanted this thing since the first time I read about it quite some time ago, but I may be optimistically biased since I am part of the exact target audience.
-
I have great plans to add all sorts of computers.
Well this is surprising news, I was prepared to buy both this and the MiST without any complaints.
I guess I should hold off on that now unless there's something major you are hesitant about.
However, this does bring up an important question; How do you intend to handle PAL dominated platforms such as the C64 and Amiga via HDMI?
-
Lightgun games are another reason for optional analog output.
Although I am curious to know if a linedoubled output to a VGA monitor would still function for lightguns, or if the 1 line of latency (is that even correct?) is still too much.
EDIT: For my part, I would be happy with my purchase if I paid $300 for a unit with the analog addon and just SD card loading, given the currently listed capabilities, as this would replace a handful of systems I currently possess -and- I could give systems I always dismissed as "too retro for me" a chance as a bonus.
Doubly so if linedouble output to 31khz RGB is an option, as I rather like the CRT PC monitor I use for 480p systems.
Adding 16bit stuff is where I start caring even less about the asking price.
EDIT2: As for pricing/competing against the Retron 5, I feel that's not really fair nor a good idea here as this is a project for those who don't mind sacrificing the real system "feel" for improvements like HDMI, overclocking, etc (are save states a possibility?) but aren't willing to sacrifice on minute technical aspects like current software emulation does.
-
I don't feel as though this thread is a wishlist thing so much as Kevtris looking to see if there's a financially viable balance between the price people are willing to pay and the questions of carts/sd, hdmi/analog, and how much people want the 16bit stuff.
Out of curiosity, Kevtris, is any of the addon hardware of the 16bit era out of reach here, and is the PCE hardware well known enough to be implimented at all?
-
The SID was mentioned because it's been notoriously difficult to nail down a reimplimentation of it on FPGA but that's being worked on still, if I recall correctly.Feature creep.. Keep it under tight control.
I could be mistaken, but it appears to me that Kevtris is focusing on console hardware, leaving home computers to projects such as the MiST, so the SID's difficulty would be irrelevant here anyway.
EDIT: In my opinion, this separation of goals is a good thing, even if you're paying more by buying two separate projects, there's more focus on the quality of each core this way.
I do hope he can pull off 16bit stuff, although I'd imagine the CD addons might complicate things.
-
I'm also in the "keep it simple" camp regarding hardware features.
I'd guess that most who are interested in this are ok with the "feel" of emulation, lacking real carts and in many cases real controllers, but dislike the lag-causing technical limitations, such as the framebuffer and the OS input system, both of which can be overcome but as of now have not been.
However, I also understand there is a crowd that strives for accuracy including the video output framerate, even when not using original hardware, such as the GroovyMAME + CRTEmuDriver users. Until AdaptiveSync or similar becomes within your reach, that's only really possible with analog output unless you break HDMI spec, so I would favor the "optional analog addon" even if it only does say 15 or 31khz RGB from a VGA port.
-
1
-
-
It seems viletim kept it under wraps until it was ready and working and considering how unbelievable it is, I can't blame him.
Be interesting to see what a board layout specificly designed around this thing would look like, though, since you'd be able to drop some parts off the bill.
(Not saying I expect such a board, just saying I'd be curious.)
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
FPGA Based Videogame System
in Classic Console Discussion
Posted
If I interpreted the post correctly, this is only needed for systems where ROMs have no headers to work with, such as the 2600. Something like NES has headers with all the needed information.