The summary under the reference article above states this:
About a minute in, he talks about the work he did at Western Technologies, programming VCS/2600 Raft Rider and Qbert. He also mentions WT getting the contract to make home versions of a Mylstar arcade game that wasn't released called Qbert Circus. I'm not sure if he's confused and was talking about Q*bert's Qubes (which a VCS version was released) or possibly Circus Charlie (which a VCS version was planned but never released).
A very simple SoC with what appears to be a 6502 clone suspiciously missing anything to do with the Y register. Stack is also in a non standard place (the top half of the zero page), probably due to only having those 128 bytes of RAM total and not wanting to give up zero page access.
"The SPC81A 8-bit microprocessor is a high performance processor equipped with Accumulator, Program Counter, X Register, Stack pointer and Processor Status Register (this is the same as the 6502 instruction structure)." Well not exactly haha. Yeah, if you look at the source code. No Y register related instructions!
I thought about it and you could get used to writing code without the Y register pretty quickly...
The actual instruction set manual for SunPlus 6502 CPUs (covers several but you can see the low end doesn't have Y instructions)
I read your comment out of context (actually in the context of programming an NES) and tried to figure out how the heck you’d live without a Y register. I’m not saying it’s not possible, but if I were writing a game It’d be a pain. Obviously it doesn’t Apply here.
> Few people are willing to rehash old discussions - so few people want to discuss why Bitcoin is/isn’t like tulips.
Society at large is wildly different than the discussions from here on HN, but at least here, discussions about Bitcoin and cryptocurrencies in general, tend to generate very large discussions, lots of them are about why cryptocurrencies is/isn't like tuplips/beanie babies/$hyped item.
Did anyone ever pay more than store prices for a Furby? My mom only bought us expensive toys if they would last and she deemed the Furby to be too much of a gimmick. I've never heard of people not being able to buy a Furby.
>> Did anyone ever pay more than store prices for a Furby?
Either you’re joking, or you absolutely didn’t live through the late 90’s to see the sheer insanity of what the Furby craze was really like. Furbies would be resold for hundreds of dollars, absolutely no exaggeration. It was mind boggling.
Maybe I was too young, I definitely remember the hype, but people around me were just buying the Furby for store prices, I think it was 120 Dutch guilders. I remember the commercials on TV and wanting one, but couldn't justify it to my mom :P Maybe by the time they started selling in The Netherlands the hype had already died down enough that they had enough in stock?
A Furby without fur even looks like a Terminator. Sort of. Similar vibe at least. There is definitely a non-zero chance that circuitbent Furbies will enslave humanity and bring about its end.
Sure. Makes me wonder how easy this code could be ported to run on the Commodore 64 though. You'd need a cartridge with the TI voice synthesis chip used in the furby of course, but it'd be doable I think. It's interesting code to read through.
> I'm not going to lie I spent a lot of money on furbies.
Oh my...
If anyone else isn't clear on what circuit bending is.
From Wikipedia:
> Circuit bending is the creative, chance-based customization of the circuits within electronic devices such as low-voltage, battery-powered guitar effects, children's toys and digital synthesizers to create new musical or visual instruments and sound generators.
Wikipedia is wrong here. Although the term is primarily used for acoustic properties, it doesn't have to be. I'd agree with the 'chance based' aspect though.
Mod list #5: "When hungry is low enough to trigger sick counter, each sensor deducts two instead of one for each hit." He made it get sicker quicker when it was on its death bed??
It is broken into a few different files by function, but this should get you there. Note that it appears that the original document omitted a few things.
I don't know why, but stuff like this (e.g. the Apollo moon lander assembly code) is really interesting to me. I think it's because I wish I had this kind of knowledge and skill. It seems daunting to wrap my head around it and become proficient.
It really isn't that hard once you have to do it, as long as you have the time to get a test / feedback loop with the client going. They probably had a dozen test versions of the Furbies for whoever was doing QA to play around with.
With the moon lander code, they surely had a very good specification of what it was supposed to do.
I worked with the second case once, some IoT-ish sensors that would be buried in the ground in greenhouses, to monitor soil data. The business logic was 90% specified, and of course, the remaining 10% took 50% of the time. Before you ask why we didn't do it in C at the very least, we had a very solid codebase from the previous products. Sure, we had to port things from a Toshiba microcontroller to an STM8, different architectures, but since we were working with 8 or 16 bits inputs it was kinda trivial to test every single possible input to make sure things matched.
My only previous experience with assembly at a Computer History college course where we coded for the PDP-11, the 6502 and a stack machine. So yeah, not a lot. Winging it while admitting you don't know what you're doing can get you decently far in some circumstances.
Don't overrate the skill of writing assembly, sure. But don't underestimate the software craftsmanship. Looking at the code, it's obviously expertly written. I'm not sure if I've ever had the pleasure of working with such a well thought out and documented code base.
And don't underestimate the skill of putting together the entire product: being able to create behavior that is relatably live-like for millions of people on such a limited Plattform may not be Apollo-Level genius but is exceptional nontheless.
I have a bit of an idea banging around in my head for a Furby-based project aimed at making it a lot more intelligent while still keeping the uncanny aesthetic:
* The furby's motions are controlled by one motor and a series of cams and gears, so it should be fairly straightforward to pull out its brains and attach the motor and position sensor to a suitable controller to allow a raspberry pi to control its movements. I've seen this done before (someone put an Alexa in their furby this way) but I think they were only running the motor when the pi was putting out audio, I'd quite like more fine-grained control so it can do all the movements it originally was capable of.
* The unusable crappy speaker and microphone should be pulled out and replaced with better equivalents (maybe even an okay quality one for dual use as a horrifying bluetooth speaker). RGB LEDs could be fitted behind its eyes for added nightmare fuel and another way to express mood. The IR gear could be kept in situ and hooked up to the Pi for some nefarious TV-related uses. I quite like the idea of a proximity sensor too so it can sense people's presence and accelerometers to sense how it's being handled.
* I'll have to fit the furby on some kind of plinth to hold all the new gear because there's no way I'm fitting all this stuff and enough batteries to run it in the original casing. Getting it all running off a bog standard USB-C connection would be nice, might even be able to figure out how to share an internet connection this way to avoid wifi-related hassle.
* I was going to use MycroftAI as its new 'brain' but I think finding some way of hooking it up to ChatGPT might be more fun! Either way I need some kind of text-to-speech and speech-to-text working on the pi for this to happen.
Anyone got any suggestions/improvements to this idea?
A raspberry pi pico would probably fit in the space available and have all the capability you might need to run mycroft on it. The pi pico has 26 gpio pins which should be plenty for what you need as well. And it has a usb on-the-go port.
Use Chat-GPT to generate gibberish responses to keywords recognized by a microphone and spoken through a Furby voice changer. Use 3+ 18650 Li-ion batteries to power this omnipotent all-knowing Furby oracle for days before recharging.
Possibly, but the 1998 furby is not longer sold. You wouldn't be competing with the company that made them by making an emulator. The code itself is most interesting as a part of history and I think you aren't really preserving historically significant code if it can no longer be run. Would this be considered fair use?
I remember when these were the biggest thing ever for a holiday season. Rumors there was understating and higher order thinking. Purchase at an premium and pretty disappointing.
I met Caleb Chung when I was in Boise several years ago. Cool guy. Real low-key. He drove a simple Chevy Express camper van and told me the porta-toilet was a game changer. If I hadn't heard of his Furby background I wouldn't have a clue that he was very successful and rich.
They tried to get one of the newer ones with the digital display eyes to do it but the CPU of those is one of those nasty Sunplus ones that are real uncharted territory with their u'nSP instruction set.
https://devpost.com/software/doomfurb
I'm actually the guy (Sam) from that post! Never got DOOM running on the Furby, but I was able to get a custom version of Pong running, with accelerometer controlled paddles.
The CPUs are definitely weird, and I ended up porting Ghidra to support u'nSP as part of that project. https://github.com/SamuelWAnderson45/sleigh-unsp Reverse engineering a CPU was a wildly fun learning experience; still proud of that project.
Can you share any more details about the Pong port? I have been collecting various bits of information about u'nSP processors, particularly the SPG2xx series used in mid 2000s plug-and-play games, but so far I have never seen an actual homebrew game for any of these chips (with the exception of the Mattel Hyperscan's SPG293, which however uses a different architecture).
I have also been looking into the newer GeneralPlus GPM4x30 SoCs used by some modern Chinese plug-and-plays with HDMI output, at least by the ones that aren't straight up Famiclones hardwired to a composite to HDMI upscaler. Those are ARM based so much less of a pain to reverse engineer but also much less fun...
It's interesting i was just watching a video on the "Furby" craze. I remember my little sister had one and was interesting.. this source code is so simple but clever. Really cool.
I am wondering if there are any Easter Eggs revealed in here that haven't yet been discovered, though I do see the Release Note specifically discuss added hidden functionality.
> I think its not possible to port Linux on a 6502, maybe Minix could be used as a base for a port. As far as I know (??), early versions of Minix did not require
an MMU.
But check out the LUnix Project, its a kind of unix for c64 and c128 from
scratch, ports to other systems should be possible:
The actual furby chip was probably a glop top right? You can't do a lot with that other than mess with the sensor input lines. Getting the code here to run on other stuff is the real prize I think.
Not possible with real Linux, the CPU on the Furby is too limited while the smallest Linux out there still requires some more resources.
Some small size Linux-like OSes do exist though: one commenter suggested Lunix (which I didn't know, thanks for the link), and a slightly bigger one is ELKS which runs on old MMU-less x86 CPUs. I managed to run it on a 8088 industrial PC ages ago.
I should have a Furby buried somewhere; now that I think of it, it may be the right platform to stick a bigger brain into, make it wireless so that it could be connected to the home IoT network then signal events or alerts.
You can watch a Computer History Museum interview with him here. [2]
[1] http://www.atariprotos.com/2600/software/qbert/qbert.htm
[2] https://www.youtube.com/watch?v=7U9eqBzmvZw