240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
A user on NESdev BBS expressed some user interface concerns, particularly with the help pages and the manual lag test. A couple of the criticisms apply only to the NES version, whose manual lag test uses Dance Dance Revolution-inspired colors to show how close the press was to exact, but the rest also apply to the Super NES version on which I based it.
[quote="In this post, "rainwarrior" (Lizard developer Brad Smith)"]The [manual] lag test discards all early presses. This biases the results toward lag by half the imprecision of the human user. The lag itself should be consistent, but human precision varies from tester to tester (and condition of the tester). Since you don't know in advance how precise the user is, the amount of bias is unknown, and can't be properly corrected for. I think early results should be included to balance out this bias.
I also think displaying an indication of how "good" your timing was improperly biases the results. No matter the lag, the user can always anticipate to reach approximately "marvelous" timing, and labelling it this way gives them incentive to try to do this. It's no longer a measure of the hardware lag, but of their ability to anticipate, unless they can mentally ignore this measure of success being presented to them. The documentation [of the NES version] mentions "if you are skilled at rhythm games"-- rhythm game skill means exactly that you can learn to anticipate and hide lag, which is the opposite of what this test should measure!
Ideally the user should be blind to their results as their coming in. I would just display "X results received" as it counts up to 10, and if you're rejecting "bad" results, bad should just be sufficiently away from the target (e.g. +/-20 frames away), not the early results.
Additionally, audio lag and picture lag should be measured separately. The user should only be using the audio cue, or only the visual cue; using them both at once is a problem if they're not the same. Thankfully there is the option to turn the audio off, and you can close your eyes to do an audio-only test, but it would seem to be more appropriate to have 3 options: picture only (to test), audio only (to test), picture+audio (to watch, same goal as "audo synch test").
The "flash" visual cue is a good cue for picture lag and should happen whether or not audio is on. Why is it disabled when you disable audio? (This is very strange to me.) Randomness on the other hand is not applicable to an audio-only test (again would reduce it to a test of the human, not a test of the lag); it should just be trying to match a steady beat. Randomness is good with the visual test though.
[...]
Suggestions for documentation:
START seems to pause a test and enter its documentation, but it also enters a test and exits its documentation. I found this a little confusing because I didn't know what START's function was, and repeated presses end up doing a different thing each time (it enters a test, but can't exit it, but it enters documentation and exits it). Not really an issue once you're oriented, but maybe it would be more intuitive if START from the menu to you directly to the documentation (and exiting returned to either the menu or the test, depending on where it was launched from)?[/quote]
[quote="In this post, "rainwarrior" (Lizard developer Brad Smith)"]The [manual] lag test discards all early presses. This biases the results toward lag by half the imprecision of the human user. The lag itself should be consistent, but human precision varies from tester to tester (and condition of the tester). Since you don't know in advance how precise the user is, the amount of bias is unknown, and can't be properly corrected for. I think early results should be included to balance out this bias.
I also think displaying an indication of how "good" your timing was improperly biases the results. No matter the lag, the user can always anticipate to reach approximately "marvelous" timing, and labelling it this way gives them incentive to try to do this. It's no longer a measure of the hardware lag, but of their ability to anticipate, unless they can mentally ignore this measure of success being presented to them. The documentation [of the NES version] mentions "if you are skilled at rhythm games"-- rhythm game skill means exactly that you can learn to anticipate and hide lag, which is the opposite of what this test should measure!
Ideally the user should be blind to their results as their coming in. I would just display "X results received" as it counts up to 10, and if you're rejecting "bad" results, bad should just be sufficiently away from the target (e.g. +/-20 frames away), not the early results.
Additionally, audio lag and picture lag should be measured separately. The user should only be using the audio cue, or only the visual cue; using them both at once is a problem if they're not the same. Thankfully there is the option to turn the audio off, and you can close your eyes to do an audio-only test, but it would seem to be more appropriate to have 3 options: picture only (to test), audio only (to test), picture+audio (to watch, same goal as "audo synch test").
The "flash" visual cue is a good cue for picture lag and should happen whether or not audio is on. Why is it disabled when you disable audio? (This is very strange to me.) Randomness on the other hand is not applicable to an audio-only test (again would reduce it to a test of the human, not a test of the lag); it should just be trying to match a steady beat. Randomness is good with the visual test though.
[...]
Suggestions for documentation:
START seems to pause a test and enter its documentation, but it also enters a test and exits its documentation. I found this a little confusing because I didn't know what START's function was, and repeated presses end up doing a different thing each time (it enters a test, but can't exit it, but it enters documentation and exits it). Not really an issue once you're oriented, but maybe it would be more intuitive if START from the menu to you directly to the documentation (and exiting returned to either the menu or the test, depending on where it was launched from)?[/quote]
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
Thanks for the feedback PinoBatch, Rainwarrior made some very valid points, and maybe we should discuss a bit how to change it. Feedback from the community would help as well.
but if video is disabled this should be disabled as well.
Thanks again for the feedback, and please feel free to discuss other improvements here.
I need to think it over, but I believe he's right. It is very simple to add an option to hide the video and the results. So it is just a matter of making a new release with that and any other feedback across all platforms. Having more and more precise tools is better for all of us.PinoBatch wrote:The [manual] lag test discards all early presses. This biases the results toward lag by half the imprecision of the human user. The lag itself should be consistent, but human precision varies from tester to tester (and condition of the tester). Since you don't know in advance how precise the user is, the amount of bias is unknown, and can't be properly corrected for. I think early results should be included to balance out this bias.
I agree, but I believe that only happens in the NES version, will check if it is present elsewhere. However, having the option to disable all current results would cover it as well with no need to remove it.PinoBatch wrote: I also think displaying an indication of how "good" your timing was improperly biases the results. No matter the lag, the user can always anticipate to reach approximately "marvelous" timing, and labelling it this way gives them incentive to try to do this. It's no longer a measure of the hardware lag, but of their ability to anticipate, unless they can mentally ignore this measure of success being presented to them.
Agree as well, that's why I made "Random" the default option... or at least I did in teh latest versions. Will have to check all of them and make it the same across them.PinoBatch wrote: The documentation [of the NES version] mentions "if you are skilled at rhythm games"-- rhythm game skill means exactly that you can learn to anticipate and hide lag, which is the opposite of what this test should measure!
Having the option to hide the input will cover this as well.PinoBatch wrote: Ideally the user should be blind to their results as their coming in. I would just display "X results received" as it counts up to 10, and if you're rejecting "bad" results, bad should just be sufficiently away from the target (e.g. +/-20 frames away), not the early results.
Additionally, audio lag and picture lag should be measured separately. The user should only be using the audio cue, or only the visual cue; using them both at once is a problem if they're not the same. Thankfully there is the option to turn the audio off, and you can close your eyes to do an audio-only test, but it would seem to be more appropriate to have 3 options: picture only (to test), audio only (to test), picture+audio (to watch, same goal as "audo synch test").
It is disabled since it was under the same if statement =P So, it was not designed, but implemented that way.PinoBatch wrote: The "flash" visual cue is a good cue for picture lag and should happen whether or not audio is on. Why is it disabled when you disable audio? (This is very strange to me.) Randomness on the other hand is not applicable to an audio-only test (again would reduce it to a test of the human, not a test of the lag); it should just be trying to match a steady beat. Randomness is good with the visual test though.
but if video is disabled this should be disabled as well.
I believe this only happens in the NES, PC Engine and Genesis 3 button layouts, and is due to the button layout. On other versions I believe I've made it so Start is always the menu or Help, and the typical accept and cancel buttons are used for those purposes. Will again, need to check across all versions.PinoBatch wrote: Suggestions for documentation:
START seems to pause a test and enter its documentation, but it also enters a test and exits its documentation. I found this a little confusing because I didn't know what START's function was, and repeated presses end up doing a different thing each time (it enters a test, but can't exit it, but it enters documentation and exits it). Not really an issue once you're oriented, but maybe it would be more intuitive if START from the menu to you directly to the documentation (and exiting returned to either the menu or the test, depending on where it was launched from)?
Thanks again for the feedback, and please feel free to discuss other improvements here.
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
I thought it'd be a nice feature to have, given how DDR-like the rest of the test is. I'll have to see what you end up doing in the Super NES version, because that's the one I'm tracking with my NES changes.Artemio wrote:I agree, but I believe that only happens in the NES version, will check if it is present elsewhere.rainwarrior wrote:I also think displaying an indication of how "good" your timing was improperly biases the results. No matter the lag, the user can always anticipate to reach approximately "marvelous" timing, and labelling it this way gives them incentive to try to do this. It's no longer a measure of the hardware lag, but of their ability to anticipate, unless they can mentally ignore this measure of success being presented to them.
"Random" is the default in both the NES and Super NES versions.Artemio wrote:Agree as well, that's why I made "Random" the default option... or at least I did in teh latest versions. Will have to check all of them and make it the same across them.rainwarrior wrote:rhythm game skill means exactly that you can learn to anticipate and hide lag, which is the opposite of what this test should measure!
Correct. I tried it on Super NES, and Start on the main menu shows help. I'll change the NES version so that only A opens a test, and Start instead opens help.Artemio wrote:I believe this only happens in the NES, PC Engine and Genesis 3 button layouts, and is due to the button layout. On other versions I believe I've made it so Start is always the menu or Helprainwarrior wrote:START seems to pause a test and enter its documentation, but it also enters a test and exits its documentation.
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
Thanks for all of your hard work on the 240p test suite, Artemio.
I was wondering if you have any plans to develop a port for the Sega Saturn?
I was wondering if you have any plans to develop a port for the Sega Saturn?
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
Apologies if this has been raised previously but a ROM for MAME would be great, I've got the 240p test suite on all sources except GroovyMAME now
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
Hey man. That is not viable, let me explain a little bit. MAME emulates arcade games (and since being merged with MESS it also emulates a bunch of consoles). But regarding arcade games, each one has its own refresh rate, palette and characteristics. That results in different resoiutions.niall wrote:Apologies if this has been raised previously but a ROM for MAME would be great, I've got the 240p test suite on all sources except GroovyMAME now
You've probably noticed that you have to adjust values each time you change a PCB on a cabinet, unless it is the same kind of PCB. However, almost all arcade games have a test menu with their own patterns. At the very least a grid, a color ramp and sometimes geometry.
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
I can attest to different arcade systems requiring adjustment of the picture size, as their dot clock rates (in MHz) and active horizontal durations (in microseconds porch to porch) differ. Though Namco games with a 6.144 MHz dot clock and arcade platforms derived from console hardware (Nintendo Vs., PlayChoice, Nintendo Super System) tend to agree well with standard TV timing, some require the picture to be set much narrower or wider. The picture size that you see on a "SuperGun" (JAMMA-to-TV adapter) isn't necessarily the same picture size that the manufacturer intended. That's why you need test patterns for each board that you plan to use, such as the ones in the system's BIOS or each game's service mode.
But if you can run the NES, Genesis, or Super NES version in MESS, this would at least get you set up to run Vs. System, PlayChoice, Mega-Tech, and Nintendo Super System games with accurate picture size in MAME.
But if you can run the NES, Genesis, or Super NES version in MESS, this would at least get you set up to run Vs. System, PlayChoice, Mega-Tech, and Nintendo Super System games with accurate picture size in MAME.
-
Einzelherz
- Posts: 1279
- Joined: Wed Apr 09, 2014 2:09 am
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
Would a TVL type test be of any value? On a 480i/p signal you'd only be able to measure accurately up to about 540TVL, but it might be good for consumer sets.
-
bobrocks95
- Posts: 3472
- Joined: Mon Apr 30, 2012 2:27 am
- Location: Kentucky
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
I think that would be useful. Apparently some test patterns exist based on info on this site http://www.causewaysecuritysolutions.co ... lines.html
Only problem is that's in relation to testing cameras, and may not directly relate to viewing on a CRT.
Only problem is that's in relation to testing cameras, and may not directly relate to viewing on a CRT.
PS1 Disc-Based Game ID BIOS patch for MemCard Pro and SD2PSX automatic VMC switching.
-
Einzelherz
- Posts: 1279
- Joined: Wed Apr 09, 2014 2:09 am
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
I've seen some of those old timey sharpness cards which is probably where the idea came from. Because we're dealing with pixels (I think, anyway) and 540TVL is the highest that a 720px line can show, factors should work well enough, though they're not super precise.
e.g. 540TVL, 270TVL, 135TVL, 67.5TVL.
e.g. 540TVL, 270TVL, 135TVL, 67.5TVL.
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
Sorry for taking longer than usual to reply, but I was away.
Regarding a TVL pattern just as you guys mention, it is intended for use with a camera and the display. And it is only really used for vertical resolution. However, you already have the equivalent highest frequency pattern possible on the suite. It is the horizontal (and vertical) alternating lines pattern on the main menu, and of course the checkerboard pattern.
in any case the only missing option would be a 256 horizontal pattern in consoles that can do both 256 and 320, like teh Sega Genesis or PCE. But those already give true 320 patterns. And you get 640x480 patterns when selecting that video mode on consoles that support it.
If I am mistaken and didn't consider all the posibilitases, please correct me so we can discuss how to implement it for valuable use within the suite.
Thanks for the suggestions, they are always welcome!
Regarding a TVL pattern just as you guys mention, it is intended for use with a camera and the display. And it is only really used for vertical resolution. However, you already have the equivalent highest frequency pattern possible on the suite. It is the horizontal (and vertical) alternating lines pattern on the main menu, and of course the checkerboard pattern.
in any case the only missing option would be a 256 horizontal pattern in consoles that can do both 256 and 320, like teh Sega Genesis or PCE. But those already give true 320 patterns. And you get 640x480 patterns when selecting that video mode on consoles that support it.
If I am mistaken and didn't consider all the posibilitases, please correct me so we can discuss how to implement it for valuable use within the suite.
Thanks for the suggestions, they are always welcome!
-
Einzelherz
- Posts: 1279
- Joined: Wed Apr 09, 2014 2:09 am
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
I was only concerning myself with horizontal TVL and my explanation above would only be useful for 480i and up vertical resolutions.
The checkerboard pattern always just gives me a headache when I use it whereas lines of even thicknesses in those TVL counts above might not?
I was just thinking of a test card type screen that's 1:1 in the center of the viewing area, kind of like the IRE screens, but when you toggle it, it switches through labeled TVL counts so you can roughly identify an otherwise unknown screen's resolution.
I may be misunderstanding the whole concept, however.
The checkerboard pattern always just gives me a headache when I use it whereas lines of even thicknesses in those TVL counts above might not?
I was just thinking of a test card type screen that's 1:1 in the center of the viewing area, kind of like the IRE screens, but when you toggle it, it switches through labeled TVL counts so you can roughly identify an otherwise unknown screen's resolution.
I may be misunderstanding the whole concept, however.
-
bobrocks95
- Posts: 3472
- Joined: Mon Apr 30, 2012 2:27 am
- Location: Kentucky
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
Does that mean a TV being fully able to resolve the checkerboard pattern in 480i is 540TVL+?
PS1 Disc-Based Game ID BIOS patch for MemCard Pro and SD2PSX automatic VMC switching.
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
A TVL mode? That would be great for testing the TVL of consumer sets.
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
It only makes sense as horizontal.Einzelherz wrote:I was only concerning myself with horizontal TVL and my explanation above would only be useful for 480i and up vertical resolutions.
I mentioned the checkerboard as the extreme case of maximum frequency, but it doesn't make sense in 480i in many scenarios. It is there for completeness and in order to evaluate how video processors deal with these extreme cases.Einzelherz wrote: The checkerboard pattern always just gives me a headache when I use it whereas lines of even thicknesses in those TVL counts above might not?
What you would use for horizontal resolution is teh vertical bars pattern, presented as a variant of the horizontal one in the suite.
It would only make sense if I could vary the resolution, but that is not the case. I can give you the max available on each video mode, and that is what is present on each version for each console. More on that below. Other than that, I could only vary it by giving it multiples of two: example 320, 160 and 80, or 256, 128 and 64 in the SNES for example. I believe that would be useless.Einzelherz wrote: I was just thinking of a test card type screen that's 1:1 in the center of the viewing area, kind of like the IRE screens, but when you toggle it, it switches through labeled TVL counts so you can roughly identify an otherwise unknown screen's resolution.
Not exactly. As mentioned above you should use the vertical bars. And what resolution you see is what the console can give in the mde you are using it. For example, SNES is 256x240/224, so you'd see 256 max. If you change the SNES to "480i" video mode, you'd still be only seeing 256x224 in reality, it is just an interlaced video mode.bobrocks95 wrote:Does that mean a TV being fully able to resolve the checkerboard pattern in 480i is 540TVL+?
A genesis will give you 320. A PCE would give you the choice of 256 or 320, a NES is 256. The Wii, DC and GC would give you 320, and 640 when in 480i mode.
The signal is generated from pixel patterns either in a digital frame buffer or from tiles. Either way we have only fixed resolutions.
Hope that clears it up, if not please let me know.
-
Einzelherz
- Posts: 1279
- Joined: Wed Apr 09, 2014 2:09 am
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
It doesn't, but that's because I still don't understand a lot of this stuff
Thank you for the very thorough explanation. I'll just take it as saying my idea can't work. Also, I'd only thought it would be useful for the GameCube, Dreamcast, or Wii anyway because the resolutions on the other systems is too low to be useful.
Thank you for the very thorough explanation. I'll just take it as saying my idea can't work. Also, I'd only thought it would be useful for the GameCube, Dreamcast, or Wii anyway because the resolutions on the other systems is too low to be useful.
-
TheShadowRunner
- Posts: 274
- Joined: Sun Feb 24, 2013 7:41 pm
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
long time no see Artemio!
A small bug I just noticed: on the suite for SFC, the Help file for the Manual Lag Test is supposed to be 4 pages, but page 4/4 cannot be accessed.
A small bug I just noticed: on the suite for SFC, the Help file for the Manual Lag Test is supposed to be 4 pages, but page 4/4 cannot be accessed.
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
TheShadowRunner wrote:long time no see Artemio!
A small bug I just noticed: on the suite for SFC, the Help file for the Manual Lag Test is supposed to be 4 pages, but page 4/4 cannot be accessed.
Thanks! Fixed for next release.
Yes, been quite busy with several projects, but I'll eventually finish the N64 version.
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
Passing on more feedback from rainwarrior about the lag test:
How could the lag test be improved for easier eyeballing? My first idea would be to use blue for the lit circle and pink for the rest, as blue is a perceptually darker color than red.rainwarrior wrote:It would be useful to be able to identify skipped frames (thinking about this recent thread [about Final Fantasy appearing to lag on a particular setup]).
In some of my work, the test I've used for this is to display a row of numbers, each number appearing for exactly one frame as we cycle through them. (All numbers have to be in a different visual position.)
[The lag test] seems to be almost this, but I find it a lot less effective to try and read it because the numbers are always displayed, and the contrast between red and blue is not nearly as strong as if it would be if the numbers were appearing only on their frame. (Black would be better than that blue, and that dark blue is better than the red for contrast against white.) [...]
Additionally, a longer period than [8] may help; I've usually found 16 to be effective, in a row or a grid. 64 is probably too many, but [8] looks like too few to me, but I'm just "eyeballing" this, YMMV. A configurable period might be even better as it could help diagnose particular framerate mismatch problems too (e.g. 60 vs 50 fps).
[...] it seems that older versions had on/off numbers instead of red/blue, which I think was better, but given that the intent of that test was to be used with a camera, I don't think it made a difference for that purpose. My suggestion is for something that you should be able to see easily with the human eye, which wasn't really the original intent I think. A human test should try to emphasize and take advantage of persistence of vision (via greater contrast, or larger numbers, or only showing one at a time, etc.).
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
How could the lag test be improved for easier eyeballing? My first idea would be to use blue for the lit circle and pink for the rest, as blue is a perceptually darker color than red.
Those ideas sound good for eyeballing as it is mentioned. Regarding colors t choose, the ones with better response would be green, pink, yellow...
Since only one of the eye receptors activate with blue, it would be the least visible color of them indeed.
Do you believe 16 circles would work better?
The test was originally designed for cameras, since a CRT would be used as baseline and everyone has at least a celphone at hand now. That's why it is that way now.
I am interested in having a better test for eyeballing, but it would also fall into the abuses the manual lag test is falling now. Since it would be subjective in the same way, people end up using that as reference, when in reality it is just there for a quick hands on.
How can we give them a test that is reliable and better than the current one?
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
And all three receptors activate with white. Contrast with a white background is important, and a dark blue circle has plenty of that. The colors I'll probably end up using for this test in version 0.15 of the NES suite are as follows:Artemio wrote:Regarding colors t choose, the ones with better response would be green, pink, yellow...
Since only one of the eye receptors activate with blue
Background: White #FFFFFF
Inactive circles at bottom: Pink #FF8B7F
Even frame numbers: Red #BD3C30
Odd frame numbers and active circle: Midnight blue #002D69
(These aren't very pure RGB-wise because the NES color space is an HSV bicone embedded in YUV space.)
I used 10 circles in mine because it's easy to get from the last digit. But if you can whip up a prototype of 16 on the SNES version, I can give it a look.Do you believe 16 circles would work better?
And it's great for the original intent of relative lag between two displays. But people are trying to use it for dropped frames, and not all cell phone cameras can record high motion (60 fps) video.The test was originally designed for cameras, since a CRT would be used as baseline and everyone has at least a celphone at hand now.
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
I have received a private message on forums.nesdev.com asking for a port of 240p test suite to Famicom Disk System. I had to reply that I lack an FDS with which to test it. Is there demand for an FDS port among anyone else?
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
I don't follow, the FDS is not itself a platform, it has no video output, it just uses the Famicom output and there is already an NES/Famicom port of the 240p test suite.
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
It will serve a specific purpose. When I made the Sega CD and PC Engine CD/SCD versions, teh intention was to reach a wider audience, since burning a CD is (easier?)/cheaper than owning a flash cart.PinoBatch wrote:I have received a private message on forums.nesdev.com asking for a port of 240p test suite to Famicom Disk System. I had to reply that I lack an FDS with which to test it. Is there demand for an FDS port among anyone else?
In this case, a similar scenario is possible, but in the same manner not as common. People with an FDS Stick http://3dscapture.com/fdsstick/ It could also include specific tests for the FDS hardware (teh extra audio channel or something like that I guess).
But other than that, you'd only be widening the possibilities of someone using it, albeit in a smaller way of course.
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
great to see updates on this
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
I still plan on doing other versions this year, just have been busy on preservation projects.GeneraLight wrote:great to see updates on this
-
- Posts: 117
- Joined: Mon Oct 30, 2006 10:44 pm
- Location: France
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
Hi Artemio!
Do you have plans to make a Neo Geo version compatible with the Neo SD?
Thanks for your awesome work!
Do you have plans to make a Neo Geo version compatible with the Neo SD?
Thanks for your awesome work!
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
Hey, unfortunately I don't have a Neo DS.. but there is already a version of the suite for Neo Geo, called "Neo Geo monitor test tool": http://junkerhq.net/xrgb/index.php?titl ... AES_and_CDViolent Ken wrote:Hi Artemio!
Do you have plans to make a Neo Geo version compatible with the Neo SD?
Thanks for your awesome work!
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
Hello,
I ported this to PS1.
For now this version lack of:
-Help texts
-Alternating 240p/480i test
-100 IRE test pattern
-Interlaced video modes
And pal resolution is only 256p
https://github.com/filipalac/240pTestSuite-PS1
I ported this to PS1.
For now this version lack of:
-Help texts
-Alternating 240p/480i test
-100 IRE test pattern
-Interlaced video modes
And pal resolution is only 256p
https://github.com/filipalac/240pTestSuite-PS1
Re: 240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD
I just so happen to already have it included in my profiles package for the Framemeister. Simply put it on your SD card with the ROMS, and it will show up in the menu list as "Monitor Test Utility". It's invaluable for adjusting A/D in the Framemeister to match the console's RGB output using the color bars test pattern.Violent Ken wrote:Hi Artemio!
Do you have plans to make a Neo Geo version compatible with the Neo SD?
Thanks for your awesome work!
-FBX