240p test suite for DC,PCE,Wii,SNES,GC,MD and SCD

[paulb_nl]

I would like a way to have more precision in the lag test. I take photos with 1/1000s shutter speed so I can get 1ms accuracy. On the photos I can easily see at which line the CRT is outputting but for a lcd screen its difficult to see. Maybe a vertical bar that changes color each frame with percentage or ms markers.

[Fudoh]

You can't get more than 16.7ms accuracy, since the console's output is fixed to 60Hz and you can only refresh the image information once a frame. The lag test (the one with the eight circles) already gives you that. Along with a ms display. If you take comparison pics with a CRT and a LCD you can average across a series of pictures (and you can interpretate the CRT readings down to a scanline level). This way it gets rather precise.

[paulb_nl]

You can't get more than 16.7ms accuracy, since the console's output is fixed to 60Hz and you can only refresh the image information once a frame. The lag test (the one with the eight circles) already gives you that. Along with a ms display.

I have compared my lcd monitor to my CRT with the camera method with lag test with circles and found it has ~2ms input lag compared to the CRT so yes you can have more accuracy.

If you take comparison pics with a CRT and a LCD you can average across a series of pictures (and you can interpretate the CRT readings down to a scanline level). This way it gets rather precise.

Thats exactly what I am doing and as I said the problem is that on a lcd screen you can't easily see which scanline its outputting unless its scanline position is at the time or a color changing circle. With a full height vertical bar that changes color every frame I could more easily see which scanline the lcd screen is outputting compared to the CRT.

[Guspaz]

You can't get more than 16.7ms accuracy, since the console's output is fixed to 60Hz and you can only refresh the image information once a frame.

The output of the display chain is not synchronized to the input framerate, and so the accuracy of lag measurements have nothing to do with the total amount of time per frame. That might be true for testing console input lag, but for display lag, any value is possible. Look at the Framemeister, which has around one and a half frames of lag, not one or two.

[Fudoh]

Thats exactly what I am doing and as I said the problem is that on a lcd screen you can't easily see which scanline its outputting unless its scanline position is at the time or a color changing circle. With a full height vertical bar that changes color every frame I could more easily see which scanline the lcd screen is outputting compared to the CRT.

your LCD doesn't refresh over a whole frame as your CRT does. LCDs work on a sample and hold basis. Meaning the whole frame is refreshed as fast as possible (let's say within a ms) and is kept like this until the next frame is ready. With a fast camera you're sometimes able to grab a photo during that refresh period, but that's misleading as it doesn't correspond to the actual refresh cycle of the input.

[paulb_nl]

your LCD doesn't refresh over a whole frame as your CRT does. LCDs work on a sample and hold basis. Meaning the whole frame is refreshed as fast as possible (let's say within a ms) and is kept like this until the next frame is ready. With a fast camera you're sometimes able to grab a photo during that refresh period, but that's misleading as it doesn't correspond to the actual refresh cycle of the input.

If that were true then on my photos I would see the color changing circles become red entirely instead of top to bottom like I see on my photos. The Leo Bodnar lag tester would also show about the same values for the three bars for every lcd display. Instead it shows about 8ms difference between the bars as expected with top to bottom scanning.

Sample and hold means the pixels of the previous frame stay on screen instead of fading away like on a CRT. That is the reason why its difficult to see which scanline the lcd is outputting compared to a CRT on the lag test screen.

[Fudoh]

The Leo Bodnar lag tester would also show about the same values for the three bars for every lcd display.

that's actually what happens on many LCDs (about 3ms difference between top and bottom on my 52" Sony). But I get your point.

[paulb_nl]

I thought it would be fun to try to add the vertical bar to the lag test. First challenge was trying to get it to build for the snes succesfully. It would error out saying the obj files were not from the same project. Took me a long time to figure out that you have to match the hdr.asm in the pvsneslib folder to the one in the 240psuite folder and then rebuild pvsneslib sources.

Finally I had the ROM but it froze at the menu before the mosaic was finished. Checking in the no$sns debugger I saw there was a brk instruction that was not in the assembly source. I don't know how to fix that so I I just commented out the setMosaicEffect function calls.

Now it was working. I changed the lagtest bitmap to include the vertical bars and the source to change the color every frame.

This is a photo of my Sony lcd tv. You can see the scanline position is between the circles. Without the bar I would not be able to see that.

[Fudoh]

That's a neat implementation! You should share the changes with Artemio, so he can include it on all future builds.

[paulb_nl]

Thanks. Sure but its only 3 lines of code added to change the color and the bitmap changed to add the bars so it's very few changes.

[Artemio]

Excellent, please share them via your preferred method so I can include them in future releases for all platforms.

[PinoBatch]

Another update for the NES remake

0.09 (2016-06-26)

• CPU clock speed no longer changes "Dendy" in main menu to "PAL" (reported by Eugene.S)
• Manual lag: Audio on by default, and when enabled, beeps for A Button presses and flashes when reticles align (parity with SNES test 1.03)
• Added Audio sync test: Press A to make the dot bounce and beep when it hits the floor
• There's another change. Blink and you'll miss it.

Incidentally, the activity I use most often is the lag test with circles (called "Stopwatch" in the NES version). I use it to time body weight squats on leg day and push-ups on arm day.

