What's this 8051 clone?

[david.given]

I'm helping reverse engineer an incredibly cheap 8051 clone; it seems to show up in blobs in little Chinese audio toys like Buddha machines. What's interesting about it is that it's capable of executing code out of XRAM, and loads the bulk of its application payload from a 8-pin serial flash chip, making it trivial to reprogram.

After dumping the flash, it seems to use an extended 8051 instruction set. It's got DPTR autoincrement via a bit in SFR 86, but more interestingly, it's got what appear to be a bunch of 16-bit instructions using A5 as a prefix. The only one I can positively identify so far is A5 6x which is a 16-bit compare or subtract or xor:

Code: [Select]

   CODE:2203 75 d0 00        MOV       PSW,#0x0
   CODE:2206 75 81 00        MOV       DAT_SFR_81,#0x0                                   = ??
   CODE:2209 75 87 02        MOV       DAT_SFR_87,#0x2                                   = ??
   CODE:220c e4              CLR       A
   CODE:220d 75 86 10        MOV       DAT_SFR_86,#0x10                                  = ??
   CODE:2210 90 11 00        MOV       DPTR,#0x1100
   CODE:2213 7a 00           MOV       R2,#0x0
   CODE:2215 7b 19           MOV       R3,#0x19
                         LAB_CODE_2217                                   XREF[1]:     CODE:2225(j) 
   CODE:2217 f0              MOVX      @DPTR=>DAT_EXTMEM_1100,A
   CODE:2218 f0              MOVX      @DPTR=>DAT_EXTMEM_1100,A
   CODE:2219 f0              MOVX      @DPTR=>DAT_EXTMEM_1100,A
   CODE:221a f0              MOVX      @DPTR=>DAT_EXTMEM_1100,A
   CODE:221b f0              MOVX      @DPTR=>DAT_EXTMEM_1100,A
   CODE:221c f0              MOVX      @DPTR=>DAT_EXTMEM_1100,A
   CODE:221d f0              MOVX      @DPTR=>DAT_EXTMEM_1100,A
   CODE:221e f0              MOVX      @DPTR=>DAT_EXTMEM_1100,A
   CODE:221f a8 82           MOV       R0,DPL
   CODE:2221 a9 83           MOV       R1,DPH
   CODE:2223 a5 61           CMP16     R0R1,R2R3
   CODE:2225 30 d1 ef        JNB       DAT_BITS_d1,LAB_CODE_2217                         = ??
   CODE:2228 75 86 00        MOV       DAT_SFR_86,#0x0                                   = ??
   CODE:222b 02 22 00        LJMP      LAB_CODE_2200

(The `CMP16` instruction is provisional. The registers are encoded in the last nibble.)

Does this look at all familiar to anyone? I'd love to know what this thing is actually called, and possibly lay my hands on a data sheet.

Thanks!

[JoeyG]

are you sure it's code and not non volatile  data  stored in flash

[voltsandjolts]

^^Yeh.

Maybe there is one block of ram loaded from serial flash, but at runtime some of that ram is mapped as code (psen access) and the rest as xram (data)?

[david.given]

It definitely looks like code. There's an actual filesystem and everything, and the filename is 'code.app'. It looks like it loads the main payload at 0x1900 and then there are multiple overlays loaded at 0x2200, and the structure all looks valid. It looks like there's mask ROM up above 0x8000 that contains the init code and BIOS. This makes sense given the application, where you can use the same low-price COB for multiple different small-production-line toys, putting the actual application that's being run on the flash chip which you're going to have to customise anyway. I'll know more once I've had a chance to compare the flash chips from some different related-looking hardware.

I suspect that the way this is implemented is that they've just wired the program and xram buses together so there's a single, unified Von Neumann address space.

But the main bit I'm interested in is the instruction set. Has anyone seen anything similar to this before?

[amyk]

80251?

