No Subject
- To: MISC
- From: jfox@xxxxxxxxxx (Jeff Fox)
- Date: Thu, 13 Apr 1995 17:01:49 -0700
Dear MISC readers,
It has been a while since I have posted any info to MISC. Here are
some updates.
I have prepared a new P21Forth 1.02. This version includes the
words FAST-I/O and SLOW-I/O to control the speed of the i/o
words. If you have installed the ACT parts you can use the fast
i/o which is about 40ns. (Like the high speed sram it still
needs a 25ns setup time, so just like high speed sram timing is 40ns,
but this is much better than the 250ns for slow i/o)
You can still use FAST.ROM to get a system that boots up in fast i/o,
but even the SLOW.ROM can switch to fast i/o after boot.
1.02 also includes several more graphics words. BPIXEL, WPIXEL, CPIXEL,
and >COLOR for drawing black, white or colored pixels. It also includes
two video pages. The word PING draws on one page while displaying
the other. PING uses SCREEN1, SCREEN2, DRAW1, DRAW2, and the variable
SCREEN#. To demo these words I have included Dave Lowry's high level
3D projection routine. DEMO1 demos a rotating cube in 3D space in
ping pong graphics. DEMO2 shows the cube with a reference plane and
scale also rotating in 3D. DEMO3 places the demo in a box on the screen
that outlines the clip area of the projection and lets the user move
the edges of the clipped image. The 3D demo is included in source code
and in a binary overlay on BLOCKS. 2B LOAD 2C LOAD GET3D DEMO1 DEMO2 DEMO3
will produce a nice graphics show. TEXT is defined as SCREEN1 DRAW1 to
end the ping pong grapics.
1.02 includes the arrow sprite and a simple demo called GUI that was
included in 1.01, with a black on grey box drawing demo.
1.02 also includes Raul's improved EXIT. This makes the 3D demo
run about 10% faster since it is written entirely in high level.
DEMO1 displays about 20 frames per second of the scaled, transformed,
rotated, projected and clipped cube image. It should be a lot
faster when I add line drawing in CODE.
1.01 and 1.02 included a bug fix for interpretting numbers when the
system was not in HEX or DECIMAL. 2 BASE ! 0101 would crash 1.00. :-(
I have discovered a couple of other bugs that I have not yet fixed.
One is \ which gets confusued after interpretting from BLOCKS. I
think I know what the problem is, but haven't fixed it. Also I
did not include the correct version of the RANDOM code and it
does not work properly either. :-(
>Klaus Blass (quoting Dr. Ting):
> >I agree that it is inconvenient to the user in not supplying an
> >EPROM with P21FORTH. However, there are logistic problems. The
> >obvious one is the FASTKIT and SLOWKIT. Which one should I
> >supply? 50% of the customer will be upset because they get the
> >wrong EPROM. P21FORTH has always been thought as a software
> >release. We hind of assume that the user has the capability to
> >program EPROM from a binary file. It is much more convenient than
> >asking people to program PCMCIA cards, as we originaally made
> >people do.
>
>It should be a simple instruction (or perhaps a jumper) to switch
>between slow and fast.
>
>Oh well...
Yes, and I imagine that a large percentage of uses will be upset to
not get a ROM at all with P21Forth from Dr. Ting. If he is not going
to ship it with a ROM I a may start shipping it myself. I have never
been paid anything for any of the copies of P21Forth that Dr. Ting
has sold. He did print out the manual, and does pay shipping cost,
but our understanding was that this would come out of his half of
the money, and that I would get $25 per copy sold. I don't really
think that including a UVPROM should be so difficult.
The first version 1.00 did not have the .ROM image file on the
the distribution diskette. (at least not the one I gave to Dr. Ting)
We created a .ROM file by reading a PCMCIA card and copying it to
a file to burn a UVPROM. He gave me a P21Forth 1.00 UVPROM, and
made another that he tolk to Taiwan.
I was under the impression that the PROM was included. I was upset
to learn that he does include his software on PROM, but not does not
include a PROM for P21Forth. I have no idea how many copies he has
sold, or if people did or didn't get proms. I have heard from a
couple of users who were upset to not get a PROM. I would have been
upset to order P21Forth and find I could not run it without getting
a prom burner, prom, and possibly even a PC compatible to read the
data file etc....
I will see what I can work out with Dr. Ting.
>----------------------------------------------------------------------
>
>I've been studying the P21 boot code a bit. Here's a summary:
>
>(1) a! doesn't work. This is a real pain. I've been toying with the
>ideas such as using a few gates to drive d10..d19 with a! ;' when
>SRAM, IO, CAS and WE are all low -- this ought to allow something
>semi-reasonable for a rom-only use. Now if only 15ns "eproms" were
>cheap... [Does a! work on a pcmia card with 15 ns access time?]
There is no such thing as a 15ns PCMCIA card. 200 or 250ns is more
like it, the same as the boot prom. You could boot from an 8 bit
250ns UVPROM and then run from 3 $3 8kx8 15ns sram, but you will
have to wire them up. It is not enough memory to generate video,
but it will run faster than DRAM.
I thought the work around that Chuck used in the boot code was
clever. He just increments A and tests it until it equals the
value he wants. Still this is not very useful for running
programs out of 8 bit memory. :-(
However Dr. Ting does have 8000 die that are not in packages. He
is looking into various packaging, and hopefully he will not be
choosing ones that have the same problem with a! as on the plastic
dip.
>(2) The page address used by jump, t=0, c=0 and call have the word's
>instruction bits included in the target address. This means you can
>have 8 targets for each instruction on each page. This is potentially
>useful. Oddly enough the 8 bits of the instruction pattern appear to
>be inverted when translated to an address pattern, and the high two
>bits appear to be set to "pattern zero". I wonder if this is related
>to the problem with a! (is it inverting some of the bits?)
No, nothing to do with a!. The 8 bits in ROM code includes the 5 bits
from the last instruction and as you say ALSO contains 8 bits of the
address. SO there are only 3 bits of real address that can be set
in this 8 bit instruction mode. As Raul says this means there are
8 possible addresses on each page in this mode. Note that the 10
bit addresses used in branch instructions are XORed with 3FF in the
P21Forth assembler. The 10 bit address field in branch instructions
is inverted from normal numeric representation. In Chuck's cross
assembler numbers are XORed with AAAAA and the 10 bit address field
is XORed with $255 I believe. This is the same as the $3FF XOR
in the P21Forth version of the assembler.
>Its difficult to understand the documentation, much of it is
>contradictory. For example, the memory/io map:
>
>Programming Manual More on Forth Engines, Vol 19
>Page 7 (2nd ed.) Page 20
>
>000000-0FFFFF DRAM 000000-0FFFFF DRAM
>120000-1203FF Slow IO 120000-13FFFF Slow SRAM
>140000 Config Reg 140000-17FFFF Fast SRAM
>160000-1603FF Fast IO
>180000-1BFFFF Fast SRAM 1A0000-1BFFFF --
>1C0000-1FFFFF Slow SRAM 1C0000-1DFFFF Fast IO
> 1E0000-1FFFFF Config Reg
>
>Anyone know which is right? I suppose I'll get around to testing this
>eventually.
Neither! I don't have time to go though and correct all of Dr. Ting's
documents. I do send him corrections, but I don't think he keeps track
of version control. SO I don't know who has what version, or whether
they have corrections or not.
Also, Chuck documented the stuff as Patterns, and Dr. Ting published
them as both numbers and patterns without every explaining which was
which. (it does make a difference) Combine that with different versions
of his documents, and other errors and, yes it is confusing.
In P21Forth I say "D5555 com a!" to setup slow input. This means
D5555 is the PATTERN 7FFFF, and when you do a com you get the PATTERN
180000. The PATTERN 180000 selects low speed input on port 0.
95555 com a! sets up high speed input. D5551 sets up slow speed output.
and 95551 sets up high speed output. Those are the numbers, as I
pointed out keep track of patterns vs numbers.
Check the end of the OK code for the code that sets the config register.
You can test the addresses out interactively in P21Forth.
>Anyways, the '21 numeric representation is rather important in the
>overall scheme of things. From the memory map and the boot code, I'm
>going to guess that the '21 fetches its first instruction from
>(internal numeric) address 1EAAAA.
>
>In More on Forth Engines, V19, p21, Dr. Ting says that that the
>initial pattern address is 1AA00 and that the initial physical address
>is 00AAA -- This contradicts his memory map on the previous page,
>which states that 1Axxxx is not mapped to anything.
>
>The FPC code for writing the '21 boot code, especially pages 54 and 58
>of Vol 19, appears to have the following history: it looks like Chuck
>originally wrote some code for programming 4 (well, up to 8) pages of
>eprom. Then, it looks like someone tacked on the capability of
>programming two more sets of 8 pages. Thus, there are routines named:
>SEND SEND1 and SEND2. SEND programs physical (pattern) addresses
>0000..1FFF, SEND1 programs pattern addresses 2000..3FFF, and SEND2
>programs pattern address 4000..5FFF.
Dr. Ting patched the SEND1 SEND2 stuff, I have never looked at it.
I did something else to attach the P21Forth to the OK code and
modify the boot code to boot up 16k of dram rather than 2k.
It is confusing. Between Chuck's code, and Dr. Ting's or my patches
to it, it is enough to confuse anyone. Even Chuck.
I worked it out, but cant remember how it all works off the top of
my head. I will say that I finally think I figured out why my patch
doesn't work on 512k pcmcia cards, but does work on 128k card. The
system boots at 1CAAAA (address) which will be 0 on a 128k card,
but not 0 on a 512k card. I will have to look into what it takes
to get the tools to work with the larger card and make the boot
code happy.
You are welcome to figure it out and document it clearly enough
for everyone to understand. It is still a bit of a problem, and
generally we have just recommended using a canned boot routine
and not worrying about the 8 bit boot code vs 20 bit code and
all the confusion that it entails. The problem is made worse
by the lack of documentation, and the mixture of Dr. Ting and
Chuck's code that you are looking at.
>Anyways, on page 58 of Vol 19, there is this line that reads
> AAA LOC ;reset
>
>As interpreted by SEND, this corresponds to address pattern 00000.
>
>If I look at the sequence of instructions that the MuP21 would be
>executing, it flows like this:
>
> OK22C.SEQ
>Numeric Pattern Value code comments
>1EAAAA 00000 C0 pop meaningless
>1EAAAb 00001 C0 pop meaningless
>1EAAAC 00006 C4 dup meaningless
>1EAAAd 00007 90 -or meaningless
>1EAAAE 00004 D1 a! meaningless (unless it works..)
>1EAAAF 00005 3A 0a! call to numeric address ..A6F
> (pattern ..0C0)
>.. \ \.
It is not meaningless. You are just not understanding what is going on.
000 001 002 003 becomes 6AA 6AB 6A8 6A9. You are counting in patterns,
you need to count in numbers and look at the address for the pattern.
Check out 6AA 6AB 6A8 6A9 and you should see the first instructions
that are executed in the boot code.
(Is everyone else confused yet???? :-) )
>Note the sequence:
>
>numeric hex digit 0 1 2 3 4 5 6 7 8 9 A b C d E F
>pattern hex digit A b 8 9 E F C d 2 3 0 1 6 7 4 5
>
>Going back to SEND, etc.
>
>Routine name PC offsets Pattern addrs
>SEND 00000-01FFF AA000-AbFFF
>SEND1 02000-03FFF A8000-A9FFF
>SEND2 04000-05FFF AE000-AFFFF
>
>In my opinion, this whole area is documented confusingly. I think it
>would be easiest to understand if the eprom programmer just set aside
>128K of PC memory, started writing the boot routine with reset at
>AAAAA, and in general had more of an absolute mapping between PC
>addresses and MuP21 addresses.
>
>Alternatively, maybe it would be better to have the PC hold an image
>of the eprom laid out in physical (pattern) order. This would mean a
>change in pc address handling (e.g. , would change), but would make it
>easier to be efficient when programming only a small region on the
>eprom.
I assemble (compile) the code for DRAM, then pack it into SRAM at
the location that the boot code will read when it is putting into
DRAM. There are many ways it could be done. Most people are
not really dealing with writing code for the SRAM.
>......................................................................
>
>Finally, it looks like running the '21 in boot mode off an eprom would
>get a 4 mips cpu which draws 1ma (video should be left off in this
>configuration). Is this a worthwhile configuration for anyone?
>
>--
>Raul D. Miller
I don't know. I have seen a P21 running without DRAM, just the
single 8 bit UVPROM. As you say it is a low power 8 bit 4mip (max)
cpu in this mode. Dr. Ting had it generating square waves of different
frequencies on each of the bits on the output port with a simple
increment and output to port routine running from UVPROM only.
Since 8kx8 bit 15ns SRAM only cost $3 now you could use $9 worth of
these and get 100mips! The cpu only decodes 1K in this address space,
but if you used 3 bits from the i/o port for page select you could
have a fast switch.
Also 32kx8 15ns SRAM is only $7. If you used these types of chips
in addition to DRAM you could generate video and make the CPU go
more than twice as fast as it does now.
Chuck has also said you could fill the DRAM address space with SRAM
if you wanted to, and like to play with hardware. This gives you
more room, but the memory coprocessor will still produce off-page
timing even though you wouldn't really need it. So it really would
not give you much.
After adding a second video display page to P21Forth 1.02 I thought
about the changes needed to generate video, boot and run a P21Forth
out of 256k DRAMs. I will need to modifiy OK, the video code,
the metacompiler (I have already done this once and it is very easy)
and the P21Forth itself. The idea would be to make the address
space look like 256k words of continuous memory to P21Forth, even
though the 9 bit pages on the 256k chips will make holes in the
physical address space with the P21 memory coprocessor.
It is not a big deal, but I am already working on a GUI and other
P21 code, so I am not sure if I should make it a higher priority.
I don't know what other people think. Any suggestions ???
The big advantage would be you could use 5 256kx4 drams which means
you could generate video with $25 worth of DRAM. OF course Dr. Ting
used the bloody simm on the kit, so it makes a bit of a problem
for converting to 256k chips.
Maybe someone will put together a cheaper kit that will use 256kx4
or 1Mx4 zipp drams, and/or 8kx8 or 32kx8 15ns SRAM. This would
be a lot more attractive to me.
F21 will have a software switch in the memory coprocessor to be able
to connect to 256kx4 chips and get the 9 bit pages correct. This
means you will need no tricks to see a continuous address space.
We plan to submit the first prototype to Mosis in less than 2 weeks
on F21.
>Klaus Blass:
> My experiences with P21 sofar are therefore restricted to running
> the Offete demos off the installed Prom (why not include P21Forth
> on the same type of Eprom as the demo (slow version probably) ???).
>
>Sure -- no point installing "fast" eprom on a board with 74HC___
>chips.
>
> Regarding the video quality I don't get any real red, it is more of a pale
> pink. Is that just my TV set, or do others observe the same thing?
>
>On my monitor I get yellow and brownish sorts of colors...
>
>Raul D. Miller
I hope the colors will be a little better on F21. We will see, I am not
sure if Chuck is using the same composite encoding or same transistor
sizes for the colors on F21, I will ask. OF course F21 will also have
RGB output, which should make for a very sharp image on a vga type monitor,
and also get much better colors. We will see.
Jeff Fox
