home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / atari / st / 17063 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  3.3 KB
  1. Path: sparky!uunet!mcsun!uknet!pyrltd!mwuk!tony
  2. From: tony@microware.co.uk (Tony Mountifield)
  3. Newsgroups: comp.sys.atari.st
  4. Subject: Re: More Falcon news...
  5. Message-ID: <1295@mwuk.UUCP>
  6. Date: 23 Nov 92 13:01:39 GMT
  7. References: <2349658@overmind.citadel> <1992Nov19.213205.86@uoft02.utoledo.edu>
  8. Organization: Microware Systems (UK) Ltd., Winchester, UK.
  9. Lines: 54
  10.  
  11. In article <1992Nov19.213205.86@uoft02.utoledo.edu> jsteiner@anwsun.phya.utoledo.edu (jason 'Think!' steiner) writes:
  12. > undermind!Steve_Johnson@overmind.mind.org writes:
  13. > > The Falcon030's 68030 has a 24-bit address/16-bit data bus.  It 
  14. > > get's a little confusing, though, because the COMBEL (the system 
  15. > > controller) has a 32-bit bus to RAM and to the VIDEL (the video 
  16. > > controller).  The machine on the whole, though, isn't a 'TRUE' 32-
  17. > > bit machine (kinda like the Mac LC II/Performa 400).  The PDS 
  18. > > (processor-direct slot) is also 24-bit address/16-bit data.  There 
  19. > > is some hope, though, that a third party will be able to 'fix' this 
  20. > > (there will, most definitely, be a 32-bit FAST RAM expansion for 
  21. > > the Falcon030 that will allow more RAM, at least, from what I've 
  22. > > heard). 
  23. > 
  24. > this is -really- strange. i was under the impression that all 68k
  25. > processors after the '020 were 32 bit all the way 'round. can someone
  26. > post a 'family tree' of the 68k series & what is what? going to
  27. > 24/16 for a 32 bit processor sounds like something Intel would do,
  28. > not Motorola.
  29. > 
  30. > i realize that Motorola doesn't have a lot to do with the bus design,
  31. > but it seems to me that trying to fit a 32 bit external processor
  32. > on a 24/16 bus would be a lot more hairy than just making it 32 bits
  33. > in the first place.
  34.  
  35. The 68020 and 68030 both have a feature called Dynamic Bus Sizing. This
  36. means that instead of a single DTACK to acknowledge the bus cycle, there
  37. is a pair of DSACK lines - DSACK0 and DSACK1. When the CPU wants to do a
  38. longword (32-bit) access, it places the data on all 32 data lines. The
  39. address decoding then determines whether the addressed device or memory
  40. can listen to all 32 or just 16 or 8. It then responds to the bus cycle
  41. with some combination of the DSACK lines to indicate whether 32, 16 or 8
  42. bits of data have been accepted. In the case of 32 the access is
  43. complete. Otherwise the data gets shifted over so the unaccepted part is
  44. on the part of the data bus that the accepted part was on, and another
  45. bus cycle is run. This keeps happening until all the data has been
  46. accepted (i.e. twice for a 16-bit port, and four times for an 8-bit
  47. port). Since the address decoding decides which DSACK lines will be used
  48. to acknowledge the cycle, it can have different addresses with different
  49. bus widths, e.g. 8-bit peripherals, 16-bit ROM, 32-bit RAM, etc.
  50.  
  51. The 68008, 68000, 68010 and 68070 don't have this facility, and neither
  52. does the 68040 (don't ask me why!).
  53.  
  54.  
  55. Tony.
  56.  
  57. -- 
  58. Tony Mountifield     (G4CJO)       | Microware Systems (UK) Ltd.
  59. -----------------------------------| Leylands Farm, Nobs Crook,
  60. Email:  tony@microware.co.uk       | Colden Common, WINCHESTER, SO21 1TH.
  61. (or:  ...!uknet!mwuk!tony)         | Tel: 0703 601990   Fax: 0703 601991
  62. ------------------------------------------------------------------------
  63. ** Any opinions are mine, not Microware's - but you knew that anyway. **
  64. ------------------------------------------------------------------------
  65.