240p test suite

This is an NES remake of Artemio Urbina's 240p test suite, a tool for evaluating TVs and upscalers for compatibility with retro video game consoles.

Current version: 0.18 (released 2019-05-02)
Download or view changes

____________________

In this post, it was recommended to port the 240p test suite to the NES. I made some prototype screens, but I couldn't write any code for it at the time because I was on another project for half a year.

I've been working on it this week. As of right now, about half of the tests are implemented.


See also:
240p topic on shmups.system11.org

Is it helpful to use timed code/DPCM IRQ and the emphasis bits on the PLUGE test?

Good job with the test suite! It will definitely come in handy.

Version 0.02 fills in these tests:

• Solid color screen
• Overscan
• Stopwatch
• Manual lag test
• Grid scroll test
• Backlight zone test
• Sound test

lidnariq: I wouldn't recommend use of emphasis in a test likely to be run on consoles modded with a 2C03 or 2C05 PPU. The 2C02 and 2C07 emphasize by darkening the phases corresponding to opposite channels, but the 2C03, 2C04, and 2C05 emphasize by forcing a particular component to full scale.

For Drop shadow sprite, Striped sprite, and Scroll test, I may need graphical assistance in order to bootstrap the project away from reliance on proprietary art.

• A 256x240 pixel anime style portrait. The original uses Motoko from Ghost in the Shell.
• A 512x240 pixel game background in the generic style of a small-g green hill zone, with a flat floor and preferably with some trees in front for parallax. Raster scrolling is encouraged; I have most of the frame time available to do sprite 0 work. The original uses a screenshot from a Sonic the Hedgehog game.
• A 32x32 pixel enemy sprite that is drawn over the background. The original uses a Buzz Bomber from Sonic.

But the entire point of the PLUGE is to allow calibration of black level and contrast. Not that the NES can produce the 3.5, 7, and 11.5 IRE from the standard SMPTE color bars, but it can produce 14 (emphasis + $2D), 0, and -9 IRE (emphasis + $1D).

You make a good point. I'll use this post to collect feature requests.

• [done in 0.03] PLUGE: Toggle sidebars between color and gray (requested by lidnariq)
• [done in 0.03] PLUGE: Toggle emphasis between none and all, with warning for 2C03/2C05 (requested by lidnariq)

I could do this if you'd like. I'm not sure what it would be. Perhaps I'll draw an anime version of your character?

You want the image colored for an NES, I imagine, as a background? In more than 256 tiles?

This evening I'll go dig up concept art of this and other characters available to me. But if it's easier to draw a different character, that'll work too, as the original has different characters on the menu (Gillian) and in the still (Motoko).


Yes. In one of the tests, I'll be putting two overlapping 32x32 pixel sprites over it, which eats up the PPU's entire overdraw, so I can't use sprite overlays.


If using more than 256 tiles substantially enhances the definition compared to staying within 256, I can cut the title screen into top and bottom portions, with 256 tiles in the top, 192 tiles in the bottom, and the division on a 16-pixel boundary. I say 192 because I need to leave about 64 tiles free in the bottom half for sprites related to the test: 16 for the enemy sprite, 32 for the two frames of the enemy sprite's drop shadow, and 16 for whatever I forgot.

I'm interested to see what you come up with.

I figured the main goal is to have something that you have the rights to so there's no issue there and I thought it would be fitting since he's like the curator of the menu. Plus I think it will be fun to do a quirky version of him.



I doubt I'll need to but just curious. If I do, I'll keep the limitations you posed in mind.

lidnariq: I implemented your suggestions in my tree, and it turns out $2D is noticeably brighter than the mix of $04 and $0C that I've been using. As expected, emphasis made it really dark.


As promised, here's more concept art of this character's race, some more poorly drawn than others: Pictures of polis

That makese sense. Pure $2D should be 34.1 IRE (sync tip depth normalized to -40IRE) or 30.7 IRE ($30 white normalized to 100IRE), while attenuated $2D should be 15.3 or 13.8 IRE...

Meanwhile, pure $0x shades "should" be 15.6 or 14.1 IRE ... at least when there isn't any chroma-into-luma crosstalk.

Here's a rough draft sketch. Any thoughts?

His shoulders are off from one another. I'll fix that.

Good job so far.


To clear up, "poli" refers to the race, and the character depicted in ljbg.jpg is named Gus, short for Gustave Nomeles. (The "lj" stands for a disease, related to a short story I wrote in 2009.)

Time for some lore of my fictional universe:

At first, humans lived on the plain. But thousands of years ago, the plain flooded. We're not sure whether it was an outburst or plain old torrential rain. But in either case, the people escaped in sizable barges and were scattered across the planet. Separated from other human groups, they began to change over time into subspecies, of which these are perhaps the most fleshed out:

• Nander
  Nander have a form of dwarfism that produces a height close to 1.2-1.4 m, significantly shorter legs and a somewhat shorter arms and torso, all the better to work in mines and other tight spaces. As with humans, nander have sub-sub-species or "breeds". One has more facial and body hair. The other somewhat resembles human children.
• Poli
  Polis have no legs due to a mutation in the founding population. This produced a low center of gravity, a need to cooperate more, a habit of hunting via trapping rather than chasing, and a strong "maker" tradition.
• Brownie
  Brownies ended up in the desert and adapted to life there. They're roughly 0.9-1.1 m tall, wearing long ragged brown robes. In human-dominated lands, a brownie is often seen doing a host family's housekeeping in exchange for room and board so long as the family tolerates the brownie's smell.
• Selkie
  Selkies have a physique comparable to Michael Phelps or Gudlaugur Fridthorsson (long torso and arms, short legs, large hands and feet, dense subcutaneous fat), all the better to swim wearing a sealskin wetsuit and foot-mounted fins around their island homeland.

This is what happens when I try to correct the shoulder, apply ink using the levels tool, and apply paint using a multiplied layer of color. But the trouble comes with choosing where the 16x16 pixel boxes go.

This is my attempt at that. I hope I got all the attribute clashes figured out, and I tried to reduce the chr tiles usage while drawing as well. The red line in the middle is where the palette would have to change. Feel free to correct stray pixels, awkward lines and whatever I did wrong with his right (our left) arm.

EDIT: I forgot one last thing about the palette of the eyes.

Palette changes might be a problem if sprites are moving in front of the picture.

Good job so far 43110, but tokumaru has a point. I'm fine with dithering the cap, which frees up one palette. Now how can it be done without a palette split? I've marked attribute boundaries in otherwise blank 16x16 areas.

Coming along well. I see some eye size issues I need to fix. (See how much of the sclera is visible in one eye vs. the other)

Thoughts about palettes: I would have added a second layer of shadow for the rest of the image, had I done it in full color. I just did the shading on the hat during sketching because I felt it was necessary to define the shape. I know we don't have palettes for more colors, but do you guys think the shadow layers in the other colors should be represented through dithering? The tongue color could probably be a decent shadow color for the skin if that's possible.

I think it's going to be inevitable that some colors will have to be removed, right? How can we address this? Perhaps if we use the darker skin tone as one of the main colors for his clothes, and for the other article, we may have to use the color from his hat. Does anyone see any other options? Recycling colors seems to be the only choice.

Okay so I still want to do some more work on it but I wanted to see what you guys thought of the colors I used.

I got it down to four palettes. I don't think there are any palette boundary issues but I didn't check extremely closely.


I would say that the torso looks flat in comparison to the head due to lack of shading. Should I dither the arms and hand?

Honestly I really don't like anime at all (even though I plan on visiting Japan someday... I've already been to Hawaii so I guess I'm halfway there. ) so maybe this is "normal" or something, but what would be the right side of his face (left to us) looks really peculiar, as if his cheek was smashed in by a bowling ball, so instead of making it concave, I made it convex like a normal face:


Also, why dither the clothing if the face is hardly shaded at all, save for that one side? (I tried to copy how you had it) The cap looks really shaded, but that's about it

Good job on palette reduction.

The face needs less dithering for a couple reasons.

1. We have a dark color, which we reuse for his tongue. This makes two shades: full and shadow.
2. Subsurface scattering, which dominates the light from human skin, keeps the lighting more even anyway.

In my opinion, what needs to be shaded are inner corners, such as between each arm and the torso, following the principle of ambient occlusion. The less-lit bottom side of his mitten might use some shading as well. (Wind has "windward" and "leeward"; what are the corresponding terms for light?) But in these cases, you might be able to get away with just making the lines thicker to suggest shading.

credit: darryl.revok/tepples/43110/Espozo

There's an indention on the side of your head (well... I haven't seen YOUR head but I'm guessing it's the same) where your eye socket is. Then it puffs out at the cheek and curves down to the chin. Lowering this jawline helps to define a character as a child or female.

Your way may be a bit less typical for anime but everybody has their own styles. I think if we made a bit of an indention for the eye socket, and then curve out to the cheek and down to the jaw like you have it, would be a pretty good middle-ground.



Palette limitations reduced the amount of shading I wanted to have. There should be a shadow dropped under his chin, and the shading on the right side of his face (left side of the picture) had to be simplified to fit into palette boundaries. Nor was I able to shade under his eyebrows as I wanted.

Even just the little bit of shading on the head to me makes the body and arms look flat by comparison. The shading on the head isn't ideal but it still adds a little bit of volume.