You mention "Buddha machines", is this related in any way? https://www.eevblog.com/forum/chat/big-clive-reverse-engineering-challenge/

[david.given]

It's not 80251 --- the instruction set's quite different. It's also not MX51 or AT89LP. But yes, that's the device! The flash encryption's been decoded and now there's tooling for unpacking and repacking the firmware. Obviously, once we can run our own code on it we can figure out what the instructions all do, but someone must know what it is, and tracking this down would save a lot of time.

See the Reddit thread here: https://old.reddit.com/r/BigCliveDotCom/comments/pmt390/buddha_machine_teardown_with_flash_dump/

[PCB.Wiz]

... What's interesting about it is that it's capable of executing code out of XRAM, and loads the bulk of its application payload from a 8-pin serial flash chip, making it trivial to reprogram.

How much XRAM is there ?  What SysClk and clocks per opcode does it have ?

It's not 80251 --- the instruction set's quite different. It's also not MX51 or AT89LP.

Yes, it looks like custom extensions, with modest extensions targeting the use of audio file and decompression.
The 80251 was quite a large extension, so it is unlikely to be (totally) that.

[david.given]

How much XRAM is there ?

The init code I quoted clears 0x1100 to 0x1900; the main binary loads at 0x1900 and goes up to 0x2200; the overlays load at 0x2200 and the biggest one goes up to 0x2800; so that suggests at least 6kB. Of course I have no idea what XRAM is used by the BIOS (there are lots of helper routines, plus the main filesystem code which loads and decrypts the code), or how much of it is exposed on the program bus.

What SysClk and clocks per opcode does it have ?

No idea so far.

Edit: I should add that it looks like there are some memory-mapped registers above 0xff00 in the XRAM, which I believe is unusual for 8051 devices, so my thought is that someone's dropped an 8051 softcore into a design with existing devices on the bus.

[PCB.Wiz]

How much XRAM is there ?

The init code I quoted clears 0x1100 to 0x1900; the main binary loads at 0x1900 and goes up to 0x2200; the overlays load at 0x2200 and the biggest one goes up to 0x2800; so that suggests at least 6kB. Of course I have no idea what XRAM is used by the BIOS (there are lots of helper routines, plus the main filesystem code which loads and decrypts the code), or how much of it is exposed on the program bus.

Once you have the loader reverse engineered, I guess you can upload an XRAM scanning routine, to see how large XRAM is ?


I know this is not a 80251 clone, but if you wanted to check 'Chinese thinking' around 'extended 8051', I see STC have data on their upcoming STC16, which looks like a MCS251 with 32b FPMU extension support.

https://www.stcmcudata.com/STC8F-datasheet/STC16.pdf

Addit : Some of that STC16 data is in English, and maybe they have used a subset of MCS251 - if I was doing an extended 8051, the lazy path would be to try to use existing tools, but cherry pick opcodes ?

Is there list of the bytes following 0A5H in the dumps you have so far ?

[PCB.Wiz]

Edit: I should add that it looks like there are some memory-mapped registers above 0xff00 in the XRAM, which I believe is unusual for 8051 devices,..

It is becoming more common for 8051 variants to MAP SFR into XDATA space, as they run out of space in the standard SFR space.
With STC's 'standard 8051'  many of the PWM etc registers are mapped into XDATA, and they use 0xff00 and above

[amyk]

It's not 80251 --- the instruction set's quite different. It's also not MX51 or AT89LP. But yes, that's the device! The flash encryption's been decoded and now there's tooling for unpacking and repacking the firmware. Obviously, once we can run our own code on it we can figure out what the instructions all do, but someone must know what it is, and tracking this down would save a lot of time.

See the Reddit thread here: https://old.reddit.com/r/BigCliveDotCom/comments/pmt390/buddha_machine_teardown_with_flash_dump/

