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
GP lisper <········@CloudDancer.com> writes:
> 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.
I was working a bit on a Lisp for my TI-85 (z80-based) at one point or
another. The problem was that garbage collection is not as much fun
to do with a z80 as it might sound like. I don't have a TI-89, but I
think it might be less work to create a new, simple Lisp for it than
to port a Macintosh Lisp (which likely is 90% interface to the OS and
10% 68k code generation).
On Mon, 25 Sep 2006 12:26:39 -0400, <·········@gmail.com> wrote:
> GP lisper <········@CloudDancer.com> writes:
>
>> 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.
>
> I was working a bit on a Lisp for my TI-85 (z80-based) at one point or
> another. The problem was that garbage collection is not as much fun
> to do with a z80 as it might sound like. I don't have a TI-89, but I
> think it might be less work to create a new, simple Lisp for it than
> to port a Macintosh Lisp (which likely is 90% interface to the OS and
> 10% 68k code generation).
GUI overhead probably wouldn't be that bad, it would be sensible to
separate the GUI and lisp afterall. One of the things I do know about
early macs is that they did have a command-line if you knew the
tricks. I also vaguely remember some sort of lisp in those early
beasts. I agree that getting something non-Mac but 68000 would be
best, I just don't know where ancient software might be hidden
nowdays.
I though about the TI-85 too, since I was a pretty good CP/M and ZCPR3
hacker (some archives still have my 'make' for ZCPR3). Thanks for the
GC pointer there, the ebay price difference between these two models
doesn't seem enough to go back to 8 bits. There is a CP/M lisp
somewhat 'freely' available BTW and faking enough of the CP/M API to
get by is not that difficult.
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper wrote:
> I though about the TI-85 too, since I was a pretty good CP/M and ZCPR3
> hacker (some archives still have my 'make' for ZCPR3). Thanks for the
> GC pointer there, the ebay price difference between these two models
> doesn't seem enough to go back to 8 bits. There is a CP/M lisp
> somewhat 'freely' available BTW and faking enough of the CP/M API to
> get by is not that difficult.
Back in 1990 I designed a Z80 based Lisp calculator. The idea was to
run CP/M and then muLisp and muMath on top of that. Since this was a
commercial project licensing these three programs wouldn't have been a
problem. The project was cancelled when the person I was doing this for
decided his company wasn't up to the task of making a product "with so
many little buttons"...
http://www.derive-europe.com/theroots.asp?history
-- Jecel
GP lisper <········@CloudDancer.com> writes:
> On Mon, 25 Sep 2006 12:26:39 -0400, <·········@gmail.com> wrote:
>> GP lisper <········@CloudDancer.com> writes:
>>
>>> 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.
>>
>> I was working a bit on a Lisp for my TI-85 (z80-based) at one point or
>> another. The problem was that garbage collection is not as much fun
>> to do with a z80 as it might sound like. I don't have a TI-89, but I
>> think it might be less work to create a new, simple Lisp for it than
>> to port a Macintosh Lisp (which likely is 90% interface to the OS and
>> 10% 68k code generation).
>
> GUI overhead probably wouldn't be that bad, it would be sensible to
> separate the GUI and lisp afterall. One of the things I do know about
> early macs is that they did have a command-line if you knew the
> tricks. I also vaguely remember some sort of lisp in those early
> beasts. I agree that getting something non-Mac but 68000 would be
> best, I just don't know where ancient software might be hidden
> nowdays.
>
> I though about the TI-85 too, since I was a pretty good CP/M and ZCPR3
> hacker (some archives still have my 'make' for ZCPR3). Thanks for the
> GC pointer there, the ebay price difference between these two models
> doesn't seem enough to go back to 8 bits. There is a CP/M lisp
> somewhat 'freely' available BTW and faking enough of the CP/M API to
> get by is not that difficult.
I have someone's '8kLisp' for the Z80. It looked like too much work
to port to the TI-85.
If I were eBaying, I'd get the TI-89. I, however, own a TI-85 already
so I am naturally more prone to hack on the z80. That said, I did do
some work on a TI-89 Lisp over the summer. I wonder if I still have
it somewhere.
On Mon, 25 Sep 2006 18:13:50 -0400, <·········@gmail.com> wrote:
> GP lisper <········@CloudDancer.com> writes:
>
>> I though about the TI-85 too, since I was a pretty good CP/M and ZCPR3
>> hacker (some archives still have my 'make' for ZCPR3). Thanks for the
>> GC pointer there, the ebay price difference between these two models
>> doesn't seem enough to go back to 8 bits. There is a CP/M lisp
>> somewhat 'freely' available BTW and faking enough of the CP/M API to
>> get by is not that difficult.
>
> I have someone's '8kLisp' for the Z80. It looked like too much work
> to port to the TI-85.
CP/M API consisted of two pieces, a jump vector at absolute address
005h and a table of BIOS jump vectors in high memory (usually about 2k
below the top). OS calls went thru the 005h jump and only about 20
existed. The BIOS jump vectors matched the CP/M system calls to the
actual routines. There is sample and actual source code available
that isn't hard to understand for a decent Z80 programmer. Runtime
CP/M code was non-relocatable and expected to start at 100h.
You really only need some way to map into the 'file system' and the
video, most CP/M programs only used 3-5 system calls to accomplish
that. When I was looking at the TI-85, I saw that I could run CP/M
inside it pretty easily. You just need some chording method to map
the keys to 'qwerty'.
The gotcha in this idea is the 160x100 dot screen alas.
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper wrote:
> 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!
Coral Lisp was the ancestor of MCL/OpenMCL, and used to fit in a couple
of megabytes. But it had pretty strong integration with the mac. You
might want something like Cambridge Lisp (ran on the amiga as a
text-only app) instead. Or any of the lisps of that era that ran on
more-or-less stock 16-bit hardware. It sounds as if you probably have
the resources to cross-compile if it turns out to be useful.
On Mon, 25 Sep 2006 14:56:36 -0400, <··@panix.com> wrote:
> GP lisper wrote:
>> 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
>>
>> 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!
>
> Coral Lisp was the ancestor of MCL/OpenMCL, and used to fit in a couple
> of megabytes. But it had pretty strong integration with the mac. You
> might want something like Cambridge Lisp (ran on the amiga as a
> text-only app) instead. Or any of the lisps of that era that ran on
> more-or-less stock 16-bit hardware. It sounds as if you probably have
> the resources to cross-compile if it turns out to be useful.
Motorola 68000 is a 32 bit processor. Thanks for the 'Coral' and
'Cambridge' hints, googling them is looking interesting.
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper wrote:
> 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.
There is a basic scheme for ti-89
http://www.ticalc.org/archives/files/fileinfo/370/37098.html
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?
Nick
ps
this all sounds very shady ;-)
On 25 Sep 2006 16:00:03 -0700, <········@gmail.com> wrote:
> GP lisper wrote:
>
> 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?
I'd have to learn C, something I've successfully ducked for over a
decade, while Assembly is an old friend. In any case, I'd want some
source that had a small core in assembler, with everything else built
up from lisp. I can grab the lisp source pieces out of Codemist for
instance, and drop them on top of an assembler base.
> this all sounds very shady ;-)
Hey, that reminds me that maybe we should be announcing those Reno
Lisp Users meetings in this newsgroup, as some of the other westerners
(even the cold ones) have been doing.
The only thing that it's sounding to me is that of a long winters
project.
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper <········@CloudDancer.com> writes:
> On 25 Sep 2006 16:00:03 -0700, <········@gmail.com> wrote:
>> GP lisper wrote:
>>
>> 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?
>
> I'd have to learn C, something I've successfully ducked for over a
> decade, while Assembly is an old friend. In any case, I'd want some
> source that had a small core in assembler, with everything else built
> up from lisp. I can grab the lisp source pieces out of Codemist for
> instance, and drop them on top of an assembler base.
Don't be put off. C combines the power of assembly with the ease of
use of assembly. :P
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.
That was my plan, at least. And it would have worked perfectly if it
hadn't been for those darn meddling kids. I got as far as the runtime
and the beginning of the GC, including a calling convention. How far
I got depends whether you ask me about the TI-85 or TI-89. I wrote
some code for each toward the same goal.
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.
On Tue, 26 Sep 2006 00:44:05 -0400, <·········@gmail.com> wrote:
> GP lisper <········@CloudDancer.com> writes:
>>
>> I'd have to learn C, something I've successfully ducked for over a
>> decade, while Assembly is an old friend. In any case, I'd want some
>> source that had a small core in assembler, with everything else built
>> up from lisp. I can grab the lisp source pieces out of Codemist for
>> instance, and drop them on top of an assembler base.
>
> Don't be put off. C combines the power of assembly with the ease of
> use of assembly. :P
A->B->C, and that A stood for assembler in the true history of unix,
i.e. prior to "designed by computer scientists worrying about their
place in history". All the bit pushers I knew kept saying that their
macro libs were better than early Cs, and muttered about the slow and
bloated code they produced.
> 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 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'.
> 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.
--
"Because no one uses Lisp, I'll have my pick of thousands of great,
experienced programmers looking to work for someone with a non-zero IQ"
--Richard Gabriel
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper <········@CloudDancer.com> writes:
> On Tue, 26 Sep 2006 00:44:05 -0400, <·········@gmail.com> wrote:
>> GP lisper <········@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. :)
On Tue, 26 Sep 2006 10:07:29 -0400, <·········@gmail.com> wrote:
> GP lisper <········@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
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" <········@CloudDancer.com> wrote in message
····························@phoenix.clouddancer.com...
> On Tue, 26 Sep 2006 10:07:29 -0400, <·········@gmail.com> wrote:
>> GP lisper <········@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
>
On Tue, 26 Sep 2006 00:44:05 -0400, <·········@gmail.com> wrote:
>
> That was my plan, at least. And it would have worked perfectly if it
> hadn't been for those darn meddling kids. I got as far as the runtime
> and the beginning of the GC, including a calling convention. How far
> I got depends whether you ask me about the TI-85 or TI-89. I wrote
> some code for each toward the same goal.
I forgot to mention that you should see the Codemist source at
http://homepage.ntlworld.com/codemist/csl/index.html
Look in
ccl/src/cslbase/0notes
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
········@gmail.com writes:
> GP lisper wrote:
>> 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.
>
> There is a basic scheme for ti-89
>
> http://www.ticalc.org/archives/files/fileinfo/370/37098.html
>
> 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
--
__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.
> > 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.
On Tue, 26 Sep 2006 01:35:16 +0200, Pascal Bourguignon
<···@informatimago.com> wrote:
>········@gmail.com writes:
>
>> 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
Aztec had a good quality rommable code K&R C compiler for the 6502.
IIRC, it was based on a prior 6800 version.
George
--
for email reply remove "/" from address
George Neuner <·········@comcast.net> writes:
> On Tue, 26 Sep 2006 01:35:16 +0200, Pascal Bourguignon
> <···@informatimago.com> wrote:
>
>>········@gmail.com writes:
>>
>>> 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
>
> Aztec had a good quality rommable code K&R C compiler for the 6502.
> IIRC, it was based on a prior 6800 version.
Indeed, C is still routinely used on any microcontroler with slightly
more than 100 byte of RAM... But AFAIK, not C++.
I'm not saying either that it's totally impossible to write an
implementation of C++ running on a 8-bit processor with 64KB of
adressable space. But this sounds like a ludicruous effort.
Note that the gcc C++ compiler on 32-bit ix86, stripped, takes 3.6 MB.
--
__Pascal Bourguignon__ http://www.informatimago.com/
CAUTION: The mass of this product contains the energy equivalent of
85 million tons of TNT per net ounce of weight.
On Thu, 28 Sep 2006 00:56:07 +0200, Pascal Bourguignon
<···@informatimago.com> wrote:
>George Neuner <·········@comcast.net> writes:
>
>> On Tue, 26 Sep 2006 01:35:16 +0200, Pascal Bourguignon
>> <···@informatimago.com> wrote:
>>
>>>········@gmail.com writes:
>>>
>>>> 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
>>
>> Aztec had a good quality rommable code K&R C compiler for the 6502.
>> IIRC, it was based on a prior 6800 version.
>
>Indeed, C is still routinely used on any microcontroler with slightly
>more than 100 byte of RAM... But AFAIK, not C++.
>
>I'm not saying either that it's totally impossible to write an
>implementation of C++ running on a 8-bit processor with 64KB of
>adressable space. But this sounds like a ludicruous effort.
>Note that the gcc C++ compiler on 32-bit ix86, stripped, takes 3.6 MB.
Oops. I saw the multiple "c->6800" references and totally missed that
_you_ were talking about C++. Actually though, I think a reasonable,
albeit non-compliant, compiler could be done in 64K if you left out
template support and made judicious use of overlays. I don't know
whether it's worth having C++ on an 8-bit chip ... I have certainly
used it (cross-compiling and mostly as "better C" rather than
idiomatic C++) for embedded programming on a number of 16 bit chips.
It would certainly be a pain to use the compiler itself in 64K ... I
still have vivid memories of writing my first C programs with the
Aztec compiler on my Apple ][e with dual 140KB floppy drives. I had
an extended 64KB memory card which gave me an 80 column screen and a
~60KB ram disk. The native 6502 compiler was ~80KB and had to be disk
based, but Aztec also included a 34KB self-compiled bytecode compiler
which, along with the linker, could fit into the ram disk.
OTOH, I have eerily similar memories of writing my first PC programs
using Microsoft C on a 640KB machine with dual 360KB floppy drives.
Except in the PC case, the compiler took 2 (compiler) disk swaps per
source file and another disk swap to link and I couldn't load any of
it into a ram disk.
On the whole, the smaller Apple was easier to work with.
George
--
for email reply remove "/" from address
On Thu, 28 Sep 2006 00:55:38 -0400, <·········@comcast.net> wrote:
>
> OTOH, I have eerily similar memories of writing my first PC programs
> using Microsoft C on a 640KB machine with dual 360KB floppy drives.
> Except in the PC case, the compiler took 2 (compiler) disk swaps per
> source file and another disk swap to link and I couldn't load any of
> it into a ram disk.
You were getting killed by the floppies, 5in floppies were slow. I
ran this sort of stuff in a 1.2 meg ramdisk, mapped into the BIOS as a
disk drive...and it was 'Microsoft'.
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
George Neuner <·········@comcast.net> writes:
> Aztec had a good quality rommable code K&R C compiler for the 6502.
> IIRC, it was based on a prior 6800 version.
The 1979 August issue of Byte Magzine had an article on a Lisp
implementation for the 6800.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Petter Gustad <·············@gustad.com> writes:
> George Neuner <·········@comcast.net> writes:
>
>> Aztec had a good quality rommable code K&R C compiler for the 6502.
>> IIRC, it was based on a prior 6800 version.
>
> The 1979 August issue of Byte Magzine had an article on a Lisp
> implementation for the 6800.
Key word being "a". But indeed, if I had a lisp on my 6809 instead of
Pascal, I would probably have had more fun :-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
"Pascal Bourguignon" <···@informatimago.com> wrote in message
···················@thalassa.informatimago.com...
> Petter Gustad <·············@gustad.com> writes:
>
>> George Neuner <·········@comcast.net> writes:
>>
>>> Aztec had a good quality rommable code K&R C compiler for the 6502.
>>> IIRC, it was based on a prior 6800 version.
>>
>> The 1979 August issue of Byte Magzine had an article on a Lisp
>> implementation for the 6800.
>
> Key word being "a". But indeed, if I had a lisp on my 6809 instead of
> Pascal, I would probably have had more fun :-)
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> "Our users will know fear and cower before our software! Ship it!
> Ship it and let them flee like the dogs they are!"
Nothing like the "good 'ol days" of using Mark Williams C compiler to write
rommable Z80 code on Zenith Z100, then split into pieces to be put on 2716
(EPROM)s. The compiler was buggy, you had to check the assembly code: "int
x; x = 1;" worked fine, but "int x = 1;" would not complain in the compiler
but leave x uninitialized! There were other bugs too. Of course you could
connect the end result to a 300 baud modem and use ITS/MacLisp!.
Sorry if I sent to your email Pascal - hit wrong button meant to send to
group!
On 2006-09-25, GP lisper <········@CloudDancer.com> wrote:
> 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.
See also any non-wireless Palm, and "Lisp-Me" (actually Scheme). Also
the Linux-based Sharp Zaurus has a clisp binary for it somewhere.
-- L
Larry Clapp wrote:
> On 2006-09-25, GP lisper <········@CloudDancer.com> wrote:
> > I have an application that needs lisp and some stealth[1]. Recently
> > I've been looking at TI calculators, since they have some
> See also any non-wireless Palm, and "Lisp-Me" (actually Scheme). Also
> the Linux-based Sharp Zaurus has a clisp binary for it somewhere.
I concur. I've made quite a bit of use of lisp-me. Its pretty solid,
integrates well with the palm, and lets you have control of the
filesystem and serial ports as well! You'll want to get something like
pedit if you intend to write any code on the palm itself.
I've also used the Z, and its a pretty nice little box, I'd opt for one
of the clamshell models if you can afford it. The older style ones can
be had for next to nothing on ebay, and have a form factor quite
similar to the TI calcs. I don't really like the screen on the older
ones, it looks kinda hokey by todays standards.
On Mon, 25 Sep 2006 16:12:57 GMT, <·····@theclapp.org> wrote:
> On 2006-09-25, GP lisper <········@CloudDancer.com> wrote:
>> 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.
>
> See also any non-wireless Palm, and "Lisp-Me" (actually Scheme). Also
^
if I thought that I could teach others the differences
between wireless and non-wireless successfully, I'd use an iPaq.
> the Linux-based Sharp Zaurus has a clisp binary for it somewhere.
doesn't look like a calculator
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper wrote:
> 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.
>
Maybe I don't get it , but obvious choice would be a
linux capable pda.
DG
On Mon, 25 Sep 2006 20:01:18 +0300, <·········@midasitech.com> wrote:
> GP lisper wrote:
>>
>> 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.
>>
>
> Maybe I don't get it , but obvious choice would be a
> linux capable pda.
re-read "security beaucracy is a bit dense"
e.g., think about those airport inspectors
--
Reply-To email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
GP lisper wrote:
> 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.
At least get a decent machine:
http://www.shopping.hp.com/webapp/shopping/product_detail.do;jsessionid=FYaRX9nWabh2wBI1PycEjHtXhkLK3IE1n43HDU9JZVeZUU1oYKbG!1113141265?storeName=storefronts&landing=handhelds&category=calculators&orderflow=1&product_code=F2229AA%23ABA&catLevel=1
70MHz ARM7 CPU, 2.5 MB RAM, SD card slot, ... all for $150. And they
appear to have thrown in a decent keyboard to boot.
See comp.sys.hp48, http://www.hpcalc.org/, and http://hpgcc.org/
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" <········@CloudDancer.com> wrote in message
····························@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
>