That's exactly what I was thinking.

Thanks. Tonight I plan to make a compromise between the cheek bone shapes in the most recent versions by darryl.revok and Espozo, so I can push out 0.03 with code for displaying the portrait. That'll at least give me a chance to see how many tiles I'm dealing with, so we know how much space there is for shading on the body. Any ideas for the 32x32 enemy sprite or the scrolling background?

If you'd like I can whip up a version with some new line-work and shading, or if it helps to wait until you see how many tiles you'll need, that's cool too.

Either way, if everybody else who worked on it is cool with it, I wanted to make sure whatever rights there are to the image get transferred to tepples so he can do whatever he wants with the program; put it on a dev tool compilation cart or just distribute it online or whatever, without having to ask or anything.



I'd be happy to help with this but it would be fun if somebody else would start the next one out.

How about a character and environment from your character's world? It seems like you've got everything pretty well thought out. Have you considering making a game about it? That's what President was going to be, right?

I don't have anything against the current portrait (besides the hand, which is a bit weird), but you can go anime without going chibi/deformed, if that's what bothers you. Just for the record, here's my attempt at a grown-up version of the character:


Admittedly, the hand is still a little off...!

Pretty cool, tokumaru! I dig it.


Just guessing from your tastes, I have a feeling if you saw some of the darker anime from the 80s/early 90s you might enjoy it.

Are you familiar with Akira or Ninja Scroll?

I fixed the cheeks and did other tweaks all around. The trickiest part was the boundary between the mitten and the vest. Because there's no black+background+vest+mitten palette, I had to move the mitten to the left by about 6 pixels to get it and the vest to touch at the corner of a 16x16 area. I ended up with 213 tiles and thus a trivial display routine. It can be viewed in "Shadow sprite", which I'll finish once I have the rest of the art.



Go ahead and fix the lines and shading if you think it'll make it look better.

0.03 (2015-11-05)

• PLUGE: Added choice of gray ($2D) instead of color ($04+$0A) outer bars (requested by lidnariq)
• PLUGE: Added choice of gray emphasis (requested by lidnariq)
• IRE: Added bottom level of black on below-black
• Unified planned Drop shadow sprite and Striped sprite
• Shadow sprite: Added an anime-style illustration of the mascot by darryl.revok, replacing motoko.bmp

Wait a minute, this is extremely obvious (although no one ever said anything) but why not also use sprites? Also, the head actually resembles a human's now!


Nope. Looked up Akira. Didn't get it. Looked up Ninja Scroll and out if the entire Wikipedia article, this is what I first found... Sound exactly like what I'd want to see!

Yeah...


Actually, now that I think about it, there is one anime I like...

I'm pretty sure sprites were mentioned, and tepples said he needed them all for a couple of moving boxes or something that are part of the test.

If you're looking for anime with more-mature-than-usual stories that don't involve rapist demons, I'll recommend 2 of my favorite anime of all time: the Rurouni Kenshin Tsuioku-hen OVAs (there are 4 parts, it's a sort of prequel to the series, but with a very different tone) and the series (not the movie, which is boring and depressing as fuck!) "X", based on the manga by Clamp. Both have English dubs, but I definitely recommend the originals.

A few days, mikejmoffitt and I were brainstorming alternatives to the Green Hill Zone background for the Scroll Test. This is what I have so far.

It could use better clouds and a mountain backdrop. So far I've only used three of the palettes:
backdrop: 22
grass: 08 1A 29
dirt: 08 18 28
sky: 08 32 20

You can always draw inspiration from the reduced complexity renditions of Green Hill Zone from games like Sonic 1 and 2 (GHZ in this game is pretty different though) on the Master System, or Sonic Pocket Adventure on the Neo Geo Pocket, if you want to stay close to the original theme. If you're going for something more original, I think you're on the right track, although the colors could be a little more vibrant.

If you're gonna include background mountains, be sure to make them look way less saturated than the foreground. Since you don't have parallax scrolling (unless you plan on adding that?), this is kind necessary to properly convey distance.

Yes, I have parallax scrolling. Currently the topmost cloud is still (to act as the sprite 0 trigger), the rest of the clouds are at 1/8 speed, the mountains/water is at 1/4 speed, and the ground is at full speed. It'll be a b#### to get right on PAL though. I haven't made anything PAL-friendly yet.

Ah, cool.


Really? If you're interested, I have a "WaitScanlines" function that receives a scanline count in X and waits that many scanlines, adjusting itself automatically to PAL or NTSC based on a flag. I planned on using it for raster effects but haven't had the chance yet. Let me know if you want it and I'll post it. It's nothing out of this world, but since it's ready...

BTW, are you using any sprites or can you consider using them for the foreground trees (blowing your sprite budget)?

I'd have to adjust the other parts of the loop as well, such as reading the breakpoint list, dividing the X position by 8, and doing that thing where I combine the current strip's fine scroll with the next strip's coarse scroll to fully avoid glitches. I lack confidence in releasing anything that races the beam that I haven't tested on hardware, and I own no PAL NES.


I could put foreground trees in "Scroll test", but they'd blow the sprite budget in "Drop shadow sprite".

Assuming all of that takes a constant amount of time, shouldn't it just be a matter of doing all that, compensating for the scanline duration difference the same way it's done in the "WaitScanlines" subroutine, and then waiting n scanlines until the next split?


Not really sure what you mean here.


You can always take your best shot with emulators, make it clear that PAL support is experimental, and have people with the proper equipment test it for you, no? Otherwise you're never going to support PAL consoles.

The table specifies a right shift of 0, 2, or 3 bits. Currently I loop, but making this take constant time is doable if necessary.


Because I'm not changing the vertical scroll, I'm writing only to $2000 and $2005. Changes to the coarse horizontal scroll ($2000 bit 0 and $2005 first write bits 7-3) have to go in before horizontal blanking, but changes to the fine horizontal scroll ($2005 first write bits 2-0) have to go in after horizontal blanking. So on the last line of a strip, the line immediately before the split, I write the current strip's fine scroll with the next strip's coarse scroll, then later (during vblank), I write the next strip's complete scroll.



I am willing to support this iff there are both A. demand and B. a willing tester who can load builds immediately. But with the reduced prestige of PAL NES, getting it feature complete for NTSC takes priority. After all, it's not called the 288p test suite.

Oh, I get it now. Since you're not using $2006, the coarse scroll doesn't change when you finish the writes, but when the PPU does v:0000010000011111=t:0000010000011111, so you have to do the $2005 write before that, but since the fine X scroll changes immediately, you can't update that part at the same time. Got it.

Anyway, landing a couple of PPU writes on hblank shouldn't be so hard, there's quite a bit of tolerance there.

Here's what mikejmoffitt did to my pseudo green hill zone.

I have only a few final checks before I release 0.04.

With new graphics in hand, I announce 240p test suite 0.04

0.04 (2015-11-16)

• IRE: Added emphasis and $2D/$3D grays
• Shadow sprite: Added full functionality
• Added Hill zone scroll test with Green Hill Zone-inspired background by mikejmoffitt
• Sound test: Added pulse beep (requested by mikejmoffitt)
• Full README file

We seek experts in the following:

• Testing on PAL NES
• Testing on Dendy
• Testing with high-quality displays and scalers
• Measuring the actual IRE levels of NES video with an oscilloscope
• Putting 27C512 onto an UNROM-compatible board

Make me a subset/variant that I can flash onto an 8KiB PRG EEPROM on a mapper 218 (CHRless) card and I will do this.

Was there anything in particular that you wanted to be tested?

In the current build, you can try these:

• Color bleed to see what PAL does with horizontal, vertical, and diagonal lines
• Linearity to see whether it recognizes PAL's aspect ratio
• Overscan to confirm that 2 pixels on the left and right are already hidden
• Shadow sprite: Press A+Up to switch to a striped shadow, then press A to switch among horizontal, vertical, and diagonal stripe patterns and see what they do to the portrait.

Here's a tentative list of changes I'll need to make for PAL support in the next build:

• Color bleed, Full screen stripes: Wrap frame counter at 50 instead of 60 on PAL NES and Dendy
• Stopwatch: Wrap frame counter at 50 instead of 60 on PAL NES and Dendy
• Hill zone scroll test: Reduce all delays by 6.25% on PAL NES only
• Sound test: Decrease tone period slightly to more closely approximate 1 kHz on PAL NES only

I hope to get to PAL over the next few days.

Here's a 1K IRE-only test, compatible with mapper 7 and (presumably) 218. The copy of FCEUX on my PC doesn't appear to support 218 at all.

Here's the measurements into the 75.1Ω of my television:

SYNC: 48 mV / -37 IRE
CBL: 148 mV / -23 IRE
0D: 228 mV / -12 IRE
1D: 312 mV / ≡ 0 IRE
CBH: 524 mV / 30 IRE
2D: 552 mV / 34 IRE
00: 616 mV / 43 IRE
10: 840 mV / 74 IRE
3D: 880 mV / 80 IRE
20: 1100 mV / 110 IRE
0Dem: 192 mV / -17 IRE
1Dem: 256 mV / -8 IRE
2Dem: 448 mV / 19 IRE
00em: 500 mV / 26 IRE
10em: 676 mV / 51 IRE
3Dem: 712 mV / 56 IRE
20em: 896 mV / 82 IRE

