[ANN] Pygmy Forth 1.7 (for DOS) released
Frank Sergeant
http://pygmy.utoh.org/forth.html
It runs under various versions of DOS, including a DOS box in any
version of Microsoft Windows and FreeDOS or other versions of DOS
under the DOS emulator (dosemu) on Linux.
It includes an assembler, screen editor and line editor, multitasker,
full source code and the ability to generate custom versions
(metacompiler), etc.
The license is BSD/MIT/X-style so you can use it freely. The shadow
blocks are now included in the main distribution as well as a 68HC11
cross assembler and my article on "A 3-Instruction Forth", manual,
tutorial, etc.
As always, comments, suggestions, and corrections are welcome.
--
Frank
fdub...@gmail.com
> As always, comments, suggestions, and corrections are welcome.
>
Yes, I got one: Pygmy is to me one of the Forth under DOS.
No, wait: it is currently the best because mine is temporarely
unavailable under DOS :)
Amicalement,
Astrobe
cy
<fr...@pygmy.utoh.org> wrote:
>A new version of Pygmy Forth for DOS, version 1.7, is now available at
>
> http://pygmy.utoh.org/forth.html
>
Hey great! Thanks.
I have often wondered, if any assembler source code is available?
I assume you have compiled each of the 1.n versions from a 1.n-1
version...back to the dawn of Pygmy? But, perhaps, the original
starting point is in X86 assembler and available?
SRB
jch
> A new version of Pygmy Forth for DOS, version 1.7, is now available at
>
> http://pygmy.utoh.org/forth.html
>
Good show.
What new and or modified words are available?
How do i reset the default colours to plain black background, and white
foreground?
--
Regards / JCH
Frank Sergeant
>> A new version of Pygmy Forth for DOS, version 1.7, is now available at
> Good show.
Thank you
> How do i reset the default colours to plain black background, and white
> foreground?
The variable ATTR controls this. It is set to $3F on block 98 (in
case you wish to metacompile a new version). White foreground and
black background would be $8F (see blocks 149 and 172 and 173).
--
Frank
Frank Sergeant
>>A new version of Pygmy Forth for DOS, version 1.7, is now available at
...
> I have often wondered, if any assembler source code is available?
Well, yes, I suppose the answer is yes. The source code for all the
primitives is present in the distribution. This is the source code
that is run when you metacompile a new version of Pygmy, by typing
1 LOAD
Some words are not primitives but are written in high-level Forth.
Some of this is also run when you metacompile a new version of Pygmy.
1 LOAD produces a new "kernel" which is a fully running Forth system
that can extend itself. Typically it is extended by starting the
kernel and typing
5 LOAD
> I assume you have compiled each of the 1.n versions from a 1.n-1
> version...back to the dawn of Pygmy?
Yes.
> But, perhaps, the original starting point is in X86 assembler
No, definitely not.
> available?
And thus no,
The starting point was probably my earlier PC Forth or possibly F83.
Those details are lost in the mists of time.
--
Frank
Frank Sergeant
> Yes, I got one: Pygmy is to me one of the Forth under DOS.
> No, wait: it is currently the best because mine is temporarely
> unavailable under DOS :)
Thank you.
--
Frank
jcomeau_ictx
> The license is BSD/MIT/X-style so you can use it freely. The shadow
> blocks are now included in the main distribution as well as a 68HC11
> cross assembler and my article on "A 3-Instruction Forth", manual,
> tutorial, etc.
> As always, comments, suggestions, and corrections are welcome.
Hi Frank, or any other riscy pygness user: I'm trying to get the ARM
version of Pygmy Forth running on an ARMmite, but am hampered my
several things including my ignorance of LISP. I get this far:
$ make combo.hex
clisp arm
loading LISP sources
loaded LISP sources
loading packages
loaded packages
(reset-forth)
(load-primitives)
(import-symbol-table)
(build-forth-word-lists)
processing raw label: (_etext . 0)
assigning label to address
assigned label to address
*** - <: NIL is not a real number
make: *** [combo.hex] Error 1
using sources patched for Cygwin and the GNU tools that come with the
Coridium download. Patch is at http://www.jcomeau.com/blog/riscy.patch
If someone could give me a kick in the right direction, I'd appreciate
it. Thanks -- jc
jcomeau_ictx
> On May 23, 1:45 pm, Frank Sergeant <f...@pygmy.utoh.org> wrote:
> > As always, comments, suggestions, and corrections are welcome.
> Hi Frank, or any other riscy pygness user: I'm trying to get the ARM
> version of Pygmy Forth running on an ARMmite, but am hampered my
> several things including my ignorance of LISP. I get this far:
> $ make combo.hex
>
> make: *** [combo.hex] Error 1
>
> using sources patched for Cygwin and the GNU tools that come with the
> Coridium download. Patch is at http://www.jcomeau.com/blog/riscy.patch
There were a whole bunch of problems, most of which were solved by
building on my Linux box then downloading to my laptop to program the
device. I now get a 'Hi' prompt but nothing else; my input seems to be
ignored. I'll follow up when I make some more progress -- jc
jcomeau_ictx
à
Hi
3 ok
4 ok
* ok
. 12 ok
OK, looks like it's going to be doable. One must set "char mode", and
set "newline" to "crlf" in TclTerm. Something is still screwy in the
baud rate, but I don't really know what I'm doing with VPBDIVISOR yet.
And it remains to be seen if 300 bytes of RAM is enough to do anything
with. I'll probably blog my progress as I have time -- jc
Frank Sergeant
> Hi Frank, or any other riscy pygness user: I'm trying to get the ARM
> version of Pygmy Forth running on an ARMmite, but am hampered my
> several things including my ignorance of LISP. I get this far:
...
I haven't used the ARMmite board but from their web site it looks like
their ARMmite Lite uses the LPC2103 ARM processor (with 32K Flash and
8K RAM).
> using sources patched for Cygwin and the GNU tools that come with the
> Coridium download. Patch is at http://www.jcomeau.com/blog/riscy.patch
Ok, I took a quick look at the patch. It looks like the main changes
were to put in print statements as progress markers, plus to change from
from the lpc2106.ld link script to an lpc2103.ld link script. This
latter is where the location of the RAM is specified, etc.
This value might be different from one ARM variant to another. So,
the link script and the riscy.S assembly source must agree on it. For
example, for the lpc2106 processor, riscy.S contains the following line
#define RAMBASE 0x40000200
(Clearly you have all this in agreement, I'm just making a note here
about it.)
> Hi
> 3 ok
> 4 ok
> * ok
> . 12 ok
Great. It looks like you got it working.
> OK, looks like it's going to be doable. One must set "char mode", and
> set "newline" to "crlf" in TclTerm.
That's under Windows, I guess. I've usually used the 'minicom'
terminal program under Linux.
> Something is still screwy in the
> baud rate,
Well, I don't think it can be too far off since what you type is
echo'd back correctly in the above example. Would it be worth trying
a different terminal program on Windows or trying minicom on Linux
(and or different baudrates) to see if that helps isolate the problem?
> but I don't really know what I'm doing with VPBDIVISOR yet.
There are several symbolic constants in the assembly source for
setting the timing information.
CCLK (crystal clock) is where you set the basic processor clock
speed (the crystal frequency), e.g.
.equ CCLK, 14745600 @ for a 14.7456 MHz crystal
or
.equ CCLK, 10000000 @ for a 10 MHz crystal
VPBDIVISOR (peripheral bus divisor) identifies the ratio between the
peripheral bus and the crystal. With a divisor of 1 the two clocks
are the same. With a divisor of 4, the peripheral bus clock is
1/4th the speed of the crystal clock, e.g.
.equ VPBDIVISOR, 4 @ ratio of processor clock to
@ peripheral clock -- must be 1, 2, or 4
From CCLK and VPBDIVISOR, the assembler calculates the PCLK (the
peripheral clock).
BAUDRATE is set to your desired serial rate, e.g.
.equ BAUDRATE, 115200
for 115,200 bps.
Then, from PCLK and BAUDRATE, the assembler can calculate the divisor
used to actually set the baudrate, e.g.
.equ DIVISOR, PCLK / (16 * BAUDRATE)
So, the point of it all is to let the assembler calculate as much as
possible so we have less editing to do when changing from one ARM
processor to another or from one crystal speed to another.
The datasheet for the LPC2106 or LPC2103 etc have lots of
information about the various timing issues.
> And it remains to be seen if 300 bytes of RAM is enough to do anything
> with. I'll probably blog my progress as I have time -- jc
I guess the 300 bytes is what's left of the 8K RAM after the various
tables allotted in RAM for interactive look up of dictionary additions
that go to RAM, block buffers, etc? I imagine some of those could be
made smaller.
Anyway, I believe the next version will go back to using a smart
terminal on the PC rather than just any serial terminal, and leave the
interactive lookups and dictionary heads to the smart terminal. (The
first version did it this way.) This should free up some Flash and
RAM.
I'm glad to hear of your success with Riscy Pygness on an LPC2103.
--
Frank
jcomeau_ictx
> jcomeau_ictx <john.com...@gmail.com> writes:
> > Hi Frank, or any other riscy pygness user: I'm trying to get the ARM
> > version of Pygmy Forth running on an ARMmite, but am hampered my
> > several things including my ignorance of LISP. I get this far:
> > ...
Hi Frank, thanks for responding. I was beginning to think I'm in
everybody's killfile... glad to see I've avoided yours so far!
> > Something is still screwy in the
> > baud rate,
>
> Well, I don't think it can be too far off since what you type is
> echo'd back correctly in the above example. Would it be worth trying
> a different terminal program on Windows or trying minicom on Linux
> (and or different baudrates) to see if that helps isolate the problem?
I've tried different ones, both in the sources and in the terminal
program. I get the best results with 115200 in the sources and 38400
in the terminal emulator, if that makes any sense. It sure doesn't to
me.
> There are several symbolic constants in the assembly source for
> setting the timing information.
> ...
> CCLK (crystal clock) is where you set the basic processor clock
> speed (the crystal frequency), e.g.
Everything I can find on the ARMmite says it's 60MHz. I can't see any
markings on the crystal, it's too small. Just ordered a 10x loupe on
eBay but it might take a few days.
I understand also, from what I've seen in documentation, that CCLK can
be a multiple of the crystal frequency. So I'm a bit confused about
that too.
>
> VPBDIVISOR (peripheral bus divisor) identifies the ratio between the
> peripheral bus and the crystal. With a divisor of 1 the two clocks
> are the same. With a divisor of 4, the peripheral bus clock is
> 1/4th the speed of the crystal clock, e.g.
>
> .equ VPBDIVISOR, 4 @ ratio of processor clock to
> @ peripheral clock -- must be 1, 2, or 4
I understand, but how do I know what that's set to on the ARMmite? Or
does your program set it to what I specify in the .equ statement?
What's happening now is that if I type 1-digit numbers or tokens such
as + on a single line, they are recognized fine. Anything over a
single character on a line is likely to be misread. So I obviously
don't have the baud rate correct yet.
And I'm curious: why do you specify "115200 BPS" in riscy.forth before
showing the "Hi" when the baud rate is already set in riscy.S?
> Anyway, I believe the next version will go back to using a smart
> terminal on the PC rather than just any serial terminal, and leave the
> interactive lookups and dictionary heads to the smart terminal. (The
> first version did it this way.) This should free up some Flash and
> RAM.
That might be good, but then again, having all the smarts onboard is
pretty cool too, and has distinct advantages for a standalone
development system, which is what I'd like to use this for. Although I
might need to upgrade to a 2106 dev board to make it practical.
> I'm glad to hear of your success with Riscy Pygness on an LPC2103.
Yeah, I'm happy to be making progress, but my ultraportable wearable
computer still seems a bit distant :^)
Thanks again, Frank! -- jc
Frank Sergeant
>> > Something is still screwy in the baud rate,
> I've tried different ones, both in the sources and in the terminal
> program. I get the best results with 115200 in the sources and 38400
> in the terminal emulator, if that makes any sense. It sure doesn't to
> me.
> Everything I can find on the ARMmite says it's 60MHz. I can't see
> any markings on the crystal, it's too small.
The crystal is most likely 14,745,600 Hz or 10,000,000 Hz or
12,000,000 Hz. (VPBDIVISOR must always be 4)
Try with each of these 3 sets of settings
.equ CCLK, 14745600 @ crystal speed
.equ VPBDIVISOR, 4 @ must be 4
.equ BAUDRATE, 115200
.equ CCLK, 10000000 @ crystal speed
.equ VPBDIVISOR, 4 @ must be 4
.equ BAUDRATE, 115200
.equ CCLK, 12000000 @ crystal speed
.equ VPBDIVISOR, 4 @ must be 4
.equ BAUDRATE, 115200
I guess you had set CCLK to 60000000 (i.e. 60 MHz)?
How do you program the Flash? Do you use the Martin Maurer
downloader? With a 14.7456 MHz crystal, I use this command
lpc21isp -bin combo.bin /dev/ttyS0 115200 14746
which specifies a serial rate of 115,200 bps and a crystal speed of
14,746 KHz (close enough to 14.745600 MHz).
Or, do you use a Philips downloader or what? Whichever, perhaps the
clock speed you give it will give a clue as to your crystal
frequency.
I gathered from their web site that the ARMmite comes with a Basic
interpreter programmed into the Flash. If you use the Maurer or
Philips downloaders, I think you have replaced the Basic interpreter
altogether. In these cases, the ARM is almost certainly not running
at 60 MHz but at 10, 12, or 14.xx MHz. It is only when the ARM's PLL
is turned on that the crystal frequency is multiplied to give the
higher clock speed.
However, if you are using some ARMmite facility to program the Flash
(which I'm not sure would work because of the .org location in
riscy.S) then all bets are off.
Do you use for your lpc2103.ld (link script) a copy of my lpc2106.ld
script but perhaps with the start of RAM changed to suit the LPC2103
chip?
(On the LPC2106 chip, RAM starts at 0x40000000 but lpc2106.ld sets it
to 0x40000200 to keep from overwriting the first 0x200 bytes of RAM.
So the lpc2103.ld file should change 0x40000200 to whatever is
appropriate for the LPC2103 chip (I have not checked where its RAM
starts. For all I know its RAM starts at the same address as the
LPC2106).)
>> .equ VPBDIVISOR, 4 @ ratio of processor clock to
>> @ peripheral clock -- must be 1, 2, or 4
> I understand, but how do I know what that's set to on the ARMmite? Or
> does your program set it to what I specify in the .equ statement?
I believe riscy.S hard codes the divisor to 4 (is spite of having the
VPBDIVISOR symbolic constant). So, I believe you must set VPBDIVISOR
to 4 for everything to be in sync.
> What's happening now is that if I type 1-digit numbers or tokens such
> as + on a single line, they are recognized fine. Anything over a
> single character on a line is likely to be misread. So I obviously
> don't have the baud rate correct yet.
Since the serial communication is almost working but not quite
reliable, I think the CCLK setting is probably off by a little more or
less than the factor of three that 115200/38400 would suggest.
> And I'm curious: why do you specify "115200 BPS" in riscy.forth before
> showing the "Hi" when the baud rate is already set in riscy.S?
I don't remember. Once everything is working, try commenting it out
and see if everything still works. However, once everything is
working, the baudrate should be changeable on the fly. That is, you
should be able to type
9600 BPS <Enter>
at the terminal and then change your terminal's settings from 115200
to 9600 bps and still be able to communicate. (Don't change the
terminal's setting first, of course.)
--
Frank
jcomeau_ictx
> jcomeau_ictx <john.com...@gmail.com> writes:
> >> > Something is still screwy in the baud rate,
> > I've tried different ones, both in the sources and in the terminal
>
> 12,000,000 Hz. (VPBDIVISOR must always be 4)
>
> Try with each of these 3 sets of settings
>
sent me and found this (irrelevant parts snipped):
#define PBSD 4
#define HOST_BAUD (19200)
//for init_coridium
// PLL setup values are computed within the LPC include file
// It relies upon the following defines
#if 1//#if defined ( ARM-express ) || defined ( ARM-mite ) ||
defined ( ARM-connect ) || defined ( ARM-expLITE )
#define FOSC (20000000) // Master Oscillator Freq.
#define PLL_MUL (3) // PLL Multiplier
#else // no longer used, but may come back with standalone compiler
#define FOSC (14745000) // Master Oscillator Freq.
#define PLL_MUL (4) // PLL Multiplier
#endif
#define CCLK (FOSC * PLL_MUL) // CPU Clock Freq.
#define PLL_DIV (FCCO_MAX / (2 * CCLK)) // PLL Divider
#define PCLK (CCLK / PBSD) // Pheripheal Bus Clock Freq.
So according to this, I _should_ set CCLK to 60000000; or are you
really using it to mean what they call FOSC? And I guess VPBDIVISOR is
what they call PBSD; so if your system assumes PBSD=PLL_MUL, that
could be another problem I'm having, since PLL_MUL is 3 not 4. That
is, assuming the PLL is set by the hardware. I don't know if that
assumption is valid.
>
> I guess you had set CCLK to 60000000 (i.e. 60 MHz)?
Yes, that still works best for me until I can reconcile your settings
with Coridium's.
> How do you program the Flash? Do you use the Martin Maurer
> downloader? With a 14.7456 MHz crystal, I use this command
>
> lpc21isp -bin combo.bin /dev/ttyS0 115200 14746
>
> which specifies a serial rate of 115,200 bps and a crystal speed of
> 14,746 KHz (close enough to 14.745600 MHz).
>
> Or, do you use a Philips downloader or what? Whichever, perhaps the
> clock speed you give it will give a clue as to your crystal
> frequency.
I guess it's from Philips, it's called load21xx.exe and is called like
this:
$ /usr/local/coridium/bin/load21xx 2103 combo.hex com4
Copyright 2007, Coridium Corp., may be used for loading Coridium
Hardware
CPU type 2103
combo.hex 10567 bytes loaded
Warning: data not aligned to 32 bits, padded (length was 2947, now
2948)
Synchronizing
Setting oscillator
Unlock
Writing Sector 0
[4096]: .......................................................
......................................
Writing Sector 1
[4096]: .......................................................
......................................
Writing Sector 2
[4096]: .......................................................
..
Download done
> I gathered from their web site that the ARMmite comes with a Basic
> interpreter programmed into the Flash. If you use the Maurer or
> Philips downloaders, I think you have replaced the Basic interpreter
> altogether. In these cases, the ARM is almost certainly not running
> at 60 MHz but at 10, 12, or 14.xx MHz. It is only when the ARM's PLL
> is turned on that the crystal frequency is multiplied to give the
> higher clock speed.
OK, so that would mean 20 MHz, what they say the crystal is in
coridium.h. But I try that, and no joy at all.
> However, if you are using some ARMmite facility to program the Flash
> (which I'm not sure would work because of the .org location in
> riscy.S) then all bets are off.
The .org, according to their .ld files, is either base+0x120 or base
+0x200. I'm guessing it's the latter, which agrees with yours,
otherwise your program probably wouldn't work at all.
> Do you use for your lpc2103.ld (link script) a copy of my lpc2106.ld
> script but perhaps with the start of RAM changed to suit the LPC2103
> chip?
I just copied your lpc2106.ld for now. The specified settings aren't
any different on the two chips, as far as I've seen.
> (On the LPC2106 chip, RAM starts at 0x40000000 but lpc2106.ld sets it
> to 0x40000200 to keep from overwriting the first 0x200 bytes of RAM.
> So the lpc2103.ld file should change 0x40000200 to whatever is
> appropriate for the LPC2103 chip (I have not checked where its RAM
> starts. For all I know its RAM starts at the same address as the
> LPC2106).)
Correct, it does also start at 0x40000000.
> Since the serial communication is almost working but not quite
> reliable, I think the CCLK setting is probably off by a little more or
> less than the factor of three that 115200/38400 would suggest.
>
That makes sense. I'll maybe figure this out tonight.
jcomeau_ictx
> I'll maybe figure this out tonight.
More progress: I set CCLK to 20000000, taking your advice that the PLL
won't be used, also the hint about the factor of 3 that had escaped
me. Then starting poking around your code, and noticed the BAUD rate
setting was based on the assumption of a 14.7456 MHz crystal:
riscy.s: .equ DIVISOR, PCLK / (16 * BAUDRATE)
Guessing that this would give suboptimal results with my 20 MHz, I
tried:
jcomeau@ns002:/usr/src/riscy$ python
Python 2.3.5 (#2, Oct 16 2006, 19:19:48)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 5000000 / (16 * 115200)
2
>>> 5000000.0 / (16 * 115200)
2.7126736111111112
>>> 5000000.0 / (16 * 9600)
32.552083333333336
>>> 5000000.0 / (16 * 2400)
130.20833333333334
The slower I go, the less of an error factor. Yet still, at 2400:
hi
Hi
1 ok
11 ok
111 ok
.S 1 143 111 ok
At least now the baud rate I set in riscy.S is what works (more or
less) with the terminal program that comes with the Coridium IDE. So
progress is being made, albeit slowly.
It seems, when I lose synchronization, typing in small numbers like
this gets it back without having to reset. In case that's any help to
anyone else following this questionable path :^)
I really appreciate the help, but I know you're busy; I'm at a point
now where I can probably grok the rest. Thanks again!
Frank Sergeant
> More progress: I set CCLK to 20000000, taking your advice that the PLL
> won't be used, also the hint about the factor of 3 that had escaped
> me. Then starting poking around your code, and noticed the BAUD rate
> setting was based on the assumption of a 14.7456 MHz crystal:
Only because of the CCLK equate, I think.
But, you changed the line
.equ CCLK, 14745600
to suit your guess as to the crystal frequency, right? After that,
the assembler should calculate PCLK (as 1/4 CCLK) and the serial port
divisor (based on BAUDRATE and PCLK) automatically. I don't think
riscy.S had any other assumptions about the crystal frequency.
So, once you have set CCLK to 20000000, PCLK should be calculated
automatically as 5000000.
Maybe the crystal is not 20 MHz.
Here are some more crystal frequencies that give perfect baudrates:
11.059200 MHz (57600 19200 9600 4800 2400 1200)
18.432000 MHz (57600 19200 9600 4800 2400 1200)
19.046400 MHz (9600 4800 2400 1200)
19.660800 MHz (38400 19200 9600 4800 2400 1200)
22.118400 MHz (115200 57600 38400 19200 9600 4800 2400 1200)
20.275200 MHz (9600 4800 2400 1200)
Does ARMmite have technical support that say what the crystal
frequency is?
Have you / could you try the lpc21isp flash utility instead of
ARMmite's (and use the lpc2106.ld link script rather than any ARMmite
link script)? I don't know that this would help.
I think the MS word in Riscy Pygness is fairly accurate (based on
PCLK), although I can't remember how carefully I checked it. Perhaps
you could write a word (give it a one-character name to make it easy
to invoke) that toggles an I/O pin or flashes an LED or emits a
character every so many seconds.
: X ( -) BEGIN 'A EMIT 100000 MS AGAIN ;
then time it with a stop watch (or wrist watch). 100,000 milliseconds
should take about 100 seconds. So, if you set CCLK to 20000000 and if
your watch shows 120 seconds or whatever, then you can take the ratio
and figure out a better approximation of the ARMmite's actual crystal.
I agree something is funny if the serial communication is not
reliable.
> I really appreciate the help, but I know you're busy;
Well, yeah, but this helps me avoid doing what I should be working
on. ;)
--
Frank