Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
In this Discussion
Furry, Needy Code (Code Critique)
- Title: FURBY.ASM
- Source: INTERACTIVE TOY (FURBY.ASM) - SPC81A Source Code (Version 25)
- Author/s: Dave Hampton / Wayne Schulz
- Languages: Assembly code for Sunplus SPC81A microcontroller (reduced 6502) [*]
- Date: July 30, 1998
Hello all!
As I was vacuuming the other day, I had a weird recollection about a childhood toy, the Furby. If you are from my generation or that of my parents', you will certainly remember these scary little fuzzballs who needed to be fed and given attention. The same fuzzballs often bring up a certain feeling of unease, and so-called creepy stories about furbies are legions online, perhaps in great part due to the toy's disturbing, big round eyes, and its tendency to trigger for unknown reasons. As a child who had a Furby, mine had become infamous in the family for coming alive at the most random of times, years after I had stopped caring for it. At this point in time, many years after the fact, I still wonder how much of my haunted Furby memories are true, and how much of those come from me sensationalizing a creepy, electronic toy that seemed too complex to allow its users to understand exactly what triggered it.
The reason I am posting here is because, following that hunch, I found out that a part of the Furby's code had been posted online, and available here.
This is a new discovery, and so my goal posting it here is to allow others the joy of a first, raw parse of those pages so we can share snippets that seem of interest to us.
While I have yet to find the time to dive deep, I did find some passages that caught my attention:
There are different elements of the code that are preoccupied with the "Bored" status of the toy, in order to determine when it should wake up and prompt the user to interact with it. What is particularly interesting to me about this is that it becomes more complex to think about programming boredom rather than the usual input-output. What to do when there is no input? How does one make a machine lonely?
On page A-2, the changelog provides some interesting snippets as to how this seemed to be a central concern for the programmers of the Furby:
; 11, On power up we still use tilt and invert to generate startup random
; numbers, but if feed switch is pressed for cold boot, we use it to
; generate random numbers, because it is controlled by the user where
; the tilt and invert are more flaky,
So the toy combines a more arbitrary element (its own position) with something that seems more subjective to the user, such as the last time the Furby's tongue was pressed.
I can't help but think back on Nick Yee's Proteus Paradox where he shows how games can provoke superstitions when enough complex factors, associated with potential bugs, end up making players create completely inexistent correlations ("if I face North while doing XYZ, I will have more chances to succeed"). Combining the code with the kind of infamous heritage of the Furby being "haunted" and finnicky to truly put to rest, I'd love to take this toward a direction of understanding how this specific toy ended up feeling uncomfortably alive.
Other things that caught my eye:
On A-11:
; This determines how long Firby waits with no sensor activity, then
; calls the Bored_table for a random speech selection,
; Use a number between 1 & 255, Should probably not be less than 10.
; SHOULD BE > 10 SEC TO ALLOW TIME FOR TRAILING OF SENSORS
Bored_eld EQU 40 ; 1 = 742 mSEC ;; 255 = 189.3 seconds
The "Bored_table" seems to refer to a list of voicelines and macros around A-137-138, though they don't tell me much outside of a few commented out sections, and the fact that the Furby's age seems to impact its boredom and response.
We also get some fun comments peppered in there:
(A-23, repeated in A-124):
; On power up of reset, Furby must go select a new name ,,, ahw how cute.
I am a little surprised to not see in the code more references to the Furby's fairly creepy appearance and behavior, even though I understand it was not the toy's goal/design. Instead, it seems to be treated as a wondrous toy with many "Easter Eggs" and different companionship games (Simon says...), so the fact that it ended up becoming an infamously needy toy does not necessarily appear here.
I hope this sparks some interest with y'all!
Comments
Fascinating find, @Lyr!
In addition to the assembly code (296 pages of assembly in one document!) I see that fan communities for Furby collecting, repair, hacking, and modding have done some work in compiling technical information on the platform, like on the Official Furby Wiki/ Furby (1998)/Technical information.
This seems to be a thing with late 20th and early 21st century animatronic toys. I once did a fairly deep dive into Teddy Ruxpin modding while look at audiobook animatronics for my history of Audiobooks and Podcasts course. A driving motivation for technical deep dives is often not just restoration-nostalgia but modding, in the sense of "I want to make this mass produced object do new things" (e.g. how can I create my own cassette tapes that make the robot's mouth and eyes move?). Those Teddy Ruxpins were driven by tone signals on a track on magnetic cassette tape that moved the actuators, but they and the larger-scale animatronics like Chuck-E-Cheese and Showbiz Pizza robots all had similar uncanny valley issues to the Furby (not unlike china dolls before them), and we see those themes alive and well in popular horror works like the Five Nights at Freddy's cross-media franchise.
Recently my kid and I rewatched an episode of Bluey called "Hide and Seek" (S01E42) which features the recurring character of Chattermax, a hyper-interactive electronic bird doll that parodies the high-engagement, attention-seeking electronic toys with sensor and timer-based behaviors typified by Furbys and descended from the same line of designs as digital pets (e.g. Tamagotchi). It is funny to me that he formed opinions about Furbys and Tamagotchi in that way -- never having experienced them, just through a loose parody.
In the episode, Bluey is failing to play hide and seek with her family due to being distracted by e.g. virtually feeding and soothing her needy Chattermax toy, and she needs to learn how to turn it off and develop mindfulness. I was also never in a household with a Furby, so I hadn't realized that "Hide and Seek" is literally one of the games that Furbys are programmed to play -- until I saw it on the Furby source code pg A-126.
Pages A-126 and A-127 seem particularly promising for thinking about representation, as they gather a lot of the encoded terms for the secret Furby language and serve as a kind of decoder key, as well as giving us a start on asking what emotions are named and unnamed, what states are modeled and un-modeled, and what Furry words and concepts are utterances in FURBY.ASM (e.g. "HUNGER" and "SICK" but no "ANGRY" or "SAD", words for "hungry" but no words for "sick", et cetera). If I was asking e.g. "how does a Furby represent wellness and emotional regulation?" I'd probably start there.
The first thing that occurs to me looking at that, since the code is all 8-bit assembly, the comments dominate the code and are the only thing that is highly readable. Compare this to code like that of the Aibo, which has its own operating system, is programmable by the user, has vision, etc. Both are built around types of play, but the Aibo is far less creepy. The Furby perhaps has just enough complexity to seem like it has some deep logic that can't be understood; not really random, but still unpredictable.
@jeremydouglass I'm curious about your deep dive on Teddy Ruxpin! Have you posted your findings anywhere, or can you point me to any resources/wikis/forums you came across? In my backlog of "someday" projects, I have a partially-disassembled Teddy Ruxpin that I want to mod somehow. I still need to fix the gears in his mouth/eyes and put his skin back on, but that all seems doable. For my next step I was going to try and reverse engineer the tone signals on the cassette tape, so I would love to see whatever you found or learned.
Hi @Lyr, I love that you (and @jeremydouglass too) have unearthed Furby code! A few weeks ago I listened to a 2014 episode of Radiolab called “Talking to Machines” (transcript here). It covers Russian bot girlfriends, ELIZA, the Turing test, Cleverbot, and Furbys. (2014 hadn’t seemed so long ago until I listened to this podcast and wow, it’s light years back, in terms of the way popular journalism approaches AI.)
The whole episode is worth listening to, but the Furby section was interesting especially because of how it puts Furby in conversation with Weizenbaum’s discomfort with seeing people interact too intimately with ELIZA. Radiolab suggests that Furby presents a kind of “emotional Turing test”:
So Radiolab does the test: they gather a group of 6-8-year-old kids, and ask them to hold three things upside down: a Barbie, a Furby, and a real hamster (named Gerbie for the purposes of the episode; they’d meant to get a gerbil).
Turns out the kids don’t care at all about holding Barbie upside down, they'll dangle her forever; they really care about Gerbie and put her down immediately; and they find Furby almost as hard to hold upside down as Gerbie. But they have a hard time saying why:
Then Radiolab finds the guy who designed Furby, Caleb Chung, who argues that Furby really does feel scared:
I’m not a programmer and have near-nil expertise in coding, but I am very interested in the affects entities like Furby (or ELIZA) can cause in people: Freedom Baird says she's "uncomfortable," the kids report feeling "guilty," "like a coward." (I am also thinking still about @markcmarino's questions about "AI shaming" in the POET code critique thread; also @dancox's point in the Week 2 thread about the "competence effect," that "most people become upset when the computer keeps apologizing for mistakes it interprets it might be making when it has not made those.") Here, I’m curious what others think about Chung’s insistence that he “can code that.” It seems absurd to me, the non-programmer, on the one hand and totally reasonable on the other. Is it persuasive to you? Is that what you see in the code?