Wow! There's a lot more progress there than I expected, and this chip is also far more capable than I thought would be used for such an application. Then again, I didn't expect the flash data to be obfuscated, nor the COB to be anything more than a dedicated ASIC. If someone volunteers to sacrifice one to see if the die has any markings, that might help identify the manufacturer and/or part number.

Unfortunately Google gives absolutely useless results (far worse than it used to be) for searching this sort of obscure stuff, so I'm having trouble finding 8051-variants that might fit. There's also the question of whether the companies who make these chips would have any presence on the English internet.

[david.given]

Once you have the loader reverse engineered, I guess you can upload an XRAM scanning routine, to see how large XRAM is ?

Yup. Hopefully the mask ROM will be accessible, too --- there seem to be two chunks, one at 0x8000 and one at 0xb000. Knowing what's in there would help a lot.

Is there list of the bytes following 0A5H in the dumps you have so far ?

Here's a link for a full disassembly. This combines the main application at 0x1900 and the first overlay at 0x2200, so everything's at the right address. It's using the MXC51 disassembler, which is wrong, but it's at least got the bytes in it. https://github.com/uzlonewolf/BuddhaMachineFirmwareTool/blob/main/firmware/fileparts.00.code.app.part-14-00.bin.asm

I see STC have data on their upcoming STC16, which looks like a MCS251 with 32b FPMU extension support.

I love the 8051 --- it's the Instruction Set That Will Not Die! The entire world runs off this god-awful antique ISA and shows no signs of stopping. I mean, trying to bolt on a 32-bit FPU onto it is sheer insanity, and yet people are. It's so delightfully perverse.

[david.given]

Somebody found what looks like an unblobbed version of the same board, and apparently bigclive has looked at one before, so here's the link with a nice big picture of the PCB: https://youtu.be/baCLqPzuiF8?t=330

The chip is a 16-pin job with the following label:

Code: [Select]

IT80ZXD
MAREF900
1816

[amyk]

Somebody found what looks like an unblobbed version of the same board, and apparently bigclive has looked at one before, so here's the link with a nice big picture of the PCB: https://youtu.be/baCLqPzuiF8?t=330

The chip is a 16-pin job with the following label:

Code: [Select]

IT80ZXD
MAREF900
1816

