----- Original Message ----- 
From: "Paul Curtis" <plc@plc@...>
To: <msp430@msp4...>
Sent: Thursday, July 01, 2004 11:54 AM
Subject: RE: [msp430] Basic compiler


> Hi Leon,
>
> > The 6502 ran BASIC programs very fast, due to the zero-page
> > addressing mode,
> > IIRC. It wasn't much good at anything else, IMHO.
>
> Huh?  I don't think that's particularly nice, Leon.  The 6502 is
a
> fantastic machine, 128 16-bit pointers, what more can you ask for?  It
> didn't have many registers, but those 256 zero-page addresses are
very,
> very flexible.  The 6502 is a fantastic machine and still lives on.  Not
> a good target for a C compiler, but I wrote a whole two-pass assembler
> (from memory or disk to memory or disk) with on-screen editor, and much
> much more, in assembly code for the C64 and 3000-series Pets.

It was mainly the lack of registers that I didn't like about it, I've
never
actually programmed one. I was into Z80s and TI 9995s in those days,
followed by the 68000.

Leon

Hi Kris, 

> > LABEL is another keyword.  The interpeter
looks down the 
> linked list 
> > of line numbers, notes each line that starts with a LABEL and 
> > registers its address.  Then, GOSUB LABEL A is a cinch and 
> performed in constant time.
> > If the program were held in RAM, it's easy to fix things 
> up, but with 
> > the program in FLASH you really do need some extra help.  The LABEL 
> > concept certainly does help the interpreter and is a good 
> programmer 
> > aid.
> > 
> > Giving away all the secrets here, but I'm going to publish the 
> > interpreter at some point anyway.
> 
> Are you referring to Butterfly Basic here ?

Yep.  MSP430 only, of course, and integer only (although FP wouldn't be
had to do).

-- Paul.

I loved my beeb. By the time I finally stopped using it it had 80x86, 
6502 3MHz and Z80 coprocessors fitted, along with a shadow ROM expansion 
that took up to 64 ROMs. the whole thing just became a thoroughly 
customized beasty, much as I'd want from a decent PC, it ran home 
automation with a built in control language *dimlights (B,4,25) for 
example would give me 25% lighting level in bedroom 4. I'll never forget 
wondering how on earth I'd ever fill 1 100K floppy disk, let alone the 
pack of 5 I'd had to buy, oh well, those days are long gone, now I 
wonder if my 120G hard drive will hold the next version of windows

Al

Ian Okey wrote:

>>Take a leaf out of Atom Basic's book: 
> 
> 
> The guys at Acorn really produced some fantastic versions of BASIC. 
> Atom and the later BBC flavour were incredibly efficient and had some
> really neat extensions.  Considering that the BBC was a 2MHz 6502 it
> could knock spots off just about every other machine around at the
> time.  IIRC 10X faster than BASIC on an IBM-pc of a similar vintage.
>   
> Having a published OS interface and built in assembler (16K OS and 16K
> for the BASIC interpreter) it just went to prove what is possible in
> small processor environments.
> 
> Ian
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 

Now the Ti was surely a part only for the masochistic. I loved the 6502, 
but for some reason never really liked the Z80 much. I programmed a few, 
but preferred writing for the 6502 by a mile. Ah those wonderful days of 
self modifying code, goto's and not giving a stuff about politically 
correct programming fads.

Al

Leon Heller wrote:

> ----- Original Message ----- 
> From: "Paul Curtis" <plc@plc@...>
> To: <msp430@msp4...>
> Sent: Thursday, July 01, 2004 11:54 AM
> Subject: RE: [msp430] Basic compiler
> 
> 
> 
>>Hi Leon,
>>
>>
>>>The 6502 ran BASIC programs very fast, due to the zero-page
>>>addressing mode,
>>>IIRC. It wasn't much good at anything else, IMHO.
>>
>>Huh?  I don't think that's particularly nice, Leon.  The 6502
is a
>>fantastic machine, 128 16-bit pointers, what more can you ask for?  It
>>didn't have many registers, but those 256 zero-page addresses are
very,
>>very flexible.  The 6502 is a fantastic machine and still lives on.  Not
>>a good target for a C compiler, but I wrote a whole two-pass assembler
>>(from memory or disk to memory or disk) with on-screen editor, and much
>>much more, in assembly code for the C64 and 3000-series Pets.
> 
> 
> It was mainly the lack of registers that I didn't like about it,
I've never
> actually programmed one. I was into Z80s and TI 9995s in those days,
> followed by the 68000.
> 
> Leon
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 

