home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.m68k
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!sdd.hp.com!news.cs.indiana.edu!umn.edu!csus.edu!netcom.com!mcmahan
- From: mcmahan@netcom.com (Dave Mc Mahan)
- Subject: Re: 68332 problem
- Message-ID: <0y6m6#h.mcmahan@netcom.com>
- Date: Fri, 14 Aug 92 17:49:03 GMT
- Organization: Dave McMahan @ NetCom Services
- References: <1992Aug8.215802.22391@olivetti.nl>
- Lines: 125
-
- 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
-
-