[TheShadowRunner]

Artemio, have you seen these new mini SNES/MegaDrive test roms?
http://www.hdretrovision.com/free-stuff/
Just thought I'd mention it ^^;

[Artemio]

Artemio, have you seen these new mini SNES/MegaDrive test roms?
http://www.hdretrovision.com/free-stuff/
Just thought I'd mention it ^^;

Yes, thank you. We've exchanged mails in the past, they are really nice guys.

I've been working on an N64 version of the suite. As usual there are specific issues to deal with on each console. In this case though, I've found out that the N64 isn't capable of displaying the full 320x240 pixels in its frame buffer, and it cuts out 1-3 pixels on each border. I'll see how to deal with that, I guess that warnings on all relevant patterns that are involved on that.

I still have to figure a bunch of stuff out, been working with DMA and the RSP to move around bitmaps in the frame buffer, and doing verticla scroll. The horizontal scroll will either suffer a 4 pixel scrolling effect or I'll have to write some microcode to try and copy that in some other manner.

It is still very early in development and I had to cease for a week or two, but will continue to develop it now.

[Einzelherz]

If the PS2 version ever becomes a possibility, one feature I think would be nice is the ability to switch back and forth between Component and RGB without returning to the PS2 system menu.

[NormalFish]

If the PS2 version ever becomes a possibility, one feature I think would be nice is the ability to switch back and forth between Component and RGB without returning to the PS2 system menu.

If it's possible to implement this, it would be good to set up some sort of "should we keep this setting?" Warning to prevent having to navigate menus blind.

[Fudoh]

If it's possible to implement this, it would be good to set up some sort of "should we keep this setting?" Warning to prevent having to navigate menus blind.

doesn't really matter this much, since if you're using a RGB cable you get a picture either way (just green tinted when the system's set to component) and using a component cable you'll never get a picture with the system set to RGB (for 240p and 480i).

[Einzelherz]

The only thing is sync changing from internal to external and back. But setting it so X or whatever cancels the change within 5 seconds would be more than enough, I think.

You could probably put a sync on green mode in there, too.

[austin532]

As much as I would also love a PS1/PS2 suite, it doesn't seem like it's going to happen. At least not anytime soon.

[Artemio]

I'll work on a ps2 suite later this year. There is no open source sdk for ps1 though. I wanted to do a ps1 version first, but that doesn't seem possible atm.

I'm not a big fan of the n64, but I got a local cartridge at an excellent price and there was demand for it. It's been challenging in unexpected ways, and want to do the best I can with it.

[Guspaz]

Have you looked into it recently? There has been an opensource SDK for the PS1 since around 2010:

http://unhaut.x10host.com/psxsdk/

[Artemio]

I'll look into it, thanks. Hard to keep track on everything

[beer monkey]

A PS1 version injected into a PSP Go (or 3000) would make for an amazing pocketable test device. I'm kind of dying for it.

[PinoBatch]

But what would you test with a PSP? The built-in display? (Or can its video output scale up to the whole screen rather than being stuck in the 480x272 pixel window used by games?)

Anyway, Artemio reported to me that that the gray ramp was broken in version 0.09 of the NES port. I have fixed it in 0.10. But to fit the vertical scroll test while keeping the ability to run on both UNROM and BNROM boards, I'd need to make a few changes to how graphics are laid out in ROM. (I also don't want to rely on chocolate-coated biscuit sticks or Sly Stallone in a boxing ring.)

[Guspaz]

But what would you test with a PSP? The built-in display? (Or can its video output scale up to the whole screen rather than being stuck in the 480x272 pixel window used by games?)

The PSP Go supports PS1 games, and it supports 240p output via YPbPr, making it a great way to play digital downloads of PS1 games on a CRT. In fact, possibly the best way, because I think it's the *only* console that can play legal PS1 digital downloads in 240p.

[Pasky]

Is there a N64 version in the works by chance? Thanks.

[Artemio]

Is there a N64 version in the works by chance? Thanks.

http://shmups.system11.org/viewtopic.ph ... 0#p1196890

Regarding a PSP version, it will be fun when I get to it. It was the third console I wrote homebrew for, 12 years ago... I bet things have changed for the best.

[silvercool2k]

Is there a N64 version in the works by chance? Thanks.

http://shmups.system11.org/viewtopic.ph ... 0#p1196890

Regarding a PSP version, it will be fun when I get to it. It was the third console I wrote homebrew for, 12 years ago... I bet things have changed for the best.

Hi I am interested in the PS1 240p test suite, is it ready? and where can I find the link to download the image.

thanks!!

[PinoBatch]

NES version updated to 0.12. Summary of changes: Gray ramp unbroken; CPS grid colors no longer reversed; manual lag test result readable even if final press is Marvelous; added vertical scroll test with redrawn tiles; changes to Stopwatch/Lag test to improve usability on black-and-white reference monitors and Hi-Def NES board

[Artemio]

Hi I am interested in the PS1 240p test suite, is it ready? and where can I find the link to download the image.

thanks!!

No, everything is available form the same sites. I've not started work on a PS1 version yet, but I finally got a PSIO in order to start development.