Searching \ for 'PICMaster Ideas' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'PICMaster Ideas'.

Truncated match.
PICList Thread
'PICMaster Ideas'
1995\09\27@115219 by BBoles

flavicon
face
Hmmm...  Maybe take the MPSIM simulator and roll it underneath of the new fully
windows version of PICMaster software to create an integrated design environment
where emulation and simulation were interchangeable.  Would we do something like
that?
tick tock tick tock .....

______________________________ Reply Separator _________________________________
Subject: Re: What's happened?
Author:  Conny Andersson <spam_OUTy93conanTakeThisOuTspamISY.LIU.SE> at Internet_Exchange
Date:    9/27/95 9:40 AM

However, I can come up with one question:

  Microchip! Why don't you take the PicMaster software and make
  a hardware emulating add-on module so that all of us who can't
  afford a complete PicMaster system still can use the user friendly
  environment of the PicMaster software? (for free of course :-)  )

  (I really don't like the DOS-MPSIM software ... it's 1995 now!)

-------------------------
Conny Andersson / LiTH

1995\09\27@150417 by Conny Andersson

picon face
Brian wrote ... (and Andy wrote about MPLAB in another letter)

> Hmmm...  Maybe take the MPSIM simulator and roll it underneath of the new
fully
> windows version of PICMaster software to create an integrated design
environment
> where emulation and simulation were interchangeable.  Would we do something
like
> that?
> tick tock tick tock .....

You know what I meant ... combine MPSIM:s accuracy with Picmaster:s user
friendly interface.

I hear MPLAB does all this and also includes an editor too. That's nice.
How fast is the MPLAB simulator? instructions/second versus amount of screen
data to update
How are stimuli injected? Not via cryptic ascii files, I hope?
And finally, will MPLAB be affordable (as free as MPSIM)?
-------------------------
Conny Andersson / LiTH

1995\09\28@120230 by John Payson

flavicon
face
> I hear MPLAB does all this and also includes an editor too. That's nice.
> How fast is the MPLAB simulator? instructions/second versus amount of screen
>  data to update
> How are stimuli injected? Not via cryptic ascii files, I hope?
> And finally, will MPLAB be affordable (as free as MPSIM)?

I've been toying with the idea of doing an in-circuit close-to-real-time
simulator for the 16C5X.  I haven't decided, though, how I should handle
the I/O pins, the RTCC, or timing.  My thinking was that I could either
use the printer port for situations where port A was 4 bits input and port
B was 8 bits output or I could use an I/O card [PC bus].  For the RTCC, I
was thinking of either providing limitted emulation [e.g. software mode
only, and a few imperfections in the way it counts] or else using external
hardware.  For overall timing, I was thinking of [if I use a PC card] having
an 8-bit counter which would run at the clock rate.  Branches or istructions
which use I/O pins would synchronize to this clock.

To get good emulation speed, I would translate the entire PIC 16C5X program
into 80x86 code; given the Von Neuman architecture, it should be pretty easy
to produce an excellent translation that would run most instructions faster
on, e.g., a 486SX33, than even a 20MHz 5X; the only slow instructions would
be computed jumps, USEFSR accesses, and possibly port/timer accesses.

What do y'all think of that for an idea?

1995\09\28@134010 by Robin Abbott

flavicon
face
> I've been toying with the idea of doing an in-circuit close-to-real-tim=
e
> simulator for the 16C5X.  I haven't decided, though, how I should handl=
e
> the I/O pins, the RTCC, or timing.  My thinking was that I could either
> use the printer port for situations where port A was 4 bits input and =
port
> B was 8 bits output or I could use an I/O card [PC bus].  For the RTCC,=
I
> was thinking of either providing limitted emulation [e.g. software mode
> only, and a few imperfections in the way it counts] or else using exter=
nal
> hardware.  For overall timing, I was thinking of [if I use a PC card] =
having
> an 8-bit counter which would run at the clock rate.  Branches or istruc=
tions
> which use I/O pins would synchronize to this clock.
>
> To get good emulation speed, I would translate the entire PIC 16C5X pro=
gram
> into 80x86 code; given the Von Neuman architecture, it should be pretty=
easy
> to produce an excellent translation that would run most instructions =
faster
> on, e.g., a 486SX33, than even a 20MHz 5X; the only slow instructions =
would
> be computed jumps, USEFSR accesses, and possibly port/timer accesses.
>
> What do y'all think of that for an idea?
>
I do like the idea of a cheaper emulation and I've also been thinking of =
real
time emulation without getting a second mortgage! However any scheme with=

translation to the 86 instruction set suffers from non-real time operatio=
n
(faster or slower is a problem), and serial routines, synchronous transfe=
r and
timers get shot, which kills dead most of my applications. I did think =
of ways
round that but then PC interrupts get in the way (try running under W95!)=
. Also
I'm not sure that instructions like BTFSC will translate to even a 586 =
in
anything like real time, that RISC register file is too damn fast!

I thought a scheme I would like to look at further would be translation =
to the
17C42 which is a code superset of the 5X/6X etc. This has the advantage =
of 1 to
1 clock conversion, the code can be loaded in to RAM, and you can play =
some
tricks with address decoding to write to any number of extra ports (C,D,E=
).
This requires a totally new symbolic assembler (well I'll just dig out =
the old
Z80 assembler I wrote years ago....) to perform address translation and =
some
PDC handling of FSR, but I think it should be possible !

Incidentally anyone know how Microchip do it in their ICE? is it hardware=

emulation or (as I suspect) a special version of the PIC which is presuma=
bly
not available world wide.....

Robin Abbott

.....robin.abbottKILLspamspam@spam@dial.pipex.com

1995\09\28@145431 by John Payson

