What's this 8051 clone? - Page 1
Forum section: electronics / general

author: david.given
author_rank: Contributor
timestamp: September 23, 2021, 01:36:48 pm
content: 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:CODE:2203 75 d0 00 MOV PSW,#0x0CODE:2206 75 81 00 MOV DAT_SFR_81,#0x0 = ??CODE:2209 75 87 02 MOV DAT_SFR_87,#0x2 = ??CODE:220c e4 CLR ACODE:220d 75 86 10 MOV DAT_SFR_86,#0x10 = ??CODE:2210 90 11 00 MOV DPTR,#0x1100CODE:2213 7a 00 MOV R2,#0x0CODE:2215 7b 19 MOV R3,#0x19LAB_CODE_2217 XREF: CODE:2225(j)CODE:2217 f0 MOVX @DPTR=>DAT_EXTMEM_1100,ACODE:2218 f0 MOVX @DPTR=>DAT_EXTMEM_1100,ACODE:2219 f0 MOVX @DPTR=>DAT_EXTMEM_1100,ACODE:221a f0 MOVX @DPTR=>DAT_EXTMEM_1100,ACODE:221b f0 MOVX @DPTR=>DAT_EXTMEM_1100,ACODE:221c f0 MOVX @DPTR=>DAT_EXTMEM_1100,ACODE:221d f0 MOVX @DPTR=>DAT_EXTMEM_1100,ACODE:221e f0 MOVX @DPTR=>DAT_EXTMEM_1100,ACODE:221f a8 82 MOV R0,DPLCODE:2221 a9 83 MOV R1,DPHCODE:2223 a5 61 CMP16 R0R1,R2R3CODE: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!

author: JoeyG
author_rank: Regular Contributor
timestamp: September 23, 2021, 01:55:46 pm
content: are you sure it's code and not non volatile data stored in flash

author: voltsandjolts
author_rank: Unknown
timestamp: September 23, 2021, 02:26:44 pm
content: ^^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)?

author: david.given
author_rank: Contributor
timestamp: September 23, 2021, 05:01:03 pm
content: 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?

author: amyk
author_rank: Super Contributor
timestamp: September 23, 2021, 06:03:00 pm
content: 80251?You mention "Buddha machines", is this related in any way?https://www.eevblog.com/forum/chat/big-clive-reverse-engineering-challenge/

author: david.given
author_rank: Contributor
timestamp: September 23, 2021, 06:19:17 pm
content: 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, butsomeonemust 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/

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 23, 2021, 10:09:56 pm
content: Quote from: david.given on September 23, 2021, 01:36:48 pmHow much XRAM is there ? What SysClk and clocks per opcode does it have ?Quote from: david.given on September 23, 2021, 06:19:17 pmYes, 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.

author: david.given
author_rank: Contributor
timestamp: September 23, 2021, 10:23:52 pm
content: Quote from: PCB.Wiz on September 23, 2021, 10:09:56 pmThe 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.QuoteNo 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 23, 2021, 10:55:40 pm
content: Quote from: david.given on September 23, 2021, 10:23:52 pmOnce 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.pdfAddit : 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 beto try to use existing tools, but cherry pick opcodes ?Is there list of the bytes following 0A5H in the dumps you have so far ?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 23, 2021, 11:17:11 pm
content: Quote from: david.given on September 23, 2021, 10:23:52 pmIt 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

author: amyk
author_rank: Super Contributor
timestamp: September 24, 2021, 12:24:59 am
content: Quote from: david.given on September 23, 2021, 06:19:17 pmWow! 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.

author: david.given
author_rank: Contributor
timestamp: September 24, 2021, 10:23:41 am
content: QuoteYup. 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.QuoteHere'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.asmQuoteI love the 8051 --- it's the Instruction Set That Will Not Die! Theentire worldruns 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.

author: david.given
author_rank: Contributor
timestamp: September 24, 2021, 10:17:27 pm
content: 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=330The chip is a 16-pin job with the following label:Code:IT80ZXDMAREF9001816

author: amyk
author_rank: Super Contributor
timestamp: September 25, 2021, 12:24:39 am
content: Quote from: david.given on September 24, 2021, 10:17:27 pmThat'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.)

author: david.given
author_rank: Contributor
timestamp: September 25, 2021, 09:48:12 am
content: 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 notthatbad; 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?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 25, 2021, 10:08:54 pm
content: Quote from: david.given on September 25, 2021, 09:48:12 amMaybe.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.Quote from: david.given on September 25, 2021, 09:48:12 amThe 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.

author: amyk
author_rank: Super Contributor
timestamp: September 26, 2021, 03:32:38 am
content: 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.mdFrom 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 easilymake their SPI resourcesby automatic process, fromaudio 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

author: david.given
author_rank: Contributor
timestamp: September 26, 2021, 11:19:02 am
content: 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.

author: amyk
author_rank: Super Contributor
timestamp: September 26, 2021, 11:38:48 pm
content: It's an expired patent, which means most likely it's in the public domain.Besides, we're talking about the Chinese here...

