It looks like you're new here. If you want to get involved, click one of these buttons!
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.