There was about 10mV of noise (and 4mV of quantization error) that I could never quite fully get rid of, so the numbers here should be taken as having an error of ± 2 IRE.

I'm curious: why are you specifically calling this out?

This is a very simple thing, so why explicitly mention the 'PROM technology?

Lack of time/tools to prepare a cartridge and make sure the program works correctly even without a Flash cart's boot ROM initializing the system?

That, and I expect some people who haven't made repros before or bought a flash cart to want to learn to make repros just for this test suite, unless perhaps I get it included as a "toy" in the third volume of Action 53. Here's what I have in the current README:

You can also burn it to an NES cartridge with an UNROM board.

1. Chop off the first 16 bytes, which contain the iNES header.
2. Write the remaining 65536 bytes to a 27C512, 29F512, or equivalent 64Kx8-bit EPROM or flash memory.
3. Open the Game Pak's case with a GameBit screwdriver.
4. Desolder the existing PRG ROM from the board. Don't desolder the short skinny chips (mapper and CIC) or the CHR RAM.
5. Make sure the UNROM board's H pad has a solder blob and the V pad is not covered. The suite uses horizontal nametable arrangement, called "vertical mirroring" by the emulation community.
6. Compare the memory's pinout to the pinout for the mask ROM on the UNROM board to see which pins need to be lifted and connected through patch wires to a different hole.
7. Solder the memory in place, and add necessary patch wires.

I gave a pre-0.05 build to thefox, and it turns out PAL NES blanks the top scanline, the one that never has sprites on it. He also confirmed with his capture card the (known) blanking of the 2 leftmost and rightmost columns of pixels.

I could do those if I get my hands on an UNROM board again. I have both, a PAL NES and a NES modded with Dendy Clone CPU/PPU/XTAL.

Thanks. It'd be good to have another pair of eyeballs and another pair of thumbs banging on it, trying to make it break.

240p test suite 0.05 is out

0.05 (2015-11-18)

• Menu: Displays TV system name (NTSC, PAL, or Dendy) in corner
• Made some tests' help pages more concise
• Color bleed, Stopwatch, Full screen stripes: Frame counter wraps at 50 instead of 60 on PAL NES and Dendy
• Linearity: Added a dot at dead center
• Linearity: Reduced the large circle to 224 pixels tall on NTSC and 239 pixels tall on PAL
• Linearity: Moved small circles 2 pixels away from the sides on PAL
• IRE: Incorporates signal measurements by lidnariq
• Overscan: Explained PAL border in help page
• Overscan: Redraws borders after returning from help page (reported by thefox)
• Hill zone scroll test: Corrected parallax strip height on PAL NES
• Sound test, SMPTE color bars, 601 color bars: Corrected frequency on PAL NES
• Sound test: Corrected emphasis color on PAL NES and Dendy

I wonder if it would be better to change the overscan test so that you have to make one pixel visible, instead of having to push it back? I'm just thinking about this scenario, where somebody might want to take a screenshot to demonstrate the amount of overscan; it would be nice if the numbers of screen are valid while the pixel column/row is visible to show that the test was done correctly.


As for the screenshot itself, it's interesting that this capture card actually grabs the bottom 240 scanlines from the 242 produced by NES, so in the bottom border area you can see effects of the palette changes that the test ROM happens to do right after NMI (which happens at start of the bottom scanline). (Just to be clear, this is not new info: viewtopic.php?p=137511#p137511)

I was implementing the behavior described in the existing overscan test's instructions, where the displayed number is the number of white pixels. Here's the wording I came up with for 0.06, which I tried to word more concisely to fit into the help engine's limit of 20 lines per page:

Move each edge inward until
you see the white border,
then go back one pixel. Or
leave one white pixel visible
and subtract 1. The result
is the amount of overscan
in pixels in each direction.

And for this test, I guess it'd be a good idea to move the palette upload after the OAM upload. I'll do that for 0.06.

In "SMPTE color bars" you're using $0D, was that intentional?

Yes. It represents the mini-PLUGE described in the Wikipedia article:

The pluge (short for "Picture Line-Up Generation Equipment") pulse is positioned within the black rectangle, below the red bar (it is present in the illustration but may be hard to see). It comprises three small vertical bars, a rightmost one with intensity just above the saturated black level, a middle one with intensity exactly equal to saturated black, and a leftmost one with intensity just below saturated black (or "blacker than black")

Tested it on my EDN8 for now.
PAL NES with NESRGB gets detected as Dendy.
Dendy NES (NTSC) with NESRGB gets detected as NTSC only.

Other than that I couldn't find anything else other than the top 8 pixels being a different color (brown) in the menu on a PAL console.

This surprises me. Is it using original 2A07/2C07, or is it modded with 6527P/6538 (and CIC bypass) for compatibility with NTSC games? In Hill zone scroll test, are the scroll splits in the right places?


If Steepler made Dendy systems with UMC's NTSC chipset (6527/6528), this would be correct.


Yeah, I'll have to make it clearer that that's the ceiling.

It's original PPU/CPU. Probably my Everdrive acting up, since it's super laggy on the PAL console. I assume it's the cartridge connector since it's not an original when I bought the NES. I ordered some originals and can give more infos on that once they arrive in 2 weeks or so.
Let me test the hill scroll test again.


Alright, then it is correct since I'm using 6527/6528 for the NTSC console.

EDIT: Hill scroll works fine.

EDIT2: I just disabled the PAL CIC on that console. Probably that's the cause for showing Dendy, I guess.

The TV system detection code uses NMI-to-NMI timing, which has nothing to do with the CIC. It counts cycles from one NMI to the next and divides by 2817 to give 10.572 for NTSC, 11.802 for PAL NES, or 12.589 for Dendy. Then it rounds down and subtracts 10 to give 0 for NTSC, 1 for PAL NES, or 2 for Dendy.

• "NTSC" means it detected something close to 113.667 cycles per line and 262 lines per frame.
• "PAL" means it detected something close to 106.5625 cycles per line and 312 lines per frame.
• "Dendy" means it detected something close to 113.667 cycles per line and 312 lines per frame.

What does the overclock test ROM do on your PAL NES?

Eh, I forgot my PAL NES was overclocked to match NTSC speed. I removed the XTAL now and going to test again. It should display PAL now.

EDIT: Displays PAL now and EDN8 works fine again. Didn't know a 28MHz XTAL to overclock the PAL NES would cause such problems.

If you were running your PAL NES's CPU off a 6.4*cb = 28.37516 MHz crystal (and its PPU off the normal 6*cb crystal), that would explain why it was working in Dendy mode. Hill zone scroll test is timed from sprite 0, which is hidden behind one of the clouds in the top (still) strip.

• PAL NES with 28.37516: NMI at 241; OAM writable only during 241-260
  NTSC games with raster effects timed from sprite 0 work
• PAL Dendy: NMI at 291; OAM writable during forced blanking
  NTSC games with raster effects timed from NMI or sprite 0 work

On the one hand, I wonder whether including the overclock test would fall within project scope, as the 240p test suite is to test the TV, but the overclock test is to test the test itself. On the other hand, I expect a lot of people to be using this with kev's Hi-Def NES mod, which includes CPU overclocking as a feature.

Finally got around to try this out. Just some small possible bug reports. The sound tone in both color bar tests does not turn off when exiting, persisting into all other tests. And the menu cursor resets when ever something else uses the menu screen temporarily (like the helps for each test, or the about and credits menu entries).

It will be fixed in 0.06. Thank you for reporting this.


The current logic is "When starting to display a document, if the most recent page is not within the requested document, go to the first page of the document and move the cursor to the top." And menus are also documents. I'll fix this for 0.06.

The overclock test ROM's functionality will also be in 0.06.

240p test suite 0.06 is out

0.06 (2015-11-20)

• First attempt at a ceiling for the help screen background
• Added CPU clock speed test for Hi-Def NES users (requested by Ice Man)
• Saves and restores position on main menu even if the user views a help page or the Sound test submenu (requested by 43110)
• SMPTE color bars, 601 color bars: Silences beep when closing (reported by 43110)
• Overscan: Uploads OAM before palette because some capture cards (and presumably underscanning displays) capture the start of vblank and can see the palette update rainbow streak (requested by thefox)
• Overscan: Clarified meaning of leaving one white pixel on the screen (requested by thefox)

240p test suite 0.07 is out

0.07 (2015-11-25)

• CPU clock speed: Help page mentions real time updates
• Stopwatch: Help page mentions use as a dropped frames test
• Hill zone scroll test (NTSC): Adjusted bottom split's timing

This is a small release to get a few minor bugs fixed. There are really only three things left:

1. Testing on Dendy famiclone
2. Testing with high-quality displays and scalers
3. Detailed instructions for building a cartridge

Some testers in #nesdev on EFnet have been making videos and uploading them to YouTube as unlisted videos. At this point I feel confident enough to make them listed.

Making a cartridge out of it isn't hard at all.
The ROM uses Mapper 2 (UNROM) with vertical mirroring.

Now get a donor cart that uses UNROM as a mapper.
Link to BootGod

Once you have an UNROM board, remove the PRG ROM on the right side of the board.
DO NOT REMOVE THE CHR RAM!

Once done, clean the holes, and use FamiROM (found in the attachment) and split the ROM to the EPROM you're using, then burn the EPROM (I usually use 27c040 since those are easy to get here) and wire it accordingly:

For 28 Pin EPROMS (27c512):
Bend up pin 22
Solder pin 22 to GND (OE)

For 32 Pin EPROMS (27c040):
Bend up pin 1, 2, 24, 31 and 32
Solder pin 2 to hole 22 (A16)
Solder pin 24 to GND (OE)
Solder pin 31 to hole 28 (+5V)
Solder pin 32 to hole 28 (+5V)

When using a 32 Pin EPROM make sure the capacitor on the right from the PRG MaskROM is removed and soldered in from the bottom. Otherwise the EPROM will not fit in properly and the cart won't close.

As for the mirroring: There's 2 jumpers saying H and V.
Since this mapper uses vertical (V) mirroring this one has to be left open and H should be closed.

Hope that helps.

How does a 28-pin EPROM have a pin 31? Copy-paste error?

Haha, yeah. I don't know how it got there. Just disregard pin 31.
1,2,24 should be fine since pin 28 goes directly into VCC hole 28.

But doesn't the pin numbering change for 24 as well if the package is two pins shorter on each side? As soon as these instructions are final, I'll include them in the manual for version 0.08.

Version 0.08 will also contain a fix for a regression elsewhere that 43110 pointed out through a private message. Don't make videos of "Shadow sprite" listed.

I got this off from other notes. Since I'm going to build an UNROM today I will let you know the correct soldering for it with a 28 Pin EPROM.

EDIT: Fixed it now. Only Pin 22 from 28 Pin EPROM needs to be lifted (OE) and connected to GND.

Thanks. This gives me an excuse to include the NMI scanline as an additional line of results in the overclock test.

240p test suite 0.08 is out

0.08 (2015-11-26)

• Shadow sprite: Restored Hepsie's colors (regression reported by 43110)
• CPU clock speed: Displays NMI scanline to distinguish a Dendy famiclone from an overclocked PAL NES (requested by Ice Man)
• CPU clock speed: Reads controller while drawing results to make hotkeys on Hi-Def NES more responsive
• Added guide to making carts based on Ice Man's guide
• Includes a Python program to split iNES ROMs into PRG and CHR

I forgot to add. When using regular NES shell you also have to cut off some plastic on the left side to make the PRG ROM fit inside. I will take a photo of it later.

EDIT: Picture added.

I changed the pinout for UNROM 32 Pin EPROM just to avoid problems, here's the correct pinout:

UNROM 32 Pin EPROM (mapper 2):
Bend up pin 1, 2, 24, 31 and 32
Solder pin 2 to hole 22 (A16)
Solder pin 24 to GND (OE)
Solder pin 30 to hole 28 (+5V) <- only for 27c020 and 27c040 (NC for 27c010)
Solder pin 32 to hole 28 (+5V)

Had an UNROM where soldering Pin 31 to VCC instead froze the game while Pin 30 works since it's the lowest address line (A17) that's floating.

Please update your guide. Thanks!

Thank you.

Version 0.08.1 updates the manual and leaves the program unchanged:

• Mention existing TG16 port
• Fix pin 30 on 32-pin EPROM
• Possible case mod requirement

For anyone building their own cart, the Konami produced pcb's are much easier to work with and don't require shell modding. They are indicated by "24" printed on the back label. Top Gun is pretty common and cheap. The other cheap silver label games are good candidates as well as some Ultra games like Skate r Die. Make sure it's UNROM game though as Konami did the same for some of their SLROM games.

That's for Famicom games, yeah. They don't need to be shell modded in some cases.
If you really want to make sure you buy an UNROM: Check here

That is for Nintendo games. Please don't correct me if you don't know what you're talking about. http://bootgod.dyndns.org:7777/profile.php?id=2829

Konami UNROM has the PRG ROM going up and down as opposed to across the board, which leaves more space for a 32-pin mod. The seven released NES games using this are some (not all) copies of Blades of Steel, Double Dribble, Jack Nicklaus, Life Force, Metal Gear, Silent Service, and Skate or Die. Do these have Nintendo pinout or EPROM pinout?

I think the rework in http://bootgod.dyndns.org:7777/profile.php?id=4618 answers your question for you.

(translation: No address lines have been changed to make an UVEPROM work there)

Sweet, good to know. Might come in handy for future uses. Thanks!

@Frank:
I thought it was Famicom exclusive since I never saw that kind of board yet and don't have all mappers and board layouts in my head. No reason to get rude there. >_>

Yeah, just checked again. It's only USA and Japan releases. I'm in Europe. We don't have those boards. So I'm stuck with shell modding along with other European people who do not want to import USA games just for that to avoid shell modding.

I swear I've found Top Guns like this too, but I don't have any on hand atm. That might be me misremembering. But I want to say bootgood hasn't had all the titles I've found that use Konami boards. They use Nintendo-prg layout for sure though.

sort of interesting side note: some of these carts use a Konami branded chip for chr-ram that only has a single chip enable line instead of /CE1 and CE2 like standard chips.

It is. The UNROM Konami with a white 24 on back label do.

Do you have a Deadly Towers you want to get rid of? Now you can destroy it to make a 240pee. This repack includes a mapper hack to BNROM, otherwise leaving the program unchanged. And if you have a game that's common but Rare, it's trivial to mod any AxROM board to BNROM: cut the mirroring trace from the 74HC161 and wire it to PA10. Merry Christmas!

0.08.2 (2015-12-25)

• Includes a BNROM mapper hack produced by mirroring the fixed bank into the top half of both 32K banks
• making-carts.md: Mentions less rework needed for Konami "24" boards (requested by FrankWDoom)

I've found this test just now.
Test on real 6527P/6538 dendy shows:

cycles/line: 113.6
lines/frame: 312
NMI scanline: 291
TV System: PAL
Frame Rate: 50.01
CPU Speed: 1.775

Do i need anything else?

Thank you. Exactly as expected.

I think now we have almost complete info about Hybrid PAL Famiclones like "Dendy" / "MicroGenius" / "Subor" / "Pegasus" - hundreds of brands worldwide.
So this text on wiki is not relevant for now:

Since you've already got it set up, could you run the Overscan test (second page)? (The 2C02 displays a 256x240 picture, while the 2C07 displays a 252x239 picture)

https://youtu.be/ir2UyvgM1i8
Now i've understand how it works.
Values before white borders will be visible:

top: 1 pix (0.4%)
bottom: 0 pix (0%)
left: 2 pix (0.7%)
right: 2 pix (0.7%)

Seems it like PAL

There are no "overscan" at all. It was invented by sales managers. To sell more advanced TVs to those who already have a good ones. Let me explain.

For example, there is PAL standard. It quietly sure describes all timings. You should keep it in mind, that CVBS transmits by serial manner. So, PAL standard describes:

So, all devices that claim to support the PAL must comply with these rules. But we have two operating side: the signal source and the TV itself. TV also must comply with this rules, but only at CVBS input. What we see on the screen is completely depends on TV specific instance. Even if it is to similar models in same batch they can be different (by semiconductor parts, by CRT or something else). Thus, the television itself, and its final adjustment will mainly affect what you see. Since there is many of different kind TVs, TV crew invent Safe Area.

Back to subject. I captured CVBS from UA6538 by high speed ADC (@250MS/s) and build this picture (clickable, huge!):

As you can see, it contains at least 3 full frames (fields). Black bar at left side is HSync. Gray level is a black level for picture (any sync must be darker that black). Also you can clearly see VSync between frames. And this picture completely comply with PAL standard.

Conclusion. Your "overscan" test in fact testing TV itself, because UA6538 PPU don't violate PAL standard. And you will get different result from TV to TV. The older will be the TV (or with malfunction), the less Safe Area you will see. I believe that it is fair and for NTSC.

This 51.95 µs isn't very different from NTSC's 52.148.

The PAL NES and PAL famiclone pixel clock is the 26.6017125 MHz master clock divided by five. At this rate, 252 pixels would be 252*5/26.6017125 = 47.37 µs, which is less than the 51.95 µs that you quoted. If the PPU didn't crop off the two pixels at far left and right, it'd still be 256*5/26.6017125 = 48.12 µs.


Is it OK for us to back that picture up on the wiki for use when testing software PAL decoder implementations?


On NTSC, that is its intent.

One of the TVs that I bought from a thrift shop had so much overscan it made the PowerPak hard to use. In fact, it was very close to the worst case that Nintendo anticipated in its background planning sheets (16 on the sides, 24 on the top and bottom). It's an Apex, and I can dig out the model number if you think you can help me find a means of adjustment.

On PAL, it's mainly to demonstrate that the PPU itself crops 2 pixels off the left and right and 1 scanline off the top.

Sure. Also there is 250MHz sharpen version and 500MHz version (only one full frame).

Sure I can try to help you to adjust your TV.

Hmm, never knew that. Since TV tuner doesn't have any "overscan" (like also any non CRT TV does) your words is true:

So, with BreakNes result I can build PPU clone that will rid off this limitation.

Thanks. I've uploaded it (and a version downsampled to 53.2 MHz, twice the master clock) as examples for the new article PAL video.


