From: si...@caleddon.jasmine.org.uk (Simon Brooke)
Subject: Mindstorms RCX: limits of programability?
Date: 1998/10/05
Message-ID: <6vbfti$pdr@caleddon.jasmine.org.uk>#1/1
X-Deja-AN: 398139412
Content-Type: text/plain; charset=us-ascii
X-Trace: 6 Oct 1998 04:10:57 -0100, 194.112.53.99
Organization: none. Disorganisation: total
Mime-Version: 1.0
Newsgroups: rec.toys.lego

OK, I admit it, this line of thought started with a tantrum at how bad
the programming interface to the RCX was. I went over and read Kekoa's
pages on the RCX internals, and saw that the damn thing has 32K of
RAM, of which 16K is apparently free for user programs, data and
stack. Which is to say, more than a BBC Micro had in hires graphics
mode, and when you think of the sophisticated programming people did
on *that*...

Furthermore, the other 16K is the 'firmware' which you download when
you start the thing up first time. Now, if you use that firmware and
the RCX programming interface, you get to use precisely nine
subroutines, and no subroutine can call another. On the other hand,
you get high level interfaces to the sensor and motor control ports.

But judging by the datasheet at

http://semiconductor.hitachi.com/products/h_micon/3_h8300/l_h8300l/
H3LTP001D1/html/h3lp1frm.cfm

the H8 has all it takes in the way of registers and instructions to be
a perfectly general eight bit processor. It has eight general purpose
16 bit registers, of which one is reserved as a stack pointer, and
each of which can be addressed as two eight bit registers; in addition
there's a 16 bit program counter and an eight bit flag register. There
are also 'port control registers', but I'm not yet clear whether I
understand what these are about.

It has a rich instruction set with all the basic stuff like subroutine
handling, stack management, conditional branching, exception handling,
logic and arithmetic. It has an exceptionally rich set of shift and
bit manipulation instructions.

In other words, it looks very like (a bit more sophisticated than) a
6502 or Z80 such as we used in the personal computers of twenty years
ago. 

Now: the core RCX software is not in ROM, it's the famous
firmware. What I'm musing about is how easy it would be to write
complete replacement firmware, supporting much richer user programs on
the RCX. As a comparison, when the BBC micro was in common use, you
could get complete interpreters for LOGO, LISP, FORTH and a number of
other high-level languages each on a single 16K ROM chip. Of course,
the people who wrote these things were *seriously* good, and my memory
of writing complex assembly language programs is that it was *masses*
of grief. But wait! According to

http://www.halsp.hitachi.com/h8edk/

they've got a back-end for the GNU C compiler to the H8... I've even
found a page on cross compiling to H8 on a Linux x86 box, but it's in
Japanese which I don't read:

http://www.aim.ilc.or.jp/~yasui/micro_mouse/h8/GCC-Cross.html

So, in short, it seems to be a practical possibility to propose to
develop a replacement firmware system which would allow software to be
written for the RCX in a high level language. My personal preference
would be for a small LISP interpreter, but I'd be equally happy to
work on any other feasible high level language (I'm assuming that a
by-product of this project would be that we would learn, and could
document, how to develop software for the RCX in C). What this is all
building up to is, would anybody else be interested in taking part in
a project of this kind?

Cheers

Simon


PS: Finally, there's a Hitachi Europe page with all sorts of stuff in
Adobe PDF format, including a note on the 'H8/300 Serial Communication
Interface' which may possibly be useful to people writing IR
transmitter drivers.

http://www.hitachi-eu.com/hel/ecg/products/micro/h83297.htm

-- 
si...@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GP/CS s++: a+ C+++ UL++++$ UB+ UV++ UX-- L++ P--- E+ W+++ N++ K w-- 
M-- PS++ PE-- Y+ PGP t? 5? X? !R b+++ DI? D G- e++ h*(-) d-- r++ y+++
------END GEEK CODE BLOCK------

From: ke...@pixel.Stanford.EDU (Kekoa Proudfoot)
Subject: Re: Mindstorms RCX: limits of programability?
Date: 1998/10/06
Message-ID: <6vdomt$f1f@pixel.Stanford.EDU>#1/1
X-Deja-AN: 398357627
References: <6vbfti$pdr@caleddon.jasmine.org.uk>
Organization: Stanford University, CA 94305, USA
Newsgroups: rec.toys.lego