author: neil555
author_rank: Contributor
timestamp: October 02, 2021, 06:22:52 pm
content: Mine finally arrived from china and also had an unblobbed microThe chip is branded JL and the part number is AB20CM9K17.1I'll grab a photo later (tried on my iphone but the macro mode is awfull)

author: david.given
author_rank: Contributor
timestamp: October 02, 2021, 06:57:58 pm
content: I'm still waiting for mine to show up. Apparently they're stuck in Swiss customs. Lucky Swiss customs.

author: amyk
author_rank: Super Contributor
timestamp: October 02, 2021, 10:42:03 pm
content: Quote from: neil555 on October 02, 2021, 06:22:52 pmThat'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/#msg2720674In 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.

author: brucehoult
author_rank: Super Contributor
timestamp: October 02, 2021, 11:21:19 pm
content: Quote from: david.given on September 25, 2021, 09:48:12 amIt 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 02, 2021, 11:39:14 pm
content: Quote from: brucehoult on October 02, 2021, 11:21:19 pmI'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.

author: brucehoult
author_rank: Super Contributor
timestamp: October 03, 2021, 12:48:34 am
content: Quote from: SiliconWizard on October 02, 2021, 11:39:14 pmYeah, 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 pairSo 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.

author: neil555
author_rank: Contributor
timestamp: October 03, 2021, 05:42:56 am
content: Here's a PCB photo ...

author: neil555
author_rank: Contributor
timestamp: October 03, 2021, 05:45:52 am
content: This is a dump of the SPI flashThe 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

author: david.given
author_rank: Contributor
timestamp: October 03, 2021, 10:44:10 am
content: 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.

author: david.given
author_rank: Contributor
timestamp: October 03, 2021, 11:07:35 am
content: Thanks! Yes, it's the same flash format as the GeneralPlus chip. I pushed your flash image through spritetm's bf-lfsr tool athttps://github.com/Spritetm/unbuddha:Code:Found initial xor value of 0x7B, xor with 0x21 on carry^lfsrFound 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:*************************************************************** FUNCTION ***************************************************************undefined FUN_EXTMEM_2213()undefined ACC:1 <RETURN>FUN_EXTMEM_2213 XREF: EXTMEM:1900(c)EXTMEM:2213 90 ff 06 MOV DPTR,#0xff06EXTMEM:2216 74 1d MOV A,#0x1dEXTMEM:2218 f0 MOVX @DPTR=>DAT_EXTMEM_ff06,AEXTMEM:2219 75 d0 00 MOV PSW,#0x0EXTMEM:221c 75 81 00 MOV SP,#0x0 = ??EXTMEM:221f 75 87 02 MOV PCON,#0x2 = ??EXTMEM:2222 90 ff 06 MOV DPTR,#0xff06EXTMEM:2225 74 1d MOV A,#0x1dEXTMEM:2227 f0 MOVX @DPTR=>DAT_EXTMEM_ff06,AEXTMEM:2228 e4 CLR AEXTMEM:2229 75 86 10 MOV DPS,#0x10EXTMEM:222c 90 11 00 MOV DPTR,#0x1100EXTMEM:222f 7a 00 MOV R2,#0x0EXTMEM:2231 7b 19 MOV R3,#0x19LAB_EXTMEM_2233 XREF: 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,DPLEXTMEM:223d a9 83 MOV R1,DPHEXTMEM:223f a5 61 SUB16 R0R1,R2R3EXTMEM:2241 30 d1 ef JNB UD,LAB_EXTMEM_2233 = ??EXTMEM:2244 75 86 00 MOV DPS,#0x0EXTMEM:2247 02 22 00 LJMP FUN_EXTMEM_2200 undefined FUN_EXTMEM_2200()-- Flow Override: CALL_RETURN (CALL_TERMINATOR)

author: brucehoult
author_rank: Super Contributor
timestamp: October 03, 2021, 10:42:02 pm
content: Quote from: david.given on October 03, 2021, 10:44:10 amI 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.

author: amyk
author_rank: Super Contributor
timestamp: October 04, 2021, 01:55:00 am
content: Quote from: david.given on October 03, 2021, 11:07:35 amAre 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.

author: david.given
author_rank: Contributor
timestamp: October 04, 2021, 11:42:44 am
content: QuoteActually, 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.

author: amyk
author_rank: Super Contributor
timestamp: October 11, 2021, 05:12:48 am
content: 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 hisgreatesthits) onto one of these devices.

author: eb4fbz
author_rank: Regular Contributor
timestamp: October 19, 2024, 10:55:02 pm
content: Maybe AD156AB. It might be the same as AD156A but in SOP-16 package.Similar chip is used on the dancing cactus toys.

author: amyk
author_rank: Super Contributor
timestamp: November 16, 2024, 08:06:37 am
content: Also stumbled upon this site if you want more info on the elusive JieLi chips:https://kagaimiq.github.io/jielie/