Mike's PCjr Page

I was reading about this topic the other day to try to understand the differences between PCjr, Tandy, and Plantronics ColorPlus. Wikipedia had this to say:

"Strictly speaking, the PCjr video and Tandy 1000 graphics subsystems are not identical. One specific difference is in the size of the video memory aperture at address 0xB8000. 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. It is also at least technically possible that software for the PCjr (that relies on the memory wrap-around at address 0xBC000) will not work correctly on a Tandy 1000. On the other hand, it is possible by intention to write software that will work correctly on either a PCjr or a Tandy 1000."

I always thought the PCjr graphics behavior was a bug, but this indicates that it was intentional. If true, will the Tandy Mod break CGA compatibility for some programs? I know that there are other ways in which the PCjr CGA mode is not fully compatible, but would this make even more program incompatible? If so, making the mod switchable would be a good idea.

Comments please.

'Bug' categorization is subjective. I'm not sure if CGA aliases the lower 16KB at BC000 or not or if it even drives the bus at BC000. If so, I suppose the aliasing on the Jr could be intentional. I suspect CGA does not and the Jr aliasing artifact was just a cost decision as a correction would require at least one more chip. Full frame buffers were still accessible in lower memory on the Jr. They were not on the T1K. Thus it was necessary for Tandy to make 32KB @ B8000 continuous to support 320x200x16.

I doubt any software made use of the aliasing artifact on the Jr. Frame buffers always started at page start boundaries and none (except 320x200x16) were as large as the page size. So the start of the wrapped write would always be in memory that could never be displayed.

alanh wrote:'Bug' categorization is subjective. I'm not sure if CGA aliases the lower 16KB at BC000 or not or if it even drives the bus at BC000. If so, I suppose the aliasing on the Jr could be intentional. I suspect CGA does not and the Jr aliasing artifact was just a cost decision as a correction would require at least one more chip. Full frame buffers were still accessible in lower memory on the Jr. They were not on the T1K. Thus it was necessary for Tandy to make 32KB @ B8000 continuous to support 320x200x16.

I doubt any software made use of the aliasing artifact on the Jr. Frame buffers always started at page start boundaries and none (except 320x200x16) were as large as the page size. So the start of the wrapped write would always be in memory that could never be displayed.

I was browsing the PCjr technical reference manual yesterday and I think I found the answer. The technical reference states that the area from B8000 to BFFFF is aliased to the actual video area. So it seems that the designers intended it to work the way Tandy computers do and it is a bug. I guess that IBM would have fixed it if the computer had been a commercial success.

In my mind, if it is fixing a bug, the video mod is a good thing to do.

Thoughts?

KenG wrote:...the area from B8000 to BFFFF is aliased to the actual video area. So it seems that the designers intended it to work the way Tandy computers do and it is a bug.

That is confusing. 1) Tandy doesn't alias and 2) Tandy came after. The strobe gates for the VGA chip are controlled by a PROM. Someone clearly intentionally set the enable bit for the B8000-BFFFF region. The address generation is identical for B0 vs B8. So there is no doubt it was intentional. Only someone from IBM on that project can really explain the nonsensical thought process behind it.

KenG wrote:In my mind, if it is fixing a bug, the video mod is a good thing to do.

That's why I added a dip switch on my board - so it can be changed back and forth without a soldering iron; just in case.