pinobatch / 240p-test-mini Goto Github PK

On SGB, GBC, and GBA, the PLUGE pattern, SMPTE color bars pattern, and color bars on gray pattern include an approximation to NTSC's 7.5 IRE setup. For example, "red" is (23, 2, 2) in 75% mode or (31, 2, 2) in 100% mode. PLUGE also has a mode without setup, which its help page describes as intended for NTSC-J.

Recently in the gbdev Discord server, SameBoy developer @LIJI32 requested a mode without setup that draws red as (31, 0, 0), for two use cases:

• Testing Super Game Boy or Game Boy Player on NTSC-J sets
• Testing color purity in emulators' simulation of the GBC and GBA displays

Ensure that NES, GBC, and GBA Stopwatch behavior matches that of 240p Test Suite (for Sega Genesis and Sega CD) version 1.16:

• Even frame number in blue, odd frame number in red
• Vertical strips at the left and right that are black during even frames, white during odd frames

Because of video memory bandwidth limits on GB and NES, I'd prefer to replace the vertical strip at left with a third mode for the ruler that has it on during even frames only.

Linearity quadrant (179070b) and IUR (7182b21) made enough space for SGB colorization (#17). HRAM (#19) and Huffman (#21) made enough space for adding the border proposed in 352c056. I'll first need to figure out an efficient data representation. I'm thinking IUR mixed with reuse of entire rows.

240p Test Suite (for Sega Genesis and Sega CD) version 1.16 adds a second pattern in the Sharpness test that's a solid screen of the following 8x8 pixel isometric brick wall pattern. Pressing C toggles between this and the normal pattern.

This is the palette: RGB4(2,0,0), RGB4(4,2,2), RGB4(6,6,4)
This is the pattern:

22111111
11221111
11112211
01111022
22011102
11221002
11112202
11111122

Make this pattern reachable in the NES, GB, and GBA suites.

When the user does Start+Reset to skip straight to MDFourier, the Genesis port of 240p Test Suite reportedly plays a tone indicating that it is ready to start playback even if the video output is disconnected. Characterize this tone then replicate it on the NES and GB ports.

I have a famiclone called FC-RGB that uses a PPU FPGA and original CPU and for the test "Color bars on gray" glichs appear after some time, between 30 and 60 seconds later. Is there any explanation for this? I'm also using an N8 China version Note: This problem only occurs for versions greater than 0.12. Test all versions besides this one and all of them show these glitchs. Sorry for my bad english.

Right now the biggest test by far is Linearity because it encodes four distinct images that don't compress well using PB53 map. Their total compressed data size is 9617 bytes.

• Need at least two, as pixel aspect ratio differs on NTSC and PAL.
• Linearity and Linearity with grid are separate pictures that share no data, unlike on GBC and GBA where the grid is added at runtime.
• Linearity with grid in NTSC doesn't have a lot of horizontal runs because its background is a 56x8-pixel (7x1-tile) pattern.

The plan is

• In the map, encode tiles seen for the first time more efficiently, as Linearity uses essentially no horizontal repeats of nonblank tiles.
• Encode tiles seen before with fewer bits, especially early in the map data.
• Encode the same tile multiple times if it appears in positions with different phases against the repeating grid. This allows adding the grid in post-processing.

The steps are

• Make a unique tiles finder that respects grid phase
• Make a bit packer in Python
• Pack using 0 for a blank tile, 10 for a new tile, or 11xxxxx to repeat an existing nonblank tile (variable count of X's based on log2 of number of nonblank tiles so far)
• 6502 decoder for nametables in this format
• Create grid pattern table from nongrid pattern table using nametable readback to determine phase for each tile number
• Integrate this into the main executable

Because of the lack of space in the Suite's fixed bank, I may have to prototype new Linearity in a separate folder. But I fully expect to save 5K with this technique, or more if I can apply it to the other SB53 maps in the suite.

From the help file for "Solid screen" in GB and GBA versions:

Poor high-voltage regulation in a CRT causes image size to depend on brightness.
This changes the width of the border on [Super Game Boy or] Game Boy Player.

The NES version's "Solid screen" is big enough that it can't be used as a test for HV regulation. However, "Overscan" could be made ideal for this. Bind Select to invert grays, as on the GB and GBA versions, and the change in border width when the screen is inverted can be quantified.

The header of 144p Test Suite for Game Boy is marked as Super Game Boy enhanced so that it can detect SGB (via the MLT_REQ packet) and display "SGB" or "SGB2" in the lower right corner of the main menu.

As of right now, we have 1.25 KiB of free space in the ROM. This should be enough to try colorizing at least one thing. Because most tests (other than Motion blur) use a small number of palettes that don't change their individual colors, we can PAL_TRN most of them at init time and load them at the start of each test with PAL_SET.

These could use SGB colorization, in roughly descending priority:

• Give most tests a static (31, 21, 11, 0) palette
• Help should still be colorful though
• Red border in Grid
• Motion blur (will need PAL01 instead of PAL_SET)
• "Color tests" menu for SGB
• PLUGE
• Color bars on gray
• Color bleed
• Gray ramp (finer than DMG but less fine than GBC)
• Solid screen
• Sharpness: brick palette when brick wall is showing
• Lame boy

Replicating GBC enhancements in these may not be practical due to SGB limits:

• Gradient color bars (unless we want to go NES-style)
• SMPTE color bars (would need more than 4 subpalettes unless we distort the bar widths more than on NES)
• Shadow sprite
• Hill zone scroll
• Vertical scroll

Hi,
i want to ask if the suite supports also the Japanese NTSC Famicom :)

Thank you!

In 240p Test Suite v0.23, I added a feature to automatically display a build identifier generated using git describe --tags. Most of the work was done around commit c056e59, in turn based on the work I did for the same feature in Holy Mapperel.

git describe --tags | tr -d '\r\n' > obj/nes/last-commit-now`

When Git cannot find an appropriate tag, this produces a blank file. This can happen when building 240p Test Suite in three situations: from a zipfile, from a shallow clone, or (a decade or two from now) once the maintainer has migrated to a VCS other than Git. This leads to a blank version number on the Credits screen. Currently we avoid a blank version number in GitHub Actions builds by avoiding a shallow clone (#45).

A user of the gbadev Discord server has characterized reliance on git describe --tags to display a version number as "a bug in your build process. My NDS SDK can detect if it isn't building in a git repo, and it doesn't try to use git describe." How can we provide a useful version number for a copy of 240p Test Suite built from a zipfile without adding yet another manual step to release_checklist.md and renumbering all steps that come after it?

Now that the GB suite's help screen is enhanced for Game Boy Color, we can decide which tests exclusive to GBC can be added to the list for the benefit of Game Boy Player owners.

• PLUGE
• Gradient color bars
• SMPTE color bars
• Color bars on gray
• Color bleed

If this were Super Game Boy, I'd suggest SGB audio and chroma crosstalk. But after adding GBC tests and GBC enhancements to existing tests, I'm not entirely sure I'll be able to fit SGB tests in the remaining space on the 32 KiB Catskull cart that we're currently targeting.

I'll request GBC enhancements to existing tests in a separate issue.

Please replace the makefile to be more forward compatible with new versions of devkitARM, per pinobatch/gsmplayer-gba#2

pulse wave on C major scale for standard controllers or chromatic for SNES or Power Pad, treat all controllers' buttons the same, set note when button is pressed, cut note when all buttons released

The three most used subroutines, totaling 67 calls, are clear_gbc_attr, read_pad_help_check, and pb16_unpack_block. See if there is other redundant code at the call sites that can be factored into the subroutines.

Merge PAL phase test at https://github.com/pinobatch/little-things-nes/tree/master/palphase as a variant of color bleed for the NES version

Right now one of the biggest things in segment RODATA (in the fixed bank) of the NES version is screen layouts. Moving these to a different bank, as with PB53 compressed data, would let individual UNROM builds make tradeoffs between keeping more of the fixed bank free (see #12) and keeping one contiguous 16K bank free.

The entry points are

• audiosync.s: rf_draw_rects_attrs_ay
• megaton.s: rf_draw_rects_attrs_labels_ay
• overscan.s: rf_draw_rects_attrs_labels_ay
• overclock.s: rf_draw_rects_attrs_labels_ay
• stills.s: rf_draw_rects_attrs_ay and rf_draw_rects_attrs_labels_ay (plus one rf_draw_rects that can be changed)
• zappertest.s: rf_draw_rects_attrs_labels_ay
• soundtest.s: rf_draw_labels (credit for "Crowd")
• stopwatch.s: rf_draw_labels

First I want to narrow the interface to one call: rf_draw_rects_attrs_labels_ay. Each list without labels would get an additional $00 after it. And each labels-only stream would begin with $00, indicating that there are no rects or attributes to render or push.

Then I'd move all layout files to a new file "rectfiles.s", along with their corresponding rf_tilenum and rf_curnametable values. (Only two nametables are ever drawn to $2400: gcbars_grid and cpsgrid_240p_rects. None are drawn to both.) The loading mechanism would resemble that for SB53 files. With the interface narrowed in this way, the fixed bank code would switch to the bank containing gate data, load the layout, and switch back to the program bank.

• Narrow the interface to rf_draw_rects_attrs_labels_ay
• Move layouts to rectfiles.s with new loading mechanism rf_load_layout_file
• Move layout files to gate data bank
• Give PB53, SB53, IU53, and layout files importable names, using an export macro like sfxdef in the Pently audio driver
• Make help bank/CODE02 the default in UNROM, switching out only when loading PB53, SB53, IU53, or layout, and switching back afterwards, and remove inline bank switching code from files other than bnrom.s and unrom.s

To make noise match better, it might be helpful to catch holding Start+A at power on and immediately go to MDFourier in play mode.

Has anyone been able to use the suite on the super card sd for GBA?

Thanks!

240p Test Suite (for Sega Genesis and Sega CD) version 1.16 adds a second pattern in the PLUGE test: Press C to draw some "Fire Shark" graffiti tag in color, dark, or light palette (select with A).

Make this reachable on NES, GB, and GBA.

During downtime of the NESdev BBS, j4m13c0#2021, Fiskbit#8021, and lidnariq#1779 in the NESdev Discord server are studying the Famicom Box, a coin-operated NES variant console with 15 slots intended to connect to a hotel TV. It's somewhat analogous to the PlayChoice 10.

Famicom Box displays a title depending on the contents of an internal header that prefigures the internal header in Game Boy and Super NES games. This header occupies $FFE0-$FFF9. Some North American games also appear to be a lot easier to obtain in Japan than others.

• Stay out of $FFE0
• Rearrange to three banks again to make free bytes contiguous
• Add MMC1 support (SGROM, SNROM, SUROM)
• Add MMC3 support (TGROM, TNROM, TQROM)
• Add Nintendo header

The help pages repeat several entire lines of instructions and other text. In particular, most tests' titles are repeated between the menus and the test titles. Find a way to capture redundancy of repeated nonblank lines, particularly on GB where space is hard to come by. I'm thinking putting all repeated lines of text at the end of helptitles, and having an opcode at the start of each line to write a page title instead of this line. I estimate it could save 300 bytes.

Using the GBC port, in the shadow sprite demo, the text that describes the mode is rendered incorrectly. Looking at the tile RAM, it looks like the Donna image overwrote the text for these sections.

To reproduce:

1. Build the current git version for GBC
2. Boot the program and select the "Shadow sprite" demo
3. Press A + Up and observe that the text isn't rendered properly on the lower right
4. Press A + Right to switch to the next background
5. Press A + Up and observe that the text is rendered properly, this is the expected behavior

When I added Super Game Boy colorization (#17), I managed to fit a lot of it into 1.25 KiB by sharing many code paths with Game Boy Color. I often ended up testing for GBC and SGB one after another. If the init code populated one variable, it'd be shorter to test for both. So introduce a new HRAM variable hw_capability with one of these values:

• $00: Monochrome handheld (DMG, MGB)
• $01: Super Game Boy (SGB, SGB2)
• $80: Game Boy Color with analog DAC (CGB)
• $C0: Game Boy Color with PWM DAC (AGB, AGS, DOL-017)

Test for Game Boy Color:

  ldh a, [hw_capability]
  add a
  call c, gbc_only_setup

Test for Super Game Boy:

  ldh a, [hw_capability]
  rra
  call c, sgb_only_setup

Test for monochrome handhelds:

  ldh a, [hw_capability]
  or a
  call nz, sgb_gbc_setup

Then initial_a would be needed only for distinguishing Game Boy from Game Boy Pocket or SGB from SGB2, which matters only in the machine type display at the lower right of the main menu.

Prototype monoscope image by Lorenzoone

At 44:26 in the video "Game Boy Advance Drop In Backlight Kit" by makho, it was noticed that Hill zone scroll test has artifacts on the left side of each split reminiscent of the split artifacts in Super Mario Bros. 3 for NES. Figure out what's doing this.

The NES2.0 header defaults to the NTSC region in current 0.23 version.

This causes flash cartridges (i.e faminvite) generate warnings every time 240pee.nes run on PAL systems.
Maybe better soluition to change header region to "both" instead of "ntsc"?

Now that the help screen is enhanced for Game Boy Color, several existing tests in the Game Boy suite could benefit from enhancement as well.

• Gray ramp (32 actual steps instead of 12 quarter steps)
• Solid color screen (custom RGB color)
• Motion blur (change shade 0-3 to 0-31 and it'll substitute for 100 IRE)
• Shadow sprite (colorize the Gus portrait)
• Scroll test
• Vertical scroll test
• Lame boy demo (make it look like nrom-template)
• Grid (make border tiles red for better contrast)

I'm to the point where redundancy within a byte is the only redundancy I can see in the Game Boy suite's assets. I plan to convert the CHR data using Huffman coding a nibble (4 bits) at a time. However, this is slow (22 cycles per input bit, maybe 74 per output byte).

The next steps:

• See if explicit tree Huffman is any faster to decode than the canonical Huffman we're using
• Design bitstream header containing Huffman tree and length
• Compress font
• Design a file system for all assets
• Decompress all CHR in advance
• Shadow sprite: Draw frame type using sprites
• Shadow sprite: Keep GHZ and Gus loaded in VRAM
• Compress CHR outside IU files
• Compress CHR inside IU files

The 2A03's triangle channel has a defined phase at power on, which then changes continuously while the triangle channel is not halted. The output level resulting from this phase noticeably affects the amplitude of the noise and DMC pitches sections of the test (by up to 3 dB), and it adds a constant to the phase of all triangle tests. So we want to distinguish runs when the triangle channel's starting phase (labeled "Sequence Pos" in Mesen) is provably the same as that on cold boot from those where it isn't.

• At cold boot, the phase is trash in a multicart or predictable otherwise.
• After pressing the Reset Button, the phase is predictable. (Source: "CPU power up state" on NESdev Wiki)
• After playing a pulse or noise note in Sound test, the phase is unaffected.
• After playing a triangle wave note in Sound test, the phase is trash.
• After running MDFourier once, the phase is trash.

Artemio mentioned that other versions of 240p Test Suite that include MDFourier skip straight to MDFourier if Start is held at power-on. Thus the following changes should fix the confusion:

• Start held at power up or reset if phase is predictable: Skip to MDFourier
• Calculate the phase as predictable or trash per the rules above
• Display "Triangle phase: OK" or "Triangle phase: Trash. Volumes may be wrong. Hold Start and press Reset"
• If triangle phase is trash, play an extra jingle before and after
• In multicart builds: Option to exit to multicart menu, in order to make exit patching optional so that Start+Reset can work
• Add a 2-frame pulse between the noise scale and the 88-frame steady noise, with pitch determining whether the starting phase was predictable

The majority of HRAM is still free, and reading or writing a variable at a (link-time) fixed address in HRAM using ldh a, [address] takes one fewer byte than reading or writing WRAM using ld a, [address]. So I searched for all variables in WRAM that aren't arrays and sorted them by my guess of their use frequency.

• Widely used: cur_keys, new_keys, nmis
• Rarely used: randstate, initial_b, das_keys, das_timer, curframe_bcd, wnd_x, wnd_progress, help_*
• Hard to measure before fixing #18: is_sgb, initial_a
• Ineligible for optimization on account of being an array fill level used with ld l, [hl]: oam_used

To confirm my hypothesis, I searched through the code and counted ld a, [address] but not ld hl, address because the latter is used with instructions that do not benefit from moving a variable to HRAM, such as cp [hl] or bit 3, [hl].

Evaluated: new_keys (20), cur_keys (6), nmis (5), das_timer (5), wnd_x (4), curframe_bcd: 3, das_keys (3), initial_b (3), wnd_progress (1; most use is through HL)

Perkka in the NESdev server is developing an FM synthesizer that connects to the bottom of the front-loading NES Control Deck. He wants an MMC3 version of the MDFourier tone generator out of not currently having a flash cart to run UNROM programs. If a tiny front end to MDFourier can be made such that the whole thing fits in 8192 bytes at $E000-$FFFF (and I'd bet it can), analogous to the 8K mapper 218 version of my controller test, that would work.

With a gap of over 2 years between tagged releases due to a combination of factors, it has become more difficult to tell what releases I'm giving out. In pinobatch/holy-mapperel@4e48b59 it was suggested to display the tag and Git commit ID. I expect this to affect primarily the various forks of paginate_help.py.

Several upstream ports have switched from Motoko to Donna. Switching from Gus_portrait and Gus_portrait-GBC to a single 4-color illustration of Donna on both GB and GBC would probably save space for not having to store two pictures.

NES overscan is about twice as big as GB overscan, with about half of it spent on preparing buffers to be copied to the tilemap. I'm thinking that doing the top and bottom borders as scroll effects might prove smaller.

Draw the top border by setting sprites 1-9 Y, waiting for sprite overflow, and scrolling from a second solid nametable to the main nametable. Draw the bottom border by setting sprite 0 Y, waiting for sprite 0, and scrolling back to the main nametable.

This will require rearranging the palette to provide opaque BG pixels behind sprite 0: 0 border, 1 arrows, 2 paper, 3 ink. This will also allow distinguishing NTSC side border even when overscan is set to 0.

Once this is in place, corner sprites and corner handling in the left and right side prepare routines can disappear.

Artemio described how the controller test in the other ports is used:

It is used by modders, emu developers, mod developers, contro9ller adapter developers and also by shops or buyers that get a lot of controllers
They want to test a controller fully, yes, but also that the proper input is registering on each controller
if they are testing a batch of 8 conrtrollers, it would be faster to plug them in as many ports are available

Unlike with allpads, we can assume that controller 1 is a standard controller. So if Four Score is plugged in, test 4 standard controllers; otherwise test standard controller 1 and possibly specialized controller 2.

Modes I can think of:

• 10-channel serial analyzer
• Standard controller 1 and 2, Famicom expansion controllers, and microphone
• NES Four Score
• Zapper (move Zapper test to this submenu)
• Power Pad for NES
• Arkanoid controller for NES
• Super NES controller
• Super NES Mouse

khmr33 and Tianfeng in the 240p Test Suite Discord server report that full-screen white is triggering some TVs' automatic brightness limiter. Add a windowed display mode, with the center surrounded by a black border, to see what effect setting the brightness/color of full screen vs. less than a full screen has on a TV. Overscan and IRE have similar effects albeit with limited color choice.

Does not apply to GB and GBA ports, which already run in a window.

Summary

The PAL NES Linear Test large main ellipse is 2 pixels too wide, such that after aspect ratio correction (using the test's own 11:8 PAR assumption), the resulting ellipse is very slightly wider than it is tall.

Disclaimer

I am not sure if this is an actual problem or if there are other factors of NES display that I'm just not familiar with contributing to this disparity. I am by no means an expert on NES display technology and have discovered this problem purely in the realm of emulation, video editing, and online sources. There's plenty I do not understand about how an NES does video, and I fully realize that once this test is used on an actual CRT television, differences like this one that I've spotted are probably totally negligible or might actually be correct when not being shown on a modern square-pixel monitor.

Details

First let me say that all of my calculations and measurements are done in the realm of pixels rather than dots on a TV, so are quite artificial. The PAL NES large ellipse has a width of 176 pixels and a height of 239 pixels. Applying PAR correction yields clean integer dimensions of 242x239. When blown up, and measured in a paint program with a circle tool, the ellipse is slightly flatter than circle. If we instead use the PAR values from nesdev's overscan page (1.3862), the problem worsens as this value is even wider.

Possible Solution

Contracting the main ellipse by 2 pixels makes a nearly-perfect circle after PAR correction. 174 * PAR = 239.25, which is very close to the height.

Example Images

Current PAL Linearty test after scaling the image a bit and correcting for a PAR of 11:8, with paint.NET's circle selection tool visible

My sloppy attempt at redrawing the ellipse in paint.NET:

After blowing up my adjusted version of the linearity test and correcting for PAR, this is the result (with circle tool visible):

The Dreamcast color bleed test has ten horizontal stripes, not just four like the NES, GB, and GBA tests or the MD and SNES tests they were based on.

From top to bottom:

• Red and black
• Green and black
• Blue and black
• White and black
• Yellow and black
• Magenta and black
• Cyan and black
• White and black
• 50% gray and black
• Blue and red

Expand color bleed on NES, GB, and GBA to include patterns like these.

I want the "Marvelous!" stuff removed from Manual lag test (megaton.s) for two reasons:

• megaton on NES is much bigger in bytes than the corresponding test on Game Boy, and #12 is pushing to reduce the suite's fixed bank footprint.
• It was suggested that the grading triggers anticipating the overlap, especially if someone has experience playing rhythm games on a laggy monitor.

Could you add NES2.0 headered versions and/or submit NES2.0 header information to no-intro or NewRisingSun so that the NES2.0-headered and headerless file information is added to their databases?

https://datomatic.no-intro.org/
https://forums.nesdev.org/viewtopic.php?f=3&t=19940

As of 3fbdde4, bank 2 has over 5 KiB free, the fixed bank only 0.8 KiB. Find ways to move more things from the fixed bank to CODE02, as this might prove useful if the Suite is included on a multicart with my other projects.

Also sort out things that might prove useful to keep in the fixed bank even on a multicart: init, pads, ppuclear, random, VWF, DTE, and zapkernel. (PB53 and IU53 are already a library of sorts because of the BNROM port.)