Pocket Lisp Machine
in [Lisp]
|
From: Richard S. Hall on 26 Sep 2006 08:45 Both TI-89 and earlier Palm Models use 68000 (NOT 6800) processor (32-bit internal). Both are supported by a cross compile version of gcc which runs under Windows and creates 68000 code. There are some quirks to the TI-89 in that you have to a public key from TI to make applications that are bigger than 64K, no such restrictions exist in the case of Palm (newer Palms use ARM processor). This idea of Lisp on a TI-89 or Palm has occurred to me before although I've never got around to doing anything about, after all, the TI-89 is kinda Macsyma's grandson. I've used Lisp-Me on the Palm and its nice, although I prefer CL to Scheme. There used to be a public domain Lisp called XLISP which was a reasonable subset of CL, which was straight C with very little OS or Platform dependencies. I remember porting it to OS/2 circa 1990 (boy have things changed) in about an hour, only required modification of one source file and the makefile. Might be a good place to start. Of course if one is really ambitious you could try porting an emulator like usim or meroko, but this probably wouldn't be practical... -- Rick "GP lisper" <spambait(a)CloudDancer.com> wrote in message news:slrnehfgsn.7fo.spambait(a)phoenix.clouddancer.com... >I have an application that needs lisp and some stealth[1]. Recently > I've been looking at TI calculators, since they have some interesting > specs, in this case a 68000 processor, the same as in early Macs. > > http://en.wikipedia.org/wiki/TI-89_series > > Since I'm willing to trash all the calculator side in favor of getting > it back with lisp later, it may be possible to drop in a old pre-clos > small 68000 lisp with the on-board flash and RAM. I'd just need a > keyboard remapper and a video module from the original code. > > The purpose is to have handy access to a small database of some 3000 > rows by 15 columns, including various simple analysis programs. The > MySQL version of the database will probably end up at less than 400k. > I can think of a few tricks that will probably keep the database under > 100k in size. A development enviroment is not necessary on board the > calculator, some host computer can do all the grunt work. > > I don't have any knowledge of old mac lisps, so I'm looking for > pointers to those programs and general feasibility comments or > alternative suggestions! > > TIA > > > [1] No, not a student sneaking something into the exams, no matter how > many times Wikipedia mentions that. > > There is a wireless restriction, solutions such as an iPaq come with > built-in wireless. While it is possible to demonstrate that a > specific iPaq does not have wireless or that counter-measures disable > the wireless, the security beaucracy is a bit dense and > conservative. Calculators "obviously" do not have wireless, and have > very long runtimes on batteries. > > -- > Reply-To email is ignored. > > -- > Posted via a free Usenet account from http://www.teranews.com >
From: Ari Johnson on 26 Sep 2006 10:07 GP lisper <spambait(a)CloudDancer.com> writes: > On Tue, 26 Sep 2006 00:44:05 -0400, <iamtheari(a)gmail.com> wrote: >> GP lisper <spambait(a)CloudDancer.com> writes: >> I think the easiest thing to do here is build a runtime, gc, and >> image-loader in assembly and then define the Lisp you want to use. >> Once you have that Lisp defined, write the compiler for it in the same >> dialect, preferably a subset of Common Lisp or Scheme to ease >> cross-compilation in the bootstrapping process. Then write whatever >> functions you need in Lisp or assembly, depending on which is easier >> for each function. Pack them into an initial image and dump it to the >> calculator. > > Nooooo, that would create a 'development' environment on this limited > hardware and ignore that super-duper computer nearby. My purpose just > needs a 'runtime' environment, any code can be created on a nearly > dual-xeon system. A very calculator like problem is involved for a > limited deployment environment, however the code that runs daily will > probably not be the same as yesterdays code, so a smart lisp base > in the calculator seems perfect. So set your image-creator up to let you choose which pieces to send over to the calculator. > So the 'compiler' for it is totally external and can be common lisp, > with an output into something like clisp makes perhaps. As long as > the 'calculator program' primatives are supported on the Pocket Lisp > Machine, it should be fine and super-speed is not necessary, an answer > that takes a couple of minutes seems OK. So you are right, I need the > image-loader and a bootstrap permanently in the calculator plus a > basic BIOS, but the GC and runtime exist inside that externally > produced image. This is just like CP/M, you loaded the code at 100h, > jumped to it and the BDOS prayed it would 'return'. The problem is that you then need an interpreter on the calculator. I'm not convinced that a compiler has to be any bigger than an interpreter does. :) >> I'd be interested in helping out in such a project, if anyone >> undertook it. I do think that rolling your own Lisp is the quickest >> way to get what you want on the calculator. > > I agree that 'rolling your own' is the true path here and can see that > the problems seem doable within the above approach. > > But a 160x100 dot-matrix screen seems deathly small. That's about 5 > words per line, and 14 lines and 70 words per page. I'm used to 32 > words per line. You'll get over it. :)
From: GP lisper on 26 Sep 2006 13:47 On Tue, 26 Sep 2006 10:07:29 -0400, <iamtheari(a)gmail.com> wrote: > GP lisper <spambait(a)CloudDancer.com> writes: > >> But a 160x100 dot-matrix screen seems deathly small. That's about 5 >> words per line, and 14 lines and 70 words per page. I'm used to 32 >> words per line. > > You'll get over it. :) Well, it makes me think that the first place to start is with something that size and see if I do. Ltk and a tk-canvas I suppose. -- "People will not use Lisp to compete with us because they are lamebrains listening to the latest fashion statement from Sun or Microsoft." -- Richard Gabriel -- Posted via a free Usenet account from http://www.teranews.com
From: Richard S. Hall on 26 Sep 2006 14:34 You could always make it a small window scrolling into a bigger virtual window and have the ability to scroll around. I had to do this with usim on my 1024x768 laptop screen until there was a patch to change the screen size - set the display driver to 1280x1024 and scroll around within the 1024x768 physical screen. Not ideal, but better than being completely constrained by the hardware, and you do "get used to it". 160x100 is a pretty small window though, it would be more like looking through a keyhole... "GP lisper" <spambait(a)CloudDancer.com> wrote in message news:slrnehipt6.dth.spambait(a)phoenix.clouddancer.com... > On Tue, 26 Sep 2006 10:07:29 -0400, <iamtheari(a)gmail.com> wrote: >> GP lisper <spambait(a)CloudDancer.com> writes: >> >>> But a 160x100 dot-matrix screen seems deathly small. That's about 5 >>> words per line, and 14 lines and 70 words per page. I'm used to 32 >>> words per line. >> >> You'll get over it. :) > > Well, it makes me think that the first place to start is with > something that size and see if I do. Ltk and a tk-canvas I suppose. > > -- > "People will not use Lisp to compete with us because they are > lamebrains listening to the latest fashion statement from Sun or > Microsoft." -- Richard Gabriel > > -- > Posted via a free Usenet account from http://www.teranews.com >
From: nallen05 on 26 Sep 2006 16:08
> > but there are also much more mature c->6800 and c++->6800 compilers. > > Would it be easier to use figure out how to interact with the OS with > > thinlisp or ecl and compile the generated c to 6800 with a tried and > > true c->6800 compiler? > > C++ on 6800 that must be funny. With only 64KB adressable... > http://www.cpu-world.com/Arch/6800.html er... yeah, 68000 not 6800... Nick > > -- > __Pascal Bourguignon__ http://www.informatimago.com/ > > ATTENTION: Despite any other listing of product contents found > herein, the consumer is advised that, in actuality, this product > consists of 99.9999999999% empty space. |