Author Topic: What's this 8051 clone?  (Read 2709 times)

0 Members and 1 Guest are viewing this topic.

Offline neil555

  • Contributor
  • Posts: 31
  • Country: gb
Re: What's this 8051 clone?
« Reply #25 on: October 03, 2021, 05:42:56 am »
Here's a PCB photo ...
« Last Edit: October 03, 2021, 05:44:39 am by neil555 »
 

Offline neil555

  • Contributor
  • Posts: 31
  • Country: gb
Re: What's this 8051 clone?
« Reply #26 on: October 03, 2021, 05:45:52 am »
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  :)
 

Offline david.given

  • Contributor
  • Posts: 19
  • Country: ch
Re: What's this 8051 clone?
« Reply #27 on: October 03, 2021, 10:44:10 am »
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.
 

Offline david.given

  • Contributor
  • Posts: 19
  • Country: ch
Re: What's this 8051 clone?
« Reply #28 on: October 03, 2021, 11:07:35 am »
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)
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 2575
  • Country: nz
  • Formerly SiFive, Samsung R&D
Re: What's this 8051 clone?
« Reply #29 on: October 03, 2021, 10:42:02 pm »
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.
 
The following users thanked this post: I wanted a rude username

Offline amyk

  • Super Contributor
  • ***
  • Posts: 7693
Re: What's this 8051 clone?
« Reply #30 on: October 04, 2021, 01:55:00 am »
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.
 

Offline david.given

  • Contributor
  • Posts: 19
  • Country: ch
Re: What's this 8051 clone?
« Reply #31 on: October 04, 2021, 11:42:44 am »
Quote
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.
« Last Edit: October 04, 2021, 11:45:13 am by david.given »
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 7693
Re: What's this 8051 clone?
« Reply #32 on: October 11, 2021, 05:12:48 am »
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. :D
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf