Re: MISC-d Digest V97 #8
- To: MISC
- Subject: Re: MISC-d Digest V97 #8
- From: jfox@xxxxxxxx (Jeff Fox)
- Date: Wed, 19 Mar 1997 14:35:49 -0800 (PST)
Dear MISC readers:
Andrew Sieber <asieber@usa.net> asked:
>Jeff Fox wrote:
>> P21A5? Which board is that? P21Forth 1.02 comes in three versions. One
>> for simulator, one for the development system (with the i/o chip I have
>> on mine) and one for the kit board with the parallel port. I don't recall
>> the version number of the boards. It does not run on the latest board
>> with only the 82C51 serial port i/o. I did start debugging a port to
>> that board but never finished it.
>I am using the P21Forth that comes in your 128kB slow.rom image file,
>which is zipped along with fast.rom in your 102roms.zip file, which is
>on your web site at
>http://www.dnai.com/~jfox/p21forth.html
>The schematic that I'm using has a 74HC245 input port and a 74HC574
>output port, which are controlled by a 74HC138 which decodes the P21's
>address lines when the P21's I/O pin goes low. No 8255 or 8051. To
>make it as simple as possible (and increase chances that I can get
>something to work), I have simplified the circuit to nothing more than a
>P21, 128kB EPROM, a 14.3MHz oscillator, and a 70ns 1x36 SIMM. No I/O.
That is the kit board for which those P21Forth ROMs apply. There
is a small delay after the P21Forth boot message as I recall so you
should be able to read a message before any i/o happens. If not
it will read the locations in SRAM address space (SLOW or FAST address
space, that is the only difference between the versions of the ROM)
and treat it as i/o. So in serial mode it will wait for a bit to
change in that location.
>I will be delighted to simply get it to throw "P21Forth" up on the
>screen after I hit the processor reset pushbutton, even though I will
>have no keyboard hooked up with which to talk to it. That will verify
>that everything is working properly.
Yes that should work.
>Since the 128kB eprom of course has only 17 address lines, the P21's
>A17, A18, and A19 are not used during a ROM access. This means that the
>ROM image is going to appear eight times across the 1 meg ROM address
>space. I assume P21Forth will run that way.
Yes. P21Forth will only read one of those 8 copies of the rom. The top
two bits are set by a register but they default (I don't to what) at
boot and bit A17 should default to a 1 as it boots at address 1AAAAA
in the P21 address space or offset 2AAAA in the ROM window. To be
safe you can just use 8 copies of the 128k image as you say and see
what those address lines are at boot. You can then use 7/8 of your
ROM for whatever after it is working.
>I've tried all of those voltages and everywhere in between, but have not
>had any success yet. I will try out the OK demo ROM if I don't get the
>P21Forth ROM working soon.
>
>I guess I should admit that I have pretty much a rat's nest
>breadboarding job that I am calling a "system", and that may very well
>be the problem.
>Has anybody on this MISC list succeeded in getting P21 running on a
>breadboard (_not_ with wirewrapping or PC board), with jumper wires
>running everywhere?
Not that I know of. You might have an inductance problem and if you
use short wires it might work. I know there are limits to the drive
from P21 and most of its power goes to video and driving the rams.
There are limits to how many and how long those wires can be.
>I kind of assumed that even at the 20MHz+ speeds the P21 accesses the
>dram with, I wouldn't have inductance/capacitance problems with a
>breadboarding job.
You might.
>Another problem I had was that I was using 1989 specs on SIMM chips from
>Motorola, and the memory book with the pinout list two pins as
>no-connects that are actually RAS pins. I fixed that problem in my
>circuit when I saw the discrepancy between the old pinout and a new one
>I just got, but the system still doesn't work, so there are other
>problems.
debugging your rig:
first try just P21 and a ROM and clock to start with and see if it
passes tests 0, 1, and 2. Then do 0-6 with DRAM.
0. does the oscilator produce a 14M wave?
1. does it access the rom when it boots?
2. does it read lots of stuff from the rom at boot?
3. does it write lots of stuff to dram at boot?
4. does it start generating a video signal (all black) durring boot?
5. does it display P21Forth in the center of the screen for a while?
6. does it read the keyboard?
>When I eventually start writing code for P21 that doesn't rely on
>P21Forth (ie. I burn my eprom with my own custom programs), of course I
>will have to XOR all of the programs' address and data with AAAAA.
>However, I believe I will also have to XOR the address lines leading to
>the eprom chip while it's being programmed (or do an equivalent
>transformation in software, of course), so that byte zero is at eprom
>address AAAAA, byte one is at eprom address AAAAB, byte two is at eprom
^
2AAAA in the boot ROM window, remember you don't read the
ROM as a 1M space but as a 256k range (actually one of two SLOW or FAST)
ROM space. Two bits in the configuration register control the top two
address bits to the ROM chips and therefore select one of 4 windows
into the ROM.
>address AAAA8, byte three at AAAA9, four at AAAAE, etc. This is because
>P21 will be loading "sequential" bytes in this order due to its bus
>interface which XORs everything with AAAAA.
>I assume the slow.rom image file already has all necessary
>transformations like this already performed. Ie. I programmed byte 0
>into eprom 00000, byte 1 into 00001, byte 2 into 00002, etc. without
>doing any XORing.
Yes of course or it wouldn't run. The OK assembler notes instructions
and data as patterns, so all the data must be xored with AAAAA to
develop the stuff on the PC and port it to P21. The assembler in P21Forth
runs on P21 and so it doesn't see any XORing of addresses or data.
You will note the all the P21 opcode masks used in the OK and P21Forth
assemblers are the AAAAA XOR of the opcode mask in the other assembler.
Jeff Fox
jfox@dnai.com Ultra Technology Inc.
jeff@itvcorp.com the iTV Corporation
http://www.dnai.com/~jfox/