home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / os9 / 1570 < prev    next >
Encoding:
Text File  |  1993-01-06  |  3.8 KB  |  93 lines
  1. Newsgroups: comp.os.os9
  2. Path: sparky!uunet!usc!howland.reston.ans.net!bogus.sura.net!darwin.sura.net!haven.umd.edu!decuac!pa.dec.com!jrdzzz.jrd.dec.com!tkou02.enet.dec.com!wpowz.wpo.dec.com!zambotti
  3. From: zambotti@wpowz.wpo.dec.com (Walter Zambotti)
  4. Subject: CoCo III hardware reference
  5. Message-ID: <1993Jan6.094126.13005@news.jit.dec.com>
  6. Lines: 80
  7. Sender: usenet@news.jit.dec.com (USENET News System)
  8. Reply-To: zambotti@wpowz.wpo.dec.com (Walter Zambotti)
  9. Organization: Digital Equipment Corporation
  10. Date: Wed, 6 Jan 1993 09:41:26 GMT
  11. Lines: 80
  12.  
  13.  
  14. Hi all,
  15.  
  16. currently I have started writing a CoCo III simulator for UNIX.  My aim is to
  17. have some sort of a working version within a few months.
  18.  
  19. My intention is to have the working version running under the X11 environment.
  20. I am aiming at supporting the BASIC ROMs but will concentrate on the OS9
  21. environment first.
  22.  
  23. I am considering supporting cartridges but need to know about any legalities
  24. about copying these items.
  25.  
  26. Whats the legal story on copying software and firmware that is no longer sold
  27. or supported by the developing parties.  Doubt there could be any claim to
  28. monitory loss.
  29.  
  30. I have already started on the 6809 machine instruction emulator and also have
  31. the MMU address translator already worked out.
  32.  
  33. I need some further technical information on the workings of all the special
  34. device registers that are mapped into device memory.  I have Kevin's "INSIDE
  35. OS9 LEVEL II" manual but this is not complete.
  36.  
  37. Does anyone have a copy of the Tandy Color Computer Hardware maintainence
  38. manual?  Good!  Scan it in and send it on.
  39.  
  40. Because a device can be triggered when reading or writing to a memory location
  41. I need to know which devices actually are triggered by a read.  I can make
  42. substantial performance increases if I dont have to check every data read.
  43.  
  44. I also need to know about all the CoCo I/II graphics modes which aren't
  45. described in the CoCo II manual.
  46.  
  47. One of the major problems I have thought about is graphics memory displaying
  48. under X.  Most X engines wont have a 1 to 1 mapping with the graphics modes
  49. supported by the CoCo.  i.e. my machine has an 8 bit plane (256 simtaneous
  50. colors) graphics memory.  The CoCo supports 1,2 or 4 bits in a byte.  So a
  51. mapping is required.
  52.  
  53. So when ever a byte is written to the CoCo graphics within the emulator
  54.  
  55. (
  56. triggered by :
  57.  
  58.     translated_address >= screen_start_address &
  59.     translated_address <= screen_end_address
  60.  
  61.     screen_start_address can be found at word FF9D
  62.  
  63.     screen_end_address is screen_start_address + the mode size the
  64.         graphics device keeps track of this already so its only
  65.         evaluated once per mode/screen_start_address change
  66. )
  67.  
  68.  
  69. ..then an additional X call will be needed to set the pixel on the X window.
  70. So far this is easy.  The hard part is there can be more than one screen active
  71. on a CoCo at once.  BASIC and OS9 accomplish this by multiplexing the
  72. screen_start_address/mode registers for all the open screens.
  73.  
  74. Now I am currently monitoring all activity on the screen_start_address register
  75. so whenever it is changed I know that a new screen is selected.  What this
  76. doesn't tell me is if the previous screen was closed.  Performance wise I should
  77. just leave them all open even if they are only used once or twice.
  78.  
  79. Of course when ever a screen is selected in the screen_start_address register
  80. it will be necessary to repaint the entire screen pixel by pixel because
  81. the screen could have been modified while it was in the background!  This would
  82. make screen flipping flippin slow.
  83.  
  84. Any ideas appreciated.   Like monitoring the screen tables within the OS9
  85. grfdrv would be nice if I knew its ever changing address.  Or modify the
  86. grfdrv to write to a special register when ever a screen is closed and its
  87. memory released.  The last way is the most efficient but means modifying the
  88. grfdrv'r.
  89.  
  90. Anyway I be keeping you all informed of my progress and pains.
  91.  
  92. Walter
  93.