8052 emulator in C

On 25/05/11 23:09, Chris H wrote:
> In message<1ZGdndkNyORi8UDQnZ2dnUVZ7rOdnZ2d@lyse.net>, David Brown
> <david.brown@removethis.hesbynett.no>  writes
>> On 25/05/11 21:16, D Yuniskis wrote:
>>> Hi David,
>>>
>>> On 5/25/2011 11:14 AM, David Brown wrote:
>>>> On 24/05/11 10:11, joolzg wrote:
>>>>> Anybody got a simple 8052 emulator in C source, im trying to reverse
>>>>> engineer
>>>>> some code and would like to emulate/simulate the code to get a better
>>>>> understanding as it looks like it was written in C and compiled by a
>>>>> very bad compiler
>>>>
>>>> It shouldn't be too hard to write a simulator yourself for a processor
>>>> like this. It's quite an effort if you want it to be fast, or to
>>>> accurately simulate interrupts and peripherals, but the core itself is
>>>> easy - you have an array to hold "ram", and array for "flash", a struct
>>>> holding the registers, and a huge switch statement interpreting each
>>>> instruction.
>>>
>>> You know, given the OP's apparent need to modify "whatever" to
>>> accommodate the peculiarities of his situation, this is probably
>>> the *best* (quickest to having something "useful") answer!
>>>
>>> Even IRQs and peripherals could be hacked in -- if you *don't*
>>> need it to be fast!
>>>
>>> it would be a great "school project" to show how a processor works
>>> and how to write "boilerplate" code (to implement the machine).
>>
>> Actually, fast run-time is not /that/ hard either - you just have to
>> separate the "interpret" phase from the "run" phase, and have the
>> "interpret" phase generate C code equivalent to the disassembly (i.e.,
>> when you see an instruction "add a, b", you write out the line "regs.a
>> += regs.b".  The joy is getting the flag registers right, and perhaps
>> the timing, and including some way for interrupts to jump in.  In the
>> end, you have a humongous C function with a few lines per original
>> disassembly line.  Run that through your host compiler, and your 8052
>> runs at a few hundred MIPS.
>
> AFAIR the ADuC84* is not a standard 8052 core and neither are the
> peripherals or memory map.
>

This would make the idea of writing a simulator himself more appealing - 
it doesn't matter how standard or non-standard it is, as long as it is 
documented.

In message <irk4e6$h4$1@dont-email.me>, hamilton <hamilton@nothere.com>
writes
>On 5/25/2011 3:09 PM, Chris H wrote:
>>
>> AFAIR the ADuC84* is not a standard 8052 core and neither are the
>> peripherals or memory map.
>>
>
>I understand extra peripheral registers added by a vendor to there 8052
>core, but the base core registers should be the same, no?
>
>hamilton

There is a bit more to it than that.  For a start it is not a standard
8052 core and it is a single cycle core which will make all the timing
very different. A simulator is not real time but it does have to
synchronise all parts of the simulation.

Also the simulation of the peripherals will take some doing.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <QuSdndUzPIYGckDQnZ2dnUVZ8v6dnZ2d@lyse.net>, David Brown
<david.brown@removethis.hesbynett.no> writes
>This would make the idea of writing a simulator himself more appealing
>- it doesn't matter how standard or non-standard it is, as long as it
>is documented.

The idea ay be appealing bit if the OP has a job to do why waste so much
time and resources re-inventing the wheel?

There is a very good 8051 sim available that is supported by AD that
will simulate the part very well (that has a serial window) and well
documented interfaces that permit adding to the peripheral support.



-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In reply to "Anders.Montonen@kapsi.spam.stop.fi.invalid" who wrote the 
following:

> joolzg <joolzg@btinternet.com> wrote:
> > In reply to "Anders.Montonen@kapsi.spam.stop.fi.invalid" who wrote the
> > following:
> > > joolzg <joolzg@btinternet.com> wrote:
> > > > Anybody got a simple 8052 emulator in C source, im trying to reverse
> > > > engineer some code and would like to emulate/simulate the code to get
> > > > better understanding as it looks like  it was written in C and compiled
> > > > by a very bad compiler
> > > There's the Daniel's s51 simulator[1] which is used in the SDCC[2]
> > > debugger.
> > > [1] <http://mazsola.iit.uni-miskolc.hu/~drdani/embedded/ucsim/
> > > [2] <http://sdcc.sourceforge.net/
> > thanks but its in delphi, pascal so would have to learn pascal again to do 
> > my
> > mods
> 
> The DOS version was written in Pascal, the Unix version is written in C++
> as you would have noticed if you'd downloaded the source code.
> 
> -a

Sorry had a quick look and delphi was mentioned, i went back and downloaded the 
source, also found a couple more on the web and ended up using ucsim

joolz



-- 
--------------------------------- --- -- -
Posted with NewsLeecher v5.0 Beta 6
Web @ http://www.newsleecher.com/?usenet
------------------- ----- ---- -- -

In reply to "Chris H" who wrote the following:

> In message <4ddcbb4c$0$1469$c3e8da3$fb483528@news.astraweb.com>, joolzg
> <joolzg@btinternet.com> writes
> > In reply to "Chris H" who wrote the following:
> > 
> > > In message <4ddb6833$0$1509$c3e8da3$efbdef2c@news.astraweb.com>, joolzg
> > > <joolzg@btinternet.com> writes
> > > > Anybody got a simple 8052 emulator in C source, im trying to reverse
> > > > engineer
> > > > some code and would like to emulate/simulate the code to get a better
> > > > understanding as it looks like  it was written in C and compiled by a 
> > > > very
> > > > bad
> > > > compiler
> > > 
> > > What is the target MCU?  The 51 family is huge (over 600 variants) and
> > > whilst the cores are similar there are some big differences.
> > > 
> > Analog Devices ADuC84x
> 
> This is NOT a true 8051/52 core.  Read the documentation it is "based
> on" an 8052.  Not all they 8051 simulators will handle the non standard
> 8051 parts like this one.
> 
> > > Why do you want the source of the simulator?
> > > 
> > So i can add in a serial driver, also the output display, you know make the
> > simulator behave like the real thing with inputs and outputs
> 
> Then use the Keil Simulator that can do this already.
> 
> 
> > > How do you know the binary was written in C?
> > I can tell from the way the code is written!! cant you tell the differnece
> > between human and machine created code
> 
> Yes... However you can not tell which HLL was used.
> 
> > > How big is the binary?
> > 64k but not all used
> 
> > > What is it supposed to do?
> > cant say
> 
> Use the Keil Sumulator.
> 
> --
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
> \/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Hence the reason for wanting source so i can modify it to take in the special 
features of the chip and also the interfaces.

Ive got ucsim running now under command line and i am now optimising the code, 
need more speed and adding in things like serial in/out and the interface 
devices.

thanks for the help

joolz



-- 
--------------------------------- --- -- -

In reply to "Walter Banks" who wrote the following:

> joolzg wrote:
> 
> > In reply to "Chris H" who wrote the following:
> > 
> > > In message <4ddb6833$0$1509$c3e8da3$efbdef2c@news.astraweb.com>, joolzg
> > > <joolzg@btinternet.com> writes
> > > > Anybody got a simple 8052 emulator in C source, im trying to reverse
> > > > engineer
> > > > some code and would like to emulate/simulate the code to get a better
> > > > understanding as it looks like  it was written in C and compiled by a 
> > > > very
> > > > bad
> > > > compiler
> > > 
> > > What is the target MCU?  The 51 family is huge (over 600 variants) and
> > > whilst the cores are similar there are some big differences.
> > > 
> > Analog Devices ADuC84x
> > 
> > > Why do you want the source of the simulator?
> > > 
> > So i can add in a serial driver, also the output display, you know make the
> > simulator behave like the real thing with inputs and outputs
> > 
> > 
> > > How do you know the binary was written in C?
> > > 
> > I can tell from the way the code is written!! cant you tell the differnece
> > between human and machine created code
> > 
> > > How big is the binary?
> > > 
> > 64k but not all used
> > 
> > > What is it supposed to do?
> > > 
> > cant say
> 
> You are going to a lot of work to reverse engineer an application.
> Why is this needed?
> 
> w..

Bugs in code, no source code available any more, its a job for a friend and i 
have been doing this work as a job for over 20 years, my first was a 
re-assembler for the C64 for a games company i worked for.

I have lots of experience in this but just needed a 8052 sim.

last job was a ARM decoder and annotate so this little chip will be a lot 
easier.

joolz




-- 
--------------------------------- --- -- -

In reply to "David Brown" who wrote the following:

> On 24/05/11 10:11, joolzg wrote:
> > Anybody got a simple 8052 emulator in C source, im trying to reverse 
> > engineer
> > some code and would like to emulate/simulate the code to get a better
> > understanding as it looks like  it was written in C and compiled by a very 
> > bad
> > compiler
> > 
> > joolz
> > 
> 
> It shouldn't be too hard to write a simulator yourself for a processor
> like this.  It's quite an effort if you want it to be fast, or to
> accurately simulate interrupts and peripherals, but the core itself is
> easy - you have an array to hold "ram", and array for "flash", a struct
> holding the registers, and a huge switch statement interpreting each
> instruction.


Yep and then the debugging od the cpu to make sure it is correct, as this is an 
old processor i did think it would be easy to find a sim

as before i found ucsim so working on it now

joolz



-- 
--------------------------------- --- -- -
Posted with NewsLeecher v5.0 Beta 6
Web @ http://www.newsleecher.com/?usenet
------------------- ----- ---- -- -

In reply to "D Yuniskis" who wrote the following:

> On 5/25/2011 2:52 AM, upsidedown@downunder.com wrote:
> > > > > You don't what a emulator, you want a de-compiler or reverse compiler.
> > > > > 
> > > > > An emulator will just execute the binary code as the real hardware 
> > > > > would.
> > > > > 
> > > > > Using the binary to get the C back is impossible !!!!
> > > > 
> > > > Actually, for some simple-minded compilers, you can often reverse
> > > > engineer the code to get much of the "C" source (neglecting
> > > > variable names, some expressions, etc.). This is especially
> > > > true of old/early compilers that didn't do much optimization.
> > > 
> > > For years I have heard that story.
> > > 
> > > I have always asked to show me any links with the compiler in question,
> > > So I will ask if you have any links to this "simple compiler" 
> > > 
> > > I took a compiler class 30 years ago, and my professor at the time
> > > stated that it was not possible.
> > > With the better compiler available today it would be even more impossible.
> > 
> > I guess "simple compiler" refers to some 1970's compilers for PDP-11,
> > Intel Intellecs and Motorola Exorcisers.
> 
> In my case, these were PC based tools.  The only compilers I had
> access to on the MDS were silly things like PL/M (which, actually,
> was *an* improvement)
> 
> > Writing compilers for these platforms  was problematic due to the 64
> > KiB address space limit. Overlay loading helped a lot (each
> > compilation phase in a separately loaded overlay branch), but you
> > still had to reserve space for the symbol table, that had to be kept
> > constantly in memory. Overlay loading with floppies was also very
> > slow, thus, much optimization could not be done. For this reason,
> > getting assembly output from a compiler was not the standard
> > situation.
> 
> I think the problem from that timeframe (mid 80's, in my case)
> was a combination of things:
> - targets were pretty crippled.  They really weren't designed
>    with HLL's in mind (with the exception of the bigger 16/32
>    bit machines).  E.g., support for stack frames was tedious
>    at best.  And, even then, limited (e.g., "index registers"
>    with +- 128 byte offsets)
> - there were *lots* of different processor *families*.  6800/3/
>    6809, 68HC11, 8080/85/Z80/Z180, Z8000, 68000, 9900, 99000, 1802/5,
>    6502/816, 2650, 8x300, etc.  With no single market leader.  
>    "compiler vendor" was almost forced to try to address *all* of
>    these targets to increase the chance for a sale.  So, you ended up
>    with a core compiler and varying backends.
> - the PC was becoming a viable development platform (previously,
>    we used CP/M boxes or vendor supported "development systems").
>    So, you had lots of folks putting forth products to try to
>    sell to that "development system".  Almost all were "command line"
>    driven tools, no IDE's, etc.
> - users were anxious to get their hands on *anything* that could
>    expedite development.  ASM was just *painfully* slow for bigger
>    projects.
> - resources were starting to become affordable.  The $50 2KB EPROMs
>    were a thing of the past.  And, you could actually think of putting
>    more than a few *hundred* bytes of RAM into a system!
> 
> > I once wrote an object code disassembler for PDP-11. Compared to
> > ordinary disassemblers, the object code disassembler can also display
> > the global symbols defined in this module as well as displaying any
> > external function names (including library function names) in plain
> > text.
> 
> Cool!  From this, you could probably port to a 68K disassembler
> with little trouble.  Or even a 32K.
> 
> > I analyzed quite a few object codes generated by Fortran, Pascal and 
> > compilers and I was capable of detecting by "organic matching" how
> > each compiler will generate code. After this, it was quite easy to
> > reverse engineering some algorithms.
> 
> Exactly.  The compiler tends to do the same thing, the same way.
> It's hard for "hand-written" code to achieve that same level of
> discipline.
> 
> > These days with good compilers, it is much harder to reverse
> > engineering things based on purely the executable code.
> 
> Have you looked at some of the code compiled for PICs?

You missed one of my old favorite cpus, 6303 a 4bit processor, i wrote the 
firmware for a mouse on that.

Also ive just finished 3 projects on a PIC18f4550 and using the Hi-TECH PRO 
compiler, code is ok and runs

joolz



-- 
--------------------------------- --- -- -
Posted with NewsLeecher v5.0 Beta 6

In reply to "Chris H" who wrote the following:

> In message <irjg31$mee$1@speranza.aioe.org>, Anders.Montonen@kapsi.spam.
> stop.fi.invalid writes
> > Chris H <chris@phaedsys.org> wrote:
> > > In message <irhc0q$p5d$1@speranza.aioe.org>, Anders.Montonen@kapsi.spam.
> > > stop.fi.invalid writes
> > > > joolzg <joolzg@btinternet.com> wrote:
> > > > > Anybody got a simple 8052 emulator in C source, im trying to reverse
> > > > > engineer some code and would like to emulate/simulate the code to get 
> > > > > better understanding as it looks like  it was written in C and 
> > > > > compiled
> > > > > by a very bad compiler
> > > > There's the Daniel's s51 simulator[1] which is used in the SDCC[2]
> > > > debugger.
> > > I doubt it will work.
> > 
> > Of course you do.
> 
> I know what the SDCC does and I know what the ADuC84* is.
> 
> 
> --
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
> \/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Ok so can you simulate 3 I2C devices [secure eeprom, temp sensor and IR 
convertor], 1 spi flash, 3 serial ports and 4 ir led drivers, without writing 
any code?

joolz





-- 
--------------------------------- --- -- -
Posted with NewsLeecher v5.0 Beta 6
Web @ http://www.newsleecher.com/?usenet
------------------- ----- ---- -- -

In reply to "David Brown" who wrote the following:

> On 25/05/11 21:16, D Yuniskis wrote:
> > Hi David,
> > 
> > On 5/25/2011 11:14 AM, David Brown wrote:
> > > On 24/05/11 10:11, joolzg wrote:
> > > > Anybody got a simple 8052 emulator in C source, im trying to reverse
> > > > engineer
> > > > some code and would like to emulate/simulate the code to get a better
> > > > understanding as it looks like it was written in C and compiled by 
> > > > very bad compiler
> > > 
> > > It shouldn't be too hard to write a simulator yourself for a processor
> > > like this. It's quite an effort if you want it to be fast, or to
> > > accurately simulate interrupts and peripherals, but the core itself is
> > > easy - you have an array to hold "ram", and array for "flash", a struct
> > > holding the registers, and a huge switch statement interpreting each
> > > instruction.
> > 
> > You know, given the OP's apparent need to modify "whatever" to
> > accommodate the peculiarities of his situation, this is probably
> > the *best* (quickest to having something "useful") answer!
> > 
> > Even IRQs and peripherals could be hacked in -- if you *don't*
> > need it to be fast!
> > 
> > it would be a great "school project" to show how a processor works
> > and how to write "boilerplate" code (to implement the machine).
> 
> Actually, fast run-time is not /that/ hard either - you just have to
> separate the "interpret" phase from the "run" phase, and have the
> "interpret" phase generate C code equivalent to the disassembly (i.e.,
> when you see an instruction "add a, b", you write out the line "regs.a
> += regs.b".  The joy is getting the flag registers right, and perhaps
> the timing, and including some way for interrupts to jump in.  In the
> end, you have a humongous C function with a few lines per original
> disassembly line.  Run that through your host compiler, and your 8052
> runs at a few hundred MIPS.

I did a 6805 to pic conversion the exact same way, had a bit include file for 
#define for all the instructions, my only sticking point was the interrupt 
driver was cycle based for writing data to another device so that had to be hand 
written to get it cycle exact, but it ran so everybody was happy and their asm 
old 6850 was not running on a pic in c

joolz



--