----- Original Message ----- 
From: "onestone" <onestone@ones...>
To: <msp430@msp4...>
Sent: Thursday, July 01, 2004 6:06 PM
Subject: Re: [msp430] Basic compiler


> Now the Ti was surely a part only for the
masochistic. I loved the 6502,
> but for some reason never really liked the Z80 much. I programmed a few,
> but preferred writing for the 6502 by a mile. Ah those wonderful days of
> self modifying code, goto's and not giving a stuff about politically
> correct programming fads.

The 9995 and the other TI chips were very nice to program. The architecture
was the same as the TI minicomputer - 16-bits with hardware multiply and
divide and a large register file from which a working group of registers
could be selected (like the SPARC). We couldn't afford the official TI
development tools.so I wrote a cross-assembler for the 9995 using macros for
the MS Macro-80 assembler running on my Model I TRS-80.

Leon

I was at university in Cambridge at the time that the Beeb was
introduced.  I had serial number 1710.  Had to upgrade the OS to
version 1 so that I could fit the disc interface.  Then got hold of a
'sideways RAM' board from Watford Electronics so I could Swap
programming languages in and out without having to plug the ROMs in.

One of the first real applications I wrote was a database to manage
the ticketing and meal selections for the 1983 Robinson College May
ball.  Data entry forms, record sort and searces all done in BBC
BASIC.  All this in the 'spare' time when not counting the bricks in
the bar (sorry, a college 'in joke') or slaving away at lab write ups.

I don't know if you had a copy, but to my mind the bible for the BBC
micro was the Advanced User Guide.  This was written by an engineer, a
vet and a physicist (or some other form of what was caaled 'Natural
Science') that were there at the same time as me.

Ah memories.  Must be getting old.

Ian

On Fri, 02 Jul 2004 02:33:24 +0930, onestone
<onestone@ones...> wrote:
> 
> I loved my beeb. By the time I finally stopped using it it had 80x86,
> 6502 3MHz and Z80 coprocessors fitted, along with a shadow ROM expansion
> that took up to 64 ROMs. the whole thing just became a thoroughly
> customized beasty, much as I'd want from a decent PC, it ran home
> automation with a built in control language *dimlights (B,4,25) for
> example would give me 25% lighting level in bedroom 4. I'll never
forget
> wondering how on earth I'd ever fill 1 100K floppy disk, let alone the
> pack of 5 I'd had to buy, oh well, those days are long gone, now I
> wonder if my 120G hard drive will hold the next version of windows
> 
> Al
> 
> Ian Okey wrote:
> 
> >>Take a leaf out of Atom Basic's book:
> >
> >
> > The guys at Acorn really produced some fantastic versions of BASIC.
> > Atom and the later BBC flavour were incredibly efficient and had some
> > really neat extensions.  Considering that the BBC was a 2MHz 6502 it
> > could knock spots off just about every other machine around at the
> > time.  IIRC 10X faster than BASIC on an IBM-pc of a similar vintage.
> >
> > Having a published OS interface and built in assembler (16K OS and 16K
> > for the BASIC interpreter) it just went to prove what is possible in
> > small processor environments.
> >
> > Ian
> 
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> 
> 
> .
> 
> Yahoo! Groups Links
> 
> 
> 
> 
>

----- Original Message ----- 
From: "Ian Okey" <ian.okey@ian....>
To: <msp430@msp4...>
Sent: Friday, July 02, 2004 12:16 PM
Subject: Re: [msp430] Basic compiler


> I was at university in Cambridge at the time that
the Beeb was
> introduced.  I had serial number 1710.  Had to upgrade the OS to
> version 1 so that I could fit the disc interface.  Then got hold of a
> 'sideways RAM' board from Watford Electronics so I could Swap
> programming languages in and out without having to plug the ROMs in.
>
> One of the first real applications I wrote was a database to manage
> the ticketing and meal selections for the 1983 Robinson College May
> ball.  Data entry forms, record sort and searces all done in BBC
> BASIC.  All this in the 'spare' time when not counting the bricks
in
> the bar (sorry, a college 'in joke') or slaving away at lab write
ups.
>
> I don't know if you had a copy, but to my mind the bible for the BBC
> micro was the Advanced User Guide.  This was written by an engineer, a
> vet and a physicist (or some other form of what was caaled 'Natural
> Science') that were there at the same time as me.

Was one of that triumvirate Adrian Dickens? He had some involvement with the
Sinclair QL later and went on to form a company called Adder which is still
in existence, I think, making printer buffers and the like.

Leon

On Fri, 2 Jul 2004 12:37:54 +0100, Leon Heller
<leon.heller@leon...> wrote:
> 
> ----- Original Message -----
> From: "Ian Okey" <ian.okey@ian....>
> To: <msp430@msp4...>
> Sent: Friday, July 02, 2004 12:16 PM
> Subject: Re: [msp430] Basic compiler
> 
> > I was at university in Cambridge at the time that the Beeb was
> > introduced.  I had serial number 1710.  Had to upgrade the OS to
> > version 1 so that I could fit the disc interface.  Then got hold of a
> > 'sideways RAM' board from Watford Electronics so I could
Swap
> > programming languages in and out without having to plug the ROMs in.
> >
> > One of the first real applications I wrote was a database to manage
> > the ticketing and meal selections for the 1983 Robinson College May
> > ball.  Data entry forms, record sort and searces all done in BBC
> > BASIC.  All this in the 'spare' time when not counting the
bricks in
> > the bar (sorry, a college 'in joke') or slaving away at lab
write ups.
> >
> > I don't know if you had a copy, but to my mind the bible for the
BBC
> > micro was the Advanced User Guide.  This was written by an engineer, a
> > vet and a physicist (or some other form of what was caaled
'Natural
> > Science') that were there at the same time as me.
> 
> Was one of that triumvirate Adrian Dickens? He had some involvement with
the
> Sinclair QL later and went on to form a company called Adder which is still
> in existence, I think, making printer buffers and the like.
> 
> Leon
> 
> 

Indeed, Adrian was one of the three.  A fellow graduate of the 1984
EST (Electrical Sciences Tripos) course.

Ian

> I've only experienced two places in the micro world have I seen
and used
BASIC
> as a development for paying applications.  The
8051 BASIC and the market
that
> the BASIC Stamp from Parallax represents.  These
are, both of them,
proto-type
> quantities or one-off application spaces like
where the PC-104 marketplace
is
> sold into.  Laboratories, university classes,
home-brew robotics, and
custom
> software for very specialized applications are
homes to these.  These are
> essentially all small volume applications.  And it is having both the
hardware
> and integrated software that makes the development
and prototyping fast
and
> worthwhile.

Hi Jonathan,

Read you post with great interest, and I'd have to say I agree on all your
points.
In my opinion, the only way incremental development in Basic is truly
time saving and fast/efficient is when the interpreting/byte tokenising
is inside the machine IOW - NO compiling on a PC, it seems to void the
incremental advantage greatly IMHO.

PS : We're very close to releasing the first run of MSP430 with inbuilt
Basic interpeter and 900 MHz transparent RF networking thru Basic.
I'll announce when ready to go.
We'll release 3 starter kit / dev boards, they all take the RF OEM module.
Pics and info will be available soon.
The starter kits have I/O, power electronics/analog interface etc etc.

-- Kris

Hi Jonathan,

I'll have to be careful with what I discuss on the forum, case
delays are experienced again :-)
We can always discuss this further off the group.

> (3)  Floating point support?  If so, will you
include transcendentals, as well?
> How are they generated?  There are general approaches, which include angle
> rotation (CORDIC) or polynomial (Taylor's [bounds avg error with next
term],
> Chebyshev [bounds max error], etc.) and there are methods which also take
into
> account the imprecise calculations with imprecise constants and minimize
the
> maximum error over the range (including non-linear methods like minimax,
etc.)
> Just curious if you are doing any of this.

Everything is written in C, so I just use the included RTL support float wise.
the whole project's written on RAL's CW430.
The whole idea was to be able to freely port it around.
So far I've run it on MSP430, LPC2000 ARM, C8051 Cygnal (any 8051 really),
Zilog Z8Encore!, and a PC :-) need to try it on AVR.
I presume RAL's RTL uses Taylor Expansion for the RTL, so that's
something for
RAL :-)

RFBasic provides full float and integer support incl transcendentals. 
At this stage vars are a bit like resident vars, A-Z. (they are cleared at
startup though)
Using A% - Z% makes the interpeter use 32 bit signed integers to really speed up
FOR-NEXT loops etc.
As an idea, 100,000 iterations in a FOR-NEXT takes about 2 secs to complete with
integer,
about 6 secs with a float control var.
(On LPC2000 ARM it runs seriously fast at 60 MHz -)

> (1)  Do you require line numbers?  I recommend it,
as it removes the need for an
> adequate editor, which I imagine is a distraction.  Line numbers tell you
> whether or not something is being inserted, replaced, deleted, etc.  Works
well
> and is not inconsistent with BASIC.

Yeah, we're on the same page here :-)
Absence of line numbers calls for an editor which again blows the incremental
development advantage.
Editing is simply through an RS232 terminal, so you're OS independent.
Of course you can ASCII upload a Basic file.
Editing is done as you would with say, GW-Basic.

