Friday, July 24, 2020
Google Drive is Evil
This blogpost is here: https://defining-computers.blogspot.com/2020/07/google-drive-is-evil.html.
Tuesday, July 21, 2020
Google Drive Is Evil (666)
666
As Unix file permissions, this file mode allows the entire world to read and write a file.
It basically makes the file a graffiti magnet: a place to write things like "Call {phone-number} for a good time.", etc.
It's particularly evil when this is the effective file permissions for your system files, as was the case for a certain early Internet-capable computer operating system of the 1990s and early 2000s.
[JMR202007231800 edit:
(I thought I had posted elsewhere about the real meaning of "666" in Unix and Unix-like operating systems, and I had promised myself to link that post in here, when I dashed this rant off just before hitting the hay several nights back. And I then forgot about it. Now I can't find that post.
I guess this is a good enough place to post it again.)
For a little preface, here (https://reiisi.blogspot.com/2011/10/conspiracy-theories.html) is a little explanation of why we shouldn't fear conspiracies, in which I point out that the author and leader of all the conspiracies is none other than the father of lies, the devil. And he can't keep his stories straight, and we can draw conclusions from that fact --
Conspiracies will always fail, even if they do serious damage going down.
And here (https://reiisi.blogspot.com/2011/10/conspiracy-theories.html) is a little discussion of a typical part of one of the reasons I feel a certain ambivalence about Google.
To go into some detail on this, in Unix-like computer operating systems, there is a concept called "file permissions". These are the permissions (or limits) that the system enforces about who can access a file. Traditionally, they were specified as bits in a binary number, representing the on/off states for sets of permissions, 1 being on and 0 being off.
The permissions were these:
Or,
Reading or expressing that as a binary number, you get the following
So "6" was read and write permissions allowed.
There were three sets of these permissions, one each for the owner of the file (the "User"), the primary group that the owner was a member of (the Group), and all others (Other).
So, a "600" permission setting allowed the owner to read and write a file, and gave no one else access.
A "644" setting allowed the owner to read and write the file, and allowed the owner's primary group and others in general to just read it.
A "660" setting allowed both the owner and the owner's primary group to both read and write a file.
A setting of "666" allowed basically anyone to read the file and write to it.
This "666" permission is not in-and-of-itself strictly evil. If you want a graffiti wall, "666" is pretty much what you usually want to set it as.
The scriptures in the Revelation which refer to "666" as the mark of the beast indicate that the mark would be in the palm of the hand and in the forehead, or a person would not be allowed to engage in necessary commerce activities. (Such marks have appeared in history, I leave that research to the interested reader.)
I'm not going to say that John was or was not also referring to file permissions. But if we interpret these file permissions in such a way, the palm of the hand might be the device drivers for an operating system, and the forehead might be certain files in the kernel (as one possible interpretation, although there is a little bit of detail I'm not discussing here: The evil "666" would be for configuration files rather than actual drivers and kernel executables. The "766" and "777" for drivers and executables, while just as evil, are obviously enough wrong and hard enough -- cough -- Java -- cough -- to implement.)
This would essentially be allowing anyone with the necessary arcane knowledge to control a computer's calculations and functions from a distance.
A certain popular operating system had this kind of setting as a "feature" during the early days of the Internet (ca. 1993-1999). (In other words, the OS allowed anyone who knew how to reach a computer running that operating system full control over the computer. I'll let the interested reader look that up as well.)
What does this have to do with Google?
]
Google offers a file storage and sharing service they call Drive.
Freebies always come with strings attached. One of the strings on this one is that you have a part of your drive that you don't manage. The effective default permissions are not 666, but are 622. You can change them to 662 if you want, but they don't let you shut off write permissions for the "everybody else on the web". Anybody who has the e-mail address for the account you use to access Google Drive can share anything they please with you.
This might not be so bad. It's a bit like a physical mailbox. But the physical mailbox comes with postal system laws about abusing the postal system, whereas Google Drive doesn't have any way to dis-incentivize abuse of the system.
So you get advertisement you didn't want to see, and you have to look at it to delete it.
Even if it is some group of men in some third world country pretending to be women who post intimate pictures of themselves and offer sexual phavors.
You can delete your share link to the file, but they can make another file and share it with you again after they figure they've caught all the phish they could the last time around.
The techniques to block this kind of thing are available for e-mail, and work well enough there to keep the offensive mail to somewhat to a minimum:
As Unix file permissions, this file mode allows the entire world to read and write a file.
It basically makes the file a graffiti magnet: a place to write things like "Call {phone-number} for a good time.", etc.
It's particularly evil when this is the effective file permissions for your system files, as was the case for a certain early Internet-capable computer operating system of the 1990s and early 2000s.
[JMR202007231800 edit:
(I thought I had posted elsewhere about the real meaning of "666" in Unix and Unix-like operating systems, and I had promised myself to link that post in here, when I dashed this rant off just before hitting the hay several nights back. And I then forgot about it. Now I can't find that post.
I guess this is a good enough place to post it again.)
For a little preface, here (https://reiisi.blogspot.com/2011/10/conspiracy-theories.html) is a little explanation of why we shouldn't fear conspiracies, in which I point out that the author and leader of all the conspiracies is none other than the father of lies, the devil. And he can't keep his stories straight, and we can draw conclusions from that fact --
Conspiracies will always fail, even if they do serious damage going down.
And here (https://reiisi.blogspot.com/2011/10/conspiracy-theories.html) is a little discussion of a typical part of one of the reasons I feel a certain ambivalence about Google.
To go into some detail on this, in Unix-like computer operating systems, there is a concept called "file permissions". These are the permissions (or limits) that the system enforces about who can access a file. Traditionally, they were specified as bits in a binary number, representing the on/off states for sets of permissions, 1 being on and 0 being off.
The permissions were these:
Read, Write, and/or Execute allowed
Or,
rwx
Reading or expressing that as a binary number, you get the following
| (0) | 000 | : | no read, | no write, | no execute |
| (1) | 001 | : | no read, | no write, | execute |
| (2) | 010 | : | no read, | write, | no execute |
| (3) | 011 | : | no read, | write, | execute |
| (4) | 100 | : | read, | no write, | no execute |
| (5) | 101 | : | read, | no write, | execute |
| (6) | 110 | : | read, | write, | no execute |
| (7) | 111 | : | read, | write, | execute |
So "6" was read and write permissions allowed.
There were three sets of these permissions, one each for the owner of the file (the "User"), the primary group that the owner was a member of (the Group), and all others (Other).
So, a "600" permission setting allowed the owner to read and write a file, and gave no one else access.
A "644" setting allowed the owner to read and write the file, and allowed the owner's primary group and others in general to just read it.
A "660" setting allowed both the owner and the owner's primary group to both read and write a file.
A setting of "666" allowed basically anyone to read the file and write to it.
This "666" permission is not in-and-of-itself strictly evil. If you want a graffiti wall, "666" is pretty much what you usually want to set it as.
The scriptures in the Revelation which refer to "666" as the mark of the beast indicate that the mark would be in the palm of the hand and in the forehead, or a person would not be allowed to engage in necessary commerce activities. (Such marks have appeared in history, I leave that research to the interested reader.)
I'm not going to say that John was or was not also referring to file permissions. But if we interpret these file permissions in such a way, the palm of the hand might be the device drivers for an operating system, and the forehead might be certain files in the kernel (as one possible interpretation, although there is a little bit of detail I'm not discussing here: The evil "666" would be for configuration files rather than actual drivers and kernel executables. The "766" and "777" for drivers and executables, while just as evil, are obviously enough wrong and hard enough -- cough -- Java -- cough -- to implement.)
This would essentially be allowing anyone with the necessary arcane knowledge to control a computer's calculations and functions from a distance.
A certain popular operating system had this kind of setting as a "feature" during the early days of the Internet (ca. 1993-1999). (In other words, the OS allowed anyone who knew how to reach a computer running that operating system full control over the computer. I'll let the interested reader look that up as well.)
What does this have to do with Google?
]
Google offers a file storage and sharing service they call Drive.
Google Drive
Freebies always come with strings attached. One of the strings on this one is that you have a part of your drive that you don't manage. The effective default permissions are not 666, but are 622. You can change them to 662 if you want, but they don't let you shut off write permissions for the "everybody else on the web". Anybody who has the e-mail address for the account you use to access Google Drive can share anything they please with you.
This might not be so bad. It's a bit like a physical mailbox. But the physical mailbox comes with postal system laws about abusing the postal system, whereas Google Drive doesn't have any way to dis-incentivize abuse of the system.
So you get advertisement you didn't want to see, and you have to look at it to delete it.
Even if it is some group of men in some third world country pretending to be women who post intimate pictures of themselves and offer sexual phavors.
You can delete your share link to the file, but they can make another file and share it with you again after they figure they've caught all the phish they could the last time around.
The techniques to block this kind of thing are available for e-mail, and work well enough there to keep the offensive mail to somewhat to a minimum:
- black lists of users you don't want anything from,
- white lists of users you will accept things from,
- and grey lists to block users who behave in certain ways (like huge To lists, which would be share lists for Google Drive).
These techniques should have been in Google Drive from the beginning. They weren't, so I didn't use Google Drive for a long time, until certain friends needed to share stuff with me on it and found it easiest to share on Google Drive.
--- Protocols for these techniques should have been part of the e-mail protocols from the beginning, but they were too hard to implement at first. And there were certain hyper-competitive companies that insisted on being king-of-the-hill in the computer industry, which insisted on making e-mail an end-user product and feature that they could use to compete unethically in the marketplace before the protocols were complete.
Now the protocols exist in conflicting ways, which is not a good thing, but a separate rant.
(The solution should have been two or three levels of protocols, and ordinary users should never have had to see the unfiltered protocols.
But, as I say, certain companies were too impatient. They needed to take over the industry, so they needed them before they were ready. History repeats itself.) ---
Now that I use Google Drive, I regularly get graphically explicit offers for sexual phavors all the time, and I have to go to the trouble of phlagging them as ophensive and illegal, and of deleting myself from the huge share lists.
When enough people flag them as offensive and illegal, Google eventually deletes the share list, at least, if not the actual files. But that's after the people who phish with the sexually explicit shared files have caught enough people who couldn't resist looking for more to make it worth their while to do it again.
Google Drive is either an incompetent service or a blatantly malicious service.
It's time to boycott it.
(Maybe not yet time to boycott Google's gmail, maybe not yet time to boycott Google's Android phone OS, maybe not yet time to boycott Google's Chrome web browser, etc. Maybe not. But definitely time to boycott Google Drive file storage and sharing.)
I will be going back to keeping my own files on my own physical file systems, and using either e-mail or self-hosted web servers to share my files. I suggest you do so, as well.
[JMR202203201344 edit:
Braver words than actions.
I still have not been able to extricate myself from Google's services. Not enough time, money, or other resources to set up my own mail server, get a static IP address and a domain, and then maintain it.
God sometimes requires us to do the very difficult or even attempt the impossible, but He generally does not require us to operate beyond the bounds of our resources and reason.
For now, at least, I must satisfy myself with simply being aware that Google is filtering my mail, tailoring my search results, trying to profit on the services they offer, and not trying to bankrupt themselves meeting ideal expectations about their services, meaning that I have to be willing to delete obvious spam without wasting time or emotional energy looking at it.
Which, really, is in keeping with the understanding I get from reading the Revelation:
The mark of the Christ is to keep his teachings in our hearts, minds, and acts.
The mark of the beast is to let the adversary of our souls impose his false teachings on our hearts, minds, and acts.
The influence of the devil does tend to work from the outside in.
But our spirits came out of God, and the influence of the light of Christ works from inside us, outwards.
]
Sunday, April 12, 2020
CPUs -- 8-bit vs. 16-bit vs. 32-bit and Unreasonable Behavior
Recently, I was participating in a FB group and I noticed extremely unreasonable behavior on the part of one member of the group.
The group is a group dedicated to the M68000 microprocessor, which is generally classed as a mixed 16-bit and 32-bit processor, and this member of the group was obstinately using all sorts of bad argument technique to insist that the 68000 must be classed strictly as a 16-bit CPU, while accusing anyone who opposed his opinion of using the very same false argumentation techniques that he was using.
I looked at his profile on his FB home, and noted two things -- he registered the user to create a certain group, and he seems to claim some virtue in "being mean to FB users". LOL.
I could report that Facebook user and probably get him kicked off, but I won't, for three reasons.
One, I have been similarly unreasonable in flame wars. I try to shut my unreasonableness down as soon as I notice it, even if it means dropping out of the flame war.
Two, putting up with unreasonable behavior is a necessary civility. If we don't allow another person's misbehavior, we have no claim to any right to behave unreasonably, and pretty soon society descends into war.
Three, we often learn useful things from unreasonable behavior.
Unreasonable behavior.
When I think of unreasonable behavior, an example from the Bible comes to mind in the incident of Baal-peor, when a man and a woman were summarily executed for adultery. The record of the Old Testament is not very complete, and it's hard to be completely sure that the killing was done to stop the plague of sexually transmitted disease that people of Moab had started among people of Israel, but careful reading does indicate that was most likely the case.
And it's a classic example of unreasonable behavior, begetting unreasonable behavior, echoing to the present when ordinary citizens who stray outside without reason in Europe have reportedly been summarily shot. A couple of things closer to home for me (Kantō area) that I get from mainstream news reports:
My tendency to diverge from the topic is pretty unreasonable, too. Back to the topic.
CPUs are yet another thing one should never use a one-dimensional yardstick to compare.
I know that there have been real, if not commercial) implementations of strictly 8-bit
CPUs.
But that requires an 8-bit address space, and it's hard to fit much of a program in 256 bytes of program + data. Well, Harvard architecture would allow 256 bytes max of data space and 256 bytes of program space, but it's still really tight, and the programs you could write in that much space are likely to be better implemented with discrete logic or programmable logic devices.
Okay, it would be a fun topic to pursue, and might even be worth a master's thesis or such. But it would also be unreasonable for anyone who is not retired, in the present socio-economic environment.
That is, until someone does it and proves that there is some useful application for it, it would be unreasonable.
RISC processors were once an unreasonable idea, too.
So, all the so-called 8-bit CPUs you have used are mixed size CPUs, because they have address spaces larger than 256 bytes.
And we probably should admit that there is no useful strictly 4-bit CPU to be built.
A CPU with a 4-bit-wide instruction set? Yes, those exist. A CPU with 4-bit-wide registers? Yes, those exist. A CPU with a 4-bit-wide address space? Hmm. Okay, there are parts of larger CPUs that actually consist of such things.
Maybe we should have more open minds, instead.
Back to 8-bit CPUs. Most such are characterized as 8-bit for their data register width and basic instruction width, and have wider addresses. That's three dimensions, data register width, basic instruction width, and address width.
There are other dimensions, such as number and type of registers, orthogonality of instruction architecture, generalization and specialization of instruction set, etc.
But, even if you line up a bunch of these measures, you really don't end up knowing that much about a CPU until you start looking at well-written code for it and comparing it with good code for other processors.
To that end, I've been working on a set of common library functions that could be useful in comparing processors. I'm borrowing the code for an old Forth interpreter to center the library around, but it will not be limited to the Forth paradigms. If I work it well, it should produce a Forth-like interpreter that will be portable across the CPUs, and it should allow others to produce similar library sets for other CPUs.
I should be posting the beginnings of the code later today, for the 6800, the 6801, the 6809, and the 68000, on my OSDN account. I'll link to that from here.
[JMR202007181941:
Here is the project on OSDN, but it's stuck at a place where the 68K code is not yet up:
https://ja.osdn.net/projects/splitstack-runtimelib/
]
The group is a group dedicated to the M68000 microprocessor, which is generally classed as a mixed 16-bit and 32-bit processor, and this member of the group was obstinately using all sorts of bad argument technique to insist that the 68000 must be classed strictly as a 16-bit CPU, while accusing anyone who opposed his opinion of using the very same false argumentation techniques that he was using.
I looked at his profile on his FB home, and noted two things -- he registered the user to create a certain group, and he seems to claim some virtue in "being mean to FB users". LOL.
I could report that Facebook user and probably get him kicked off, but I won't, for three reasons.
One, I have been similarly unreasonable in flame wars. I try to shut my unreasonableness down as soon as I notice it, even if it means dropping out of the flame war.
Two, putting up with unreasonable behavior is a necessary civility. If we don't allow another person's misbehavior, we have no claim to any right to behave unreasonably, and pretty soon society descends into war.
Three, we often learn useful things from unreasonable behavior.
Unreasonable behavior.
When I think of unreasonable behavior, an example from the Bible comes to mind in the incident of Baal-peor, when a man and a woman were summarily executed for adultery. The record of the Old Testament is not very complete, and it's hard to be completely sure that the killing was done to stop the plague of sexually transmitted disease that people of Moab had started among people of Israel, but careful reading does indicate that was most likely the case.
And it's a classic example of unreasonable behavior, begetting unreasonable behavior, echoing to the present when ordinary citizens who stray outside without reason in Europe have reportedly been summarily shot. A couple of things closer to home for me (Kantō area) that I get from mainstream news reports:
- pretty much every member of one group of young people who had a "live event" (dance party) last week has tested positive for COVID-19;
- one man who tested positive deliberately went out and got in the face of innocent salesclerks and others, infecting at least two of the people he came into contact with.
My tendency to diverge from the topic is pretty unreasonable, too. Back to the topic.
CPUs are yet another thing one should never use a one-dimensional yardstick to compare.
I know that there have been real, if not commercial) implementations of strictly 8-bit
CPUs.
But that requires an 8-bit address space, and it's hard to fit much of a program in 256 bytes of program + data. Well, Harvard architecture would allow 256 bytes max of data space and 256 bytes of program space, but it's still really tight, and the programs you could write in that much space are likely to be better implemented with discrete logic or programmable logic devices.
Okay, it would be a fun topic to pursue, and might even be worth a master's thesis or such. But it would also be unreasonable for anyone who is not retired, in the present socio-economic environment.
That is, until someone does it and proves that there is some useful application for it, it would be unreasonable.
RISC processors were once an unreasonable idea, too.
So, all the so-called 8-bit CPUs you have used are mixed size CPUs, because they have address spaces larger than 256 bytes.
And we probably should admit that there is no useful strictly 4-bit CPU to be built.
A CPU with a 4-bit-wide instruction set? Yes, those exist. A CPU with 4-bit-wide registers? Yes, those exist. A CPU with a 4-bit-wide address space? Hmm. Okay, there are parts of larger CPUs that actually consist of such things.
Maybe we should have more open minds, instead.
Back to 8-bit CPUs. Most such are characterized as 8-bit for their data register width and basic instruction width, and have wider addresses. That's three dimensions, data register width, basic instruction width, and address width.
There are other dimensions, such as number and type of registers, orthogonality of instruction architecture, generalization and specialization of instruction set, etc.
But, even if you line up a bunch of these measures, you really don't end up knowing that much about a CPU until you start looking at well-written code for it and comparing it with good code for other processors.
To that end, I've been working on a set of common library functions that could be useful in comparing processors. I'm borrowing the code for an old Forth interpreter to center the library around, but it will not be limited to the Forth paradigms. If I work it well, it should produce a Forth-like interpreter that will be portable across the CPUs, and it should allow others to produce similar library sets for other CPUs.
I should be posting the beginnings of the code later today, for the 6800, the 6801, the 6809, and the 68000, on my OSDN account. I'll link to that from here.
[JMR202007181941:
Here is the project on OSDN, but it's stuck at a place where the 68K code is not yet up:
https://ja.osdn.net/projects/splitstack-runtimelib/
]
Wednesday, November 13, 2019
Connecting Screen Controls And Audio on the Panasonic Let's Note CF-NX2 (Defenestration And Deforestation, Part 3)
This thread probably all belonged in this blog, but I put the first two parts in my main blog:
Update on the status of this notebook PC:
I called the recycling company again, and, after initially arranging to return this thing, I asked again, and this time they said they'd send me the AC Adapter and I could send the bad one back. And if it didn't work out I could still send it back later.
I said a quick prayer and weighed the options again, and decided this machine is usable enough for me, and I need a true PC, so I asked them to send the adapter.
Then I did a search on the web for others who might have had screen control and audio control issues with this particular model, and found several posts:
This one gave me the methods to connect the keyboard function controls, so that I can hear audio without plugging in external speakers or a headset, and so that I can turn the bright back up when the dying/dead AC adapter forces the backlight off.
https://gtrt7.com/blog/linux/ubuntu1710-on-letsnote
These two are earlier posts that essentially confirm the information in the later post:
https://qiita.com/PopularHero/items/5fda32b42f772061eb2c
https://www.linuxquestions.org/questions/slackware-14/sounds-issues-realtek-hda-14-2-a-4175596546/
The nitty-gritty is that Ubuntu has not had the appropriate settings information in the common install code. I should talk with the devs and get them to fix that. In the meantime, here are the settings:
In
Section "Device"
Identifier "card0"
Driver "intel"
Option "Backlight" "intel_backlight"
BusID "PCI:0:2:0"
EndSection
The file probably won't exist, so, if you do this, you will probably make it new, and this will probably be the only thing in it.
And then in
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor acpi_osi="
(with no line breaks, regardless of how your browser shows the line).
Then run update-grub with the usual root privileges:
(But, if you have the bad AC adapter, you really do have to fix the adapter or get a new one if you plan to continue using the PC. The wires inside the insulator will eventually break, like they have on this one, and then you will be running on fumes, like I am right now.)
Two points to take note of. One, this does not fix the behavior of the notebook when a failing AC adapter is plugged in. It will force the brightness on the internal display to zero, and keep firing the phantom button pushes until you unplug the thing.
Which means that you will need to unplug the adapter, and then wait until the filled button-push buffer empties and the on-screen indicator goes away. Then you can manually hit the brightness-up button so you can see what's on the internal screen again.
(Just between you and me, I consider this a poorly-thought-out feature in Panasonic's ergonomic design. Yeah, maybe it saves you from burning your notebook PC out, but must people will just think the thing has died. And, instead of taking it to someone who knows to replace the AC adapter, will just throw the poor thing away and add to the landfills and worker poisoning in poor 3rd-world communities.)
In the file
[Element Headphone]
switch = off
volume = off
and change the volume line, and add two override lines, as follows:
[Element Headphone]
switch = off
volume = merge
override-map.1 = all
override-map.2 = all-left,all-right
Then find the following lines (speaker element):
[Element Speaker] required-any = any
switch = mute
volume = merge
override-map.1 = all
override-map.2 = all-left,all-right
and change only the volume line, as follows:
[Element Speaker] required-any = any
switch = mute
volume = off
override-map.1 = all
override-map.2 = all-left,all-right
Having done that, you and I can just restart the pulseaudio daemon by the usual methods, whether we do it by the cool way with service commands or the hard way by rebooting the computer.
And now we can hear the computer beep at us, or listen to youtube in monaural.
[JMR201911160031 Update:
Rather than make another post to confirm that the replacement adapter does fix the brightness problem, I'll add that information here. However, the adapter does not fix the brightness controls disconnect problem, so, until the patches make their way into the Debian and Ubuntu distributions, the information on this page remains relevant.
Let's figure out what kind of pics to take:
Booting up, AC adapter plugged in, pilot showing green, and no complaints about the adapter. (No internal screen because BIOS has the external screen selected at higher priority than the internal screen for the boot process.)
Made it all the way to the Ubuntu login screen without the phantom screen brightness control button activity, and the screen is appropriately bright.
Brightness control keyboard controls work, and no phantom presses pushing the brightness down, and you can see I was not eating my nightly yogghurt with chopsticks.
- Defenestration And Deforestation
Not conspiracy theories, theories about economic entropy. - Ubuntu on Let's Note (Defenestration And Deforestation, Part 2)
Discussion of partial success swimming against economic entropy
Update on the status of this notebook PC:
I called the recycling company again, and, after initially arranging to return this thing, I asked again, and this time they said they'd send me the AC Adapter and I could send the bad one back. And if it didn't work out I could still send it back later.
I said a quick prayer and weighed the options again, and decided this machine is usable enough for me, and I need a true PC, so I asked them to send the adapter.
Then I did a search on the web for others who might have had screen control and audio control issues with this particular model, and found several posts:
This one gave me the methods to connect the keyboard function controls, so that I can hear audio without plugging in external speakers or a headset, and so that I can turn the bright back up when the dying/dead AC adapter forces the backlight off.
https://gtrt7.com/blog/linux/ubuntu1710-on-letsnote
These two are earlier posts that essentially confirm the information in the later post:
https://qiita.com/PopularHero/items/5fda32b42f772061eb2c
https://www.linuxquestions.org/questions/slackware-14/sounds-issues-realtek-hda-14-2-a-4175596546/
The nitty-gritty is that Ubuntu has not had the appropriate settings information in the common install code. I should talk with the devs and get them to fix that. In the meantime, here are the settings:
** For the screen controls,
In
/usr/share/X11/xorg.conf.d/20-intel.confadd
Section "Device"
Identifier "card0"
Driver "intel"
Option "Backlight" "intel_backlight"
BusID "PCI:0:2:0"
EndSection
The file probably won't exist, so, if you do this, you will probably make it new, and this will probably be the only thing in it.
And then in
/etc/default/grubchange the line
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor acpi_osi="
(with no line breaks, regardless of how your browser shows the line).
Then run update-grub with the usual root privileges:
sudo update-grubWhen you reboot, the screen controls should take effect, and, if you have a bad AC adapter, you will be able to restore the screen brightness, maybe after logging in to a user.
(But, if you have the bad AC adapter, you really do have to fix the adapter or get a new one if you plan to continue using the PC. The wires inside the insulator will eventually break, like they have on this one, and then you will be running on fumes, like I am right now.)
Two points to take note of. One, this does not fix the behavior of the notebook when a failing AC adapter is plugged in. It will force the brightness on the internal display to zero, and keep firing the phantom button pushes until you unplug the thing.
Which means that you will need to unplug the adapter, and then wait until the filled button-push buffer empties and the on-screen indicator goes away. Then you can manually hit the brightness-up button so you can see what's on the internal screen again.
(Just between you and me, I consider this a poorly-thought-out feature in Panasonic's ergonomic design. Yeah, maybe it saves you from burning your notebook PC out, but must people will just think the thing has died. And, instead of taking it to someone who knows to replace the AC adapter, will just throw the poor thing away and add to the landfills and worker poisoning in poor 3rd-world communities.)
** For the audio controls
In the file
/usr/share/pulseaudio/alsa-mixer/paths/analog-output-speaker.conffind the following lines (headphone element):
[Element Headphone]
switch = off
volume = off
and change the volume line, and add two override lines, as follows:
[Element Headphone]
switch = off
volume = merge
override-map.1 = all
override-map.2 = all-left,all-right
Then find the following lines (speaker element):
[Element Speaker] required-any = any
switch = mute
volume = merge
override-map.1 = all
override-map.2 = all-left,all-right
and change only the volume line, as follows:
[Element Speaker] required-any = any
switch = mute
volume = off
override-map.1 = all
override-map.2 = all-left,all-right
Having done that, you and I can just restart the pulseaudio daemon by the usual methods, whether we do it by the cool way with service commands or the hard way by rebooting the computer.
And now we can hear the computer beep at us, or listen to youtube in monaural.
[JMR201911160031 Update:
Rather than make another post to confirm that the replacement adapter does fix the brightness problem, I'll add that information here. However, the adapter does not fix the brightness controls disconnect problem, so, until the patches make their way into the Debian and Ubuntu distributions, the information on this page remains relevant.
Let's figure out what kind of pics to take:
Booting up, AC adapter plugged in, pilot showing green, and no complaints about the adapter. (No internal screen because BIOS has the external screen selected at higher priority than the internal screen for the boot process.)
Made it all the way to the Ubuntu login screen without the phantom screen brightness control button activity, and the screen is appropriately bright.
Brightness control keyboard controls work, and no phantom presses pushing the brightness down, and you can see I was not eating my nightly yogghurt with chopsticks.
Logged in, nicely bright screen, and you can see I had a gforth session going in a virtual terminal window while playing with musescore, showing my typically distracted mental states when I should be sleeping.
One less notebook PC going to the landfills this month, I think.
]
[JMR202203201420 Update:
I added more audio stuff (Jack, etc.) and discovered that the audio settings got reverted.
]
Friday, August 9, 2019
Re: Move (and Other Information Leakage)
I find myself reconsidering the wisdom of having ignored a certain free-mail provider's advice some fifteen or more years ago, to move from the unadorned address I was using to an address with some meaningful decoration.
(Ergo, from joelrees@freemailprovider.com to something like joelreesinjapan@freemailprovider.com or joelrees57738@freemailprovider.com.)
Here's why:
After receiving this message in my e-mail box, I consider myself to have a few options:
This option, of course, is not a reasonable option for several reasons, not the least of which is that they might take my joke about testing their systems seriously.
(Sorry. This is not a novel. The risk involved in such work is great enough to overcome any motivation I might see for it, not to mention the not insignificant labor and sheer drudgery involved. Go find your entertainment elsewhere.)
So, here's a fifth option: remove most of the identifying information and blog about it, add the sender and recipient to my contacts in a certain SNS service, and put it in that service's feed.
That way, they have a chance to take action without my getting further involved. Also, everybody who reads this knows that I have publically declared my intent not to use the information I have, and the public nature of the declaration gives weight to the declaration itself.
But I then have to hope that no one else attempts to test their systems security before they take action.
I have chosen to take yet another option that can be extrapolated from the above.
And I am seriously considering changing the freemail address now. This sort of thing has happened before, although the details have not been quite as problematic.
I am also considering whether I can afford a proper vanity domain, such as joelreesinjapan.com.
In the original definition of the network technology that underlies the Internet, such domain names were not considered vanity. They were considered de rigueur -- required for every computer that would act as a user's interface to the network.
You can see some of the reasons from the above.
[JMR201908100903:
Or maybe it's not as obvious as I think.
Consider the odds of having to change your credit card number under the following accidental leak scenarios. You've sent it in an accidentally mis-addressed message to
Hmm. This is the post-snail-mail age. Maybe I should use a real example instead of an analogy.
Say you've accidentally sent the credit card number to
So they send me information I shouldn't get.
I don't want the information.
]
Somehow, during the "wild west days" of the extreme exploitation of the nascent Internet, such "minor requirements" got swept under the rug in favor of immediate profit.
(In more than one of my fantasy alternate realities, the countries burdened with the load of cleaning up the information systems, economic, social, and political impact of the exploitation of the early Internet combine to levy serious fines and other punishment on those who have profited in the extreme from the exploitation.
If only.)
Meanwhile, check the addresses that receive internal company mail before you use them.
It's safer that way.
(Ergo, from joelrees@freemailprovider.com to something like joelreesinjapan@freemailprovider.com or joelrees57738@freemailprovider.com.)
Here's why:
[Various indicative e-mail headers]
From: C**** D**** <C****.D****@somecompany.com>
To: "joelrees@freemailprovider.com" <joelrees@freemailprovider.com>, Joel Rees <Joel.Rees@somecompany.com>
Subject: 6th floor move ...
Date: [recent, elided]
[More indicative headers]
Hi Joel
Next week is our last week in our current positions. We need to start our =
clearing out and packing. Will you be back in the office before Friday, or=
shall I pack for you?
C****
---------------------------------------------------------------------------=
------------
The information in this email is intended only for the named recipient and =
may be privileged or confidential. If you are not the intended recipient pl=
ease notify us immediately and do not copy, distribute or take action based=
on this email. [More disclaimers, instructions, and assertions of relative
low priority, and questionable wisdom and utility.]
[Body repeated in HTML]
After receiving this message in my e-mail box, I consider myself to have a few options:
- (1) I could ignore this message based on the possibility that it might actually be phishbait. (But I have received other mail, and the probability is appearing low.)
- (2) I could be quiet and see what happens next. (But that really is not very nice, considering the other mail I have already received and tried to ignore.)
- (3) I could set the source address of the mail as a bounce address and otherwise remain silent. (Some might say this is my best option. If not for the other mail, I might consider it.)
- (4) I could send a laconic reply something as follows:
Hi, C****,
Thank you for the offer to help with the move.
Unfortunately, I doubt I shall be in the office any time soon.
Moreover, I suspect it would be not be easy or meaningful for you to attempt to pack for me.
By the way, thank you for your previous e-mail giving me certain information about the internal systems. I shall proceed to test the company's information systems security forthwith.
Joel Some Other Rees
This option, of course, is not a reasonable option for several reasons, not the least of which is that they might take my joke about testing their systems seriously.
(Sorry. This is not a novel. The risk involved in such work is great enough to overcome any motivation I might see for it, not to mention the not insignificant labor and sheer drudgery involved. Go find your entertainment elsewhere.)
So, here's a fifth option: remove most of the identifying information and blog about it, add the sender and recipient to my contacts in a certain SNS service, and put it in that service's feed.
That way, they have a chance to take action without my getting further involved. Also, everybody who reads this knows that I have publically declared my intent not to use the information I have, and the public nature of the declaration gives weight to the declaration itself.
But I then have to hope that no one else attempts to test their systems security before they take action.
I have chosen to take yet another option that can be extrapolated from the above.
And I am seriously considering changing the freemail address now. This sort of thing has happened before, although the details have not been quite as problematic.
I am also considering whether I can afford a proper vanity domain, such as joelreesinjapan.com.
In the original definition of the network technology that underlies the Internet, such domain names were not considered vanity. They were considered de rigueur -- required for every computer that would act as a user's interface to the network.
You can see some of the reasons from the above.
[JMR201908100903:
Or maybe it's not as obvious as I think.
Consider the odds of having to change your credit card number under the following accidental leak scenarios. You've sent it in an accidentally mis-addressed message to
- a random post office box number in New York City;
- a random post office box number in Wink, Texas;
- a random mail drop in some big company like Microsoft;
- a random mail drop in your own company.
Hmm. This is the post-snail-mail age. Maybe I should use a real example instead of an analogy.
Say you've accidentally sent the credit card number to
johnjones@hotmail.comvs. accidentally sending it to
johnjones@tanakahardware.comYou'll note that this company does have their own internal e-mail addresses. The problem is that they added a freemail address to their contacts lists without first testing it. And it wasn't the address they thought it was.
So they send me information I shouldn't get.
I don't want the information.
]
Somehow, during the "wild west days" of the extreme exploitation of the nascent Internet, such "minor requirements" got swept under the rug in favor of immediate profit.
(In more than one of my fantasy alternate realities, the countries burdened with the load of cleaning up the information systems, economic, social, and political impact of the exploitation of the early Internet combine to levy serious fines and other punishment on those who have profited in the extreme from the exploitation.
If only.)
Meanwhile, check the addresses that receive internal company mail before you use them.
It's safer that way.
Wednesday, May 1, 2019
Analyzing Mechanized Trust
So people have told you about the GIMP or Krita or one of hundreds of
"free" programs you can download on the web, and you think, maybe you
ought to try them, but you don't know if you can really trust them.
After all, installing free software was the proximate cause, as the tech
said, the last time you had to have your PC's OS cleaned of malware and
such.
So, can you tell which ones you can trust and which ones you can't?
How can you tell?
It comes down to trust.
You've heard a lot about HTTPS recently, how it is supposed to guard you from all the bad guys. But you're not sure how that works.
And Microsoft and Intel talk about their "Trusted Computing" or whatever that is, and yet they still have to update stuff about twice a month because of vulnerabilities and such. And the downloads take a long time. And you're not sure how that works either, how they guard your computer from fake updates and such.
Well, I tend to recommend free and open source software to people, too, so I should try to explain how some of this works.
First, HTTP vs. HTTPS:
HTTP is a little like somebody sets up a booth on side of the road and sells stuff. You have no proof they are who they claim to be or that the merchandise they sell is legitimate or that they have it legitimately, etc.
If they have a regular building, it helps a little, but only about impressions. Proper buildings can hide bad stuff happening inside.
But if they show their business license from the city, you can assume that either the license is fake or they have identified themselves to the city sufficiently to get the license. And if they have a technical certification, you can assume either the certificate is fake or they have passed some sort of course or test of certification. And so forth.
(Those certificates say something, and it is usually better than saying nothing, but we can't be sure just from the certificate exactly what it means. But we'll get back to that.)
HTTPS uses what are called asymmetric encryption methods to show their digital certificates to your browser, and your browser uses similar technology to check that the certificates have been issued by who they say they have been issued by. There are two keys involved, one for encrypting and one for decrypting. Keep one secret and make the other public, and people can tell that a person who has the secret key has encrypted a document or used it to calculate something called a checksum and to make a digital signature, perhaps with a digital fingerprint.
The checksum can be used to make sure that you get a complete, accurate, correct copy, and the fingerprint, signature, and checksum together can be used to make sure that the person who put it up for you to download is the person he or she claims to be.
HTTPS uses these techniques to make sure that the person or company who manages or admins the website you are visiting is the person or company claimed. Your browser has certificates from a bunch of certificate authorities (some more trustworthy than others), and the website usually refers to one of those certificate authorities, perhaps through a chain of references.
Secret keys can be discovered through carelessness, databases can be deliberated corrupted, etc., and there other ways of defeating the assurances, but they are difficult to pull off for very long without discovery. Rarely do they go undiscovered for more than a few weeks or a month.
The details are important, but not so important here. We need to talk about what the mechanisms of certification or assurance actually allow us to do, before we can turn this "mechanical trust" into a meaningful kind of trust. Let's look at an example:
Say, for instance, I recommend Cygwin for development tools, or the GIMP for working on images, or an operating system like Ubuntu or Devuan, or maybe the Gnupg tools for checking these digital signature and certificate thingies themselve.
Hmm. I recommend all of the above. Not because they can be used without money, by the way. If they help you make a profit, you do have a moral obligation to contribute to the projects, either with money or time, or preferably both. When you fail to contribute, that's one less person helping keep the proects running.
I recommend them for reasons of trust. They trust us enough to let us use what they have, and, more important, to let us look inside the "magic box", the source code for their software. They put their reputations on the line when they publish their stuff. That latter part gives us more reason to trust them.
But you need something like the Gnupg tools to check that the copy you get does not have malware inserted into it by some unrelated third party who doesn't care about your safety or their reputation, or maybe even wants to undermine your safety and/or destroy their reputation.
At this point, we need to distinguish between "random free download sites", on the one hand, and public repositories and their mirror sites, on the other.
A public repository is a site like osdn.jp (Open Source Developers' Network Japan) or sourceforge.net, both of which I have projets on, or github.com (very popular these days). They provide space for people like me who don't have the resources to maintain a server to host their own projects, and they provide various tools to help make sure the stuff we post there makes it through the download intact. They also provide things like project pages and means to provide checksums and signatures.
(Speaking of which, I need to start signing the stuff I put up in my projects. Right now they only have checksums.)
Random free download sites post blobs of dubious provenance. They generally fail to provide the tools to make sure that what they provide is safe, because part of their business model is to get you to download adware, which is one step short of malware.
Incidentally, sourceforge at one time was taken over by a bad management crew who started inserting dubious adware in many of the more prominent MSWindows downloads. The guys that started sourceforge were able to pool enough funds together to buy sourceforge back, and they have worked on cleaning out the adware infested downloads. But inactive projects are harder to clean out than active projects.
Also, any public repository gets part of the revenue that keeps them afloat from ads, and some advertisers deliberately try to look like legitimate downloads, so be careful what you click on. Patience is a virtue for many reasons.
Two more classes of sites I need to mention, mirror sites and stores.
Mirror sites are separate download sites provide by interested parties such as schools, public institutions, businesses, and such, to help support some of the larger projects by reducing the direct bandwidth burden on the project's primary servers or repositories. I've never seen ads there, and they basically mirror the public parts of each project they mirror, including checksums and signatures. They operate outside the question of trust by only hosting what the projects provide, unchanged. You have to check what you get from them, but that's not a problem because you have to check what you get from the project site itself, too.
Stores are kind of like a commercial re-visioning of repositories and mirrors oriented towards a particular device or family of devices (Google's playstore for Android, Apple's appstore for iPhones, etc., etc.). The company that provides the device makes the download procedure a bit more automatic and provides payment methods. (This is possible because they control the software on the device to a large extent.)
So, this has been an overview of the mechanisms of trust currently in use. What next? How do you convert mechanized trust into real trust?
Number one, patience. Diligent patience.
(Give them a little faith, but faith does not mean just instant belief.)
You do not want to download and install the latest, greatest, newest gadget the first day you hear about it. As I am hinting, patience is a major part of legitimate trust.
Looking for an allegory, the quickest ones that come to mind are human relations. Shaking hands is one thing. Going out to a movie is another. Accepting an invitation to a party is yet another. Friends that you trust are people you've known for a while, and you generally want to avoid committing yourself too far beyond your experience with a friend you haven't known very long.
So, say you think you might want to start using the GIMP. The first thing you should do is search for GIMP on your favorite search engine, and look at the stuff that comes up. You'll find a site that claims to be the official project site at gimp.org, and tutorials will point you to gimp.org and I'm pointing you to gimp.org. You have multiple witnesses that gimp.org is the official project site.
If you type
Look around. Scan the front page. Don't download it yet Check the news, even though there will be things there that you may not understand. Read the About page a bit. Check out the Docs and Tutorials. Take a peek at Participate and Donate. Look around for about a half an hour. Wait a day or two.
A day or two later, come back and look at the front page again. If you scan down to the bottom of the front page, you'll see a link to the mailing lists. Take a look at the archives of the user and developer lists and read some of the messages there to get a feeling for the community. If you happen to pick a message from a person with a lousy attitude or bad mouth, remember, every good project will attract a few of those. Dont judge the whole project by a few hotheads.
(Truth be told, one of my favorite OSses is run by what seems sometimes to be a whole crew of such hotheads. That's kind of the nature of what they do. It took me more than a year to understand what's going on over there, but that's another story. Trust comes in a variety of shapes and forms.)
While you're here this time, or maybe the next time you visit, check out the download page. You'll notice a list of hashes. These are those checksums I've mentioned. When you download it, you'll want to check the hash against what you downloaded, but I'll tell you about that in a different post.
Check it out. Don't download just yet.
Visit the project main page and read and listen to tutorials several times before you decide to download. Read the wikipedia pages on the GIMP. Get background. That way you have a feel for the community and have some basis for making those trust mechanisms meaningful.
Speaking of the trust mechanisms, I mentioned a tool called GnuPG, up there. Do a web search on that in between looking at the GIMP. The project main page is
You'll notice that they put a close focus on the "integrity check" processes. This is not your integrity, nor is it the integrity of the developers. This is one of those mechanical things. It's about whether something might have happened to the file between when the developers put it up for downloading and when it arrives in your computer. They use a lot of technical jargon, but you'll notice that they tell you not to use the program to check its own integrity.
You can understand why, can't you?
I'll try to walk you through the integrity check -- through checking the hashes or checksums and the signatures in another post. [JMR202111141814: Finally got this partially done. Look here: https://joels-programming-fun.blogspot.com/2021/11/getting-freelibre-software-gimp-and.html.] For now it's important to realize you have something of a chicken-and-egg problem here, and it's important to understand that problem.
As I mentioned above, HTTPS helps somewhat, here. It gives you a moderate level of confidence that the website you are reading has not been filtered by some man-in-the-middle who will send you malware when you try to download the software. There are some things you can do to reduce the possibility of the man-in-the-middle attack, and one of those things is precisely this patient approach I have been describing.
Another is the many witnesses princple.
One more place I suggest visiting while you are checking things out, if you are working on MSWindows. (If you are working on Linux, one of the BSDs, or Mac OS X, this is not as relevant.)
Microsoft can give you a number of tools, but their tools tend to push you into their universe. That is one of the reasons I don't trust them as much as I trust Apple or the Free-as-in-freedom and open source crowd. (Google has been losing my trust since before they began developing Android, but I'm still more willing to trust them than Microsoft. Microsoft has burned me too many times. Technical stuff you don't need to know about.)
There is a group, and a piece of software, that you can use as a shim to help get somewhat free of Microsoft.
Some of these tools are compilers and other programming language tools. Others are versions of software like the GIMP and GnuPG that can run on MSWindows computers.
Without some special settings, the versions of the GIMP and other graphical tools they can provide need an X-11 or other graphical shell to run within, but these tools allow you to build them yourself. There are details here that I'm going to gloss over, but the point is that Cygwin can help with a lot of things that you would otherwise have to do without when using MSWindows. And that is a topic for another blogpost, as well.
Maybe you think this is not for you, but it will give you more opportunities to check out the community. So, while you are checking out GnuPG and the GIMP, or whatever other software you are interested in, check out the Cygwin site as well.
Trust is not just about the mechanisms.
If it isn't about the people and what they do, it isn't about trust.
[I wrote this to restructure some of the ideas in this post on bootstrapping trust: https://joels-programming-fun.blogspot.com/2019/04/bootstrapping-your-freedom-cygwin-gpg.html.]
So, can you tell which ones you can trust and which ones you can't?
How can you tell?
It comes down to trust.
You've heard a lot about HTTPS recently, how it is supposed to guard you from all the bad guys. But you're not sure how that works.
And Microsoft and Intel talk about their "Trusted Computing" or whatever that is, and yet they still have to update stuff about twice a month because of vulnerabilities and such. And the downloads take a long time. And you're not sure how that works either, how they guard your computer from fake updates and such.
Well, I tend to recommend free and open source software to people, too, so I should try to explain how some of this works.
First, HTTP vs. HTTPS:
HTTP is a little like somebody sets up a booth on side of the road and sells stuff. You have no proof they are who they claim to be or that the merchandise they sell is legitimate or that they have it legitimately, etc.
If they have a regular building, it helps a little, but only about impressions. Proper buildings can hide bad stuff happening inside.
But if they show their business license from the city, you can assume that either the license is fake or they have identified themselves to the city sufficiently to get the license. And if they have a technical certification, you can assume either the certificate is fake or they have passed some sort of course or test of certification. And so forth.
(Those certificates say something, and it is usually better than saying nothing, but we can't be sure just from the certificate exactly what it means. But we'll get back to that.)
HTTPS uses what are called asymmetric encryption methods to show their digital certificates to your browser, and your browser uses similar technology to check that the certificates have been issued by who they say they have been issued by. There are two keys involved, one for encrypting and one for decrypting. Keep one secret and make the other public, and people can tell that a person who has the secret key has encrypted a document or used it to calculate something called a checksum and to make a digital signature, perhaps with a digital fingerprint.
The checksum can be used to make sure that you get a complete, accurate, correct copy, and the fingerprint, signature, and checksum together can be used to make sure that the person who put it up for you to download is the person he or she claims to be.
HTTPS uses these techniques to make sure that the person or company who manages or admins the website you are visiting is the person or company claimed. Your browser has certificates from a bunch of certificate authorities (some more trustworthy than others), and the website usually refers to one of those certificate authorities, perhaps through a chain of references.
Secret keys can be discovered through carelessness, databases can be deliberated corrupted, etc., and there other ways of defeating the assurances, but they are difficult to pull off for very long without discovery. Rarely do they go undiscovered for more than a few weeks or a month.
The details are important, but not so important here. We need to talk about what the mechanisms of certification or assurance actually allow us to do, before we can turn this "mechanical trust" into a meaningful kind of trust. Let's look at an example:
Say, for instance, I recommend Cygwin for development tools, or the GIMP for working on images, or an operating system like Ubuntu or Devuan, or maybe the Gnupg tools for checking these digital signature and certificate thingies themselve.
Hmm. I recommend all of the above. Not because they can be used without money, by the way. If they help you make a profit, you do have a moral obligation to contribute to the projects, either with money or time, or preferably both. When you fail to contribute, that's one less person helping keep the proects running.
I recommend them for reasons of trust. They trust us enough to let us use what they have, and, more important, to let us look inside the "magic box", the source code for their software. They put their reputations on the line when they publish their stuff. That latter part gives us more reason to trust them.
But you need something like the Gnupg tools to check that the copy you get does not have malware inserted into it by some unrelated third party who doesn't care about your safety or their reputation, or maybe even wants to undermine your safety and/or destroy their reputation.
At this point, we need to distinguish between "random free download sites", on the one hand, and public repositories and their mirror sites, on the other.
A public repository is a site like osdn.jp (Open Source Developers' Network Japan) or sourceforge.net, both of which I have projets on, or github.com (very popular these days). They provide space for people like me who don't have the resources to maintain a server to host their own projects, and they provide various tools to help make sure the stuff we post there makes it through the download intact. They also provide things like project pages and means to provide checksums and signatures.
(Speaking of which, I need to start signing the stuff I put up in my projects. Right now they only have checksums.)
Random free download sites post blobs of dubious provenance. They generally fail to provide the tools to make sure that what they provide is safe, because part of their business model is to get you to download adware, which is one step short of malware.
Incidentally, sourceforge at one time was taken over by a bad management crew who started inserting dubious adware in many of the more prominent MSWindows downloads. The guys that started sourceforge were able to pool enough funds together to buy sourceforge back, and they have worked on cleaning out the adware infested downloads. But inactive projects are harder to clean out than active projects.
Also, any public repository gets part of the revenue that keeps them afloat from ads, and some advertisers deliberately try to look like legitimate downloads, so be careful what you click on. Patience is a virtue for many reasons.
Two more classes of sites I need to mention, mirror sites and stores.
Mirror sites are separate download sites provide by interested parties such as schools, public institutions, businesses, and such, to help support some of the larger projects by reducing the direct bandwidth burden on the project's primary servers or repositories. I've never seen ads there, and they basically mirror the public parts of each project they mirror, including checksums and signatures. They operate outside the question of trust by only hosting what the projects provide, unchanged. You have to check what you get from them, but that's not a problem because you have to check what you get from the project site itself, too.
Stores are kind of like a commercial re-visioning of repositories and mirrors oriented towards a particular device or family of devices (Google's playstore for Android, Apple's appstore for iPhones, etc., etc.). The company that provides the device makes the download procedure a bit more automatic and provides payment methods. (This is possible because they control the software on the device to a large extent.)
So, this has been an overview of the mechanisms of trust currently in use. What next? How do you convert mechanized trust into real trust?
Number one, patience. Diligent patience.
(Give them a little faith, but faith does not mean just instant belief.)
You do not want to download and install the latest, greatest, newest gadget the first day you hear about it. As I am hinting, patience is a major part of legitimate trust.
Looking for an allegory, the quickest ones that come to mind are human relations. Shaking hands is one thing. Going out to a movie is another. Accepting an invitation to a party is yet another. Friends that you trust are people you've known for a while, and you generally want to avoid committing yourself too far beyond your experience with a friend you haven't known very long.
So, say you think you might want to start using the GIMP. The first thing you should do is search for GIMP on your favorite search engine, and look at the stuff that comes up. You'll find a site that claims to be the official project site at gimp.org, and tutorials will point you to gimp.org and I'm pointing you to gimp.org. You have multiple witnesses that gimp.org is the official project site.
If you type
https://www.gimp.orgdirectly into your browser's URL field, you can eliminate some games sneaky types play with the displayed URLs. You really should keep that URL field out where you can type directly into it, separate from the search field. It's only a little inconvenient, and it keeps people from playing games with the displayed URL. (Browsers have done some things about protecting displayed URLs, but there are still ways to play those games.) That means, unless there is DNS poisoning, you'll go to gimp.org's servers, which is where you want to go.
Look around. Scan the front page. Don't download it yet Check the news, even though there will be things there that you may not understand. Read the About page a bit. Check out the Docs and Tutorials. Take a peek at Participate and Donate. Look around for about a half an hour. Wait a day or two.
A day or two later, come back and look at the front page again. If you scan down to the bottom of the front page, you'll see a link to the mailing lists. Take a look at the archives of the user and developer lists and read some of the messages there to get a feeling for the community. If you happen to pick a message from a person with a lousy attitude or bad mouth, remember, every good project will attract a few of those. Dont judge the whole project by a few hotheads.
(Truth be told, one of my favorite OSses is run by what seems sometimes to be a whole crew of such hotheads. That's kind of the nature of what they do. It took me more than a year to understand what's going on over there, but that's another story. Trust comes in a variety of shapes and forms.)
While you're here this time, or maybe the next time you visit, check out the download page. You'll notice a list of hashes. These are those checksums I've mentioned. When you download it, you'll want to check the hash against what you downloaded, but I'll tell you about that in a different post.
Check it out. Don't download just yet.
Visit the project main page and read and listen to tutorials several times before you decide to download. Read the wikipedia pages on the GIMP. Get background. That way you have a feel for the community and have some basis for making those trust mechanisms meaningful.
Speaking of the trust mechanisms, I mentioned a tool called GnuPG, up there. Do a web search on that in between looking at the GIMP. The project main page is
https://www.gnupg.orgbut, again, look for what people say about it, look around their website, read the archives. This group may not feel as comfortable as the GIMP group for several reasons -- They use a specialized jargon, and they have to have a rather strict attitude about what they do.
You'll notice that they put a close focus on the "integrity check" processes. This is not your integrity, nor is it the integrity of the developers. This is one of those mechanical things. It's about whether something might have happened to the file between when the developers put it up for downloading and when it arrives in your computer. They use a lot of technical jargon, but you'll notice that they tell you not to use the program to check its own integrity.
You can understand why, can't you?
You: Do you have integrity?
The Software: Yeah! Sure!
You: Can I trust you?
The Software: Of COURSE!
I'll try to walk you through the integrity check -- through checking the hashes or checksums and the signatures in another post. [JMR202111141814: Finally got this partially done. Look here: https://joels-programming-fun.blogspot.com/2021/11/getting-freelibre-software-gimp-and.html.] For now it's important to realize you have something of a chicken-and-egg problem here, and it's important to understand that problem.
As I mentioned above, HTTPS helps somewhat, here. It gives you a moderate level of confidence that the website you are reading has not been filtered by some man-in-the-middle who will send you malware when you try to download the software. There are some things you can do to reduce the possibility of the man-in-the-middle attack, and one of those things is precisely this patient approach I have been describing.
Another is the many witnesses princple.
One more place I suggest visiting while you are checking things out, if you are working on MSWindows. (If you are working on Linux, one of the BSDs, or Mac OS X, this is not as relevant.)
Microsoft can give you a number of tools, but their tools tend to push you into their universe. That is one of the reasons I don't trust them as much as I trust Apple or the Free-as-in-freedom and open source crowd. (Google has been losing my trust since before they began developing Android, but I'm still more willing to trust them than Microsoft. Microsoft has burned me too many times. Technical stuff you don't need to know about.)
There is a group, and a piece of software, that you can use as a shim to help get somewhat free of Microsoft.
https://www.cygwin.comCygwin is a vendor/provider of developer tools from the free-as-in-freedom, open source community which bridge the gap between the Microsoft community and the greater outside world.
Some of these tools are compilers and other programming language tools. Others are versions of software like the GIMP and GnuPG that can run on MSWindows computers.
Without some special settings, the versions of the GIMP and other graphical tools they can provide need an X-11 or other graphical shell to run within, but these tools allow you to build them yourself. There are details here that I'm going to gloss over, but the point is that Cygwin can help with a lot of things that you would otherwise have to do without when using MSWindows. And that is a topic for another blogpost, as well.
Maybe you think this is not for you, but it will give you more opportunities to check out the community. So, while you are checking out GnuPG and the GIMP, or whatever other software you are interested in, check out the Cygwin site as well.
Trust is not just about the mechanisms.
If it isn't about the people and what they do, it isn't about trust.
[I wrote this to restructure some of the ideas in this post on bootstrapping trust: https://joels-programming-fun.blogspot.com/2019/04/bootstrapping-your-freedom-cygwin-gpg.html.]
Thursday, December 20, 2018
68HC11 Is Not a Modified 6809 (and What if?)
(I have a more high-level treatment of this topic, comparing the 6801, 68HC11, and 6809 with the 6800, here: https://defining-computers.blogspot.com/2021/08/differences-between-6800-and-6801-with-notes-68hc11-6809.html.)
In the Color Computer Facebook group, somebody started a "What if?" thread.
What if Radio Shack had recognized that they had in the TRS-80 Color Computer the makings of an IBM PC killer way early in the game? etc.
(Yeah, we know hypothesis contrary to fact is a no-win game. We don't care. Call going there our happy place.)
So, I was looking up the history of the 6809 to refresh my memory so I could talk intelligently about what who shoulda done where when, and I noticed on the wikipedia page for the 6809 that somebody was talking about how the 68HC11 is a modified 6809.
Say what?!?!?!
And the wikipedia page for the 68HC11 had the same assertion.
Double-huh!?
Huh-uh. No. Where did they get that bit of history so tangled up?
(But that might explain why someone in the group would be talking about the 68HC11 as if it were a modified 6809.
For what it's worth, NXP, the successor in interest to Motorola relative to the 6800 and it's descendants, implies in their on-line materials that the 68000 is a descendant of the 6800 through the 6809, which is also just plain wrong. The 68000 and 6809 were essentially developed in parallel, by separate departments. They apparently communicated with each other, but pursued similar but different paths.)
I know, you don't care. I should just log in and correct it, if I care so much.
Well, maybe I will sometime. But stick with me. Maybe it'll be more amusing than youtube videos of geeks spraying package thieves with glitter. Let's take a look.
First, lets look at the register model of the 6800, the 8-bit grandaddy of Motorola's homespun lines of CPUs:
| accumulator A:8 | |
| accumulator B:8 | |
| Index X:16 | |
| Stack Pointer SP:16 | |
| Program Counter PC:16 | |
| Condition Codes CC:8 | |
Accumulators are kind of like displays on calculators. This calculator has two small displays, so to speak. Not two calculators, two displays. They can accumulate separate sums, but the CPU has to say which it's working on:
LDAA #1 ; Put the number 1 in accumulator A.
LDAB #110 ; Put the number 110 in accumulator B.
* Now you have the year 366 in the combined A:B,
* but you have to work on the number a byte at a time.
PSHB ; Saving the number on the stack
PSHA ; has to be done in two pieces.
*** By the way, all code on this page is untested. ***
*** If you find errors, let me know. ***
LDX #YEARSTABLEIf you want to do math on the pointer, you have to store it somewhere and work on it 8 bits at a time.
STX <TEMP ; Make sure TEMP is in the direct page.A stack is useful for tracking where you've been so you can know where to go next. It's also good for temporary storage of things. With the 6800, to do any math on the item on the top of stack, or to point at things that are buried under the top of stack requires copying the stack pointer to the index register.
LDAA <TEMP ; Grab the high byte,
LDAB <TEMP+1 ; then the low byte.
ADDB #160 ; (2000*2) modulo 256
ADCA #15 ; (2000*2)/256
* This is a big table in a small computer.)
STAB <TEMPX+1 ; Save the location for later
STAA <TEMPX
TSX ; Now we can address the stack.It works, but it feels a little awkward and takes lots of instructions.
LDAA 0,X ; Get the number 366
LDAB 1,X
LDX <TEMPX ; Point to the entry for the year 2000.
STAA 0,X ; Put 366 in the table.
STAB 1,X
The Program Counter (Instruction Pointer in other companies' parlance) is necessary to know where you are in the problem solution now. Pointing at things relative to the PC on the 6800 requires executing a moot call to the next instruction, transferring the stack pointer to the index register to get the pointer and do math on it, and loading the index register to load the index register indexed by itself. This is useful if you want to have code containing tables of constants buried in the code itself. Maybe it will help to walk through some code:
* Yes, there are times you might actually do something like this.Heh. You really wanted to know how to do that, didn't you?
DAYSINMONTHS:
FCB 31,28,31,30,31,30,31,31,30,31,30,31
* Leap year check will be done elsewhere.
* Month number on stack is 16 bit integer, but less than 256.
GETDAYSINMONTH:
BSR DUMMY
DUMMY:
PULA ; Get the address of DUMMY to work on.
PULB
SUBB DUMMY-DAYSINMONTHS ; Less than 256, okay?
SBCA #0 ; Address of DAYSINMONTHS, relocatable.
STAA <TEMPX2
STAB <TEMPX2+1
TSX
LDB 3,X ; Skip return address, ignore high byte of month number.
* It would be nice if we could use B as an offset to X, wouldn't it?
* LDX <TEMPX2
* LDB B,X
* But we can't on the 6800.
ADDB <TEMPX2+1
BCC SKIPIT
INC <TEMPX2 ; Had a carry.
SKIPIT:
STAB <TEMPX2+1
LDX TEMPX2
LDB 0,X ; Finally got the days in the month!
TSX
STB 3,X ; Let's use the stack to return the count.
CLR 2,X
RTS ; We remembered to keep the return address safe, right?
Condition codes, by the way, are where you keep track of things like whether the last math carried or overflowed or not, and of certain modes like whether the processor should let anyone interrupt it or not. The carry bit (C) in the condition code register is what allows BCC (Branch Carry Clear) to fall through and add 1 to the high byte in the above code.
One more useful example is moving a block of code:
* Parameters on stack, hard limit of 2048 bytes.
* pushed in order of source, destination, count:
* 0,S ; return PC
* 2,S ; count
* 4,S ; destination
* 6,S ; source
* Slightly paranoid code.
BLOCKMOVE:
TSX
LDAB 3,X
LDAA 2,X
STAB <COUNT+1 ; Page zero globals, erk.
STAA <COUNT
BMI BLOCKMOVEEND ; Bit 15 set is way too big.
SUBB #1 ; Yes, this is necessary.
SBCA #8 ; 8*256+1 == 2049
BCC BLOCKMOVEEND ; Don't even try if too much.
LDX 4,X
STX <DESTINATION
TSX
LDX 6,X
STX <SOURCE
* We know it's a good, non-zero count.
LDAB <COUNT+1 ; Low byte, easier to check the count.
BRA BLOCKMOVETEST ; Test on entry does what you want.
BLOCKMOVELOOP:
LDX <SOURCE
LDAA 0,X
INX
STX <SOURCE
LDX <DESTINATION
STAA 0,X
INX
STX <DESTINATION
BLOCKMOVETEST:
SUBB #1 ; Reflect it in carry
BCC BLOCKMOVELOOP ; Gets much harder if not test on entry.
DEC <COUNT
BMI BLOCKMOVEDONE ; For count < 256 at start.
BNE BLOCKMOVELOOP
BLOCKMOVEDONE:
TSX
LDAA <DESTINATION
LDAB <DESTINATION+1
STAA 4,X
STAB 5,X
LDAA <SOURCE
LDAB <SOURCE+1
STAA 6,X
STAB 7,X
BLOCKMOVEEND:
RTS
* Leave the parameters for the calling routine.
That looks inefficient, but in the mid 1970s it wasn't that bad. But it definitely shows one of the warts of the 6800, and one of the motivations for adding index registers.
There are ways to do it quicker, especially if you know how much you are moving when you are writing the code. These tricks involve buffer alignment and size alignment and unrolling the loop, etc. That's not what we need to look at here.
(The 6800 was used in a few PCs and game machines of the late 1970s and early 1980s, for example, the APF Imagination Machine and the Tektronix 4050, and some more obscure office machines.)
(The 6800 was used in a few PCs and game machines of the late 1970s and early 1980s, for example, the APF Imagination Machine and the Tektronix 4050, and some more obscure office machines.)
Now this M6800 microprocessor is useful, but Motorola's customers wanted to have an entire controller in a single part, not a bunch of parts on a PC board. And they wanted it to be a little easier to write programs for. So Motorola put together a project (around 1977) to improve the 6800, keeping it simple so that adding transistors for ROM, RAM, I/O, and timers and such would not blow budget out of the water. They called the result the 6801.
The 6801 was actually in limited production in 1977, but they were pretty quiet about it.
(Why? Maybe they worried that some customers would be upset they had bought the less capable 6800. It's a valid worry. Customers can be unreasonable about wanting the perfect thing yesterday at tomorrow's cheap thing's price.)
Motorola talked to some select customers besides GM in 1978, and started telling general customers about it in 1979. In other words, development on the 6801 started before development on the 6809 and 68000.
accumulator D (A:B)
accumulator A
accumulator B
| |
| Index X | |
| Stack Pointer SP | |
| Program Counter PC | |
| Condition Codes CC | |
What's the difference from the 6800? Well, to see, we'll reproduce the code above using some of the additional instructions. First, we'll load the days in a leap year in the A and B accumulators:
LDD #366 ; The 6801 does this in one instruction!That's a lot simpler, less likely to forget something, even if it isn't really fewer total instructions. Runs a bit faster, too. Really simple additions made significant difference for the 6801. Let's look at the DAYSINMONTH thing:
* Much easier. Now let's point to the right place for it in YEARSTABLE:
LDX #YEARSTABLE ; We could actually put this directly in D.
* And we could have worked more difficult pointer math above,
* to shorten the code. We could also have made it not relocatable.
* So, keeping the two sets of code parallel, we will use X here, too.
PSHB ; Save the day count on the stack.
PSHA
PSHX ; This is a new instruction in the 6801!
TSX ; We can avoid putting TEMP variables in the direct page!
LDD 0,X
ADDD #(2000*2) ; All 16 bits at once!
STD 0,X
* Now we can save the days in the leap year in the table:
LDD 2,X ; There's the days!
PULX ; Of course we can pop what we push!
STD 0,X ; Done! All stored away in YEARSTABLE.
INS ; But we have to drop the count to balance the stack.
INS
DAYSINMONTHS:13 instructions versus 19. Nice, huh?
FCB 31,28,31,30,31,30,31,31,30,31,30,31
* Month number on stack as 16 bit integer.
* Leap year check done elsewhere.
GETDAYSINMONTH:
BSR DUMMY
DUMMY:
TSX
LDD 0,X ; Get the address of DUMMY to work on.
SUBD DUMMY-DAYSINMONTHS
STD 0,X ; Address of DAYSINMONTHS, relocatable.
LDB 5,X ; Ignore high byte of month number.
PULX
* It would be nice if we could use B as an offset to X, wouldn't it?
ABX ; But now, on the 6801, we can add B to X!
LDB 0,X ; Get the days in the month!
TSX
CLRA
STD 2,X ; Let's use the stack to return the count.
RTS
How much help for the block move are the additions?
* Parameters on stack, hard limit of 2048 bytes.
* pushed in order of source, destination, count:
* 0,S ; return PC
* 2,S ; count
* 4,S ; destination
* 6,S ; source
* Slightly paranoid code.
BLOCKMOVE:
TSX
LDD 2,X
STD <COUNT
BMI BLOCKMOVEEND ; Bit 15 set is way too big.
SUBD #2049
BCC BLOCKMOVEEND ; Don't even try if too much.
LDD 4,X
STD <DESTINATION
LDD 6,X
STD <SOURCE
* We know it's a good, non-zero count, so we can test at end.
BLOCKMOVELOOP:
LDX <SOURCE
LDAA 0,X
INX
STX <SOURCE
LDX <DESTINATION
STAA 0,X
INX
STX <DESTINATION
LDD <COUNT ; Faster than doing it by halves.
SUBD #1 ; Reflect it in carry
STD <COUNT ; Cleaner than by halves, too.
BHI BLOCKMOVELOOP ; Different end condition from 6800 code.
BLOCKMOVEDONE:
TSX
LDD <DESTINATION
STD 4,X
LDD <SOURCE
STD 6,X
BLOCKMOVEEND:
RTS
* Leave the parameters for the calling routine.
The code is much clearer, and a little faster and shorter.
Just as an exercise, to help convince you these are real improvements, you might want to unroll the loop once to see what happens. Use an extra variable in the zero page to remember if the count is odd, and use the ASR instruction to divide the count by two:
CLR <TAILCOUNT
LDD 2,X
ASRA
RORB
BCC BLOCKMOVEHALVE
INC <TAILCOUNT
BLOCKMOVEHALVE:
STD <COUNT
should get you started. It takes a bit of extra code, but it gets close to double the speed for counts greater than 8 bytes if you do it right.
(The 6801 was used in a few PCs and game machines of the late 1970s and early 1980s. For example, Radio Shack's TRS-80 MC-10 had the 6803, which was a ROM-less 6801.)
Motorola's management realized at the time that competing in semiconductors meant really competing, so they decided to leapfrog the competition around 1977 or '78, and invested a lot of engineering time to bring out the 68000 in 1979 or '80:
| Data register/Accumulator D0:32 | |
| Data register/Accumulator D1:32 | |
| Data register/Accumulator D2:32 | |
| Data register/Accumulator D3:32 | |
| Data register/Accumulator D4:32 | |
| Data register/Accumulator D5:32 | |
| Data register/Accumulator D6:32 | |
| Data register/Accumulator D7:32 | |
| Index register/Stack pointer A0:32 | |
| Index register/Stack pointer A1:32 | |
| Index register/Stack pointer A2:32 | |
| Index register/Stack pointer A3:32 | |
| Index register/Stack pointer A4:32 | |
| Index register/Stack pointer A5:32 | |
| Index register/Stack pointer A6:32 | |
| Index register/User stack pointer A7:32 | |
| Index register/System stack pointer A7:32 | |
| Program Counter (Indexable) PC:32 | |
| Status/Condition Codes CC:16 | |
8 bits and 16 bit registers were too short, 32 bits is the answer! (True, but not without some downside.)
Two accumulators were good, eight were better! (True, but not without some downside.)
One index was not enough, and not being able to index off the stack pointer is a pain, eight index/stack pointer registers is the answer! (Again true, but not without some downside. We won't look at the downsides here, however. Suffice it say those were valid engineering trade-offs.)
As you can see, stack pointers are directly indexable. So is the PC.
This is oversimplifying but you can see a bit of pattern here. Let's see what effect that has on the code:
MOVE.W #366,D0 ; No problem!That's what all the extra transistors in the 68000 do for you. More leeway to work on more difficult problems. So let's look at the DAYSINMONTH thing on the 68000:
* Now let's point to the right place for it in YEARSTABLE:
MOVE.L #YEARSTABLE,A0 ; Again, could have put it in D1.
* Actually that should be LEA YEARSTABLE,A0
* but I don't want to distract myself or you.
* Still keeping the two sets of code parallel:
MOVE.W D0,2000(A0) ; Done. I'm not kidding you.
DAYSINMONTHS:
DC.B 31,28,31,30,31,30,31,31,30,31,30,31
* Month number on stack as 16 bit integer.
* Leap year check done elsewhere.
GETDAYSINMONTH:
* The assembler can get the address difference at assemble time: LEA DAYSINMONTHS(PC),A0 ; Relocatable. LEA will use the difference.
* Single stack to keep the code parallel.
MOVE.L 4(A7),D0 ; Month number in 32 bit integer on stack.
* CLR.L 4(A7)
* MOVE.B (D0,A0),7(A7) ; Done. I kid you not.
* Except it's better not to abuse the external memory bus so much:
CLR.L D1
MOVE.B (D0,A0),D1 ; Got the count.
MOVE.L D1,4(A7) ; Done. For real.
RTS
Heh. This is why we like the 68K.
Interested in how nicely it works for block moves?
Interested in how nicely it works for block moves?
* Parameters on stack, hard limit of half a megabyte.
* pushed in order of source, destination, count:
* 0,A7 ; return PC
* 4,A7 ; count
* 8,A7 ; destination
* 12,A7 ; source
* We could call A7 SP, but you get the point.
* Slightly paranoid code.
BLOCKMOVE:
MOVE.L 4(A7),D0
BMI BLOCKMOVEEND ; Bit 31 set is way, way too big.
SUB.L #524289,D0 ; Subtract 524289 *from* D0.
BCC BLOCKMOVEEND ; Don't even try if too much.
* We know it's a good, non-zero count.
MOVE.W 4(A7),D1 ; One of the 68000's warts.
MOVE.W 6(A7),D0 ; Just the lower 2 bytes.
MOVEA.L 8(A7),A1
MOVEA.L 12(A7),A0
BRA BLOCKMOVETEST ; Designed for test on entry.
BLOCKMOVELOOP:
MOVE.B (A0)+,(A1)+
BLOCKMOVETEST:
DBF D0,BLOCKMOVELOOP ; That wart, only the lower half counts.
DBF D1,BLOCKMOVELOOP ; Did I get this right this time?
MOVEA.L A1,8(A7)
MOVEA.L A0,12(A7)
BLOCKMOVEEND:
RTS
* Leave the parameters for the calling routine.
Loop unrolling to four bytes at a time is pretty straightforward, but if you're going that far you'll also want to check memory alignment. It can get a little messy before it becomes obvious. And then the 68000 has the MOVEM instruction that would let you push blocks of 64 bytes or more in one time through, using registers. You really have to think that one through if you try it.
Many PCs and game machines had 68000s in them -- the Atari ST, the Amiga, the original Macintosh and the Lisa which preceded the Macintosh, the Sega Genesis/Mega Drive and so on. Lots of arcade games. There were also many workstations with versions of the 68000, including early Suns, the Apollo/Domain, the NeXT, early HP 9000s, the Tandy Model 16, and a lot of workstations from less well-known companies. IBM even had a scientific computer with the 68000 (System 9000) at the time it introduced the infamous IBM PC.
Arguments that the 68000 was somehow inferior to the 8086 in any way but being initially more expensive and being produced by a company that had no intention of trying to form a monopoly with it are pure revisionist history.
Many PCs and game machines had 68000s in them -- the Atari ST, the Amiga, the original Macintosh and the Lisa which preceded the Macintosh, the Sega Genesis/Mega Drive and so on. Lots of arcade games. There were also many workstations with versions of the 68000, including early Suns, the Apollo/Domain, the NeXT, early HP 9000s, the Tandy Model 16, and a lot of workstations from less well-known companies. IBM even had a scientific computer with the 68000 (System 9000) at the time it introduced the infamous IBM PC.
Arguments that the 68000 was somehow inferior to the 8086 in any way but being initially more expensive and being produced by a company that had no intention of trying to form a monopoly with it are pure revisionist history.
Some of the engineers thought the 6800 could use some polishing up beyond the 6801, and management allowed them to put together the 6809 at pretty much the same time the company was putting together the 68000. The 6809 was actually brought into production before the 68000, but neither is an ancestor of the other.
The 6809 looks like this:
accumulator D:16 (A|B)
accumulator A:8
accumulator B:8
| |
| Index X:16 | |
| Index Y:16 | |
| Indexable Return Stack Pointer S:16 | |
| Indexable User Stack Pointer U:16 | |
| Indexable Program Counter PC:16 | |
| Direct Page Base DP:8 | |
| Condition Codes CC:8 | |
The design team here was a bit less ambitious than the design team for the 68000. The 6809 only got half as many index/stack pointers. And the two 8-bit accumulators can be put together for 16 bit addition and subtraction like the 6801 does, but there's only 16 bits of accumulator. Some people think it's register poor.
Anyway, you can definitely see the influence of the 6800 in the 6809. The 6809 is truly descended from the 6800. (We are pretty sure the 68000 and the 6809 influenced each other, but, in parallel, going somewhat different directions.)
Influence from the 6801? Maybe, but the op-codes in the 6809 have been seriously restructured from the 6800, especially the indexing. Indexing is much more richly supported on the 6809.
[JMR202009211038:
My memory is that the 6801 project actually began after the 6809, and the influence was in the reverse, with the D double accumulator borrowed back to the 6801 and the ABX instruction implemented to help overcome lack of the LEA load effective address. But I can't find good references for that now.
]
Incidentally, many small engineering projects that can be designed with the 6809 actually take less code and run faster on the 6809 at a 1 MHz memory cycle than on the 68000 at 1 MHz memory cycle. The downside of that is the limit of expansion of functionality. There are many problems that just can't be solved with only 16 bits of address. (Thousands of characters in Unicode? Millions of colors on a screen way too large to directly address in 16 bits?) That's why you need the larger CPU for many things.
And the 68000 was produced at much higher frequencies, as well. Should give some examples of these, but not today.
Let's look at 6809 code examples per the above, instead:
LDD #366 ; Days in leap years.
* Now let's point to the right place for it in YEARSTABLE:
LDX #YEARSTABLE ; Here's why we didn't put it in D.
* Or LEAX YEARSTABLE,PCR -- but we won't mention that here.
* Keeping the several sets of code parallel, still,
STD (2000*2),X ; Done. No, I'm still not kidding you.
Less than half the transistors of the 68000, and it still nails it. Let's look at the DAYSINMONTH thing on the 6809, also:
DAYSINMONTHS:
FCB 31,28,31,30,31,30,31,31,30,31,30,31
* Month number on stack as 16 bit integer.
* Leap year check done elsewhere.
GETDAYSINMONTH:
LEAX DAYSINMONTHS,PCR ; Relocatable. The assembler knows how.
* Single stack to keep the code parallel.
* LDB 3,SP ; Month number in 16 bit integer, ignore high byte.
* CLR 2,SP ; Either way, really.
* LDB B,X ; Ignore high byte of offset.
* STB 3,SP ; Or, go ahead and use the (zero) high byte:
LDD 2,SP ; Month number in 16 bit integer.
LDB D,X ; Got the count in B.
CLRA
STD 2,X ; For real.
RTS
* Parameters on stack, hard limit of 2048 bytes.Are you sold? Do you want to try unrolling the loop to see how hard it is? Percentagewise, it won't be as much of an increase in speed as the 6801 sees in unrolling, but it would probably still be worth the effort.
* pushed in order of source, destination, count:
* 0,S ; return PC
* 2,S ; count
* 4,S ; destination
* 6,S ; source
* Slightly paranoid code.
BLOCKMOVE:
LDD 2,S
BMI BLOCKMOVEEND ; Bit 15 set is way too big.
SUBD #2049
BCC BLOCKMOVEEND ; Don't even try if too much.
* We know it's a good, non-zero count, so we can test at end.
LDX 6,S
LDY 4,S
BLOCKMOVELOOP:
LDA ,X+
STA ,Y+
LDD 2,S ; Faster than doing it by halves.
SUBD #1 ; Reflect it in carry
STD 2,S ; Cleaner than by halves, too.
BCC BLOCKMOVELOOP
BLOCKMOVEDONE:
STY 4,S
STX 6,S
BLOCKMOVEEND:
RTS
* Leave the parameters for the calling routine.
One of the downsides of both the 6809 and 68000's improved functionality is that it takes a lot of those small transistors to make them work. That makes less room for adding IO, ROM, RAM, etc. for one-chip stuff.
But the 6809 takes much fewer than the 68000, and only needs 8 bit wide memory where the 68000 needs sixteen bit wide memory.
Perhaps the most well-known PC/game machine to use the 6809 was the TRS-80 Color Computer, an odd-ball machine that existed, perhaps, because the 6809 was just too powerful to suppress. There were others, however, some of which you can find on Wikipedia's category page for 6809 home computers (Dragon in the UK, models from Thomson in France, Fujitsu's FM-8 in Japan, ) and others still in the Wikipedia main 6809 entry. There were also multi-user business machines produced by obscure companies such SWTP, many of which had started with the 6800. And lots of arcade machines and music synthesizers, also still mentioned on Wikipedia. And it was heavily used in Aerospace. I need to gather more links for these, sometimes, but the Wikipedia page still has a lot. And I should mention operating systems, such as the real-time OS, OS-9 from Microware. But this page was not intended as such a list. The point is that the 6809 was and is a hidden workhorse.
The 6809 really could have been used as a core by 1983, just as the 6801 was in 1979. Just as a somewhat advanced version of the 68000 was in the late 1980s. Just as somewhat advanced versions of the 6801 (68HC12 and 68HC16) also were in the 1990s.
I understand that there may have been, among the salescrew and management, those who were scared of having Motorola competing with itself -- scared of cannibalizing 68000 sales with the very competitive 6809, if they told everyone how good the 6809 was. If it was so, it was very shortsighted. The 6809 could easily have gone head-to-head with the 8088 on a lot of smaller designs, and the 68000 would have been an almost natural upgrade path from the 6809, just as the 6809 was a natural upgrade path from the 6801.
Just as a bit of text processing can convert 6800 code into executable 6809 code, a bit of text processing can convert a 6800 code or 6809 code into 68000 code. It may require a little engineering time for cleanup, but you'll want to take the time to optimize the code anyway.
So the 6801 improves the 6800 model by adding instructions that treat the accumulator pair as a single double (16-bit) accumulator, with A holding the high byte and B holding the low byte. And it adds an 8 x 8 multiply with 16 bit result. This much is about all there is in common with the 6809, other than the 6800 origins.
The 6801 also includes a few new instructions that allow adding an offset to the index register, comparing the index register, pushing and popping (PULling) the index register. These are significant improvements, improving efficiency in core areas that were bottlenecks in the 6800 for high-level functionality. Better than the 6800, not as good as the 6809, different. And done differently.
The instructions of the 6809 are not a proper superset of those of the 6801. Conversion is required.
The single indexing mode of the 6801 is the exact same as the 6800's. And the single stack pointer is not directly indexable. Nor is the PC. Comparing that with the 6809, you see all sorts of indexing available in the 6809 to shorten and clarify code.
There were some other important improvements, such as additional interrupt vectors for built-in hardware and such. But the 6801 is very much a separate path of evolution from the 6809. The additional interrupts in the 6809 are more general. I guess I'm repeating myself.
More general. That's a good way to compare the 6809 and the 6801.
Game machines with the 6809 in them are too numerous
Now we come to the 6811, which, functionally speaking, harks back to and extends the 6801 rather than the 6809. The year of introduction was 1985.
accumulator D:16 (A:B)
accumulator A:8
accumulator B:8
| |
| Index X:16 | |
| Index Y:16 | |
| Stack Pointer SP:16 | |
| Program Counter PC:16 | |
| Condition Codes CC:8 | |
The 68HC11 improves on the 6801 by adding another index register, Y. This significantly eases another bottleneck when handling two pointers at once, but the indexing mode is the same as the 6800's. It is not as general as the 6809's indexing modes (plural). The additional index register is supported by adding instructions, not by modifying the addressing modes.
Even after all my preaching, you might still think, oh, that's like the 6809, only missing the U. Uhm, and the DP, whatever that is.
Yes. It's missing U. Still only one stack pointer. SP is still not indexable. Neither is PC.
And no direct page register, which I haven't really demonstrated uses for here. (It's a bit of a complex topic, which I have partially addressed in other rants, erm, blog posts, in this blog.)
It is not a stripped down 6809. If it were, it would have much more complex addressing modes.
We can be sure the manufacturing process was influenced by things they learned developing the 6809, but that can also be said of the 68000, and we are not going to say it was somehow derived from the 68000. Not if we want to speak meaningfully.
It's a beefed-up 6801, not at all by way of the 6809. You still don't believe me?
Let's look again at that code we've been playing with, converted for the 68HC11:
LDD #366 ; The leap year.
LDY #YEARSTABLE ; How much will Y actually help?
PSHY ; Still have to have it in some temporary.
PSHB ; Save the day count on the stack.
PSHA
TSX
LDD 2,X ; Extra index register let us reorder the stack.
ADDD #(2000*2)
STD 2,X ; 2,X costs the same as 0,X on this CPU.
PULA ; Leap year days.
PULB
PULY ; Bring the entry address back.
STD 0,Y ; Done! All stored away in YEARSTABLE.
* And we don't have to balance the stack.
Not much of a savings here, and you could say this is contrived, but stack order issues do occur in real code. That's part of why two accumulators were useful in the original 6800.
Will it help in DAYSINMONTHS?
Will it help in DAYSINMONTHS?
DAYSINMONTHS:
FCB 31,28,31,30,31,30,31,31,30,31,30,31
* Month number on stack as 16 bit integer.
* Leap year check done elsewhere.
GETDAYSINMONTH:
BSR DUMMY
DUMMY:
TSY
LDD 0,Y ; Get the address of DUMMY to work on.
SUBD DUMMY-DAYSINMONTHS
STD 0,Y ; Address of DAYSINMONTHS, relocatable.
LDB 5,Y ; Ignore high byte of month number.
PULX
ABX
LDB 0,X ; Get the days in the month.
CLRA
STD 4,Y ; Y is not equal S, but we can use it.
RTS
Not much, but it does help.
The real utility of having X and Y in the 6811 is for moving large blocks of data. You can have both the source and destination pointers in registers, where in the 6801 and before you must juggle the source and destination through X.
* Parameters on stack, hard limit of 2048 bytes.
* pushed in order of source, destination, count:
* 0,S ; return PC
* 2,S ; count
* 4,S ; destination
* 6,S ; source
* Slightly paranoid code.
BLOCKMOVE:
TSX
LDD 2,X
BMI BLOCKMOVEEND ; Bit 15 set is way too big.
SUBD #2049
BCC BLOCKMOVEEND
LDD 2,X ; Bring it back.
PSHA ; Save the high byte.
LDY 4,X
LDX 6,X
* We know it's a good, non-zero count.
BRA BLOCKMOVETEST ; But test-on-entry is what we want.
BLOCKMOVELOOP:
LDAA 0,X
INX
STAA 0,Y
INY
BLOCKMOVETEST:
SUBB #1 ; Reflect it in carry
BCC BLOCKMOVELOOP ; Speed up the inner loop.
PULA
SBCA #0 ; Because I prefer BCC here.
PSHA
BCC BLOCKMOVELOOP
INS ; Drop high half of count.
PSHX
PULA
PULB
TSX
STY 4,X
STD 6,X
BLOCKMOVEEND:
RTS
* Leave the parameters for the calling routine.
Well, there's still a little bit of juggling, but the loop is much cleaner than on the 6801, even. But not at all as clean as the 6809 code. Here is where it really becomes clear that the 6811 is not a modified 6809, it's a beefed up 6801.
Incidentally, the 68HC11 defines a number of new bit manipulation instructions, and some other useful things, including hardware byte-wide integer divide, which are not available on the 6809. These instructions, and the fact that it was available as a core for integrated controllers, were the reasons for using the 68HC11.
This is further along the path of evolution that the 6801 began, but it is still on a separate path from the 6809. (Do you get the feeling I'm peeved about this? I do have reasons. Motorola should have provided 6809 as a core like the 6811. More transistors, sure, but look at all the transistors in the 68000-family controllers. Yes, I know that much of Motorola's development work was driven by customer demands, but ....)
Now, there is/was a 68HC12, which further extends the 68HC11. I don't remember some details of the register model, so I'll refrain from putting bad information here. Maybe later.
The stack pointer and, if I recall correctly, the PC, are both indexable on the 68HC12.
The 68HC12 could almost be called a modified 6809. Still missing the second stack pointer. It even has fancy indexing modes similar to some of the 6809's. But the encodings are different, and there aren't as many of them. And if we look at it carefully, it's clear that it is a beefed-up 6811, borrowing ideas from the 6809.
The 68HC12 is still less a modified 6809 and more of a modified 6800 that has some of the features of the 6809, and is missing the most important feature, the extra stack pointer. The instruction set is said to be a superset of the 6811's.
The 68HC16 further extends the 68HC12, but it's still missing the extra stack pointer. Has a third index register which, we supposed, can either be a substitute for the DP register or the U stack pointer, but not both at once. And the indexes are wider, giving an addressable range of a full megabyte.
Okay, so, the what-if game.
What if Motorola's management had recognized that they should have been pitching the 6809 as the direct competitor to the 8088 instead of the 68000? What if they had recognized the opportunity to use the 6809 in researching correct processor design?
Step one, fill in some holes in the instruction set and addressing modes.
1.1 Widen the direct page register to 16 bits, so it can actually be used to point to a local/statically allocated data segment. (This has a ripple effect in the interrupt stack frame and in the encoding and meaning of the TFR and EXG instructions. Or it requires additional PSH/PUL instructions. Maybe both. But the gain is well worth it.)
1.2 Add indirect addressing through direct page variables, so you can stash a pointer in the direct page and use it without disturbing X, Y, U, or S. (Lesson from the 6502.) Essentially adds 128 possible statically allocated local index registers.
1.3 Add integer and fractional divide (as in 68H11). Possibly add bit multiply and divide primitives, but those tended to be misdesigned back then, so maybe not. Make the internal address and double accumulator math functions 16 bits to speed many instructions by a cycle.
1.4 Make it available as a system-on-a-chip core, like they did with the 6801 and then 68HC11, etc.
1.5 Make the mapping MMU and the DMA functions avaliable to be integrated with the core, and add support for both in the condition codes and interrupt architectures.
At step 1.5, the rumoured CoCo 4 could be built without the separate GIME -- or, rather, with the GIME on the same die as the CPU.
In fact, they might have implemented the full 6829 MMU functionality on-chip, succeeding where the 6829 on a separate chip was too slow. And they might have avoided some of the less stable aspects of the 6829 design, accessing CPU control signals directly.
With care in the design of the MMU, the S stack could be made completely unreachable, blocking whole classes of stack gaming vulnerabilities. Likewise, full process separation and such could have been achieved.
And they could have gone on to experimenting with true segment registers (full 32 bit, unshifted, not like the half-baked segments of the 8086, not the big bank switches of the 68HC16) and perhaps bounds registers, to experiment with memory management without re-mapping the memory itself.
And somewhere along the line, they might have proven to themselves that their fear of competing with themselves would not have done damage, that a decent lineup with the 6809 would have actually helped 68000 sales rather than cannibalize them.
If Motorola had been researching correct CPU design on the 6809 in 1981 and '82, they would have been much less likely to have taken the detour through the full reportoire of useless addressing modes that they built in the 68020. They could have applied the lessons of the smaller cousin to the bigger, and avoided the trap of trying to compete with the feature king Intel on useless features.
We can dream, can't we?
Of a world where competition is dog-meet-dog instead of dog-eat-dog, utility of the best fit instead of survival of the artificial fittest.
It's at present only slightly more realistic dream, I suppose, but it would be fun if I had the chance sometime to implement a FIG Forth interpreter optimized to each of the CPUs I've talked about here.
The 6800 version of the fig model was done by members of the Forth Interest Group back in the late 1970s, and I transcribed it in the mid-2000s and made it available as part of my M6800/1 assembler project, and I did a modified version for the 6809 back in the mid-1980s for college. (If you are interested in the 6809 code, contact me. I have it running on emulation, just need some time and motivation to put it up in its own tree. [JMR20201022: You can now find it here: https://osdn.net/projects/bif-6809/.]) (I started on an SH-3 conversion at 32 bits once several years back when I was trying to get myself back in the computer industry.) Really want to do a 68000 conversion at 32 bits, and the 68HC12 and 68HC16 have interesting aspects relative to implementing the thing.
And I'd like to go back and do them all as so-called subroutine-threaded. [JMR20201022: Project now in slow progress, here: https://osdn.net/projects/splitstack-runtimelib/.] Having all of that would be rather useful for comparing processor architectures and instruction sets.
Subscribe to:
Posts (Atom)