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












17















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



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)? For example, this might happen if an intermittent bug caused the system to sometimes query the wrong address in search of inverse video characters - it might have been deemed easier to simply copy the characters into the "wrong" address than to fix the root addressing bug.

  • 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

























  • "For example, this might happen if an intermittent bug caused the system to sometimes query the wrong address in search of inverse video characters - it might have been deemed easier to simply copy the characters into the "wrong" address than to fix the root addressing bug." Mind to explain what that should be? More so, what is 'search for an invese character' ?

    – Raffzahn
    Jan 6 at 13:30
















17















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



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)? For example, this might happen if an intermittent bug caused the system to sometimes query the wrong address in search of inverse video characters - it might have been deemed easier to simply copy the characters into the "wrong" address than to fix the root addressing bug.

  • 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

























  • "For example, this might happen if an intermittent bug caused the system to sometimes query the wrong address in search of inverse video characters - it might have been deemed easier to simply copy the characters into the "wrong" address than to fix the root addressing bug." Mind to explain what that should be? More so, what is 'search for an invese character' ?

    – Raffzahn
    Jan 6 at 13:30














17












17








17








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



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)? For example, this might happen if an intermittent bug caused the system to sometimes query the wrong address in search of inverse video characters - it might have been deemed easier to simply copy the characters into the "wrong" address than to fix the root addressing bug.

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



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)? For example, this might happen if an intermittent bug caused the system to sometimes query the wrong address in search of inverse video characters - it might have been deemed easier to simply copy the characters into the "wrong" address than to fix the root addressing bug.

  • 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 text font






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 6 at 12:41







Robert Columbia

















asked Jan 3 at 22:26









Robert ColumbiaRobert Columbia

3691315




3691315













  • "For example, this might happen if an intermittent bug caused the system to sometimes query the wrong address in search of inverse video characters - it might have been deemed easier to simply copy the characters into the "wrong" address than to fix the root addressing bug." Mind to explain what that should be? More so, what is 'search for an invese character' ?

    – Raffzahn
    Jan 6 at 13:30



















  • "For example, this might happen if an intermittent bug caused the system to sometimes query the wrong address in search of inverse video characters - it might have been deemed easier to simply copy the characters into the "wrong" address than to fix the root addressing bug." Mind to explain what that should be? More so, what is 'search for an invese character' ?

    – Raffzahn
    Jan 6 at 13:30

















"For example, this might happen if an intermittent bug caused the system to sometimes query the wrong address in search of inverse video characters - it might have been deemed easier to simply copy the characters into the "wrong" address than to fix the root addressing bug." Mind to explain what that should be? More so, what is 'search for an invese character' ?

– Raffzahn
Jan 6 at 13:30





"For example, this might happen if an intermittent bug caused the system to sometimes query the wrong address in search of inverse video characters - it might have been deemed easier to simply copy the characters into the "wrong" address than to fix the root addressing bug." Mind to explain what that should be? More so, what is 'search for an invese character' ?

– Raffzahn
Jan 6 at 13:30










2 Answers
2






active

oldest

votes


















22















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 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 (*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?




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 - 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
    Jan 4 at 15:48











  • Either way, it got scraped before production start.

    – Raffzahn
    Jan 4 at 18:37











  • According to mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/… it looks like revs 0 and 1 of the video generator used a 64x7x5 ROM; Rev 7 went to a 2Kx8 ROM. If the 2Kx8 ROM had been used from the start, the Apple II could have easily supported 96 normal, 96 inverse, and 64 flashing characters with less circuitry than it ended up using.

    – supercat
    Jan 7 at 21:14





















5














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
    Jan 4 at 0:05











  • 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
    Jan 4 at 15:41











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









22















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 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 (*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?




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 - 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
    Jan 4 at 15:48











  • Either way, it got scraped before production start.

    – Raffzahn
    Jan 4 at 18:37











  • According to mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/… it looks like revs 0 and 1 of the video generator used a 64x7x5 ROM; Rev 7 went to a 2Kx8 ROM. If the 2Kx8 ROM had been used from the start, the Apple II could have easily supported 96 normal, 96 inverse, and 64 flashing characters with less circuitry than it ended up using.

    – supercat
    Jan 7 at 21:14


















22















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 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 (*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?




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 - 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
    Jan 4 at 15:48











  • Either way, it got scraped before production start.

    – Raffzahn
    Jan 4 at 18:37











  • According to mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/… it looks like revs 0 and 1 of the video generator used a 64x7x5 ROM; Rev 7 went to a 2Kx8 ROM. If the 2Kx8 ROM had been used from the start, the Apple II could have easily supported 96 normal, 96 inverse, and 64 flashing characters with less circuitry than it ended up using.

    – supercat
    Jan 7 at 21:14
















22












22








22








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 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 (*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?




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 - 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 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 (*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?




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 - 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 Jan 6 at 13:33

























answered Jan 4 at 0:00









RaffzahnRaffzahn

46.6k5104189




46.6k5104189













  • 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
    Jan 4 at 15:48











  • Either way, it got scraped before production start.

    – Raffzahn
    Jan 4 at 18:37











  • According to mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/… it looks like revs 0 and 1 of the video generator used a 64x7x5 ROM; Rev 7 went to a 2Kx8 ROM. If the 2Kx8 ROM had been used from the start, the Apple II could have easily supported 96 normal, 96 inverse, and 64 flashing characters with less circuitry than it ended up using.

    – supercat
    Jan 7 at 21:14





















  • 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
    Jan 4 at 15:48











  • Either way, it got scraped before production start.

    – Raffzahn
    Jan 4 at 18:37











  • According to mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/… it looks like revs 0 and 1 of the video generator used a 64x7x5 ROM; Rev 7 went to a 2Kx8 ROM. If the 2Kx8 ROM had been used from the start, the Apple II could have easily supported 96 normal, 96 inverse, and 64 flashing characters with less circuitry than it ended up using.

    – supercat
    Jan 7 at 21:14



















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
Jan 4 at 15:48





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
Jan 4 at 15:48













Either way, it got scraped before production start.

– Raffzahn
Jan 4 at 18:37





Either way, it got scraped before production start.

– Raffzahn
Jan 4 at 18:37













According to mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/… it looks like revs 0 and 1 of the video generator used a 64x7x5 ROM; Rev 7 went to a 2Kx8 ROM. If the 2Kx8 ROM had been used from the start, the Apple II could have easily supported 96 normal, 96 inverse, and 64 flashing characters with less circuitry than it ended up using.

– supercat
Jan 7 at 21:14







According to mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/… it looks like revs 0 and 1 of the video generator used a 64x7x5 ROM; Rev 7 went to a 2Kx8 ROM. If the 2Kx8 ROM had been used from the start, the Apple II could have easily supported 96 normal, 96 inverse, and 64 flashing characters with less circuitry than it ended up using.

– supercat
Jan 7 at 21:14













5














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
    Jan 4 at 0:05











  • 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
    Jan 4 at 15:41
















5














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
    Jan 4 at 0:05











  • 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
    Jan 4 at 15:41














5












5








5







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 Jan 4 at 15:42

























answered Jan 3 at 23:35









faddenfadden

3,02211147




3,02211147








  • 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
    Jan 4 at 0:05











  • 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
    Jan 4 at 15:41














  • 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
    Jan 4 at 0:05











  • 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
    Jan 4 at 15:41








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
Jan 4 at 0:05





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
Jan 4 at 0:05













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
Jan 4 at 15:41





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
Jan 4 at 15:41


















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.




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

Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

ComboBox Display Member on multiple fields

Is it possible to collect Nectar points via Trainline?