Russell McMahon wrote:

> - You can't do Peek & POKE AFAIK
> an unnecessary restriction due to ???

  I understood that you can do PEEK and POKE quite fine, they are
*called* "read" and "write".  That's part of how they cracked the token
code, write a program and get it to read itself out of memory onto a
serial line!

> You also can't get to internal RAM / registers to do anything that the
> language won't let you directly.

  Well, it gives access to the port registers, and the RAM is designated
as either W0 to W6 as 16-bit words, or B0 to B13 as bytes.  There's only
another 9 bytes of RAM plus FSR, STATUS and what-not which are obviously
used in the interpretive process so there would be no point in being
able to access them as the process of access would of course alter their
contents at every step of the program.

  And whether TMR0 is used or not, interpreter access is so slow it
would be pointless.

> Very cotton-woolish protection.

  I can't see any protection at all.  You can over-write program memory
quite easily.  Of course, you are almost certain to cause a crash, but,
no protection!

> You can't use interupts or the timer directly.

  The timer is as I say.  The lack of interrupts on the BS-1 is sheer
pragmatism - if you only have 14 bytes of user RAM to start with, how
many would you be prepared to forfeit for context saving in an
interrupt?  You must save Status and W, plus the state of the
interpreter while you interpret an alternative thread.  If the
interpreter *already* uses 9 variables, many of these would have to be
saved.

  However, to interpret an alternative thread from (external) EEPROM,
you have to complete a current read operation of an entire token, so you
can't just allow interrupts.  You would have to "virtualise" the
interrupt and even then, interpreting it would be far too slow to
service real interrupts.

  At best, an interrupt on a virtual timer, or virtualised port might be
possible.

  All these are implicit limitations of the interpretive process,
just the price you pay, especially as it involves IÓC reading of an
external EEPROM.  It's no fault though of lack of design innovation.
-- 
  Cheers,
        Paul B.