home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2968 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB
  1. Path: munnari.OZ.AU!metro!metro!news
  2. From: accolyte@wr.com.au (Accolyte)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: need help on A1200/030 board programming
  5. Date: 7 Feb 1996 13:30:44 GMT
  6. Organization: Information Services, The University of Sydney, NSW, Australia
  7. Distribution: inet
  8. Message-ID: <1578.6612T18T1581@wr.com.au>
  9. References: <4f4hiu$oum@ionews.io.org>
  10. NNTP-Posting-Host: dialup36.wr.com.au
  11. X-Newsreader: THOR 2.22 (Amiga;TCP/IP) *UNREGISTERED*
  12.  
  13.  
  14. > Hello,
  15. >
  16. > this will sound strange, but here's what happens.
  17. > We have been testing some of the 030 boards for A1200 (Amiga Power,
  18. > DKB...), and got some strange results.
  19. >
  20. > It appears that these boards are almost two times slower when accessing
  21. > CHIP RAM, than a basic A1200 (no acel. no extra RAM)!?
  22. >
  23. > 12 gauge, Blizzard and others, on the other hand, are two times faster
  24. > (which is normal).
  25. >
  26. > So, the question is - is there a solution to make these 030s access
  27. > CHIP RAM at normal speed?
  28.  
  29. I had a theory about.. well, let me explain:
  30.  
  31. Say you have an 030 at 50MHz, and presuming the internal 020 is clocked
  32. to 14. As I understand it, this comes from a 28MHz crystal that is
  33. sent to the chip-ram and custom chips, etc before being halved and sent
  34. to the processor.
  35.  
  36. If you could replace that 28MHz clock with a 56MHz one, send that straight
  37. to the 030, halve it then put the resulting 28MHz signal into the normal
  38. pathway that goes to the custom chips and is halved again before reaching
  39. the processor. This would give you a slightly overclocked 030 that's
  40. perfectly timed with the chip-ram, and hopefully giving optimal performance.
  41.  
  42. Unfortunately, theorising is the limit of my hardware knowledge. Could
  43. some people more experienced in hardware comment on it's feasability?
  44.  
  45.  
  46. For the moment though, the only solution seems to be using fast ram
  47. whenever possible if it is present. Certainly for the code, and
  48. for the source bitmaps wherever it's possible. It might mean a seperate
  49. routine to replace straight blits, but the result would be great 
  50. improvement.
  51.  
  52.  
  53.  
  54.