flavicon
face
> I've been toying with the idea of doing an in-circuit close-to-real-time
> simulator for the 16C5X.  I haven't decided, though, how I should handle
> the I/O pins, the RTCC, or timing.  My thinking was that I could either
> use the printer port for situations where port A was 4 bits input and port
> B was 8 bits output or I could use an I/O card [PC bus].  For the RTCC,I
> was thinking of either providing limitted emulation [e.g. software mode
> only, and a few imperfections in the way it counts] or else using external
> hardware.  For overall timing, I was thinking of [if I use a PC card] having
> an 8-bit counter which would run at the clock rate.  Branches or istructions
> which use I/O pins would synchronize to this clock.
>
> To get good emulation speed, I would translate the entire PIC 16C5X program
> into 80x86 code; given the Von Neuman architecture, it should be prettyeasy
> to produce an excellent translation that would run most instructions faster
> on, e.g., a 486SX33, than even a 20MHz 5X; the only slow instructions would
> be computed jumps, USEFSR accesses, and possibly port/timer accesses.
>
> What do y'all think of that for an idea?
>
|I do like the idea of a cheaper emulation and I've also been thinking of real
|time emulation without getting a second mortgage! However any scheme with
|translation to the 86 instruction set suffers from non-real time operation
|(faster or slower is a problem), and serial routines, synchronous transfer
|and timers get shot, which kills dead most of my applications. I did think of
|ways round that but then PC interrupts get in the way (try running under
|W95!).  Also I'm not sure that instructions like BTFSC will translate to even
|a 586 in anything like real time, that RISC register file is too damn fast!

For timing, I was thinking an 8-bit counter driven by the PIC "clock input"
or a crystal oscillator would be the way to go; any jumps or I/O instructions
would wait for this timer to reach an appropriate value [so the code sequence

movwf  PA
nop
nop
movfw  PB

would be translated

       mov dl,pa_loc
       in  al,dx
       mov bl,al

       add ah,4
       mov dl,time_loc
lp:
       in  al,dx
       cmp ah,al
       jnz lp

       mov al,bl
       mov dl,pa_loc
       out dx,al

if the I/O is port-mapped or as

       mov al,[es:pa_loc]
       add ah,4
lp:
       cmp ah,[es:time_loc]
       jnz lp

       mov [es:pa_loc],al

if the I/O is memory mapped]

As for BTFSC, that would translate just fine for anything but USEFSR; the
most likely translation would be:

       mov bh,[f_reg]
       bit bh,bit_num
       jz  next_statement

The only annoying case would have to be translated as:

       call [usefsr_fetch]
       bit  bh,bit_num
       jz   next_statement

with usefsr_fetch being a pointer to a routine to load the currently-
selected address.

|I thought a scheme I would like to look at further would be translation to the
|17C42 which is a code superset of the 5X/6X etc. This has the advantage of 1
|to 1 clock conversion, the code can be loaded in to RAM, and you can play some
|tricks with address decoding to write to any number of extra ports (C,D,E).
|This requires a totally new symbolic assembler (well I'll just dig out the old
|Z80 assembler I wrote years ago....) to perform address translation and some
|PDC handling of FSR, but I think it should be possible !

This could be a little bit tricky, as I don't think all the opcodes are
available for a perfect 1-1 translation.  With the 80486, the CPU would be
fast enough that loss of a cycle here and there shouldn't matter because
the CPU should be able to catch up.  For simulating machines up to about
10MHz or so, though, your approach might work if you add external clock-sync
hardware.

|Incidentally anyone know how Microchip do it in their ICE? is it hardware
|emulation or (as I suspect) a special version of the PIC which is presumably
|not available world wide.....

|Robin Abbott

PS: Please watch your formatting; you had long line breaks rather excessively.

1995\09\28@163634 by BBoles

flavicon
face
    Robin Abbott asked..

    Incidentally anyone know how Microchip do it in their ICE? is it
    hardware emulation or (as I suspect) a special version of the PIC
    which is presumably not available world wide.....
    ------------------------------------------

    Yes, it is done with a special bondout version of the PIC which is not
    commercially available except to 3rd party emulator vendors.

    Rgds, Brian.

1995\09\30@033500 by Conny Andersson

flavicon
picon face
John wrote ...

> I've been toying with the idea of doing an in-circuit close-to-real-time
> simulator for the 16C5X.  I haven't decided, though, how I should handle
> the I/O pins, the RTCC, or timing.  My thinking was that I could either
> use the printer port for situations where port A was 4 bits input and port
> B was 8 bits output or I could use an I/O card [PC bus].

-- snip -- snip --

> What do y'all think of that for an idea?

Good idea, on newer PC:s the printer port can be set to some kind of
special, fast mode (ECP/EPP). I don't know how it works but I guess
you can set some/all pins as inputs and outputs. If this special
mode is fast > 8MHz this approach would kill all competitive PC-card based
emulators at least if you look at the price ... just a short printer
cable and some sort of connection to your "protoboard", a few dollars
I guess :-).

- Conny

1995\09\30@164437 by Jim Scorse

picon face
In a message dated 95-09-30 03:37:40 EDT, you write:

> If this special
>mode is fast > 8MHz this approach would kill all competitive PC-card based
>emulators at least if you look at the price ... just a short printer
>cable and some sort of connection to your "protoboard", a few dollars
>I guess :-).
>
>

The EPP is spec'ed at 1.5 MHz MAX.  I don't believe that anyone has yet to
achieve this data rate on a production basis.  Most of the parallel port hard
drive backups that use EPP run somewhere between 800 and 1200 kilobytes per
second.

More... (looser matching)
- Last day of these posts
- In 1995 , 1996 only
- Today
- New search...