No Subject

[jfox@xxxxxxxxxx (Jeff Fox)]

M. Edward Borasky writes:

>It looks like my best course is to get a 1 MBYte SRAM card (about $50) and run
>the cross-development code on my HP100LX, then pull the card from the HP and
>stick it in the MuP21 box.  There are some special things about the HP
>interface, though: the SRAM is treated as a RAM disk with some embedded
>firmware in the HP.  Would this be a problem?  Another question: would I be
>constrained to FPC on the HP or can I use some other FORTH (ZenFORTH leaps to
>mind since that's what I have now).

I see no problems there.  I got a Poqet PC in 1990 so I would use the two
PCMCIA slots for development.  In 1991 I got a PCMCIA card device for my 386.
I do exactly what you are talking about on these two machines.

I even have a utility called FLOPCARD that allows DOS and DOS files to
reside on the same card as MuP21 boot code.

I provide a patch to Chuck's code that uses the BIOS to read and write
the PCMCIA card on these machines.  Chuck designed a PCMCIA interface
using a couple of parallel ports, so his code is not portable.  My
patch should work with other system with BIOS support, but might
need some small change depending on the implementation.  I had to save
a couple more registers on the 486 BIOS version.  I am still just
working with  128k cards, so I will have to make a small change to
work with 1M cards.

>Next question: since my intended application is off-line signal processing and
>other flavors of number crunching, I will need fast multiply operations.  Is
>there a multiplier in the hardware or will I have to do this in software?

There is no multiply instruction, but there is a multiply step.  Check out
the documentation or play with the S21 chip simulator to get a feel of
the instruction set and the performance.  We have coded many math words
in CODE on P21FORTH to get performance.  The eForth model only has one
math word in CODE (UM+) and everything else is high level.  So math is
very slow in eForth.  We have many standard Forth words 2* 2/ U2/ * UM* 
UM/MOD and many other words in CODE to get better performance.  We also
have fractional multiply words *. and *_ and a CORDIC function.

Math is the weakest thing on MuP21.  You have to plan code well to get
the best performance.  Penio has ported some code to the simulator and
has experimented with optimizing performace.  Dr. Montvelishsky has
written many of the Math routines in P21FORTH.  There are some good
examples on the net.

MuP21 is not designed for DSP, it has no multiply accumulator.  (most
multiply accumulators are bigger than MuP21)  The slowest instruction
is + (and +*) which can take more than one instruction cycyle.  So
math must be carefully constructed if speed is an issue.  

Chuck says math was not important for OKAD.  He does a few multiply and
a bunch of adds, but it was not important to this design.

Chuck is in the CUSTOM silicon business, and his idea is attack
problems with custom hardware and custom instructions and custom
coprocessors.  MuP21 was not designed to be equally good at all things,
math is one that needs attention.  Penio or Dr. Montvelishsky might
have useful advice for what you want to do.

And there are lots of math examples in the eForth or P21FORTH
implementations.

Jeff Fox