While experimenting with video hardware on an actual PCjr, I discovered that the video memory mapping address, 0xB8000, only maps 16K of video memory, even in 32K modes (like 16-color 320x200). 0xBC000-0xBFFFF is just a repeat of 0xB8000-0xBBFFF, leading to "stripes" on the display if you try to write to address 0xB8000 in 320x200 mode. This is, in fact, pointed out in the Incompatibilities section of the https://en.wikipedia.org/wiki/Tandy_Graphics_Adapter Wikipedia article (would have saved me a lot of trouble had I read this first!):

While the PCjr video hardware can use up to 32 KB of RAM for the video buffer, it emulates the CGA precisely by making only 16 KB of this available at address 0xB8000; like in a true CGA, in the PCjr, the 16 KB at 0xB8000 is aliased at address 0xBC000. The Tandy hardware, in contrast, makes the full 32 KB of selected video RAM available at 0xB8000. This difference causes some software written for Tandy graphics not to work correctly on a PCjr, displaying images in 320x200 16-color or 640x200 with periodic black horizontal lines: a venetian-blinds effect.

In the DOSBox 0.74-3 environment I have been testing in, this "feature" is not emulated -- writes to 0xB8000-0xBFFFF fill the whole screen. But I came across an older SVN build (EmuCR or something) that _did_ emulate this feature, and looking at the SVN source, it appears DOSBox correctly emulated the PCjr behavior at least as far back as the beginning of 2007 -- commit 2781 is the oldest one where I can clearly see the bank-replication behavior:

//test for a unaliged bank, then replicate 2x16kb
if (vga.tandy.mem_bank & 1)
phys_page&=0x03;

The current source looks slightly different here, but still correctly emulates the PCjr behavior.

Additionally, I've tried DOSBox 0.74-2 and 0.74; neither one of them include this behavior. How is it that this PCjr quirk exists in SVN going all the way back to 2007 but doesn't exist in the official builds?