artemiourbina / 240ptestsuite Goto Github PK

Hi!

I've been using 240p Test Suite for ages and it's been one of my favorite utilities.

I think I've discovered a bug, however, which you can see here:
https://github.com/ArtemioUrbina/240pTestSuite/blob/master/240psuite/Dreamcast/PVR/vmodes.c#L359

data = 0x03 | 0x3f << 8 | 0x319 << 12 | 0x0f << 22;

Should be:

data = 0x03 << 8 | 0x3f | 0x319 << 12 | 0x0f << 22;

The reason I believe this to be a bug is because I was looking at a disassembly of my own Dreamcast BootROM (BIOS), and saw that it uses a value of 0x03f1933f.

By the same token, I think all of the regs[0x38] assignments in vmodes.c have that << 8 in the wrong place. This may be the underlying cause for your note that states that US Dreamcasts corrupt a PAL signal; they should not as they all have the same video hardware. It's just some region parameters in the internal flash memory that differ between the models.

480i NTSC looks like it should be 0x07d6c63f
576i PAL looks like it should be 0x07d6a53f

Attempting to run make in 240pTestSuite/240psuite/Wii/240pSuite results in
textures.scf
make[1]: *** [/opt/devkitpro/devkitPPC/wii_rules:25: textures.tpl] Segmentation fault (core dumped)
make: *** [Makefile:105: build] Error 2

If it matters, this was built on Linux Mint 20, using the devkitpro package obtained here

Is the "356x239" here a typo perhaps? :)
https://github.com/ArtemioUrbina/240pTestSuite#super-nintendosuper-famicom

Hello! I'd like to say for reference that I'm currently conducting thorough tests on how the Wii U outputs and upscales Wii content (and how bad it is...)

I don't know how well known it is, but the Wii as a matter of fact outputs with a width of 720, both in Progressive and Interlaced modes. This is the case for the Wii U yes, but I tested and verified the original Wii outputs this resolution also.

It's actually somewhat of a feature... In summary, the framebuffer is (more or less) hard-limited to a width of 640 and a height of 528. However, the image can be stretched vertically by(?) the XFB to a height of 576, and it can be stretched horizontally by(?) the VI to a width of 720.

