8052 emulator in C

On 2011-05-27, Chris H <chris@phaedsys.org> wrote:
> In message <vuftt6hluba3rp9f9bi40b7t98lo1jbpva@4ax.com>, George Neuner
>
>>But there isn't any need unless acquiring a existing simulator will
>>blow the budget.
>
> The entire Keil 8051 development suite costs less than a weeks work.
> You will not create a simulator including peripherals for an ADuC84*
> in that time. So the Keil simulator is very cost effective.

Often that depends on whether the tools budget and the time budget are
fungible.  I've worked plenty of places where that's not true.

-- 
Grant Edwards               grant.b.edwards        Yow! I brought my BOWLING
                                  at               BALL -- and some DRUGS!!
                              gmail.com            

Hi Grant,

On 5/27/2011 6:56 AM, Grant Edwards wrote:
> On 2011-05-27, Chris H<chris@phaedsys.org>  wrote:
>> In message<vuftt6hluba3rp9f9bi40b7t98lo1jbpva@4ax.com>, George Neuner
>>
>>> But there isn't any need unless acquiring a existing simulator will
>>> blow the budget.
>>
>> The entire Keil 8051 development suite costs less than a weeks work.
>> You will not create a simulator including peripherals for an ADuC84*
>> in that time. So the Keil simulator is very cost effective.
>
> Often that depends on whether the tools budget and the time budget are
> fungible.  I've worked plenty of places where that's not true.

Yes.  Where the hassle involved in getting approval of a few
kilobucks just isn't worth it!  "What the heck... let them spend
the dollars on my salary, instead.  It's *their* money.  If they
think this is the best way to spend it, <shrug>"

Or, where you expect to *go* with the tool after you have it.
E.g., if <vendor> stops supporting <tool> upon which a good
part of your business depends, you can find yourself SoL in
short order.

Or, if <vendor> doesn't want to add <feature> to <tool> (for
any "realistic" amount of money -- perhaps because he doesn't
want to assume the responsibility of supporting <feature>
in perpetuity) and that <feature> has some significant value
to you.

Lastly, having that IP has some intrinsic value.  E.g., when
putting your own core on an ASIC -- even *rolling* your own
core! -- is NoBigDeal, nowadays, being able to have a
simulator for *that* core available in short order can be
a real win.

It's also possible the OP hasn't made clear *all* of his/her
decision criteria...  ;-)

On Fri, 27 May 2011 09:08:53 +0100, Chris H <chris@phaedsys.org>
wrote:

>In message <vuftt6hluba3rp9f9bi40b7t98lo1jbpva@4ax.com>, George Neuner
><gneuner2@comcast.net> writes
>
>> Good simulators all are extensible so I/O and
>>non-standard devices can be emulated.
>
>There are few simulators of that calibre.  Added to which it is a 90%
>chance the original system was written using the Keil system.

Hmm.  I've worked with a number of simulators that were extensible.
One even had a scripting language but the others provided a C language
API for extending the model with dynamic libraries.

I will stipulate that these all were for (far) more modern chip
families.  I haven't worked much in very small systems and it's been
many years since last I used one of Kiel's simulators.

I would have thought they would be caught up, but perhaps not.
George

D Yuniskis  wrote:

>> (OK, for purists, the "return" instruction was an indirect jump
>> through the first word of the function, lets call it JUMPBACK for now)
>
>Like the PDP-8?

Precisely - That was a common approach at the time, used by PDP-8s,
Novas, HP-1000/2000s etc. I believe the same applies to IBM 360s.
--
Roberto Waltman

[ Please reply to the group,
  return address is invalid ]

On 28.5.11 10:11 , Roberto Waltman wrote:
> D Yuniskis  wrote:
>
>>> (OK, for purists, the "return" instruction was an indirect jump
>>> through the first word of the function, lets call it JUMPBACK for now)
>>
>> Like the PDP-8?
>
> Precisely - That was a common approach at the time, used by PDP-8s,
> Novas, HP-1000/2000s etc. I believe the same applies to IBM 360s.
> --
> Roberto Waltman
>

The IBM 360 and descendants put the return address into
a general register specified in the call (BAL or BALR).
The return is performed with a register-indirect branch.

-- 

Tauno Voipio