Hacker News Reader

Comment by dbcurtis | Hacker News Reader

These have their uses.

A friend who frequently does contract development in the toy space has (or at least used to have) a favorite go-to MCU that costs under $0.06 in bare die. It is essentially a 6502 with 100 bytes of RAM and a metric butt-load of mask-programmable ROM. It was originally designed for greeting cards. He has designed it into toys.

It is hard to use, you need a dev kit and a good relationship with the distributor to get the documentation. It only makes sense in high-volume products, since it comes as passivated bare die so assembly requires a die-bonder and expoxy encapsulation depositer.

Not for everyday use. But as my friend says: “You haven’t lived until you have spent an entire afternoon arguing over $0.05 on the BOM.”

View on HN

That sounds very similar to my experience with toy development. For a toy that played a bunch of pre-recorded sounds, we used a 4-bit Winbond MCU (their MCU division is now Nuvoton) that had a tiny bit of RAM and a ton of mask ROM. Firmware development was done in assembly and targeted a huge (physically large) emulator for test/debug. When we were satisfied with the firmware, we'd send it off to our CM, who would then order the parts with our FW in ROM. They'd get back bare die parts, which were wire bonded to the PCB and then epoxied over (that miserable "glop top" packaging, which is the bane of many teardowns). Development was a bit painful, but high volume production was extremely cheap.

Edit: Oops. I conflated projects. The toy project actually used a SunPlus MCU, not a Winbond MCU. It was an 8-bit RISC CPU running at 5MHz with 128 bytes RAM and 256KB mask ROM. The ROM held both the program and audio samples. I don't recall what encoding was used for the audio.

Well, I'm curious which project used a 4-bitter. Jack Gansle and Robert Cravatta did a survey a while back:

http://www.embeddedinsights.com/channels/2010/12/10/consider...

http://www.ganssle.com/rants/is4bitsdead.htm

The two examples were timepiece designs and Gilette Fusion ProGlide. On top of getting yours, I'm curious if any of these cheap MCU's in the article could today have met whatever your requirements were for a 4-bitter?

It was also for a low-cost audio application, but it wasn't a toy. This was back in 2001 or so. The MCUs in this article all only have ~1KB ROM, which wouldn't have been enough for our audio samples. We needed >256KB. The "4-bitness" was just incidentally what Winbond offered with a large ROM at the time. However, the SunPlus that we later used in the toy also offered a large ROM with an 8-bit CPU for a similar cost. So, while I can't authoritatively say that 4-bit is dead, it does seem like there are a lot of alternatives in similar price ranges now.

Great story, thanks for sharing. I for one pretty much constantly live the life he alludes to at my company bomquote.com. In China, we actually negotiate in increments of ~1/6th of a penny.

Why not a tenth?

I guess the 1/6 comes from a currency conversion

The yuan-usd exchange rate has floated around 6:1 until recently, with yuan denominated down to 0.01. So possibly that.

Nailed it. https://en.wikipedia.org/wiki/Jiao_(currency)

Don't you mean fen? https://en.wikipedia.org/wiki/Fen_(currency)

1/6 of a penny is 0.0016 USD, or 0.01 CNY: https://www.google.com/search?q=0.0016+usd+to+cny

Ah, yes, there was an article here a year back about the original Furby using that same configuration. The article actually had the annotated 6502 source code.

https://news.ycombinator.com/item?id=17751599

It´s very common to find those chips in cheap home alarm systems.

In Brazil, Holtek has a huge presence in that niche.

>6502

Without question, one of the nicest platforms to have in multitudes of thousands, at low energy and cost ..

Honestly I'd prefer an ARM or an 8086 or an AVR. I imagine I'd prefer a J1A too but haven't tried. The 6502 makes it a pain to do anything in any language higher-level than assembly, even C, and being 8-bit means you're constantly facing tradeoffs between making things fast or making them correct for more than 128 or 256 items.

Is a "expoxy encapsulation depositer" the thing that makes those black blobs?

Yes - but more it's two machines - the one that place the raw die on the board then stitches the bonding wires, and the one that throws the epoxy blob on top of that

"metric butt-load of mask-programmable ROM"

What would that be in this context? I'm guessing we're talking KB rather than TB?

the poster mentioned it was for greeting cards, I remember their used to be a lot of greeting cards that would play a recording when you opened them. I bet they loaded low-quality samples into the ROM for that.

I'd guess about 1 MB order of magnitude. That would be a butt-load even for samples.

1 MB would be enough for 45 seconds audio at 8 bit PCM @22 kHz. If they're half competent, they could use ADPCM or much better (and cheaper to decode too!) vector quantization.

With VQ, you could go even down to ~1 bits (~6 minutes of audio per megabyte) per sample while maintaining good audio quality. Decoding is very simple, so 6502 would have plenty of oomph to do that.

> [Vector quantization] Decoding is very simple.

Do you have an encoder/decoder to point us to?

VQ is a very well known technique. For something quick, you might be interested to check this blog post about (unmodified) C64 playing high quality audio at 44.1/48 kHz, VQ compressed down to 96-128 kbit/s: https://brokenbytes.blogspot.com/2018/03/a-48khz-digital-mus...

There's some decoder code there as well.

Arithmetic coded uniform quantization works very well and is straightforward to implement!

MB == Metric Buttload.

Makes sense.

Using the trivial BTc encoding, you could archive a good compression ratio and generate audio without using a DAC . https://www.romanblack.com/picsound.htm

The 6502 can only address 64K, so I'd assume 32K of ROM at 8000-FFFF with 128 (not 100) bytes of RAM mapped at both 80-FF (zero page) and 180-1FF (for the stack) and 128 MMIO bytes at 00-7F. It depends on how much they've modified the base 6502 design, though; the above is for "not at all".

In such an integrated design 6502 can address exactly as much as you want/need it to.

Just implement bank switching for top 32 kB of address space. 256 banks (= one 8-bit register) * 32 kB = 8 MB. Need more? Add another bank switch register and you got up to 2 GB.

For a $0.06 part? Uh, clearly not TB...

Amazing numbers. Can you give me a more accurate number than metric buttload? Closer to 8K or 64K, for example?

500k to 1M IIRC. Originally indended for audio assets.

Absolutely amazing! There are some very credible sampled synths that used 1M of ROM.

Reply on news.ycombinator.com