Also, there is already an Option to stretch vertically to 288 / 576 on Wii (but it's impossible to maintain the 1:1 pixel-aspect). My request is for a similar feature to stretch horizontally to 720 (still impossible to maintain the 1:1 pixel-aspect).

This feature would allow for better determination of horizontal overscan; I believe right now the program is outputting 640x480 and the Wii is naturally letter-boxing it, so the program would always show an "overscan" of 0 because horizontally all 640 pixels are obviously in frame. (In theory... I haven't tested this on an original Wii just yet but I have tested on Wii U.)

Side notes:

• I don't know whether or not this whole system also applies to the GameCube, they are quite similar hardware after all, but I think it might output 640 pixels wide all the time unlike the Wii. I will test and confirm this on console and get back to you.
• If you want to see some of my empirical testing results and data, I can link a Google Document, but it's very unfinished at the moment.

There are no build instructions in the repository at all or if there are I can't find them. As the saying goes, a source repository without instructions is worth nothing ;3

In particular, I'm trying to build the megadrive version. Using the ususal SGDK build commmand results in a lot of errors. Is a customized SGDK needed?

help.c: In function 'ChangeResolution':
help.c:31:17: error: 'APLAN' undeclared (first use in this function)
  VDP_drawTextBG(APLAN, "Resolution can be changed by", TILE_ATTR(PAL0, 0, 0, 0), 4, (*y)++);
                 ^~~~~
help.c:31:17: note: each undeclared identifier is reported only once for each function it appears in
help.c:31:2: error: too many arguments to function 'VDP_drawTextBG'
  VDP_drawTextBG(APLAN, "Resolution can be changed by", TILE_ATTR(PAL0, 0, 0, 0), 4, (*y)++);
  ^~~~~~~~~~~~~~
In file included from C:/SGDK/inc/tools.h:15:0,
                 from C:/SGDK/inc/genesis.h:15,
                 from help.c:22:
C:/SGDK/inc/vdp_bg.h:323:6: note: declared here
 void VDP_drawTextBG(VDPPlane plane, const char *str, u16 x, u16 y);
      ^~~~~~~~~~~~~~
[...]

This suite forces PAL video mode on my European wii, even when I regionhack it and use the hack to have NTSC video on games. I really don't know where this suite gets its information. My CRT is only NTSC so I have wrong colors with this suite. I think options for different video modes on wii can solve this.

Hi @ArtemioUrbina . Like the work you are doing here! I have been trying to make this compatible with the latest libdragon version: https://github.com/N64-tools/cmake-demo-rom/tree/develop-display-testsuite
using this fork: https://github.com/N64-tools/libdragon/tree/develop-displaytest

I am just wondering what you had working when you first built it so that I can (attempt) to get it all working as well...

BTW, I am creating the libdragon and ROM's with VS2019 on windows (and my ultimate goal is to ensure compatibility across platforms, so I would be unsurprised if some of my issues result from that)... also I am on the n64brew discord channel if it helps...

Thanks,

Robin.

On the darker setting for the color bars pattern (00-1F) Red and Blue bars are swapped. Confirmed only with the Wii version, unsure about other builds. Screenshot from an emulator as I was unable to get a decent photo.

Tested on real TG16 hardware with the latest GitHub PCE TestSuite built, I can only get the Composite filter to work once.

On the first toggle it works as expected but subsequent toggles afterwards don't appear to do anything.

Hi

I number of months ago for the neogeo diag bios I went through and recorded the REG_SYSTYPE and REG_STATUS_A values for all MVS models and found you can determine if a board is 2 slot board (code).

 bit6 of REG_SYSTYPE | bit5 of REG_STATUS_A | slot count
---------------------+----------------------+-----------
         0           |         0            | 2 slot
         0           |         1            | 1 slot
         1           |         0            | 4 slot
         1           |         1            | 6 slot

I don't have a flash cart or I would have created a patch and PR. I did however have a 240p cart show up today from SAG. If its helpful I can take a picture of 240p Test Suite's registers screen on each MVS model to show this.

The one downside is mame doesn't correctly set REG_STATUS_A bit so it shows up as a 2 slot.

Thanks for all your work on the 240p Test Suite. It will be a great addition at helping diagnose issues on faulty boards.

I have ogxbox, and would love to see 240pTestSuite run as native application in it.
The ogxbox has been modded so it's not a problem to display patterns in image/picture format, or run S/NES version on its emulator. But am not sure for the accuracy of the display from the emulators or the custom dashboards.

I find the 240p test suite interesting as someone who has worked on simulating CRT displays using GPU shaders. There are some additional kinds of test patterns that would be useful for testing these shaders:

1. Gamma test. This works by comparing a pattern of alternating horizontal lines (which can be averaged optically) with a gradient of solid colors: see e.g. the calibration page here.
2. Frequency response. A system with limited video bandwidth will blur the image horizontally. Combined with the nonlinear gamma ramp, this tends to darken areas with high-frequency information. A practical test could be implemented similarly to the gamma test, but with vertical rather than horizontal lines.
3. Artifact colors. With NTSC or PAL composite video, high-frequency luma information can get mixed with chroma and vice-versa. This is responsible for e.g. the famous rainbow waterfalls in Sonic 2. Test patterns for these effects would have to be system-specific, since the details of the composite encoding can vary. For NES, I'm aware of two NTSC test roms: tvpassfail and this "torture test".

Is there any interest in adding these kinds of patterns to the test suite?

Have dumped euro v2.11 bios (submitted to mame)

I was looking at adding some more diagnostics to the PCE version and even managed to do so in a somewhat hackish way. However, I noticed after a while that the options/help/credits menu and the "TG-16" and screen resolution in the bottom right of the screen were getting corrupted. If I remove enough string constants from my code (e.g. statically declared, text for put_string(), etc.) it goes back to normal. I suspect this is due to overwriting something in a particular memory location, certain banks being full, or similar. Being new to PCE development I don't really understand what's happening but maybe someone has experienced this before and can determine the cause (and hopefully solution). To reproduce: add a long string constant to test_sound.c for example.

I get this error :

Compiling Soundbank ...
@/c/snesdev/devkitsnes/tools/smconv -l -s -o soundbank -v -b 5 samples.it
make: *** [Makefile:84: soundbank.asm] Error 127

Is it missing soundbank.asm ? Thanks.