From: mcmahan@netcom.com (Dave Mc Mahan)
Subject: Re: 68332 problem
Date: Fri, 14 Aug 92 17:49:03 GMT
Organization:  Dave McMahan @ NetCom Services 

 In a previous article, benst@olivetti.nl (Ben Stuyts) writes:
>Greetings!
>
>I am designing a board around the 68332. This board requires that
>I have two 128 KB eproms connected to the CSBOOT lines. There is
>also sort of a dram and video controller (Philips SCC66470) which
>occupies 4 MB of the adress space. It seems logical that this should
>be the bottom 4 MB, because of interrupt vectors and such. I'd like
>the eproms to start just above this area at $400000.
>
>The dram controller has a chip select, but as it is 4 MB I cannot
>use any of the CS lines of the 68332. (These are limited to a
>maximum of 1 MB.) Therefor I just connect the chip select of the
>66470 to A22. (A23 is not used, and its pin is programmed as an
>ECLK, by the way.)

If I was you, I'd use four chip select pins to do the address decoding for
the dram and video controller.  It cuts way down on having to figure out
how to generate DTACK signals, and you can easily change the wait state
numbers if your DRAM controller needs faster or slower access times.


>When the system boots, the eproms are mapped to the bottom 1 MB.
>Therefor the reset vector must point to the lower 1 MB. The pins
>for A19..A22 are high at that point, because they are assigned to
>chip selects by default. Later on, they should be assigned to
>A19..A22 by software.
>
>Now how do I get the eprom to reside at address $400000?

Motorola solved this problem quite cleverly in their 332bug montior,
available on the 68332 BCC.  It took me quite some time to figure out what
was going on, but the idea was quite clever once I figured it out.

First, your two EPROMs occupy 32 Kbytes of space.  When they are connected
to CSBOOT and the CPU comes out of reset, it has CSBOOT configured for 1
Mbyte of space.  The first thing the 332bug monitor does is vector to the
starting address of the program at location 0x400 (actual value doesn't matter,
just as long as it is in the EPROM space).  Since you only have 32 Kbytes
of actual EPROM and CSBOOT is configured to access 1 Mbyte of space, the
EPROM is phantom addressed all over the place.  The value stored at
location 0x00000 shows up again at location 0x08000, 0x18000, 0x20000, etc.
This keeps going on until you get to an address outside the range of
CSBOOT.  Now things get tricky.

The 332bug monitor recognizes that the EPROM is phantom addressed all over
the first 1 Mbyte of space.  The instruction at location 0x400 does a long
jump to 0x20406, which just happens to contain the same instruction as
location 0x406.  Since the EPROM is phantom addressed at this spot, the
code continues to run, but the PC is now executing out of 0x20406 rather
than 0x0406.  The instructions starting at location 0x20406 remaps CSBOOT
so that it now points to 0x20000 (instead of the boot value of 0x00000) and
the address range of CSBOOT is only 32 Kbytes in size, just the same as the
EPROM chips it is addressing.  The monitor then remaps the RAM chip selects
to begin at address 0x00000, thus putting RAM at address 0x00000 and the
EPROM up higher.  You can set up your code to do this same kind of thing
in your boot code.  If the eventual address of the EPROM is outside the 1
Mbyte limit of CSBOOT, you will have to take these jumps in stages and
remap the EPROM each time.  Since you want to get the EPROM up to the 4
Mbyte address space, you will probably have to do 5 or six such jump
steps.

Note that this solution is one that you describe as one of your options.
It is a bit tricky (ok, it's _real_ tricky), but it does work.  I have a
feeling that it is a bit difficult to debug if something goes wrong,
however.  There may be some small amount of comfort in knowing that
Motorola does it in their products.  If you pick this road, I'd suggest
that you document the heck out of it, as it is quite subtle.



>I have considered several options, but there must be a simpler one.

>- Remap the eprom in software in stages to $80000, jump to *+$80000,
>map to $100000, jump, then to $180000, etc. until $400000.

This is the method described above and is used by Motorola in their 332 bug
monitor.  You should also think about exactly how tricky this might be to
actually program into an assembler.  EPROM programmers have a hard time
understanding the concept of phantom addressing, so describing the
procedure for making your boot EPROMs could be difficult and error prone
for any young turks that take over your product in the future.


>- Download a small bootstrap program into the 68332's 2 KB ram,
>which remaps the eprom to $400000, and then jumps to that new
>address.

This will allow you to perform all the remappings quite simply in one step,
but is also non-intuitive.


>- Rely on the prefetch mechanism, just remap the eprom to $400000
>and do a jump to *+$400000. But I don't think the 68332 does do a
>prefetch when it encounters a jump.

I think I would stay away from this method if I were you.  I don't think
the pre-fetch mechanism is deep enough for your purposes and would be a
major pain to debug or modify later.


>By the way, in my SIM manual page 3-39 describing the retry operation
>is completely wrong. (It is more or less page 3-43.) Is there a new,
>corrected printing available?

The latest manual I have is MC68332UM/AD and has only black writing on the
cover.  There was an earlier manual with the number SIM32UM/AD and has a 
gold box on the front.  This manual is old and has been superceded by the other.
I would get the most recent if you don't have it.  If you find one that is
different than the two I describe, please let me know.  It sounds as though
you have the most recent manual, however.  Can you tell me which part of
the retry operation is in error?  I don't have any answers, but I'd like to
make a note in my manual in case I need it in the future.

I hope this helps.


>Thanks,
>Ben Stuyts (benstn@olivetti.nl)

  -dave
-- 
Dave McMahan                            mcmahan@netcom.com
					{apple,amdahl,claris}!netcom!mcmahan