From: zambotti@wpowz.wpo.dec.com (Walter Zambotti)
Subject: CoCo III hardware reference
Reply-To: zambotti@wpowz.wpo.dec.com (Walter Zambotti)
Organization: Digital Equipment Corporation
Date: Wed, 6 Jan 1993 09:41:26 GMT


Hi all,

currently I have started writing a CoCo III simulator for UNIX.  My aim is to
have some sort of a working version within a few months.

My intention is to have the working version running under the X11 environment.
I am aiming at supporting the BASIC ROMs but will concentrate on the OS9
environment first.

I am considering supporting cartridges but need to know about any legalities
about copying these items.

Whats the legal story on copying software and firmware that is no longer sold
or supported by the developing parties.  Doubt there could be any claim to
monitory loss.

I have already started on the 6809 machine instruction emulator and also have
the MMU address translator already worked out.

I need some further technical information on the workings of all the special
device registers that are mapped into device memory.  I have Kevin's "INSIDE
OS9 LEVEL II" manual but this is not complete.

Does anyone have a copy of the Tandy Color Computer Hardware maintainence
manual?  Good!  Scan it in and send it on.

Because a device can be triggered when reading or writing to a memory location
I need to know which devices actually are triggered by a read.  I can make
substantial performance increases if I dont have to check every data read.

I also need to know about all the CoCo I/II graphics modes which aren't
described in the CoCo II manual.

One of the major problems I have thought about is graphics memory displaying
under X.  Most X engines wont have a 1 to 1 mapping with the graphics modes
supported by the CoCo.  i.e. my machine has an 8 bit plane (256 simtaneous
colors) graphics memory.  The CoCo supports 1,2 or 4 bits in a byte.  So a
mapping is required.

So when ever a byte is written to the CoCo graphics within the emulator

(
triggered by :

	translated_address >= screen_start_address &
	translated_address <= screen_end_address

	screen_start_address can be found at word FF9D

	screen_end_address is screen_start_address + the mode size the
		graphics device keeps track of this already so its only
		evaluated once per mode/screen_start_address change
)


..then an additional X call will be needed to set the pixel on the X window.
So far this is easy.  The hard part is there can be more than one screen active
on a CoCo at once.  BASIC and OS9 accomplish this by multiplexing the
screen_start_address/mode registers for all the open screens.

Now I am currently monitoring all activity on the screen_start_address register
so whenever it is changed I know that a new screen is selected.  What this
doesn't tell me is if the previous screen was closed.  Performance wise I should
just leave them all open even if they are only used once or twice.

Of course when ever a screen is selected in the screen_start_address register
it will be necessary to repaint the entire screen pixel by pixel because
the screen could have been modified while it was in the background!  This would
make screen flipping flippin slow.

Any ideas appreciated.   Like monitoring the screen tables within the OS9
grfdrv would be nice if I knew its ever changing address.  Or modify the
grfdrv to write to a special register when ever a screen is closed and its
memory released.  The last way is the most efficient but means modifying the
grfdrv'r.

Anyway I be keeping you all informed of my progress and pains.

Walter