Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett!ForthNet
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: PYGMY Forth
Message-ID: <2238.UUL1.3#5129@willett.pgh.pa.us>
Date: 16 Jan 91 03:38:18 GMT
Organization: (n.) to be organized.  But that's not important right now.
Lines: 75

Category 1,  Topic 45
Message 65        Mon Jan 14, 1991
F.SERGEANT [Frank]           at 02:16 CST
 

 JEB> BTW, how difficult is it to make Pygmy ROMable?

 Nothin' to it.  All you have to do is go through the source code for  Pygmy
and make sure that any time it tries to change memory, that that  memory is
RAM not ROM.

 The above is the key but might make it sound harder (or easier) than  it is.
Browse through the source code (mainly screens 0 - 80 of  PYGMY.SCR). Look for
the word RAM.  Note how CONSTANTs and system  constants work. You'll need to
initialize RAM to point to actual ram.   That will take care of system
variables (which are defined via  CONSTANT).  You'll have to change VARIABLE
so it uses CONSTANT and RAM  for any of the variables that are defined in ROM.
You'll have to see  that H (dictionary pointer) points to actual RAM.  You'll
have to see  that your ROM and RAM are in the same 64K segment (this might be
the  hardest to do on a PC).  Watch out for DEFER and IS and make sure all 
variables are initialized correctly.  Those are the main things that  come to
mind. As you browse through the source you might see other  things that need
attention.  Are you planning to run it on a PC?  If  not, getting the ROM &
RAM in the same segment should be easy.  But  then, I'd think you'd not want
to have DOS either.  In that case look  over any DOS calls and be sure they
get changed over to BIOS calls  (assuming you'll still have the BIOS ROM).  On
the other hand, you  might have been talking about putting Pygmy on another
processor, etc,  which is pretty easy, especially if you can use a PC (with
Pygmy on it)  as the terminal and file server.

 If you plan to run it on a PC from ROM, I must ask WHY?  If you'll  still
have BIOS & DOS and still want Pygmy in ROM, the simplest thing  to do would
be to put the unROMable version of Pygmy in ROM but change  the very beginning
boot up code (on scr 17) to copy itself, byte by  byte, into RAM and then do a
long jump to the RAM copy.  This way all  the problems of making it ROMable
disappear.

 I hope the above gives you the general idea.  If you'll give me more  details
on exactly what you want to accomplish I might be able to  refine my advice
somewhat.

 JEB> How do you end up with really small file sizes for your exe 
 JEB> files? I may be overlooking something.  The other related issue 
 JEB> is running space.

 I don't bother.  I just run everything out of Pygmy.  Pygmy is not set  up to
make headerless definitions (which would save some space).  With  the editor
and assembler Pygmy only takes up about 14K of disk space.   The kernel by
itself about 8K.  Using the meta-compiler you should be  able to generate a
system that has only the words in it that you want,  leaving out the editor,
assembler, unneeded file words, SEE, .S,  anything you didn't need.  This
would still let you *use* the  assembler, etc. at meta-compile time - it just
wouldn't be present in  the target image you are building.  I imagine this
could get your  utilites down to a fairly small (disk) file.

 The related question is how much RAM does it take up at run-time.  All 
programs run under DOS initially take up ALL the available ram!  All 
programs!  To take up less RAM they have to explicitly release some.   Why do
you care how much it takes up, unless you plan to start another  "process"
from within Pygmy, or unless you make it a TSR, or unless you  already have so
many TSRs loaded that you have less than 64K of RAM  available?  Pygmy always
occupies 64K of RAM.  (If the optional HASH  dictionary lookup method is used,
it takes up 128K.)  You can change  down to 10K, 12K, 20K, whatever by
initializing the stacks, disk  buffers, TIB to lower memory and then doing a
DOS call to release all  the memory above them.

 I hope I've answered what you wanted to know; if not, ask again with  some
more specifics.

  -- Frank
-----
This message came from GEnie via willett.  You cannot Reply to the author
using email.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp