I often wanted to develop a humanoid robot, but I doubt I’ll ever have the money and time to do so. Although, while computer vision is easier nowadays, computer hearing still is difficult, and apparently nobody managed to invent a suitable model for the mind yet.
Isaac Asimov grossly reduced the issue of the mind to three simple laws. But those are just three lines of source code in a program of many million lines. He thought man could simply copy a human brain using positronics, but in fact what we have nowadays is electronic computers which work with ones and zeroes, and primitive instructions like add a number here, move a value there, branch in the program, and so on.
To model the mind, it is necessary to work bottom-up, i.e. to write the layers first that communicate with the hardware, then abstraction layers that generate an internal projection of what is perceived, and then it’s possible to model the mind based on those impressions. Even telepathy is possible and desirable (by abstracting network functionality — a short range WiFi or Bluetooth communication would be sufficient). The mind then can formulate intent on the impressions gathered, or be further abstracted.
The issue of the operating system, I think, has been solved already. Nowadays, it would be possible to simply pick one among the many free open-source operating systems that are available, like FreeBSD, OpenBSD or NetBSD, Linux, or Android, etc. — any of these have broad hardware support, and there is no need to keep everything in one computer board. Miniature computers could be scattered all about the humanoid’s body, handling various tasks in the background, so that higher-function computers can handle the tasks that are more complicated. Internally, they could communicate via TCP/IP in a local area network.
Yesterday, I connected an old multimedia keyboard (a Cherry Linux keyboard ) to my PC, and I wanted to have the multimedia keys working on XFCE4. I’m using Ubuntu 12.04 64-bit on that machine. It’s pretty simple once you know how: First, go to the XFCE4 session settings and disable the XFCE4 audio volume demon (if it doesn’t work for you — it didn’t for me), then log out and back in. Pressing the volume buttons on the keyboard now shouldn’t do anything. Install the package “moc” (on Ubuntu), which is an audio player for the console. It’s controller application is called “mocp” which has plenty of options. There’s an example config file (required to set default directory) in “/usr/share/doc/moc/examples” (on Ubuntu). You can extract it for instance by typing “zcat /usr/share/doc/moc/examples/config.example.gz >~/.moc/config”. Before that, make sure the “.moc” directory exists: “mkdir ~/.moc”. After that, you should be ready to go: Fire up the XFCE4 keyboard settings dialog and change to the “application shorcuts” tab. Then add shortcuts like shown in the following screenshot (click image to enlarge) :
I wrote a simple Intel HEX to binary file converter in C (see attached file). License: GPLv3.
NOTE that the address fields are ignored, addresses are expected to be contiguous. This is sufficient for platforms like the C-64 which only support contiguous binary files.
While tinkering with the 6502 processor on assembly code level, I just realized the 6502 contains a nasty bug in the CMP instruction. Every other CPU on Earth computes the carry flag correctly when doing an A – M operation. The 6502 however, does the exact opposite of what is expected:
Suppose, A contains zero (0), and M contains two (2), a simulated subtraction (as performed by the CMP instruction) would result in -2 (or $FE), causing the carry flag to be set. A subsequent BCS instruction should then branch and a BCC instruction should not branch. However, on the 6502, BCC has the meaning of “is lower than”. So, on the 6502, the BCC would branch in this case, instead of the BCS instruction, which would be the expected behavior.
So, essentially, the outcome of the C flag is inverted during CMP. That’s why our brain hurt so much in the olden days when we tried to understand the behavior of those branch instructions on the 6502. Turns out we had been right all along getting our brain in a knot over this.
I often watch TV shows that talk about the SETI project and how it failed to meet expectations. However, people seem to forget that humankind invented radio waves little more than a hundred years ago, and will probably abandon that technology within the next thirty or forty years, a hundred maximum. So, how on Earth should alien civilizations that are many light years away just coincidentally happen to use exactly the same technology while we’re aiming our measly telescopes at them? This is ridiculous and completely unlikely.
To illustrate that, I’ll explain to you why we might be abandoning electromagnetic communication in the near future. Since the discovery of quantum physics it has apparently been observed that two particles can exist in so-called quantum entanglements, in which one particle seems to transmit information to the other instantaneously, regardless of distance. Now imagine that such an entangled particle could be captured within a computer chip, and its peer within another chip. Put one chip in a home computer, and another at an ISP’s data center, and bam, you have a network connection which requires neither a cable, nor a radio transmission. Within only a few years after such an invention, electromagnetic communication would vanish altogether, and aliens on other planets would pick up zip with their radio telescopes.
Recently, I’ve created a new project on SourceForge called “The Engine”. It’s a 3D engine with built-in BASIC interpreter. Version number is still 0.00, so it’s fairly incomplete still, but I’ll work on it as much as muse and spare time permit.
After messing with Fedora 17 after reinstallation and not getting anywhere, I decided to give Ubuntu 12.04 a go, and it seems to be better suited for that hardware platform. For one, Ubuntu automatically installs the proprietary NVidia driver and its control panel applet. With that, it’s easy to set a new resolution and save it to an X config file. HDMI audio works after using the workaround that I used for Fedora 17 before (see earlier article).
If you happen to have an NVidia graphics card or chipset and are using Fedora 17 with the default Nouveau driver, you might have noticed that HDMI Audio support seems to be missing. The reason is that the PulseAudio drivers for the hardware do not work. However, the ALSA drivers do work. So, all you have to do is to create ALSA sinks for the PulseAudio demon. Edit “/etc/pulse/default.pa” to contain the additional lines:
load-module module-alsa-sink device=hw:1,7
load-module module-alsa-sink device=hw:2,7
After editing, a reboot is necessary for the changes to take effect. Also, the actual ALSA outputs that you have to use may vary “1,7″ and “2,7″ are only mine (depending on which chip was recognized first during boot), and “7″ need not always be the channel for your HDMI screen. With programs that let you test your ALSA outputs (like the KDE audio setup applet), you can find out which the right ones are for your system.
The “.nofail” / “.fail” bracket is to avoid a PulseAudio demon failure during boot.
If you happen to have NVidia hardware and a digital flat planel and are using the Nouveau driver on Fedora 17, you might have noticed that the driver never changes actual screen resolution and only scales the screen up or down from your desired resolution, there’s hope (see paragraph number 17: “My custom video mode is not effective”). You can either issue the command “xrandr –output OUTPUT –set ‘scaling mode’ None” manually (with OUTPUT being the connector of your card, see “/var/log/Xorg.0.log” to get its name), or you can add it to the KDE RandR startup commands (if you’re using KDE), at the end of the line, separated by “\n”. For me, the entry in “.kde/share/config/krandrrc” looks like this: “StartupCommands=xrandr –output HDMI-1 –pos 0×0 –mode 1920×1080 –refresh 60.0\nxrandr –noprimary\nxrandr –output HDMI-1 –set ‘scaling mode’ None”. It’s important that the option is on a separated line, otherwise you’ll get a black screen.
Happy birthday, Intel 8008!! The processor celebrates its 40th anniversary this year, and I wrote a small emulator and assembler for the CPU, that can be extended easily. Published as open-source under GNU GPL v3 license, and tested on Linux! This is a v0.0.1, so it may still contain some bugs here and there that I haven’t found yet. The emulator has a simple stack and console circuit emulation, and more will follow if spare time permits.
Intel 8008 Assembler and Emulator, v0.0.1