Why did the original Apple //e have two sets of inverse video characters?












16














According to Apple II Technical notes Mouse #6, updated January 1989,




In unenhanced Apple IIe computers, the alternate character set contained two sets of inverse uppercase characters. In the enhanced Apple IIe, and in all Apple IIc and IIGS computers, one set of inverse uppercase characters is replaced by a MouseText character set. MouseText is a set of graphical characters designed to allow Apple II computers to display a desktop metaphor on the text screen.




I remember reading about this in the 1990's, and the story was that MouseText was an afterthought, implemented in order to take advantage of the 'extra' character set that had somehow crept in to the system.



Why did the original Apple //e have two sets of inverse uppercase characters?




  • Was this a bug?

  • Was this intended as a hack to fix some other bug (and MouseText was introduced after this hack was no longer necessary)?

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










share|improve this question



























    16














    According to Apple II Technical notes Mouse #6, updated January 1989,




    In unenhanced Apple IIe computers, the alternate character set contained two sets of inverse uppercase characters. In the enhanced Apple IIe, and in all Apple IIc and IIGS computers, one set of inverse uppercase characters is replaced by a MouseText character set. MouseText is a set of graphical characters designed to allow Apple II computers to display a desktop metaphor on the text screen.




    I remember reading about this in the 1990's, and the story was that MouseText was an afterthought, implemented in order to take advantage of the 'extra' character set that had somehow crept in to the system.



    Why did the original Apple //e have two sets of inverse uppercase characters?




    • Was this a bug?

    • Was this intended as a hack to fix some other bug (and MouseText was introduced after this hack was no longer necessary)?

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










    share|improve this question

























      16












      16








      16







      According to Apple II Technical notes Mouse #6, updated January 1989,




      In unenhanced Apple IIe computers, the alternate character set contained two sets of inverse uppercase characters. In the enhanced Apple IIe, and in all Apple IIc and IIGS computers, one set of inverse uppercase characters is replaced by a MouseText character set. MouseText is a set of graphical characters designed to allow Apple II computers to display a desktop metaphor on the text screen.




      I remember reading about this in the 1990's, and the story was that MouseText was an afterthought, implemented in order to take advantage of the 'extra' character set that had somehow crept in to the system.



      Why did the original Apple //e have two sets of inverse uppercase characters?




      • Was this a bug?

      • Was this intended as a hack to fix some other bug (and MouseText was introduced after this hack was no longer necessary)?

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










      share|improve this question













      According to Apple II Technical notes Mouse #6, updated January 1989,




      In unenhanced Apple IIe computers, the alternate character set contained two sets of inverse uppercase characters. In the enhanced Apple IIe, and in all Apple IIc and IIGS computers, one set of inverse uppercase characters is replaced by a MouseText character set. MouseText is a set of graphical characters designed to allow Apple II computers to display a desktop metaphor on the text screen.




      I remember reading about this in the 1990's, and the story was that MouseText was an afterthought, implemented in order to take advantage of the 'extra' character set that had somehow crept in to the system.



      Why did the original Apple //e have two sets of inverse uppercase characters?




      • Was this a bug?

      • Was this intended as a hack to fix some other bug (and MouseText was introduced after this hack was no longer necessary)?

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







      apple-ii display font






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked yesterday









      Robert Columbia

      3641315




      3641315






















          2 Answers
          2






          active

          oldest

          votes


















          17















          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). 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 (*4) 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 (*5). 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 magic happens)
          $60..$7F Inverse Lowercase Letters
          $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 (*6). 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 (*7)), 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?




          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 - Everything except the control characters ($20..$7F) ... err ... more correct its only 95 characters, as $7F is as well an ASCII contoll character, still the IIc displayed it as a doted rectangle.



          *5 - 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.



          *6 - $C00E for standard Charset, $C00F for alternate and $C01E to read the actual state.



          *7 - The Enhanced IIe upgrade and all later II versions, all the way to IIe card and IIgs.






          share|improve this answer























          • Was the character set ever intended to be stored in two 256x8 PROMs, or the 64x7x5 mask ROM part which was used on the Apple I?
            – supercat
            12 hours ago










          • Either way, it got scraped before production start.
            – Raffzahn
            9 hours ago



















          3














          The screen character set on the Apple II looks like this:



          00-1f: ASCII 40-5f, but inverse text
          20-3f: ASCII 20-3f, but inverse text
          40-5f: ASCII 40-5f, but flashing text
          60-7f: ASCII 20-3f, but flashing text
          80-9f: ASCII 40-5f (officially control characters, but displayed as normal text)
          a0-bf: ASCII 20-3f
          c0-df: ASCII 40-5f
          e0-ff: ASCII 20-3f (Apple ][/][+) -or- ASCII 60-7f (Apple //e and later systems with lower case)


          With the 80-column firmware enabled (//e and later), the output is similar, but replaces flashing upper-case text with inverse, and gains lower case:



          40-5f: ASCII 40-5f, inverse
          60-7f: ASCII 60-7f, inverse


          Starting with the Apple //c, the alternate character set with MouseText could be enabled. It left the character set largely unchanged, but replaced flashing upper-case text in the character map:



          40-5f: MouseText


          So MouseText actually replaced the flashing upper-case text in the original layout. When in alternate-text mode, however, flashing was replaced by inverse, so in that sense it also replaced inverse upper case.



          (You can find most of the above in my notes on the "talk" page for the Apple II character set page on wikipedia. The page itself is currently very wrong.)






          share|improve this answer



















          • 2




            Nice writeup. Realy. Maybe a few remarks: MouseText was introduced with the IIc, not IIe, and it replaced he inverse upperces of the second character set, not flashing - that was already done with the IIe. Also, this is not only done for 80 columne mode, but can be switched in in both (40 and 80).
            – Raffzahn
            yesterday










          • You're right: release order was //e, then //c, then enhanced //e, with MouseText first appearing on the //c. I wrote "80-column or alternate-text mode" with the thought that alternate text mode works in 40 columns, but it does seem vague as written. I'll tweak it.
            – fadden
            12 hours ago











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "648"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          noCode: true, onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8652%2fwhy-did-the-original-apple-e-have-two-sets-of-inverse-video-characters%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          17















          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). 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 (*4) 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 (*5). 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 magic happens)
          $60..$7F Inverse Lowercase Letters
          $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 (*6). 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 (*7)), 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?




          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 - Everything except the control characters ($20..$7F) ... err ... more correct its only 95 characters, as $7F is as well an ASCII contoll character, still the IIc displayed it as a doted rectangle.



          *5 - 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.



          *6 - $C00E for standard Charset, $C00F for alternate and $C01E to read the actual state.



          *7 - The Enhanced IIe upgrade and all later II versions, all the way to IIe card and IIgs.






          share|improve this answer























          • Was the character set ever intended to be stored in two 256x8 PROMs, or the 64x7x5 mask ROM part which was used on the Apple I?
            – supercat
            12 hours ago










          • Either way, it got scraped before production start.
            – Raffzahn
            9 hours ago
















          17















          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). 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 (*4) 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 (*5). 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 magic happens)
          $60..$7F Inverse Lowercase Letters
          $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 (*6). 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 (*7)), 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?




          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 - Everything except the control characters ($20..$7F) ... err ... more correct its only 95 characters, as $7F is as well an ASCII contoll character, still the IIc displayed it as a doted rectangle.



          *5 - 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.



          *6 - $C00E for standard Charset, $C00F for alternate and $C01E to read the actual state.



          *7 - The Enhanced IIe upgrade and all later II versions, all the way to IIe card and IIgs.






          share|improve this answer























          • Was the character set ever intended to be stored in two 256x8 PROMs, or the 64x7x5 mask ROM part which was used on the Apple I?
            – supercat
            12 hours ago










          • Either way, it got scraped before production start.
            – Raffzahn
            9 hours ago














          17












          17








          17







          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). 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 (*4) 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 (*5). 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 magic happens)
          $60..$7F Inverse Lowercase Letters
          $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 (*6). 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 (*7)), 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?




          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 - Everything except the control characters ($20..$7F) ... err ... more correct its only 95 characters, as $7F is as well an ASCII contoll character, still the IIc displayed it as a doted rectangle.



          *5 - 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.



          *6 - $C00E for standard Charset, $C00F for alternate and $C01E to read the actual state.



          *7 - The Enhanced IIe upgrade and all later II versions, all the way to IIe card and IIgs.






          share|improve this answer















          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). 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 (*4) 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 (*5). 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 magic happens)
          $60..$7F Inverse Lowercase Letters
          $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 (*6). 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 (*7)), 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?




          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 - Everything except the control characters ($20..$7F) ... err ... more correct its only 95 characters, as $7F is as well an ASCII contoll character, still the IIc displayed it as a doted rectangle.



          *5 - 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.



          *6 - $C00E for standard Charset, $C00F for alternate and $C01E to read the actual state.



          *7 - The Enhanced IIe upgrade and all later II versions, all the way to IIe card and IIgs.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 6 hours ago









          wizzwizz4

          8,319636108




          8,319636108










          answered yesterday









          Raffzahn

          45.7k5103186




          45.7k5103186












          • Was the character set ever intended to be stored in two 256x8 PROMs, or the 64x7x5 mask ROM part which was used on the Apple I?
            – supercat
            12 hours ago










          • Either way, it got scraped before production start.
            – Raffzahn
            9 hours ago


















          • Was the character set ever intended to be stored in two 256x8 PROMs, or the 64x7x5 mask ROM part which was used on the Apple I?
            – supercat
            12 hours ago










          • Either way, it got scraped before production start.
            – Raffzahn
            9 hours ago
















          Was the character set ever intended to be stored in two 256x8 PROMs, or the 64x7x5 mask ROM part which was used on the Apple I?
          – supercat
          12 hours ago




          Was the character set ever intended to be stored in two 256x8 PROMs, or the 64x7x5 mask ROM part which was used on the Apple I?
          – supercat
          12 hours ago












          Either way, it got scraped before production start.
          – Raffzahn
          9 hours ago




          Either way, it got scraped before production start.
          – Raffzahn
          9 hours ago











          3














          The screen character set on the Apple II looks like this:



          00-1f: ASCII 40-5f, but inverse text
          20-3f: ASCII 20-3f, but inverse text
          40-5f: ASCII 40-5f, but flashing text
          60-7f: ASCII 20-3f, but flashing text
          80-9f: ASCII 40-5f (officially control characters, but displayed as normal text)
          a0-bf: ASCII 20-3f
          c0-df: ASCII 40-5f
          e0-ff: ASCII 20-3f (Apple ][/][+) -or- ASCII 60-7f (Apple //e and later systems with lower case)


          With the 80-column firmware enabled (//e and later), the output is similar, but replaces flashing upper-case text with inverse, and gains lower case:



          40-5f: ASCII 40-5f, inverse
          60-7f: ASCII 60-7f, inverse


          Starting with the Apple //c, the alternate character set with MouseText could be enabled. It left the character set largely unchanged, but replaced flashing upper-case text in the character map:



          40-5f: MouseText


          So MouseText actually replaced the flashing upper-case text in the original layout. When in alternate-text mode, however, flashing was replaced by inverse, so in that sense it also replaced inverse upper case.



          (You can find most of the above in my notes on the "talk" page for the Apple II character set page on wikipedia. The page itself is currently very wrong.)






          share|improve this answer



















          • 2




            Nice writeup. Realy. Maybe a few remarks: MouseText was introduced with the IIc, not IIe, and it replaced he inverse upperces of the second character set, not flashing - that was already done with the IIe. Also, this is not only done for 80 columne mode, but can be switched in in both (40 and 80).
            – Raffzahn
            yesterday










          • You're right: release order was //e, then //c, then enhanced //e, with MouseText first appearing on the //c. I wrote "80-column or alternate-text mode" with the thought that alternate text mode works in 40 columns, but it does seem vague as written. I'll tweak it.
            – fadden
            12 hours ago
















          3














          The screen character set on the Apple II looks like this:



          00-1f: ASCII 40-5f, but inverse text
          20-3f: ASCII 20-3f, but inverse text
          40-5f: ASCII 40-5f, but flashing text
          60-7f: ASCII 20-3f, but flashing text
          80-9f: ASCII 40-5f (officially control characters, but displayed as normal text)
          a0-bf: ASCII 20-3f
          c0-df: ASCII 40-5f
          e0-ff: ASCII 20-3f (Apple ][/][+) -or- ASCII 60-7f (Apple //e and later systems with lower case)


          With the 80-column firmware enabled (//e and later), the output is similar, but replaces flashing upper-case text with inverse, and gains lower case:



          40-5f: ASCII 40-5f, inverse
          60-7f: ASCII 60-7f, inverse


          Starting with the Apple //c, the alternate character set with MouseText could be enabled. It left the character set largely unchanged, but replaced flashing upper-case text in the character map:



          40-5f: MouseText


          So MouseText actually replaced the flashing upper-case text in the original layout. When in alternate-text mode, however, flashing was replaced by inverse, so in that sense it also replaced inverse upper case.



          (You can find most of the above in my notes on the "talk" page for the Apple II character set page on wikipedia. The page itself is currently very wrong.)






          share|improve this answer



















          • 2




            Nice writeup. Realy. Maybe a few remarks: MouseText was introduced with the IIc, not IIe, and it replaced he inverse upperces of the second character set, not flashing - that was already done with the IIe. Also, this is not only done for 80 columne mode, but can be switched in in both (40 and 80).
            – Raffzahn
            yesterday










          • You're right: release order was //e, then //c, then enhanced //e, with MouseText first appearing on the //c. I wrote "80-column or alternate-text mode" with the thought that alternate text mode works in 40 columns, but it does seem vague as written. I'll tweak it.
            – fadden
            12 hours ago














          3












          3








          3






          The screen character set on the Apple II looks like this:



          00-1f: ASCII 40-5f, but inverse text
          20-3f: ASCII 20-3f, but inverse text
          40-5f: ASCII 40-5f, but flashing text
          60-7f: ASCII 20-3f, but flashing text
          80-9f: ASCII 40-5f (officially control characters, but displayed as normal text)
          a0-bf: ASCII 20-3f
          c0-df: ASCII 40-5f
          e0-ff: ASCII 20-3f (Apple ][/][+) -or- ASCII 60-7f (Apple //e and later systems with lower case)


          With the 80-column firmware enabled (//e and later), the output is similar, but replaces flashing upper-case text with inverse, and gains lower case:



          40-5f: ASCII 40-5f, inverse
          60-7f: ASCII 60-7f, inverse


          Starting with the Apple //c, the alternate character set with MouseText could be enabled. It left the character set largely unchanged, but replaced flashing upper-case text in the character map:



          40-5f: MouseText


          So MouseText actually replaced the flashing upper-case text in the original layout. When in alternate-text mode, however, flashing was replaced by inverse, so in that sense it also replaced inverse upper case.



          (You can find most of the above in my notes on the "talk" page for the Apple II character set page on wikipedia. The page itself is currently very wrong.)






          share|improve this answer














          The screen character set on the Apple II looks like this:



          00-1f: ASCII 40-5f, but inverse text
          20-3f: ASCII 20-3f, but inverse text
          40-5f: ASCII 40-5f, but flashing text
          60-7f: ASCII 20-3f, but flashing text
          80-9f: ASCII 40-5f (officially control characters, but displayed as normal text)
          a0-bf: ASCII 20-3f
          c0-df: ASCII 40-5f
          e0-ff: ASCII 20-3f (Apple ][/][+) -or- ASCII 60-7f (Apple //e and later systems with lower case)


          With the 80-column firmware enabled (//e and later), the output is similar, but replaces flashing upper-case text with inverse, and gains lower case:



          40-5f: ASCII 40-5f, inverse
          60-7f: ASCII 60-7f, inverse


          Starting with the Apple //c, the alternate character set with MouseText could be enabled. It left the character set largely unchanged, but replaced flashing upper-case text in the character map:



          40-5f: MouseText


          So MouseText actually replaced the flashing upper-case text in the original layout. When in alternate-text mode, however, flashing was replaced by inverse, so in that sense it also replaced inverse upper case.



          (You can find most of the above in my notes on the "talk" page for the Apple II character set page on wikipedia. The page itself is currently very wrong.)







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 12 hours ago

























          answered yesterday









          fadden

          3,00211146




          3,00211146








          • 2




            Nice writeup. Realy. Maybe a few remarks: MouseText was introduced with the IIc, not IIe, and it replaced he inverse upperces of the second character set, not flashing - that was already done with the IIe. Also, this is not only done for 80 columne mode, but can be switched in in both (40 and 80).
            – Raffzahn
            yesterday










          • You're right: release order was //e, then //c, then enhanced //e, with MouseText first appearing on the //c. I wrote "80-column or alternate-text mode" with the thought that alternate text mode works in 40 columns, but it does seem vague as written. I'll tweak it.
            – fadden
            12 hours ago














          • 2




            Nice writeup. Realy. Maybe a few remarks: MouseText was introduced with the IIc, not IIe, and it replaced he inverse upperces of the second character set, not flashing - that was already done with the IIe. Also, this is not only done for 80 columne mode, but can be switched in in both (40 and 80).
            – Raffzahn
            yesterday










          • You're right: release order was //e, then //c, then enhanced //e, with MouseText first appearing on the //c. I wrote "80-column or alternate-text mode" with the thought that alternate text mode works in 40 columns, but it does seem vague as written. I'll tweak it.
            – fadden
            12 hours ago








          2




          2




          Nice writeup. Realy. Maybe a few remarks: MouseText was introduced with the IIc, not IIe, and it replaced he inverse upperces of the second character set, not flashing - that was already done with the IIe. Also, this is not only done for 80 columne mode, but can be switched in in both (40 and 80).
          – Raffzahn
          yesterday




          Nice writeup. Realy. Maybe a few remarks: MouseText was introduced with the IIc, not IIe, and it replaced he inverse upperces of the second character set, not flashing - that was already done with the IIe. Also, this is not only done for 80 columne mode, but can be switched in in both (40 and 80).
          – Raffzahn
          yesterday












          You're right: release order was //e, then //c, then enhanced //e, with MouseText first appearing on the //c. I wrote "80-column or alternate-text mode" with the thought that alternate text mode works in 40 columns, but it does seem vague as written. I'll tweak it.
          – fadden
          12 hours ago




          You're right: release order was //e, then //c, then enhanced //e, with MouseText first appearing on the //c. I wrote "80-column or alternate-text mode" with the thought that alternate text mode works in 40 columns, but it does seem vague as written. I'll tweak it.
          – fadden
          12 hours ago


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Retrocomputing Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8652%2fwhy-did-the-original-apple-e-have-two-sets-of-inverse-video-characters%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          An IMO inspired problem

          Management

          Investment