Why did the original Apple //e have two sets of inverse video characters?
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
add a comment |
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
add a comment |
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
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
apple-ii display font
asked yesterday
Robert Columbia
3641315
3641315
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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.
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
add a comment |
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.)
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.)
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
add a comment |
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.)
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
add a comment |
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.)
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.)
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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