Simon Brooke <si...@caleddon.jasmine.org.uk> wrote:
> So, in short, it seems to be a practical possibility to propose to
> develop a replacement firmware system which would allow software to be
> written for the RCX in a high level language.

So the subject of your post was "Mindstorms RCX: limits of
programmability?"  In my opinion, the RCX is very flexible in terms of how
it can be programmed once you jump to native H8 code.  Like you seem to
say, you can do a lot with 32K of RAM and an 8-bit processor.  Certainly,
all the questions haven't been answered yet, and I don't think anyone has
written any interesting replacement firmware to date, but all of that is on
the very near horizon.  Enough is known about the RCX that very flexible
replacement firmware is definitely possible.

By far the biggest limitation of the RCX is not how programmable it is, it
is the number of input and output ports.  Having only three of each is the
real limitation.

-Kekoa

From: "Ralph Hempel" <CanTh...@StopSpam.com>
Subject: Re: Mindstorms RCX: limits of programability?
Date: 1998/10/06
Message-ID: <907703259.123211@Virginia.BMTS.Com>#1/1
X-Deja-AN: 398376681
Cache-Post-Path: Virginia.BMTS.Com!unk...@ts2-ap23.bmts.com
References: <6vbfti$pdr@caleddon.jasmine.org.uk> <6vdomt$f1f@pixel.Stanford.EDU>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-Trace: news3.ispnews.com 907703437 204.191.100.12 (Tue, 06 Oct 1998 15:50:37 EDT)
Organization: Bruce Municipal Telephone System
NNTP-Posting-Date: Tue, 06 Oct 1998 15:50:37 EDT
Newsgroups: rec.toys.lego



Kekoa Proudfoot wrote in message <6vdomt$f...@pixel.Stanford.EDU>...
>
>By far the biggest limitation of the RCX is not how programmable it is, it
>is the number of input and output ports.  Having only three of each is the
>real limitation.
>
>-Kekoa
>

How many IOs would you like to see? Is there enough of a market
for real embedded programming to be done?

Most of us (me included) have all of the blocks and motors that
come with the RCX. What would you pay for a controller with 4
each IOs? How easy would you like it to be programmable?

Is a byte code OK? Would you like FORTH, a C compiler? I still
firmly beleive that buying is better, but for 100 controllers, I
could probably sell them for $100 US. Of course there is no box
for it :-(

Sorry if this is unclear, but I'm interested in finding out if
the RCX folks have had their appetites whetted, and would like to see
more complex controllers. Or would the two RCX combination work?

Questions, questions. Ideas or comments anyone....?

Cheers,

Ralph Hempel - P.Eng

------------------------------------------------------
The train stops at the train station,
The bus stops at the bus station,
So why am I sitting at a work station?
------------------------------------------------------
Reply to:      rhempel at bmts dot com
------------------------------------------------------

From: ke...@pixel.Stanford.EDU (Kekoa Proudfoot)
Subject: Re: Mindstorms RCX: limits of programability?
Date: 1998/10/06
Message-ID: <6veub9$k50@pixel.Stanford.EDU>#1/1
X-Deja-AN: 398539274
References: <6vbfti$pdr@caleddon.jasmine.org.uk> 
<6vdomt$f1f@pixel.Stanford.EDU> <907703259.123211@Virginia.BMTS.Com>
Organization: Stanford University, CA 94305, USA
Newsgroups: rec.toys.lego

Ralph Hempel <CanTh...@StopSpam.com> wrote:
> Kekoa Proudfoot wrote in message <6vdomt$f...@pixel.Stanford.EDU>...
> >
> >By far the biggest limitation of the RCX is not how programmable it is, it
> >is the number of input and output ports.  Having only three of each is the
> >real limitation.
> 
> How many IOs would you like to see? Is there enough of a market
> for real embedded programming to be done?

Three is enough for me, but (say) six of each would allow for much cooler
robots.  But like I said, three is fine - if you aren't limited by
something, there's no challenge.

My point wasn't to argue for more I/O ports, although more would definitely
be nice.

Regarding programmability, I don't think anything needs to be added to what
comes out of the box - aside from some tools that will undoubtedly appear,
for free, in the near future.  Replacement firmware is less than a few
weeks away as far as I'm concerned; beyond that I don't really care about
the specifics.  A C compiler for writing new firmware would be nice.  I'm
pretty sure we'll see one of those.

The current set of tools, like NQC, are great too - except for the fact
that the byte code itself is crippled because it only has 32 variables -
and they're global ones at that.

-Kekoa