No Subject

[jfox@xxxxxxxxxx (Jeff Fox)]

Dear MISC Readers,

I thought I would give you an update on Dr. Ting's presentation
on his P21 eForth.  He ported the 2.0 eForth to OK using a few
extensions to Chuck's P21 assembler.
The system includes a high level single step debugger and a
hex editor with the 7 buttons on the pad.  One of the buttons
starts up this eForth with serial i/o to the PC at 9600 baud,
and video output to the screen.

The eForth is the 2.0 version that was published and available
from ftp for some time, except that Dr. Ting wrote his own
metacompiler on top of OK.  I am not sure how he will market
this, or if he will include it in the basic software that comes
with the kit.

It has about 30 words in CODE, and does not inlcude all the
ANS words, or even the words in the version I put up for ftp
last year.  But it is a good example, and is nicely integrated
into the OK system.

I have noticed that there is still some confusion about how my
P21Forth boots up and supports both parallel and serial keyboards.
My code checks the 8 bit input port for about 100ms to see if 
there is anything there.  If you are pressing on one of the 7
buttons on the pad, or if there is an rs232 connection providing
-12v to input bit 7 on P21 then P21Forth will boot up in
serial mode and ask for a "b" on the serial terminal.  If
it does not see an active device (-12v) in that 100ms it assumes
you have a parallel keyboard and starts looking for ascii keys
on the lower 7 bits of the 8 bit input port.  

I also wanted to say one thing that I noticed  recently when
I coded some graphics routines on P21.  You do have to deal with
AAAAA XOR when dealing with the graphics processor.  It is not an
issue when you just do bitblock transfers to or from the screen,
and this is all I had done in the past.  But when I coded a
graphics cursor routine, a form of sprite, I realized that you
do have to deal with the fact the the video processor deals
with "patterns" and the cpu deals with "numbers".

So to AND and OR different pixels with those on  the screen you
have to also do an AAAAA XOR on the screen data when you get it,
and when you put it back.  This is because AND and OR do not
perform AND and OR on patterns...   So  although I have said
that it mostly is invisible, it is not completely invisible.
If you write code to do logical operations like AND OR, XOR,
on screen data you have to deal with the complementary bus
representation difference between the CPU and video processor.
It would be better if you didn't have to do this.

Chuck's video design  is quite efficient for what he does, which
is basically flood rectangles with colors.  This specialized type
of bit block transfer can actually take advantage of the fact
that the P21 data stack is so small to get very efficient transfers.
To do a normal 100x100 pixel bit block transfer you would have to
read and write 25 words in each row, and 100 rows.  This would
be 2500 reads and writes all of which would be off page, and some
other code overhead in the inner loop.  In the type of flood bit
block transfers that Chuck does it is all one color, so he can
fill the data stack with 6 copies of the word to be bit block
transfered, and then do 2500 writes with no reads.  3 of 4 of
those writes will be ON page so it ends up being 10 times faster
than a regular general purpose bit block transfer.

Chuck also do not do logical transfers that AND, OR, or XOR the
data with the data already on the screen.  To do this as I have
discovered you DO have to deal with the fact that colors are
patterns, not numbers.

Anyway I thought I would mention some of the details that I
have run accross while working on the P21 GUI.

I should  also mention that I completed P21Forth 1.0.1 and
delivered it to Dr. Ting.  The User Manual is the same as for
1.00, but there are a couple of differences.  First the 1.0.1
version has the correct code for Plastic chips running at
lower voltages.  That is a! was not used at all in the boot code,
and nop was placed before all a! in DRAM that were not the
first instruction in a word.
Version 1.00 would only run above 5.4V, while 1.01 will run at
4.9V on the plastic chips.
Version 1.01 is also available with either fast or slow i/o. So
if you upgrade your kit to ACT i/o chips you can run the i/o
through the high speed address space and get a very stable
video image.  The video jitter caused by so much slow i/o in
P21Forth 1.00 can be reduced by putting some delays into the
keyboard routines, and it can be eliminated by running at
higher voltages.  But with 1.01 you can also run the i/o
at high speed to reduce video noise even at lower voltages.
I can also supply the addresses that can be modified on the
fly in P21Forth 1.00 to convert from low speed i/o to high
speed i/o.  So if you upgrade your kit from 74hc parts to
74act parts it will still work with the slow speed i/o
software, but after you boot you can always do a couple of !
to addresses in P21Forth 1.00 to switch to high speed i/o.
With 1.01 you can pick a fast i/o or slow i/o boot uvprom.
In addition to the GUI in development 1.0.1 will also
be the version that will use the new one word metacompiler
to metacompile P21Forth 1.0.1 with P21Forth 1.0.1.  Once
that happens new versions like  1.0.2 can be generated very
fast.

F21 is now planned for prototyping in March.  We didn't make
the Feb data, but March seems almost certain now.  So this
will mean F21 should be back from Mosis in May.  P8 should
get a prototype run back from Mosis in March, and P32 will
go in in April it appears.

Jeff Fox
Ultra Technology
2510 10th St.
Berkeley CA 94710
(510) 848-2149 or 848-565
jfox@netcom.com
http://www.dnai.com/~jfox