Why did the original Apple //e have two sets of inverse uppercase characters?
Simple: To allow lower case inverse letters.
It's all about the clever way Woz arranged the original II's single character set to save in hardware and offer additional functionality. There is only a single character set of 64 characters, showing up 4 times in 256 entry character space (*1). The first occurrence ($00..$3F - 2^6&7 cleared) showed up inverse. The next ($40..7F - 2^6 set) will appear flashing on screen, while the remaining two ($80..$FF - 2^7 set) display normal.
The last may seem strange, until we realize that it is meant to be ASCII compatible - that is, all (available) characters show up at their corresponding ASCII code plus high bit set. To make this happen, Woz swapped position of the letter rows with symbols/numbers. As a result the following assignment can be seen:
$00..$1F Inverse Uppercase Letters (aka glyphs of ASCII $40..$5F)
$20..$3F Inverse Symbols/Numbers (aka glyphs of ASCII $20..$3F)
$40..$5F Flashing Uppercase Letters
$60..$7F Flashing Symbols/Numbers
$80..$9F Normal Uppercase Letters (make ASCII control codes show up as letters)
$A0..$BF Normal Symbols/Numbers (like ASCII + $80)
$C0..$DF Normal Uppercase Letters (like ASCII + $80)
$E0..$FF Normal Symbols/Numbers
So by fiddling with address lines and ROM content multiple effects could be reached. The whole circuit was also intended to be used with two 256x8 Bit PROMs (*2). When the A2 was made ready for production, these two chips where replaced by a single 2 KiB ROM where only 512 Bytes (*3) are used (*4). At that point a few tweaks would have allowed the addition of lower case without much increase in hardware cost, as the most expensive part, the character generators size, was already spend. It didn't happen and offered much room for after market enhancements :))
On the IIe, Apple wanted to add lower case letters, which would have worked easy for the normal display, but not for inverse and/or flashing. After all, the readable ASCII portion (*5) is 96 characters. It's impossible to squeeze 96 three times into 256 code positions, so flashing was sacrificed to give way to lower case inverse (*6). The resulting screen codes now looked like this:
$00..$1F Inverse Uppercase Letters
$20..$3F Inverse Symbols/Numbers
$40..$5F Inverse Uppercase Letters (this is where the mouse magic will happen)
$60..$7F Inverse Lowercase Letters (the reason why flashing got dropped)
$80..$9F Normal Uppercase Letters
$A0..$BF Normal Symbols/Numbers (like ASCII + $80)
$C0..$DF Normal Uppercase Letters (like ASCII + $80)
$E0..$FF Normal Lowercase Letters (like ASCII + $80)
So basically two 128 character sets one inverse, one normal. This is now the alternate character set, activated by writing the according soft switch (*7). With the custom IOU it wasn't a big deal to rearrange encoding this way - and have the ROM take care of conversion when outputting in either code set.
Now, when searching for space for MouseText to be included in the IIc (and retrofit to the IIe (*8)), they noticed that there are still two sets of upper case letters in inverse, so one was replaced by 32 new graphics symbols. And the rest is history - as they say :))
Except, it seems strange (again at first) that not $00.$1F, but $40..$5F was used for MouseText graphics. Unless we cross reference back to original character set, where this region was flashing. So using this did complicate the character output routine in ROM further, but at the same time kept compatibility with existing programs displaying inverse by direct screen writes.
Enhancing an existing system is always a mess, isn't it?
I specifically remember a 'warning' that certain 'old' software could display MouseText instead of the desired inverse video if the programmer had used the "redundant" set of inverse characters instead of the ones that they should have, in hindsight, used.
That's the same 'problem' any use of flashing will produce when the alternate character set is used. So not special to MouseText, but the fact that the characterset got modified.
Was this a bug?
Nope. Just the result of being able to display lower case letters.
Was this intended as a hack to fix some other bug (and MouseText was introduced after this hack was no longer necessary)?
While MouseText was indeed a later add-on, it wasn't a bugfix, only an enhancement. After all, the normal text has as well a second upper case letter set ($80..$9F).
Was the creation of MouseText intended all along, with the area reserved by an extra set of inverse characters until the graphical characters were ready?
Nope. As usual, it's a series of later add-ons forced into an existing design.
*1 - Aka, the value written into screen memory.
*2 - A chip Woz seemed to like a lot :))
*3 - More exact, only 448, as only 7 bytes per character cell where read.
*4 - Which kind of sucks, as now there was space to add lower case normal text without much change. At least for output. And if not with teh II for whatever reason, the II+ board would have been the perfect time. :(
*5 - Everything except the control characters ($20..$7F) ... err ... more correct its only 95 characters, as $7F is as well an ASCII contol character, still the IIc displayed it as a doted rectangle.
*6 - Well, there would have been a way to keep flashing and make inverse lower case available (96+96+64=256) by using the codes $80..$9F for inverse lower case. This would require a bit more logic (easy available in the IOU custom chip) plus mode dependant output code to recaclulate screen codes. On the backside this would break the way control codes where displayed (which wouldn't be displayed in all instances - and MouseText broke it anyway for inverse).
Hard to tell why the decision was taken, I guess it was the usual buerocratic one for an easy, straight solution or two full character sets.
*7 - $C00E for standard Charset, $C00F for alternate and $C01E to read the actual state.
*8 - The Enhanced IIe upgrade and all later II versions, all the way to IIe card and IIgs.