It's an Apex AT2408, which I bought used without a remote. I vaguely remember finding service menu-related information a couple months ago, but it requires the use of a remote.

I've found a bug in 240p v.0.08.2:
If you run test on Dendy mode, it detects as "Dendy" (right bottom) until you exit "CPU clock speed test".
Dendy detects as "PAL" after exit this test.

You can repeat this bug on punes\nintendulator\nestopia etc

Thanks. I reproduced the problem in FCEUX SVN, which has support for the Dendy region. The fix is to open src/overclock.s and change all instances of tvSystem to oc_tvSystem if they aren't already. I'll include this fix in the next version.

I downloaded version 1.03 of the test suite for Super NES and plan to incorporate some of its new features.

• When audio is on, manual lag test beeps when A is pressed and flashes when reticles align
  Fixed in forthcoming 0.09.
• New "Audio sync test" designed to be readable on a scope: Black screen with an 8 pixel tall white floor. A 2x2 pixel square travels up from the floor for 60 frames then down, and at 40, 60, 80, and 100 frames, 24x24 pixel squares close in from the sides; the bottom of these is about 20px above the peak of the square's travel. At 120, the screen turns white and a 1000 Hz tone plays for 2 frames. A pauses the sprite or starts the test from the beginning.
  Fixed in forthcoming 0.09.
• Vertical counterpart to "Hill zone scroll test", using kiki.bmp that's sort of reminiscent of Sgt. Helmet Training Day by The Mojon Twins
  First off, where does this image come from?

The vertical scroll test would require size-optimizing a bunch of things to free ROM space if I want to keep it under 48K for BNROM/UNROM dual compatibility. Currently the ROM is using 47475 of 49152 bytes.

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 (parity with SNES test 1.03)
• There's another change. Blink and you'll miss it.

Egg on face.

0.10 (2016-07-13)

• Fixed Gray ramp, which was inadvertently broken during rearrangement to fit Audio sync test (reported by Artemio)
• Linearity: Help mentions PAL PAR
• Stills: Refactored check for help page to save code size
• IRE: Treats Up as Right and Down as Left for convenience

There's about 1.5K of usable free space left in the 48K of the ROM that I'm using (UNROM banks 0, 1, and 3). In order to add the vertical scroll test, I'd need to break into the 16K that I've so far been intentionally leaving blank. This means either dropping BNROM support or adding trampolines to get in and out of bank 0. I've done trampolines before (Haunted: Halloween '85 and Action 53); I just need to get my head in the right direction.

I'd also need a new tile set. Artemio made the current vertical scroll background by arranging tiles from one of the Pocky and Rocky games in a map editor.


kiki.bmp (Super NES) (256x512)

The 240p test suite for NES uses vertical mirroring. I plan to make it appear as 256x480 by using sprite 0 to trigger a switch to the other nametable. So to add this test, I'll need to remove a couple rows of tiles from the path. I also need different tiles that look good on NES and don't resemble Pocky and Rocky too closely.

Unless you know of someone who really needs BNROM support, I'd just drop it. UNROM is like 25% of the NES library(?), and BNROM is maybe like 0.015% (one game). If someone can afford a 64kB ROM but not a 128kB one with duplicate banks for a test cart, they've probably got bigger things to worry about (yeah I know BNROM is 28-pin socket, but any newer boards are 32-pin).

Really cool test ROM!

I think the idea of BNROM is that it's one wire different from AxROM, to allow use of common Rare games (oxymoron?) as donors.

So I drew some similar tiles and arranged them similarly to Artemio's map. Does this look any good?

After some fairly straightforward size optimizations, I found just enough free space to add an 80% complete version of the vertical scroll test. The lanterns/TVs aren't in, but I'm not sure how critical they are.

0.11 (2016-07-16)

• Refactored OAM upload and scrolling to top left to save code size
• CPU clock speed: Rearranged alignment-sensitive code to save size
• Stopwatch: Uses metasprite drawing routine from Shadow sprite
• Hill zone scroll test: Left and Right both toggle direction
• Added vertical scrolling test (parity with SNES test 1.03)

This palette is jarring. I don't think the luminosity of the orange and green are far enough apart to deliver good contrast.

The original 240p test suite for Sega Genesis / Mega Drive prominently features borrowed artwork - almost exclusively. Including art from KiKi KaiKai is not going to introduce an actual problem.

How could the palette be improved given the lack of desaturated oranges in the NES palette?


Again, I don't want to be the one they make an example of. This goes double if I want this to qualify for the third compo, as NESHomebrew suggested. After Square bought up Enix and Taito, it started to go full Disney on amateur derivatives, especially of a Chrono Trigger homage. It suddenly pulled the Kiki Kaikai license from the developer of Heavenly Guardian/Legend of Sayuki, and the game suffered for it.

In version 0.11, getting too many "exact" hits in the manual lag test causes it to freeze with a white screen (though I can still press B to exit it).

Reproduced: result screen wasn't resetting the background color since 0.09. Will be fixed next version. Thank you for the problem report.

Note to self: retrorgb requested support for a Nintendo on a black-and-white TV. I just checked, and the only ones that might be hard to read in B&W are Stopwatch and Hill zone scroll test.

Through private messages, retrorgb and I figured out what was going on.

When a Hi-Def NES board is active, the composite output of the PPU is white for sprite pixels and black for background pixels. (This is combined with the 4-bit "slave" pixel output to form a 5-bit index into CGRAM.) The lag from composite to HDMI output is 2 ms or less, as the Hi-Def NES board's 32-line circular buffer can't hold more than 2 ms of pixels. We can exploit this to measure the whole system's lag down to the millisecond: connect the HDMI out to the TV being tested and the composite out to a dumb composite CRT SDTV, count scanlines of difference, and divide by 15.7.

I can break this into three feature requests for Stopwatch:

• Draw both digits of "frame" with sprites instead of background tiles, so they show up in white on the composite output. The ones place of frames already shows up on the composite output as the "clock hand" at the bottom, but the tens place doesn't. I was worried about a scaler adding exactly 10 fields of lag.
• Draw a castellated (notched) strip of sprites down the right side of the screen to allow counting scanlines by inspection.
• Ensure that the shades of blue and red for the clock face appear distinct even in grayscale, to allow use of an NTSC NES with PAL TVs that can view a 262-line (PAL60 or PAL-M) signal.

I'll keep you posted on whether I can squeeze them in, or whether I have to go jump on a trampoline.

Here's a video demonstrating the issue. I usually prefer to use a DSLR to get a clearer picture, but this should be decent: https://youtu.be/E525KsUh_VQ

I barely made it fit.

0.12 (2016-07-26)

• Manual lag test: Result screen background is black even if last press is Marvelous (0.09 regression; reported by Quietust)
• Stopwatch: Blue in clock face is darker to improve visibility on black-and-white TVs (requested by retrorgb)
• Stopwatch: Draws frame number with sprites to remain visible through composite out of Hi-Def NES (requested by retrorgb)
• Stopwatch: Up to show scanline ruler (requested by retrorgb)
• Grid: Fixed reversal of red and white colors
• Help: Doesn't draw page numbers for 1-page help documents

I think these Hi-Def NES-related new features are the last features I can add without either adding trampolines or expanding the Jeopardy!-donor build to 128K. It was so tight that I had to reword a few other help pages for conciseness.

Wow, that's awesome! That should do the trick, as all we'd need is the frames - Seconds would be nice too, but that's still enough to use the Hi-Def NES as a true lag tester for flat-screen TV's!! Thanks so much for adding this! I'll bring it up on the podcast and add a page on my site that describes exactly what people would need to do!

This is actually a really great feature-add. There aren't a lot of devices available to test a 1080p TV against a 480i CRT, both running at native resolution in the best-possible circumstances.

It can conversely act as (additional) tangible proof that the Hi-Def NES doesn't introduce more than a few lines of latency.

Suggestions for the lag test, pardon me if they're a repeat, I didn't reread the whole thread to check:

The 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 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.


Suggestion for sound test:

Periodic noise (and regular noise for comparison), since some revisions of the Famicom are missing it.


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)?

Trampoline get.


The original (source code) also mentions "rhythm". Perhaps I misinterpreted something.


It's at least consistent with Kirby's Adventure, which uses Start to enter or exit documentation.

I've tried to make the behavior reflect that of the versions of the suite for other consoles, particularly the version for Super NES because that's the other console that I leave hooked up. Toward that end, is it OK to pass your feedback on to the development topic for other versions? And if so, would linking or quoting be better?

I'm not familiar with other versions of the test, but I don't mind if you want to link to or quote my suggestions.

I passed on your suggestions, and Artemio replied. I've implemented two (noise in sound test and fix inconsistent Start behavior). The manual lag test changes will wait for what Artemio ends up deciding to do.

This is largely a behind-the-scenes reorganization of how graphics data is loaded, though it includes some requested changes.

0.13 (2016-08-04)

• Reorganized most compressed graphics into "files"
• Moved compressed graphics files into banks 0 and 1
• Made separate BNROM build, with graphics decompression code behind interbank call gates
• Expanded usable portion of ROM from 48K to 64K
• make clean is more thorough
• Sound test includes noise channel in hiss and buzz mode (requested by rainwarrior)
• Start on main menu always opens About (SNES parity; reported by Artemio)

