home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / m6809 / 573 < prev    next >
Encoding:
Text File  |  1993-01-11  |  5.3 KB  |  109 lines

  1. Newsgroups: comp.sys.m6809
  2. Path: sparky!uunet!usc!wupost!gumby!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!ee.ualberta.ca!ulan
  3. From: ulan@ee.ualberta.ca (Dale Ulan)
  4. Subject: Re: 68008 address demultiplers?.is it this simple?
  5. Message-ID: <ulan.726800288@ee.ualberta.ca>
  6. Sender: news@kakwa.ucs.ualberta.ca
  7. Nntp-Posting-Host: bode.ee.ualberta.ca
  8. Organization: University Of Alberta, Edmonton Canada
  9. References: <steveh.726715748@tasman>
  10. Date: Tue, 12 Jan 1993 00:58:08 GMT
  11. Lines: 96
  12.  
  13. steveh@tasman.cc.utas.edu.au (Steve Howell) writes:
  14.  
  15.  
  16.  
  17. >ok.. its been somewhat confirmed that a 6809 is not avail in a SMD package, so
  18. >i guess the time has come to go 68k at long last.
  19.  
  20. Congratulations on the step up. You should find the 68k quite versatile for
  21. your needs, if not overkill...
  22. I still like the 6809, but the 68000's registers are too huge... great if
  23. you are used to a smaller processor...
  24.  
  25. >just a few questions before i dive in...
  26. >can i do the following with a mc68008?
  27.  
  28.  Great choice.... 68008 is a great starting point
  29.  
  30. >1) can i use the upper address lines thru say a 74ls138 (3-to-8) decoder
  31. >to create the enable signal for each pheripherial?.. or do i need some
  32. >complex PAL or something (like everone elses uses that ive seen!)
  33.  
  34. Yes, you can demux the lines, but provide pullups on the address lines so
  35. that the 68008's hi-z mode does not cause false triggering.
  36. I used the 74154 16 line demux, but the 74138 should work fine.
  37. I am addicted to HC logic, but LS will work fine. I usually use HCT
  38. for mixing NMOS and CMOS circuitry, but only because of power consumption.
  39.  
  40.  
  41. >2) the E timing signal on the 68000. is it on the 68008?
  42.  
  43. Yes, but it is often easier NOT to deal with the E signal. Simply use
  44. the 8 MHz clock, giving a 4-cycle access time equal to 2 MHz (easy
  45. to get 8-bit peripherals for it), tie /AS and /DTACK together for 
  46. maximum memory throughput, and you can use /AS and /DS as inputs to your
  47. demux as INVERTED E signals. They should probably be combined (via OR),
  48. then inverted (use a NOR gate), and that will give you a quick and dirty
  49. E signal. With this, you can use the /AS and /DTACK to single-step the
  50. processor, one bus cycle at a time, providing you build a bit of extra
  51. logic. (it usually is not necessary, but it can be handy when debugging
  52. hardware-software interactions... better to have the facilities there).
  53. I am assuming that you want to have the lowest-parts-count system, yet
  54. not limit throughput by using low-speed peripherals.
  55. If you need different wait states, then you will probably need to use some
  56. PALs (EP600 does the job) to generate wait states. 
  57.  
  58. You can use the E clock if you do something with the /VPA and /VMA lines
  59. (similar to my /AS and /DTACK solution) The disadvantage is spped. You will
  60. have to check the timing specs on the 68008 to see how much slower it 
  61. would be.
  62.  
  63. My solution is not the best, but I think it is the easiest and highest
  64. throughput solution I have seen.
  65. Maximum throughput is supposed to be somewhere in the 2 MHz rate (I think).
  66. I don't have the timing diagrams right here...
  67.  
  68. What I am doing is using the 68008's internal delays to generate the data
  69. transfer ack signal straight from the address strobe signal. This is as fast
  70. as the 68000 bus will operate. The pseudo E signal (obtained from the strobes)
  71. is not going to be perfect in frequency, so timers should be run off of the
  72. processor's E clock. If you need timers, you may want to use the /VPA and /VMA
  73. lines to get constant 6800 peripheral access cycles. They are slower, though.
  74. For the price of complexity, you can run the timers on E (6800 cycle), but
  75. the rest on 68000 cycles. You have to decide.
  76.  
  77. >3) what is the base address for RAM ($0000 is what a 6809 is at, but i hear its
  78. >not this simple with 68k devices?.. is this right)
  79.  
  80. Vectors start at $000000. For a low parts count system, put EPROM there.
  81. The first locations should be the SSP and the reset Program Counter.
  82. Check the book for this...
  83. Most systems use some PAL stuff to substitute EPROM for RAM, and put the 
  84. vectors in RAM. This requires a 8-cycle counter to allow the first
  85. two 32-bit words to be loaded, then go to the normal memory map. This
  86. is handy, but it has too many parts. Since I ususally write embedded
  87. controllers, having RAM for vectors only means that I have to copy a
  88. table from ROM to RAM.  It is easier for me, then, to just run EPROM there.
  89.  
  90. I would suggest starting ROM from $000000, and RAM from whatever address is
  91. handy from the decoder. I usually had EPROM from $000000 to $03FFFF, which
  92. is very large for EPROM, and run the RAM right above that. It really does
  93. not matter, since the stacks are set up by your program.
  94.  
  95. The way I usually see this done is to put ram at $000000 and rom at a
  96. very high location, but I don't like this approach, mainly because of the
  97. added circuitry required.
  98.  
  99. >4) Can i put ROM anywhere i like in the address map? (as long as its big enough)
  100.  
  101. See comment #3. Like I said, put it in the BOTTOM, so you don't need any
  102. fancy switching circuitry... The alternative, if you need RAM vectors, but
  103. don't want the switching circuitry, is to hard-code the vectors to a JUMP
  104. table in RAM. This allows the advantages of changable vectors, and a simple
  105. design.
  106.  
  107. ----------------------------------------------------------------------------
  108. Dale Ulan  VE6DAU        ulan@ee.ualberta.ca   Computer Eng. Undergrad
  109.