That's a Generalplus IC judging by the logo, but no guarantee it's going to be the same model or even manufacturer in the COB version. They do make 8051s though. (G+'s website is a horribly slow JS-ridden "modern" abomination. I tried browsing the datasheets there but gave up shortly. If I was going to be a customer, they just lost me. )

[david.given]

Wow, I completely failed to notice that was a manufacturer logo. I think my brain just assumed it was a smear on the chip. Bad brain. Thanks very much!

So someone's dumped the SPI flash and cracked the encryption --- same scheme, different settings --- and it's very similar to the COB version: same file system, slightly different code.app file, etc. So it's very likely it's the same chip. https://old.reddit.com/r/BigCliveDotCom/comments/pmt390/buddha_machine_teardown_with_flash_dump/he6650t/

I've poked around GeneralPlus's website (it's not that bad; at least the documents are there, mostly. When it works.). Apparently their really low-end stuff use 6502 cores! The most plausible looking devices are the GPM8 series, which are 8051s with additional XRAM. The GPM8F3496A has 12kB of XRAM, which makes it very plausible, but there's no documentation available and it's weirdly high-end for such a trivial application (like, it's got USB support). The other 8051 data sheets don't mention any extended instructions. The GPM8F3132C has 8kB of XRAM but doesn't have a unified bus, and while it's got a bunch of 16-bit ALU extensions they're all implemented via SFRs. So I think we're getting closer, but are still unfortunately cigarless.

I wonder whether this is a batch of failed chips which have been sold off cheap for use in toys?

[PCB.Wiz]

I wonder whether this is a batch of failed chips which have been sold off cheap for use in toys?

Maybe.
Another angle is sometimes a customer is large enough to dictate features and the chip exists because of them.
The IC vendor is then allowed to sell the part on the open market after some time delay, and often with not all features documented. That keeps the edge for the original customer and covers the risk for the IC vendor.

... The GPM8F3496A has 12kB of XRAM, which makes it very plausible, but there's no documentation available and it's weirdly high-end for such a trivial application (like, it's got USB support).

The incremental cost of USB support is not great, and it can give a useful upgrade and late-change pathway for expanded products.

The STC 8051 parts also have some form of what I'd call 'quasi USB support', where they have a ROM loader that can use USB in software as a low cost ISP pathway.
Like the AVR SW USB efforts, it likely does not pass full USB specs, but is 'workable enough' for programming use.  That makes it a clever solution.

[amyk]

GeneralPlus (and its parent/??? company SunPlus) definitely make more different parts than they publicly advertise. But that discovery with the nearly identical SPI flash format between the G+ chip and the COB is definitely progress, because it points to G+ being the MCU company. Following that lead, I found that Furbies use a GeneralPlus MCU too, and they can play audio encoded using something called the "GeneralPlus A1800 codec":

https://github.com/Jeija/bluefluff/blob/master/doc/dlcformat.md

From there is a link to a tool called "G+ Gadget" and the download is available on the GeneralPlus site, with description "With this gadget, users can easily make their SPI resources by automatic process, from audio converting to file packing" which sounds (no pun intended) a lot like what's happening here. Unfortunately it's a rather large download - 45MB - so perhaps I'll let someone else look into what it contains.

But looking further around those topics on the Internet I found a very old (expired), entirely-Chinese patent about audio encoding by Sunplus that also comes with source code(!):

https://patentimages.storage.googleapis.com/bd/b2/46/d4a799fa82ed8d/CN1867968B.pdf

[david.given]

Very nice --- thanks a lot! Although the patent PDF has no text layer, and OCR isn't having good luck with the font, so that's 83 pages of manual typing... I'll keep trying with the OCR. Unfortunately there's no license specified, unless it's in Chinese in the body text, so I probably can't upload it anywhere.

[amyk]

It's an expired patent, which means most likely it's in the public domain.

Besides, we're talking about the Chinese here...

[neil555]

Mine finally arrived from china and also had an unblobbed micro

The chip is branded JL and the part number is AB20CM9K17.1

I'll grab a photo later (tried on my iphone but the macro mode is awfull)

[david.given]

I'm still waiting for mine to show up. Apparently they're stuck in Swiss customs. Lucky Swiss customs.

[amyk]

Mine finally arrived from china and also had an unblobbed micro

The chip is branded JL and the part number is AB20CM9K17.1

I'll grab a photo later (tried on my iphone but the macro mode is awfull)

That's a very different part. The even more elusive company that made it is JieLi and I've done a little bit of digging on them before, but there's next to zero information about them: https://www.eevblog.com/forum/projects/datasheet-for-chinese-parts/msg2720674/#msg2720674

In other news, I did manage to download the whole "G+ Gadget" and there is about a dozen different audio codecs in it with names like A1800, A1600, A1601, etc; the audio files from Clive are unlikely to be A1800 (or possibly they have been obfuscated) but there's plenty of others to try. There are also some .S37 firmware with suggestive names like "PlayA1800FromSPIFlash.S37" but a quick search didn't match anything from the flash dump. I found a "CipherUtil.dll" which could have the relevant code.

[brucehoult]

Apparently their really low-end stuff use 6502 cores!

It should be the other way around, really!

If you squint right, the 8051 and 6502 are not all that different, except the 8051 has A plus 8 numbered registers while the 6502 has A, X, Y plus 256 registers.

If your algorithm can fit into 8 registers then 8051 code can be more compact because opcodes are generally just 1 byte (with only 3 bits needed to specify the register), but if it doesn't then the 6502 is instantly a lot easier to use. The 6502 is also easier if you have a lot of pointers or complex memory data structures.

[SiliconWizard]

If your algorithm can fit into 8 registers then 8051 code can be more compact because opcodes are generally just 1 byte (with only 3 bits needed to specify the register), but if it doesn't then the 6502 is instantly a lot easier to use. The 6502 is also easier if you have a lot of pointers or complex memory data structures.

I've never actually programmed for a 6502, but I have for 8051 cores, and I can confirm those are annoying and inefficient for memory access in general.

[brucehoult]

If your algorithm can fit into 8 registers then 8051 code can be more compact because opcodes are generally just 1 byte (with only 3 bits needed to specify the register), but if it doesn't then the 6502 is instantly a lot easier to use. The 6502 is also easier if you have a lot of pointers or complex memory data structures.

I've never actually programmed for a 6502, but I have for 8051 cores, and I can confirm those are annoying and inefficient for memory access in general.

Yeah, as I understand it, access to the full external RAM is available only with MOVX @DPTR (internal RAM locations 82H & 83H) to and from A.

For accessing the full 64k of RAM 6502 has:

$nnnn     absolute
$nnnn,X  absolute indexed (8 bit index register)
$nnnn,Y
($nn,X)   index X modifies which Zero Page pair is used to hold the pointer
($nn),Y   index Y is added to the address held in the Zero Page pair

So you effectively have up to 128 ZP pairs that each work like @DPTR. And you can do an offset from that address (incrementing correctly to the next memory page if required)

And if you actually know the address in advance, you don't have to set up a DPTR at all, even if you want to index from that known location.

Note that these addressing modes are all available with LDA, STA, ADC, SBC, CMP, AND, EOR, ORA so you don't need MOV/MOVX instructions in addition to the arithmetic and the code expansion from longer opcodes isn't as bad as you might think.

The 8051 is pretty good if you only have a small amount of state to deal with.

[neil555]

Here's a PCB photo ...

[neil555]

This is a dump of the SPI flash

The SPI dump looks very similar to all the other dumps but i haven't tried to decode it yet.

No idea how to post the dump to the Reddit thread but if anyone else wants to then please do 

[david.given]

I did a compiler for the 6502 a while back (https://cowlark.com/cowgol/; it's a self-hosted strongly typed programming language designed to run on small machines. You can actually run the compiler itself on a 6502, if you're very patient). It definitely has some functionality holes, the biggest of which is the limited stack. Trying to manage a stack frame is awful and basically rules the architecture out for C-like languages. You're stuck with using stack and frame pointers in zero page, which makes adjusting them complex, or using the internal stack and TSX tricks, which limits you to 256 bytes as well as using up a precious register. Of course the 6502 was never designed for this and non-stack-frame languages work much better, such as Fortran (or Cowgol!).

I haven't worked with the 8051 in any great detail yet; this device has DPTR autoincrement/decrement that would make stacks easier. I'd like to do a Cowgol port but I'm still thinking about how best to make use of the internal RAM. At some point I suppose I'd better add address space support so I can have variables in internal RAM as well as external RAM.

[david.given]

Thanks! Yes, it's the same flash format as the GeneralPlus chip. I pushed your flash image through spritetm's bf-lfsr tool at https://github.com/Spritetm/unbuddha:

Code: [Select]

Found initial xor value of 0x7B, xor with 0x21 on carry^lfsr
Found lfsr keystream! 000000001BDBF9A9 Finding possible LFSR config...
Found lfsr keystream! FFFFFFFF9BDBF9A9 Finding possible LFSR config...
Found LFSR: initial state 0x1917, taps 0x7c07 (use args -x 0x7B -i 0x1917 -t 0x7C07 )
Found LFSR: initial state 0x2b39, taps 0x8408 (use args -x 0x7B
 -i 0x2B39 -t 0x8408 )
Checked all lfsr keystreams.

Your image has more code in it, with 54 different overlays, which very weird. Most of them are tiny. The application payload is very different, with the 0x1900 code jumping straight into overlay 0 at 0x2213. The init code's different too, although it uses the same memory clear routine as on the G+ device, including the extended instructions. It's clearly the same chip and development kit.

Code: [Select]

                             **************************************************************
                             *                          FUNCTION                          *
                             **************************************************************
                             undefined FUN_EXTMEM_2213()
             undefined         ACC:1          <RETURN>
                             FUN_EXTMEM_2213                                 XREF[1]:     EXTMEM:1900(c) 
     EXTMEM:2213 90 ff 06        MOV       DPTR,#0xff06
     EXTMEM:2216 74 1d           MOV       A,#0x1d
     EXTMEM:2218 f0              MOVX      @DPTR=>DAT_EXTMEM_ff06,A
     EXTMEM:2219 75 d0 00        MOV       PSW,#0x0
     EXTMEM:221c 75 81 00        MOV       SP,#0x0                                           = ??
     EXTMEM:221f 75 87 02        MOV       PCON,#0x2                                         = ??
     EXTMEM:2222 90 ff 06        MOV       DPTR,#0xff06
     EXTMEM:2225 74 1d           MOV       A,#0x1d
     EXTMEM:2227 f0              MOVX      @DPTR=>DAT_EXTMEM_ff06,A
     EXTMEM:2228 e4              CLR       A
     EXTMEM:2229 75 86 10        MOV       DPS,#0x10
     EXTMEM:222c 90 11 00        MOV       DPTR,#0x1100
     EXTMEM:222f 7a 00           MOV       R2,#0x0
     EXTMEM:2231 7b 19           MOV       R3,#0x19
                             LAB_EXTMEM_2233                                 XREF[1]:     EXTMEM:2241(j) 
     EXTMEM:2233 f0              MOVX      @DPTR=>DAT_EXTMEM_1100,A                          = ??
     EXTMEM:2234 f0              MOVX      @DPTR=>DAT_EXTMEM_1101,A                          = ??
     EXTMEM:2235 f0              MOVX      @DPTR=>DAT_EXTMEM_1102,A                          = ??
     EXTMEM:2236 f0              MOVX      @DPTR=>DAT_EXTMEM_1103,A                          = ??
     EXTMEM:2237 f0              MOVX      @DPTR=>DAT_EXTMEM_1104,A                          = ??
     EXTMEM:2238 f0              MOVX      @DPTR=>DAT_EXTMEM_1105,A                          = ??
     EXTMEM:2239 f0              MOVX      @DPTR=>DAT_EXTMEM_1106,A                          = ??
     EXTMEM:223a f0              MOVX      @DPTR=>DAT_EXTMEM_1107,A                          = ??
     EXTMEM:223b a8 82           MOV       R0,DPL
     EXTMEM:223d a9 83           MOV       R1,DPH
     EXTMEM:223f a5 61           SUB16     R0R1,R2R3
     EXTMEM:2241 30 d1 ef        JNB       UD,LAB_EXTMEM_2233                                = ??
     EXTMEM:2244 75 86 00        MOV       DPS,#0x0
     EXTMEM:2247 02 22 00        LJMP      FUN_EXTMEM_2200                                   undefined FUN_EXTMEM_2200()
                             -- Flow Override: CALL_RETURN (CALL_TERMINATOR)


[brucehoult]

I did a compiler for the 6502 a while back (https://cowlark.com/cowgol/; it's a self-hosted strongly typed programming language designed to run on small machines. You can actually run the compiler itself on a 6502, if you're very patient). It definitely has some functionality holes, the biggest of which is the limited stack. Trying to manage a stack frame is awful and basically rules the architecture out for C-like languages.

I don't think that's true.

Implementing C in a way that makes constant use of data in a stack frame is something that happens on machines that don't have many registers, such as PDP11 or 32 bit x86 (8 registers), or even VAX, 32 bit ARM or x86_64 (16 registers). A frame pointer is just a crutch for assembly language programmers so they don't have to manually keep track of constantly changing offsets to stack frame items in an environment where things are constantly being pushed and popped on the stack within a function. A compiler can easily keep track without a frame pointer.

On a machine with more registers -- for example all the RISC machines with 32 registers -- the usual thing is to decrement the stack pointer by 16 or 32 (etc) bytes as the first instruction in a function and save a few registers into that space. At the end of the function those same registers are reloaded from the stack frame and the stack pointer is incremented. In between, you usually don't touch the stack at *all* unless you've got some structs or arrays as local variables in the function. In that case you usually just make a pointer to them by adding an offset to the stack pointer and keep that pointer throughout the function and access them exactly the same as if they were on the heap or anywhere else.

The registers you're saving into the stack frame (callee-save registers) aren't all the registers the function touches. Most of the registers used in a function are just for temporary values that don't need to be preserved across calls to other functions. The saved registers are just to make space to store (typically) some of the arguments of the function and a loop counter or two and not very much else. It's typically 2 or 3 or 4 things.

The 6502 can effectively be used as a machine with *256* registers. As such, you should generate code for it like for a RISC, not like for a 386. Copy a few contiguous Zero Page locations to a stack frame at the start of a function and restore them at the end (both of which it makes sense to do using a helper function) and never touch the stack in between. Obviously you do want to use a couple of the ZP locations as a stack pointer for your C saved registers, not the hardware stack.

The 6502 has SO MANY registers that you can go further than a typical RISC machine and statically allocate different callee-save registers -- and main (non ZP) memory save slots for them -- for each function. If you can do whole-program analysis then you can find all the call chains. Functions A and B only need to have different register (and save space) allocations if there is a call chain from A to B or from B to A. Most programs won't have call chains deep enough to run out of 256 bytes of callee-save registers (or, say, 224 bytes if you reserve 32 bytes for temporary registers shared by all functions). You only need to copy Zero Page locations (and save space) to a real FIFO stack when recursion (or a call via a function pointer) actually happens, which is usually pretty rare.

[amyk]

Thanks! Yes, it's the same flash format as the GeneralPlus chip.

Are we sure about that? It seems like we have no definitive evidence, i.e. a flash dump from a device with a G+ logo, only some hypotheses which I think are being disproven with the fact that the above dump from a JL device matches the COB from Clive and the unmarked IC from Spritetm on Reddit. I suspect these similar ones with the 8051 are not G+ but JL.

[david.given]

Are we sure about that?

Actually, having gone back through the paper trail, no --- I conflated two devices together, and you're right, we don't have a flash dump from the G+ chip. Oops. I shouldn't post this stuff late at night. There is a flash dump from an unlabelled chip which contains a code-less payload, probably for a dedicated music player. The only dump with code in it from a labelled chip is a JL.

[amyk]

According to the Reddit thread it seems like Clive's device has the same JL chip, and more information has been uncovered about the .f1a audio format:

https://old.reddit.com/r/BigCliveDotCom/comments/pmt390/buddha_machine_teardown_with_flash_dump/hg3edlf/

Judging by the function names in those libs, I'm guessing it's very closely related to WMA, and thus is actually a more complex codec than initially thought (but perhaps not what Clive initially thought - MP3). That said, it may not be necessary to figure out the details of the format since there's also an encoder available in the SDK linked above - although it's also a lib presumably for the microcontroller to use. Either way, I don't think it'll be long before someone manages to put all of Clive's catchphrases (and his greatest hits) onto one of these devices.

[eb4fbz]

Maybe AD156AB. It might be the same as AD156A but in SOP-16 package.
Similar chip is used on the dancing cactus toys.

[amyk]

Also stumbled upon this site if you want more info on the elusive JieLi chips: https://kagaimiq.github.io/jielie/