On Thu, 29 Aug 2002, Michael Rigby-Jones wrote:

> > -----Original Message-----
> > From: Bob Ammerman [SMTP:rammerman@ADELPHIA.NET]
> > Sent: Thursday, August 29, 2002 3:49 PM
> > To:   PICLIST@MITVMA.MIT.EDU
> > Subject:      Re: [PIC]: The PICLIST Development Project: Concession
> > Speech
> >
> > Java is certainly the way for this!
> >
> > Bob Ammerman
> > RAm Systems
> >
> Ugh.  Have you seen HiTechs new IDE "HiTide" ?  It looks very pretty, has a
> potentialy fantastic simulator built in and is all written in Java.  Shame
> it runs at the speed of a drugged snail when you try to simulate anything
> with peripherals.

I haven't seen it, but I've seen similar fiascos. OTOH, when done
properly, Java can be fast.

>
> I'm sure I have seen an MPASM compatible assembler written in Java somewhere
> on the web, (apart from the very nice miSim at
> http://www.feertech.com/misim/index.html which is a commercial package).

This started as an "open source" project and then changed over at some
point to commercial. BTW, this will not happen with gpasm or gpsim. Their
license specific precludes this.

> However, there already exists a 100% MPASM compatible, open source assembler
> in the shape of GPASM which has been ported to Win32 IIRC.

True. AFAIK, The only thing gpasm lacks at the moment is the banksel
macro.

> Porting GPSIM to Windows would be more usefull activity IMHO (although a
> fair amount of effort I suspect).

Someone did this a couple of years ago already. The issue is not gpsim per
se, but with gpsim's dependencies. For example, 2 years ago GTK on Windows
was very flaky. I don't know if that's changed or not.

BTW, gpsim is approaching a 100k lines of code. That's a lot of code to
port to another language! If you want to leverage off gpsim's speed and
maturity then the best way would be to interface to it through the
methods I described earlier.

Scott

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads