Furry, Needy Code

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!