Is there any way to make $0D in PLUGE / etc. an option, so that these tests aren't useless on a TV that loses picture due to it? (Though, the pattern used does not seem to negatively affect any device I have available to test, so this is only a speculative question for me.)

Solid color screen uses $0D only if you move to black and press A. IRE uses $0D only if you move to the very bottom of the range. PLUGE uses $0D, and the entire point of PLUGE (Wikipedia) is to show a strip of "super-black" in contrast with a gray ramp. The approximation of SMPTE EG 1-1990 also includes a mini-PLUGE at bottom right. I guess I could mention the possibility to lose sync on some TVs in the help page, so long as the user knows to press Start to see it.

And while I'm at it, I might as well incorporate the NTSC chroma-to-luma crosstalk test from tvpassfail (with the red/green/blue diagonal stripes).

I have a hypothesis about 240p to 480p line doublers: It might be possible to use a 480p CRT if the scanline darkening is set high enough and the doubler has no more than a line or two of lag. So to encourage testing this hypothesis, I plan to add the 1-gun test screen from Zap Ruder into the version of the test that I've been invited to submit to the compo.

Sorry for the triple post. This will probably be the last update I release this year, as I've been busy watching Windows tech support scam baiting videos.

0.14 (2016-12-31)

• Added chroma crosstalk test for NTSC
• Added basic Zapper test based on Zap Ruder
• Added audio lag test using Famicom microphone (caution: untested on hardware)
• PLUGE, SMPTE, Solid color screen, IRE: Help page warns about super-black signal causing distortion (requested by rainwarrior)
• Some help copyedits
• Documented interbank call gate mechanism

Once this version gets tested, the next thing I plan on is refactoring display of 2- and 3-digit decimal numbers throughout the program.

I tested this on my Twin Fami, and a couple obvious problems are apparent:
Did you know that all models of the Famicom pass the microphone input, amplified, through the TV speaker/ audio output? So, merely bringing the Fami close to a CRT TV / speaker set causes immediate squealing due to mic overload & feedback. I tried it on an LCD TV, and there is a bit of delay & echo, but the feedback is here as well.

The feedback is far louder than the Fami's PSG output, and the mic detection circuit in the Fami hardware is a little deaf, so there's no way to test the Fami audio-> mic with such feedback ruining everything. Users will have to open up their Famis to solve this, so I don't think this is a very useful test.

But as you mentioned earlier, a Titler was more sensitive than a Twin in a different test. I guess we need someone with a red and white Famicom to test this.

And perhaps the kind of person who would install an RGB or HDMI output mod is also the kind of person who would bridge a resistor.

As for feedback, I'll need to ask users to turn down the mic's volume just below where feedback starts to happen. That's also why I added a few frames' delay between pressing A and the tone: to distinguish feedback from a valid result.

You've got a catch-22 here. Lowering the slider on the P2 controller decreases the input to the mic, ie: its sensitivity overall. It will never detect a PSG sound when its own amplified feedback is louder at any combination of volume & slider. I think so, anyway. Perhaps someone with a regular red & white Famicom can verify this.

I can see it from the schematic. As far as I know there is no mapper with the function to mute the audio; I have suggested such a thing before (and you said apparently is not so useful, but now we can see that actually it is useful) and if it existed then that would help if it also has expansion audio. Of course such thing would require such a cartridge to be built in order to test it, but that will be possible.

I just tried it on my NESRGB-modded Famicom and it didn't seem to work - No audio played on the TV, no matter what I did. Maybe I'm just making a stupid mistake? Load the audio test and press A, right?

Does it say "noise"? If so, the microphone bit is getting triggered before the tone begins. Does it still say "noise" when you turn the mic volume all the way down? I'll need to add a real time display to troubleshoot this. If it instead says "no signal", does the other sound test make noise?

It says "noise" regardless of the mic position, including if I start with the mic all the way down.

Is the mic continuously triggered if you open player 2 in my controller test?

Yes, "mic" stays red no matter what. Does that mean my controller is bad?

Also...cool controller test program!

That or the mic circuit in your Famicom is bad. It might cause problems in other games using the mic, such as the FDS version of Zelda where the player is supposed to blow Pols Voice away. If you want to troubleshoot it, feel free to open a new topic.


UPDATE: I had krom in #nesdev test an interim build with a couple changes, such as less frequent polling (155 CPU cycles per sample instead of 11), and it still had the problem of not being loud enough to trigger without going straight to feedback. I'll just remove this test from the next version and wait until I get a Famicom of my own to try other things like $4011 manipulation.

With that said, is there any other output testing functionality I could put in 0.15?

Test suggestion:

It would be useful to be able to identify skipped frames (thinking about this recent thread).

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.)

Actually, after looking at the stopwatch test, that 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.) The little dots in the centre are only on for one frame, but they're small and red and in a circle instead of a row.

Additionally, a longer period than 10 may help; I've usually found 16 to be effective, in a row or a grid. 64 is probably too many, but 10 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).


Other versions of the 240p suite seem to have a "lag test" that is like your stopwatch but with bigger numbers arranged in a 4x2 grid; 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.).

You make a good point about the contrast. I've passed your feedback upstream and changed my version to use a blue ($01) active circle and pink ($26) inactive circles. This should improve visual contrast.

Honestly, I think the most critical thing here is that inactive ones should be invisible (i.e. the background colour). Simply changing the colour is not very effective for persistence of vision.

When I was talking about contrast I just meant that dark blue against the white background was a better contrast than red against white, but black against white would be best, and the inactive numbers should be invisible.

If all goes well, here's the version I'll submit to the compo.

0.15 (2017-01-23)

• Removed Famicom audio lag test after negative results by ccovell and krom
• Stopwatch: Clock face uses a blue active circle and pink inactive circles for contrast (requested by rainwarrior)
• Stopwatch: Down to show or hide inactive circles (requested by rainwarrior)

And the blurb:

I have received a private message asking for a port of 240p Test Suite to Famicom Disk System. I had to reply that I lack a Famicom, RAM adapter, and FDSStick with which to test it. Is there demand for an FDS port among anyone else?

Do you really need those three things? Emulator / PowerPak / Everdrive should be good enough to get it together, and if you need verification testing I'm sure there's many who could oblige (myself included).

The main caveat with PowerPak or Everdrive is that they swap sides automatically, and also the PowerPak FDS seems to have an accelerated load timing, but that only matters if you're doing something that requires loading to be specifically slower. (You can still make the license skip work on it without this.) Actually a test that can tell you the disk bandwidth might be interesting, though I'm not sure how you'd time it, since you'd want to go through the BIOS for compatibility.

This is not a request for a 240p port, though. I'm just suggesting that your lacking hardware isn't really a big problem. A good emulator with the original BIOS does a pretty good job of replicating it.

What Rainwarrior said re: emulators, but if you really need, I can provide testing or lend hardware.

The port would be neat, but I don't know that it's so important. Unlike a Sega CD port, it doesn't really make it a lot easier for others to use it by offering it on this disc based platform.

I was wondering if anyone tried the 0D color address? It's supposed to be blacker than black. For the pulge bars in the SMTPE pattern this would be extremely helpful. As long as the NES's other blacks other are outputting a 7.5 NTSC in middle bar, left bar is 0 or blacker; that's about all you need for 7.5 NTSC brightness calibration. (Sounds likely 0D is a 0 level NTSC instead of 7.5 like used in actual pluge bars which would be even better)

Further, I think it would be better if the lightest of the 3 bars on the right was one of the light greys, 10 or 3d (how are they different?) While it might technically be further from a pulge lightest grey (15?) than black, that's not really point of the test pattern; functionally, anything but black there would be better. Then if the 0D, blacker black, actually works out, you'd have functioning, maybe fully functioning, pluge bars!

BTW I've used this rom extensively for nearly all my CRT testing and calibration (which I do A LOT of), does everything great besides pluge, and of course chroma/phase calibration, but the later is a given with 55 colors; I have to use a TSG for both.

reference:
http://wiki.nesdev.com/w/index.php/File ... atches.png
https://upload.wikimedia.org/wikipedia/ ... rs.svg.png

Shade $0D is unfortunately significantly darker than 0 IRE. The NES was designed for NTSC-J , so there was no design for different black and blanking levels.

This wiki page contains the measurements I did some years ago: color $0D is approximately -12IRE.

With full color emphasis on, shades $01-$0C average to approximately 4 IRE.

Even with -12 IRE, I'd still rather have that (and a light grey on the right bar) for some limited functionality, rather than zero functionally with everything the exact same color.

