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