> (2)  Since the MSP430 does NOT have an external
memory interface (conflict with
> low power goals), are you entirely depending on the internal memory system?
 If
> so, how are you handling adding, deleting, replacing lines in flash? 
Further,
> how are you going to handle wear-leveling of the flash, if so.

I can't fully comment here :-)
I spent an enormous amount of time on Flash wear levelling.
I use a scheme that emulates EEPROM in baseline, but it requires 4 times more
Flash than what 
is actually needed. Each new entry in priciple is stored in the next rotating
sector.
There's also the option to add an external ultra high endurance EEPROM or
an
FRAM (SPI) for larger programs, up to 30 K.
In that case editing is done in that EEPROM space, and to run - the program is
first 
transferred to Flash.

Thanks to Paul for the inspiration (:-), the interpeter also first analyzes the
program
for structural loop integrity. It won't let you run a program if the loops
aren't closed properly.
eg
10  FOR .....
20 WHILE ....
30 NEXT....
40 WEND ....
 
Will give :
ERROR - NEXT at line # 30 mismatches WHILE at line # 20


> (5)  In the system I developed, each line had a
line number that was stored in
> binary (not ASCII) form and the keywords were tokenized.  

Same here.
Each line is a 16 bit binary number.
Even constants are stored straight in binary for maximum speed. The tokeniser
picks
the most suitable : an 8 bit, 16 bit or 32 bit literal.
I'd been tempted to use ASCII for this, but some late decisions made me
stay with
binary literals after all. This is a nightmare though, especially on ARM -
because
literals have to be padded on 4 byte boundaries. (I know Paul,  I shouldn't
:-)
To really make it fun, when the RF link carries literals around, they sometimes
need 
repadding on the fly.
(You can edit, debug, start/stop programs through the RF link BTW, you can
actually
even access any peripheral from any node to any node, that was one of the design
targets,
orthogonality)

> Also, statements
> referencing line numbers (such as GOTO 1000) had their line number
replaced, not
> with the binary number, but with a memory pointer to the line prefixed with
that
> line number.  

I've been very tempted to use a JUMP as well as a GOTO statement for
exactly that reason :-)
Line numbers are stored in binary for GOTOs, but not a pointer.
JUMP will do that later.
Alpha testers seemed to think that introducing JUMP would confuse users, and
that it's better
to stick to simplicity, also you can't forward reference then at edit time.
(ie. GOTO 1000 when 1000 doesn't exist yet)
Another reason is to only need a single linked list instead of a double one, and
to enable
the use of the REN (renumber) statement with single list.

Your idea is good though, using both. (line ptr + line num)
I might introduce that at some stage, that would indeed speed it up allright,
just the editing
would be complicated as above ?

> execution, this made the GOTO and IF very fast. 
Similarly, all variables were
> replaced with a pointer to their entry in a vartable.  Again, no searching,
just
> fast access to an entry that described the type and value and name (the
name
> wasn't used at run time but was there for listing purposes.)

A variable is flagged by its unique token. The following token is the offset of
the variable.
(float, integer, float array var, integer array var etc)
No searching, and name is irrelevant at runtime
This is to allow to introduce long alpha name vars later on.

> (4)  String support?

You know where it hurts ! :-)
A simple string support scheme is used for now that tries to avoid garbage
collection
issues. Full strings is for later, I don't expect users to need strings too
advanced
in the first generation on embedded systems.

> (6)  Will you support initialized constant arrays,
such as sine tables or CRC
> tables?  (Or, will it require a DIM plus some READ/DATA statements to set
up?)
> Or what?

Currently you have to use DIM and READ/DATA.
You can also use ON var GOTO .. , .. , .. ELSE ..  or 
ON var GOSUB .. , .. , .. ELSE of course but less efficient again.

I'd seriously consider introducing that later.
CRC stuff etc. isn't really needed at this stage because the RF/ network
operation
is truly transparent to the user.
Also the LET has to used as-is, because I don't want to loose 128 tokens
for extra
library functions later on.
You don't have to use LET though for assignment. The tokenizer analyses
your entry and
automatically inserts the LET keyword for the procedure call.
You can even use most loop constructs in immediate mode, as long as you use :
on a single line.
 
> Be interesting to see, Kris.  An MSP430 system
presents some interesting
> problems.

Sure does :-)
If you're interested in this, and play on ARM, I've got a HEX file
intended for LPC2000.
(Set up to run on LPC210X). It has most basics in there.
I'd make an MSP430 one available, but I don't know what format is
mostly used
for MSP430 programming.
(Program storage is restricted to RAM only as a demo)

B rgds
Kris