home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / m68k / 1033 < prev    next >
Encoding:
Text File  |  1992-08-14  |  6.2 KB  |  136 lines

  1. Newsgroups: comp.sys.m68k
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!sdd.hp.com!news.cs.indiana.edu!umn.edu!csus.edu!netcom.com!mcmahan
  3. From: mcmahan@netcom.com (Dave Mc Mahan)
  4. Subject: Re: 68332 problem
  5. Message-ID: <0y6m6#h.mcmahan@netcom.com>
  6. Date: Fri, 14 Aug 92 17:49:03 GMT
  7. Organization:  Dave McMahan @ NetCom Services 
  8. References: <1992Aug8.215802.22391@olivetti.nl>
  9. Lines: 125
  10.  
  11.  In a previous article, benst@olivetti.nl (Ben Stuyts) writes:
  12. >Greetings!
  13. >
  14. >I am designing a board around the 68332. This board requires that
  15. >I have two 128 KB eproms connected to the CSBOOT lines. There is
  16. >also sort of a dram and video controller (Philips SCC66470) which
  17. >occupies 4 MB of the adress space. It seems logical that this should
  18. >be the bottom 4 MB, because of interrupt vectors and such. I'd like
  19. >the eproms to start just above this area at $400000.
  20. >
  21. >The dram controller has a chip select, but as it is 4 MB I cannot
  22. >use any of the CS lines of the 68332. (These are limited to a
  23. >maximum of 1 MB.) Therefor I just connect the chip select of the
  24. >66470 to A22. (A23 is not used, and its pin is programmed as an
  25. >ECLK, by the way.)
  26.  
  27. If I was you, I'd use four chip select pins to do the address decoding for
  28. the dram and video controller.  It cuts way down on having to figure out
  29. how to generate DTACK signals, and you can easily change the wait state
  30. numbers if your DRAM controller needs faster or slower access times.
  31.  
  32.  
  33. >When the system boots, the eproms are mapped to the bottom 1 MB.
  34. >Therefor the reset vector must point to the lower 1 MB. The pins
  35. >for A19..A22 are high at that point, because they are assigned to
  36. >chip selects by default. Later on, they should be assigned to
  37. >A19..A22 by software.
  38. >
  39. >Now how do I get the eprom to reside at address $400000?
  40.  
  41. Motorola solved this problem quite cleverly in their 332bug montior,
  42. available on the 68332 BCC.  It took me quite some time to figure out what
  43. was going on, but the idea was quite clever once I figured it out.
  44.  
  45. First, your two EPROMs occupy 32 Kbytes of space.  When they are connected
  46. to CSBOOT and the CPU comes out of reset, it has CSBOOT configured for 1
  47. Mbyte of space.  The first thing the 332bug monitor does is vector to the
  48. starting address of the program at location 0x400 (actual value doesn't matter,
  49. just as long as it is in the EPROM space).  Since you only have 32 Kbytes
  50. of actual EPROM and CSBOOT is configured to access 1 Mbyte of space, the
  51. EPROM is phantom addressed all over the place.  The value stored at
  52. location 0x00000 shows up again at location 0x08000, 0x18000, 0x20000, etc.
  53. This keeps going on until you get to an address outside the range of
  54. CSBOOT.  Now things get tricky.
  55.  
  56. The 332bug monitor recognizes that the EPROM is phantom addressed all over
  57. the first 1 Mbyte of space.  The instruction at location 0x400 does a long
  58. jump to 0x20406, which just happens to contain the same instruction as
  59. location 0x406.  Since the EPROM is phantom addressed at this spot, the
  60. code continues to run, but the PC is now executing out of 0x20406 rather
  61. than 0x0406.  The instructions starting at location 0x20406 remaps CSBOOT
  62. so that it now points to 0x20000 (instead of the boot value of 0x00000) and
  63. the address range of CSBOOT is only 32 Kbytes in size, just the same as the
  64. EPROM chips it is addressing.  The monitor then remaps the RAM chip selects
  65. to begin at address 0x00000, thus putting RAM at address 0x00000 and the
  66. EPROM up higher.  You can set up your code to do this same kind of thing
  67. in your boot code.  If the eventual address of the EPROM is outside the 1
  68. Mbyte limit of CSBOOT, you will have to take these jumps in stages and
  69. remap the EPROM each time.  Since you want to get the EPROM up to the 4
  70. Mbyte address space, you will probably have to do 5 or six such jump
  71. steps.
  72.  
  73. Note that this solution is one that you describe as one of your options.
  74. It is a bit tricky (ok, it's _real_ tricky), but it does work.  I have a
  75. feeling that it is a bit difficult to debug if something goes wrong,
  76. however.  There may be some small amount of comfort in knowing that
  77. Motorola does it in their products.  If you pick this road, I'd suggest
  78. that you document the heck out of it, as it is quite subtle.
  79.  
  80.  
  81.  
  82. >I have considered several options, but there must be a simpler one.
  83.  
  84. >- Remap the eprom in software in stages to $80000, jump to *+$80000,
  85. >map to $100000, jump, then to $180000, etc. until $400000.
  86.  
  87. This is the method described above and is used by Motorola in their 332 bug
  88. monitor.  You should also think about exactly how tricky this might be to
  89. actually program into an assembler.  EPROM programmers have a hard time
  90. understanding the concept of phantom addressing, so describing the
  91. procedure for making your boot EPROMs could be difficult and error prone
  92. for any young turks that take over your product in the future.
  93.  
  94.  
  95. >- Download a small bootstrap program into the 68332's 2 KB ram,
  96. >which remaps the eprom to $400000, and then jumps to that new
  97. >address.
  98.  
  99. This will allow you to perform all the remappings quite simply in one step,
  100. but is also non-intuitive.
  101.  
  102.  
  103. >- Rely on the prefetch mechanism, just remap the eprom to $400000
  104. >and do a jump to *+$400000. But I don't think the 68332 does do a
  105. >prefetch when it encounters a jump.
  106.  
  107. I think I would stay away from this method if I were you.  I don't think
  108. the pre-fetch mechanism is deep enough for your purposes and would be a
  109. major pain to debug or modify later.
  110.  
  111.  
  112. >By the way, in my SIM manual page 3-39 describing the retry operation
  113. >is completely wrong. (It is more or less page 3-43.) Is there a new,
  114. >corrected printing available?
  115.  
  116. The latest manual I have is MC68332UM/AD and has only black writing on the
  117. cover.  There was an earlier manual with the number SIM32UM/AD and has a 
  118. gold box on the front.  This manual is old and has been superceded by the other.
  119. I would get the most recent if you don't have it.  If you find one that is
  120. different than the two I describe, please let me know.  It sounds as though
  121. you have the most recent manual, however.  Can you tell me which part of
  122. the retry operation is in error?  I don't have any answers, but I'd like to
  123. make a note in my manual in case I need it in the future.
  124.  
  125. I hope this helps.
  126.  
  127.  
  128. >Thanks,
  129. >Ben Stuyts (benstn@olivetti.nl)
  130.  
  131.   -dave
  132. -- 
  133. Dave McMahan                            mcmahan@netcom.com
  134.                     {apple,amdahl,claris}!netcom!mcmahan
  135.  
  136.