Also the grid on the linearity screen (pressing A) is BY FAR the best and most useful test pattern, (I believe it's 7x7 black pixel squares with 1 pixel thick lines, which are very good parameters) could be EVEN BETTER if pressing A again could cycle to remove the 5 circles, as these circles often get in the way, much like an OSM does when trying to scrutinize a white line for calibration.

You'd rather have this?

https://youtu.be/3fhyX3HdVcg

(the immortal uses color $0d for black here...)

"The game uses a non-standard "blacker than black" color value for black pixels and then further exacerbates the problem by using "emphasis bits" to darken the whole screen. This pushes things even further out of spec so that the TV sees a sync pulse where there shouldn't be one."

Well if that's the case no, but I assume that was with composite, and maybe RF only. I'd be interested in using it for RGBS which would have the sync line separated and couldn't happen. Further, I wonder how much the emphasis bits play a part in that vs -12 IRE instead of the 0 which every CRT is more than designed to handle.

Regardless, a light grey on the right bar would be better.

If you're using RGBS from a NESRGB, HDNES, or 2C03, it's already completely synthetic and only vaguely related to the composite generated by the 2C02... I doubt any of those devices emit something useful for shade $0D.

The "SMTPE color bars" test does and "IRE" test can already display shade $0D.

"The "SMTPE color bars" test does and "IRE" test can already display shade $0D"

Are you saying they use $0D currently? O.o

That is, in fact, exactly what I am saying.

From what I recall, the small deep-black region in this ROM's test is not nearly as problematic as with The Immortal. Sometimes how much of it there is onscreen can matter a lot. E.g. my capture card wobbles with The Immortal but didn't seem to be bothered with this test. Loss of picture is theoretically possible, but it really varies from hardware to hardware quite a bit.

Incidentally, this has actually been discussed twice in this thread previously:
https://forums.nesdev.com/viewtopic.php?p=159374#p159374
https://forums.nesdev.com/viewtopic.php?p=178503#p178503

lidnariq, that's neat they're in there, (though the IRE pattern is somewhat dubious because also has much lower values); unfortunately, it doesn't seem to work at all like others have said, at least with RGBS and S-video through the RGBNES, could it maybe somewhat work through composite/RF unmodded?

I think a better idea, that could still include the marginal useful if any -12 IRE $0D, would be to use all of the NES darkest colors alternating with a black bar, so a pluge pattern like this:

| $0D | $0E | $08 | $0E | $09 | $0E | $00 |

which could be actually pretty useful, I know when turning down the brightness a bit too low you can't distinguish a black from that dark brown, like at the start of Castlevania 3 (dark brown hair on black background and later in level the whole big house background)

Sorry for double post but this maybe got missed:

The grid on the linearity screen (pressing A again) is BY FAR the best and most useful test pattern. (I believe it's 7x7 black pixel squares with 1 pixel thick lines, which are very good, if not ideal parameters) It could be EVEN BETTER if pressing A again could cycle to remove the 5 circles, as these circles often get in the way, much like an OSM does when trying to scrutinize a white line for calibration, particularly convergence.
(If you wanted to get really fancy, a way to change between just horizontal lines or just vertical lines could be just slightly helpful)

The solid color screen is also awesome for checking purity.
Those two are about the only patterns I use 240p test suite for.
And I guess with higher end consoles, the SMTPE pattern can actually be accurate enough auto-calibrate BVMs and the like.

The sound check, system clock checks, lag test and some others are pretty neat too.

The "Grid" is so over used, the linearity's grid is so much better, grrr.

Thank you for the feature requests.


So something like this I take it, where hot pink represents the $0D.

How would that test be translated for the RGB consoles (TG16, Genesis, and Super NES)? Mostly I try to track the functionality of the Super NES test, and I might include a corresponding screen in the NES version. I'll pass on your request to the topic on Shmups Forum to see if they can come up with a corresponding test.


The grid in Linearity is 7 pixels wide and 8 pixels tall on NTSC or 8 pixels wide and 11 pixels tall on PAL. This gives it as close as I can get to a square aspect ratio for the grid squares. But loading two images (circles only and circles with grid) takes up all of video memory on the board I'm using. In order to cycle among more than two screens (circles only, circles with grid, grid only, horizontal lines with same spacing as Linearity grid, and vertical lines with same spacing as Linearity grid), I'd need to load screens into video memory in response to a button press. I could do this one of two ways:

1. Cut to a black screen
2. Fit the updates into vertical blanking time, which incurs a lag of 40 frames (two-thirds of a second) to load the 5K of data that make up a screen at 128 bytes per frame

As I get time, I'll let Shmups Forum know about the limits of Grid and Linearity when setting convergence to see if there's demand for a fine grid test as you describe.

"So something like this I take it, where hot pink represents the $0D."

Yes, that pattern for the NES would be nice! Since it doesn't have very much in terms of greys, really dark greys, the darkest other colors work better, like the dark brown. Further, half being on white background with lightest colors (maybe the light grey here is good) could be good too, see example link below. *NOTE the continuous gradient stuff in the middle not necessary or especially helpful or applicable for limited color palettes.

"How would that test be translated for the RGB consoles (TG16, Genesis, and Super NES)?"

A pattern like this below is kind of ideal, color/shade labels if not the way can help too, those consoles might have SOME good greys that are actually close to black or close to white, those greys would be good to have, blacker than black, but then the very lightest and very darkest colors also could good to mix in there:
http://spearsandmunsil.com/wp-content/uploads/2013/02/1920x1080p24_Contrast_Main.png

Another good example of effective pluge pattern:

"As I get time, I'll let Shmups Forum know about the limits of Grid and Linearity when setting convergence to see if there's demand for a fine grid test as you describe."

The main thing is really just getting that same fine grid patterns, but with the circles removed.

For more capable consoles, getting the white lines as thin as possible is always helpful.
The Parameters are great, 29-30 squares high.

Would you be happy with a black screen transition between the circles-and-grid screen and the grid-only screen? Or do you require the ability to enable and disable the circles instantly the way the current ROM enables and disables the grid instantly?

"a black screen transition"
You mean like a few frames of black before the just the fine grid comes up?

that wouldn't really be a problem, faster is always better, but a few frames isn't much.

One thing that's nice to switch between quickly is the solid color screens, (mostly just all white and all red) and the fine grid. When doing geometry/convergence adjustments(with fine grid since it's best) some can effect purity (which is best to check with all white and all red) and purity adjustments can effect geometry and convergence. So often I find myself checking fine grid, then B, down, down, A to check purity, then B, up, up A, A back to fine grid, make minor adjustment, repeat.

Is it common for others to switch back and forth between solid white and a fine grid? Is there a standard test procedure that I can cite in that test's help page, analogous to the SMPTE standard defining color bars? If you are the only person who would use that feature, it would probably be better as a stand-alone ROM.

But if anyone else expresses interest, I could add Select to switch between solid color screen and a fine line grid.

Ya I'm not sure how many other people do those kinds of adjustments, not super common, I'm a power user

Could you make a stand-along that swaps between them, fine grid, full red, full white?

Also one other way to improve the fine grid is small the dot in the middle indicator, it's certainly useful to see the middle quickly without counting lines; however, certainly can be in the way when scrutinizing the very import static convergence.

a separate way to toggle it on/off would be nice, maybe ideal solution.

The standalone convergence test turned out to be 1.25 KiB, but iNES format rounds that up to 16 KiB.

Left: Switch to grid (or toggle center dot)
Right: Switch to solid color (or toggle white/red)
Start: Toggle help

Automatically detects PAL or NTSC, using 7x8 pixel cells on NTSC or 8x11 pixel cells on PAL.

Sick, DLed, I'll check it out really soon.
Thanks!

Looks like a good idea! Thank you.

I guess I ought to post the changes I made a year ago when I was preparing the suite for release as part of Action 53 volume 3.

0.16 (2017-03-13)

• Grid: Select toggles gray or black background (parity with Genesis test 1.15)
• Sound test: Added "Crowd", a bytebeat composition by Kragen ported to NES by rainwarrior
• paginate_help.py: Specify UTF-8 encoding for input file (Python for Windows instead defaults to cp1252)
• paginate_help.py: Fix NameError in error message formation
• paginate_help.py: Helper to raise UnicodeEncodeError, whose constructor argument order is undocumented outside interpreter source code
• makefile: Work around %Path% quirk in Python for Windows

Sorry for Delay, been using this for awhile, it's great so far!
Just needs a few more of the important test options and I'll only need to use it to be a lot quicker

1. Down, accesses the black level screen with all the darkest colors compared to black talked about earlier,
2. Up, go to a color bleed screen
3. Press A while on full red or full white to cycle Green and Blue (or some other simple input scheme that doesn't lose the instant, D-right, to cycle red/white)
4. Press A while on grid to bring up overscan test with default to 1 pixel L/R, 7 pixels top bottom. Also original over-scan screen would be nice to have the pixels outside of the grey box all be white rather than everything outside of 0 0 0 0 box is also same grey, because then it's hard to tell your edge with 0 or less.
5. Press A while on black level to bring up a an eye candy screen. Something like a half/half of these two screens below would be awesome and/or a mashup of the NES characters people are most familiar with like: Belmont, Mario(s), Megman, Samus, Link, Little Mac, ect.
https://images.craigslist.org/00w0w_dk7 ... 00x450.jpg
https://images.craigslist.org/00l0l_6iG ... 00x450.jpg
6. Press B while black level to cycle a focus test screen, just white dots on black and black dots on white; or sub dots for text.


Ways to make the color bleed screen better:
The horizontal stripes are great now, but White is the most important, would want to check white bleed on ALL parts of the screen. Would be nice to have 4-6 horizontal stripes that extend ALL the way to left/right sides, and repeat that strip of white strips with section of black in between. Could also allow pressing again/holding D-up to scroll the stripes up. The reason not making it half white stripe half black stripe on full screen is that it puts too much load out at once and is harder to get an accurate bleed test. Input-A could cycle the colors Red, Green Blue could be nice to double check which colors are bleeding more. Input-B could switch to vertical or checker but not important.

I wonder what the upstream developer would have to say about these UI changes.


I hadn't considered that. But I expect a bit of "Why is there white when it's 0?" confusion. Making it black instead might cause confusion on PAL systems, which draw the border as solid black along with 1 top and 2 left and right pixels.


I'd prefer not to include anything copyrighted by control-freak publishers. That's why I replaced the graphics in several of the tests.


If you mean something other than what "Full screen stripes" does, I'd like to see a mock screenshot of what you want.

Basically that, but cutting out half of the lines in blocks of about 5, so it doesn't put too much load on the CRT at once and skew the results, also being able to toggle to Red, Green, Blue lines.
like this image below but repeated all the way down.
https://photos.app.goo.gl/O4QT8BSPTyPCP9wg1


For me and some other friends we had the opposite confusion of why is there no border when I have the overscan set to 0 or less and I only see a defined edge with less overscan and why are there two areas of grey and one of white and which one is real border of the now TWO defined edges.


Probably not for them because they want to put in tons of these superfluous test and options, much better to do that with pages of indexed items, also easier for first time users to see the name of the test before they select it each time.


I suppose that's true, rom hack generally don't provide an actual rom but rather a patch which you need a 3rd party software to patch an "illegal rom" with. It wouldn't be in the same boat. I wonder if something of a similar vien could be used though, like the bricks with leafs and text from CVIII name select screen with some other colorful pixel art thrown in. Are there just free assists of good colorful pixel part that could be imported?

Patches are welcome, especially if nobody has seconded the development of a new feature such as linking the different test patterns together via some state machine.

Now on GitHub: pinobatch/240p-test-mini

See also port to Game Boy

The first to guess what this pic is for in 240p Test Suite wins a cookie.

240p Test Suite (NES, GB, GBA) v0.17

A minor update, largely to track updates to the Genesis version. Also includes continued size optimizations in the Game Boy version.

Highlights on all platforms:

• Sharpness: A to show brick wall pattern (Genesis 1.16 parity)
• Stopwatch: Add third ruler setting to show in even frames (Genesis 1.16 parity)
• Audio sync: Move ceiling up (Genesis 1.16 parity)
• Begin to unify help conversion tooling
• Unify version numbers

Highlights on specific platforms:

• Help (GB): Compress document titles with DTE
• Help (GBA): Align line buffer to prevent corruption of nearby variables by DMA memset, fixing Down after Scroll test
• Gray ramp (GB): Use Color tests map loader for GBC version
• Solid screen (GB, GBA): Explain what a bad high voltage regulator does to SGB and GB Player border (requested by ISSOtm)
• Stopwatch (GB, GBA): Draw even frame numbers in blue and odd in red (Genesis 1.16 parity)
• Manual lag (GB): Fix all-black result screen if final press was 0 lag (reported by Great Hierophant, echoing Quietust's NES report)
• GB: ISSOtm golfed SGB detection by 3 bytes; numerous other size optimizations and tile sheet unifications
• GBA: Add license headers

GitHub release

I recently added compression improvements that saved about 10 KiB:

• 5.2 KiB by compressing help text with digram tree encoding (DTE), the same text codec I used for my robotfindskitten port
• 4.8 KiB by generating the Linearity with grid from Linearity without a grid instead of storing both

This let me splurge a bit, adding more detail and color to the character on the help screens to match the GBC and GBA versions.

These compression improvements were in part to help keep this included as a "toy" in the full Action 53 collection. The more I keep the size down, the more other stuff the builder can squeeze into the unused area, and the more likely 240p Test Suite will meet the "Must fit" criterion. Compression improvements would also be appreciated if someone else attempts a port to the Famicom Disk System with FDSStick, as requested in a private message about a year ago, as they would help more tests' data fit in the 32 KiB RAM of the system card without loading breaks.

In an effort to hit an arbitrary 40960 byte (40 KiB) milestone, I recently took a survey of size in bytes of each test on both NES and Game Boy. The Overscan and Manual lag test were identified as two places where the size of the NES version greatly exceeds the size of the GB version. Other places were justified, largely because of the greater perimeter and area of the NES picture, but these two deserve special consideration.

Overscan on NES spends about half of its ROM space (about 1K of 2K) on calculating 32x4- and 4x30-cell tilemap update packets for the side borders. I could probably reduce this by drawing the side borders partially with sprites, the way I did with GB's right border. (It draws the left and top borders with scrolling, the bottom border with the scanline counter, and the right border with a combination of sprites and the window.)

Manual lag test on NES displays a string "Marvelous", "Perfect", "Great", "Good", "Boo", or "Miss" depending on how far the press was from 0 lag, with the appropriate color from Dance Dance Revolution. Artemio's original versions on Genesis and Super NES do not, nor does my Game Boy port. Two years ago, rainwarrior suggested that this DDR theming could trigger reflexes in users to anticipate the press, which could bias the result. Cutting this experimental feature should reduce ROM size.

I could shoot for 40K, or I could instead target 48K and add more features:

• SpiderWaffle has requested the thin, aspect-ratio-adjusted grid of Linearity by itself, with no circles. In 0.17 and earlier, this wasn't possible, as the versions with and without grid used different nametables, and I had to put the grid-only version in a separate ROM. But now with the recent improvement to Linearity's compression, they use the same nametable, and I can use the second nametable to make a third version with just the grid.
• SpiderWaffle has requested a PLUGE with vertical bars of all $0x colors.
• Expand IRE to Motion blur as on GB

Pluge. Whatever that is.

"PLUGE" is one of the tests:

The PLUGE (picture line-up generation equipment) pattern is used to adjust the TV's "brightness" or black level.

The inner bars are a signal level slightly lower than standard black, which causes some TVs to distort or even lose sync. The outer bars are the darkest mix of colors the NES can show.

You should adjust brightness until the outer bars are clearly visible and inner bars are not.

But how would the shark image be used with the PLUGE test?

It was the filename.

I know about the filename. But where would a shark appear in a PLUGE pattern?

Would it be a good idea to add a screensaver that begins after five minutes of inactivity, draws a bouncing logo, and plays a fanfare whenever it hits the corner?

240p Test Suite (NES, GB, GBA) v0.18

Add one new test from the Genesis version. This time it was the NES version's turn for size optimization.

Highlights on all platforms:

• PLUGE: Add PLUGE Contrast sub-test with shark graphic (Genesis 1.16 parity)
• Want your name in the credits? Become a patron

Highlights on specific platforms:

• GB: Mention worse smearing on Game Boy Pocket and other help tweaks
• Overscan (NES): Select to invert grays; border contrasts with BG
• Sharpness (NES): Pixel-align emblem at center
• Manual lag (NES): Remove misleading DDR-style grading

Behind the scenes:

• VWF (GB): Glyph address calculation uses 16-bit shift instruction
• VWF labels (GB): Reduce stack use, including moving tile width from stack to register C (requested by ISSOtm)
• PB16 (GB): Fix padding for odd-length packets
• gbcnamtool (GB): Fix vertical flip and conversion without incruniq
• GB: More refactoring and other size optimizations (with ISSOtm's help)
• Help (NES): Compress text with DTE; update Gus look to match GBA
• Linearity, Sharpness, Stopwatch, Crosstalk (NES): Compress map with new iu53 codec
• NES: Move several tests' code to UNROM bank 2 to make room in fixed bank
• Linearity (NES): Construct grid CHR from gridless CHR
• Stopwatch (NES): Reduce tiles of sprite circles (the "hand")
• NES: Move rectfill-based screen layouts to UNROM bank 1
• NES: Organize "library" code shared by my other projects into a separate part of the fixed bank
• NES: Move most local variables to zero page for smaller code size: now below 40 KiB
• NES: Rename some source files to match their GB/GBA counterparts

Download: GitHub release or ROM+source zipfile (below)

240p Test Suite (NES, GB, and GBA) v0.19 is out

It took another heroic compression effort, but I freed enough space to add a Super Game Boy border and colorization to all tests that would benefit from it. Not a lot of changes on NES and GBA though.

Highlights on all platforms:

• Stopwatch: Bolder digits
• Help: Standardize phrasing: "stuck pixels", "hide or show", "start or stop"
• Help: List patrons as of release time

Highlights on specific platforms:

• GB: Super Game Boy colorization and border
• Backlight zone (NES, GB): Increase starting size to 2 pixels
• Color bleed (GBA): Fix frame # covering everything
• PLUGE Contrast and Vertical scroll (GBA): Center pattern horizontally
• README (GB, GBA): Explain rationale behind "144p" and "160p" titles

Behind the scenes:

• Help (NES, GB): Integrate Johnathan Roatch's faster DTE compressor written in C
• Linearity (GB): Compress with reflection
• GB: Improve incruniq tilemap compression
• GB: Compress font and large graphics with nibble-wise Huffman coding
• GB: Move variables to HRAM; other code size optimizations
• GBA: Use a more common makefile
• GBA: Specify each PNG's conversion settings in a grit file

Download: GitHub release or the ROM and source zipfile below