mirror of
https://github.com/aaru-dps/docs.git
synced 2025-12-16 19:24:38 +00:00
1487 lines
54 KiB
HTML
1487 lines
54 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
|
|
<html>
|
|
|
|
<head>
|
|
<meta http-equiv="Content-Type"
|
|
content="text/html; charset=iso-8859-1">
|
|
<meta name="Author" content="David Keil">
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 2.0">
|
|
<title>Color Computer Emulator v1.00 Documentation (Technical)</title>
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<p><a name="Technical"></a><font size="5"><b>Technical Info:</b></font>
|
|
</p>
|
|
|
|
<p>What follows is technical information for users who want to
|
|
know more about the emulator or want to develop support programs
|
|
for the emulator or new software for the Color Computer running
|
|
on the emulator. Nothing contained here is required to use the
|
|
emulator. </p>
|
|
|
|
<p><a href="../../~dmkeil/coco/cocodoc.htm#Contents">Return to contents:</a> </p>
|
|
|
|
<hr align="left">
|
|
|
|
<p><a name="Technical-DMK-disks"></a><font size="5"><b>Technical
|
|
info - DMK type virtual disks:</b></font> </p>
|
|
|
|
<p>This information on what has become known as the DMK virtual
|
|
disk format is provided for users wanting to better understand
|
|
the operation of the emulator and for programmers writing their
|
|
own emulators wanting to add support for this format and/or the
|
|
creation of PC utilities to work with the DMK virtual disk
|
|
format. </p>
|
|
|
|
<p>This virtual disk format is as close to the way data on a real
|
|
disk is stored as possible. There is very little added overhead
|
|
and the data is easily examined and edited using PC based hex
|
|
editors. The actual design is really quite simple and enables
|
|
support of ALL the WD-1771 and WD-19xx controller functions and
|
|
formats. While the design is simple however the programming
|
|
requirements for this format are much more extensive then for the
|
|
JV1/JV3 formats. </p>
|
|
|
|
<p><font size="4">Disk header:</font> </p>
|
|
|
|
<p>Virtual disks have a 16 byte disk header which is initialized
|
|
when the user creates a new virtual disk. This header may be
|
|
modified before or after a virtual disk has been formatted to
|
|
change some of its characteristics. </p>
|
|
|
|
<table border="1" width="100%" cols="2">
|
|
<tr>
|
|
<td width="15%">Byte 0</td>
|
|
<td width="85%">If this byte is set to FFH the disk is
|
|
`write protected', 00H allows writing.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 1</td>
|
|
<td width="85%">Number of tracks on virtual disk. Since
|
|
tracks start at 0 this value will be one greater than the
|
|
highest track written to the disk. So a disk with 35
|
|
tracks will have a value of 35 (23H) in this field after
|
|
formatting while the highest track written would be 34.
|
|
This field is updated after a track is formatted if the
|
|
track formatted is greater than or equal to the current
|
|
number of tracks. Re-formatting a disk with fewer tracks
|
|
will NOT reduce the number of tracks on the virtual disk.
|
|
Once a virtual disk has allocated space for a track it
|
|
will NEVER release it. Formatting a virtual disk with 80
|
|
tracks then re-formatting it with 35 tracks would waste
|
|
space just like formatting only 35 tracks on an 80 track
|
|
drive. The emulator and COCO operating systems don't
|
|
care. To re-format a virtual disk with fewer tracks use
|
|
the re-create the virtual disk first, then re-format to
|
|
save space. <p>Note: This field should NEVER be
|
|
modified. Changing this number will cause COCO operating
|
|
system disk errors. (Like reading an 80 track disk in a
|
|
35 track drive)</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 2 & 3</td>
|
|
<td width="85%">This is the track length for the virtual
|
|
disk. By default the value is 1900H, 80H bytes more than
|
|
the actual track length, this gives a track length of
|
|
6272 bytes. A real double density track length is aprox.
|
|
6250 bytes. This is the default value when a virtual disk
|
|
is created. Values for other disk and format types are
|
|
0CC0H for single density 5.25" floppies, 14E0H for
|
|
single density 8" floppies and 2940H for double
|
|
density 8" floppies. The max value is 2940H. For
|
|
normal formatting of disks the values of 1900H and 2940H
|
|
for 5.25" and 8" are used. The emulator will
|
|
write two bytes and read every second byte when in
|
|
single density to maintain proper sector spacing,
|
|
allowing mixed density disks. Setting the track length
|
|
must be done before a virtual disk is formatted or the
|
|
disk will have to be re-formatted and since the space for
|
|
the disk has already been allocated no space will be
|
|
saved. <p>WARNING: Bytes are entered in reverse
|
|
order (ex. 2940H would be entered, byte 2=40, byte
|
|
3=29). <br>
|
|
Note: No modification of the track length is necessary,
|
|
doing so only saves space and is not necessary to normal
|
|
operation. The values for all normal 5.25" and
|
|
8" disks are set when the virtual disk is created.
|
|
DON'T modify the track length unless you understand these
|
|
instructions completely. Nothing in the PC world can be
|
|
messed up by improper modification but any other virtual
|
|
disk mounted in the emulator with an improperly modified
|
|
disk could have their data scrambled.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 4</td>
|
|
<td width="85%">Virtual disk option flags. <p>Bit 4
|
|
of this byte, if set, means this is a single sided ONLY
|
|
disk. This bit is set if the user selects single sided
|
|
during disk creation and should not require modification.
|
|
This flag is used only to save PC hard disk space and is
|
|
never required. </p>
|
|
<p>Bit 6 of this byte, if set, means this disk is to be
|
|
single density size and the emulator will access one byte
|
|
instead of two when doing I/O in single density. Double
|
|
density can still be written to a single density disk but
|
|
with half the track length only 10 256 byte sectors can
|
|
be written in either density. Mixed density is also
|
|
possible but sector timing may be off so protected disks
|
|
may not work, a maximum of 10 256 byte sectors of mixed
|
|
density can be written to a single density disk. A
|
|
program like "Spook House" which has a mixed
|
|
density track 0 with 1 SD sector and 1 DD sector and the
|
|
rest of the disk consisting of 10 SD sectors/track will
|
|
work with this flag set and save half the PC hard disk
|
|
space. The protected disk "Super Utility + 3.0"
|
|
however has 6 SD and 6 DD sectors/track for a total of 12
|
|
256 byte sectors/track. This disk cannot be single
|
|
density. </p>
|
|
<p>This bit is set if the user selects single density
|
|
during disk creation and should not require modification.
|
|
This flag is used only to save PC hard disk space and is
|
|
never required. </p>
|
|
<p>Bit 7 of this byte, if set, means density is to be
|
|
ignored when accessing this disk. The disk MUST be
|
|
formatted in double density but the emulator will then
|
|
read and write the sectors in either density. The
|
|
emulator will access one byte instead of two when doing
|
|
I/O in single density. </p>
|
|
<p>This flag was an early way to support mixed density
|
|
disks it is no longer needed for this purpose. It is now
|
|
used for compatibility with old virtual disks created
|
|
without the double byte now used when in single density.
|
|
This bit can be set manually in a hex editor to access
|
|
old virtual disks written in single density.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 5-B</td>
|
|
<td width="85%">reserved for future options</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte C-F</td>
|
|
<td width="85%">Must be zero if virtual disk is in
|
|
emulator's native format. <p>Must be 12345678h if
|
|
virtual disk is a REAL disk specification file used to
|
|
access REAL COCO floppies in compatible PC drives.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Track Header</td>
|
|
<td width="85%">Each track has a 128 (80H) byte header
|
|
which contains an offset to each IDAM in the track. This
|
|
is created during format and should NEVER require
|
|
modification. The actual track data follows this header
|
|
and can be viewed with a hex editor showing the raw data
|
|
on the track. Modification should not be done as each
|
|
IDAM and sector has a CRC, this is just like a real disk,
|
|
and modifying the sector data without updating the CRC
|
|
value will cause CRC errors when accessing the virtual
|
|
disk within the emulator. <p>Note: Modification
|
|
within MSDOS could however be done to emulate a protected
|
|
disk in the TRS-80 & COCO emulators.</p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p><font color="#000000" size="4">Track header:</font> </p>
|
|
|
|
<p>Each side of each track has a 128 (80H) byte header which
|
|
contains an offset pointer to each IDAM in the track. This allows
|
|
a maximum of 64 sector IDAMs/track. This is more than twice what
|
|
an 8 inch disk would require and 3.5 times that of a normal
|
|
TRS-80/COCO 5 inch DD disk. This should more than enough for any
|
|
protected disk also. </p>
|
|
|
|
<p>These IDAM pointers MUST adhere to the following rules. </p>
|
|
|
|
<ul>
|
|
<li>Each pointer is a 2 byte offset to the FEh byte of the
|
|
IDAM. In double byte single density the pointer is to the
|
|
first FEh.</li>
|
|
<li>The offset includes the 128 byte header. For example, an
|
|
IDAM 10h bytes into the track would have a pointer of
|
|
90h, 10h+80h=90h.</li>
|
|
<li>The IDAM offsets MUST be in ascending order with no
|
|
unused or bad pointers.</li>
|
|
<li>If all the entries are not used the header is terminated
|
|
with a 0000h entry. Unused entries must also be zero
|
|
filled..</li>
|
|
<li>Any IDAMs overwritten during a sector write command
|
|
should have their entry removed from the header and all
|
|
other pointer entries shifted to fill in.</li>
|
|
<li>The IDAM pointers are created during the track write
|
|
command (format). A completed track write MUST remove all
|
|
previous IDAM pointers. A partial track write (aborted
|
|
with the forced interrupt command) MUST have it's
|
|
previous pointers that were not overwritten added to the
|
|
new IDAM pointers.</li>
|
|
<li>The pointer bytes are stored in reverse order (LSB/MSB).</li>
|
|
</ul>
|
|
|
|
<p>Each IDAM pointer has two flags. Bit 15 is set if the sector
|
|
is double density. Bit 14 is currently undefined. These bits must
|
|
be masked to get the actual sector offset. For example, an offset
|
|
to an IDAM at byte 90h would be 0090h if single density and 8090h
|
|
if double density. </p>
|
|
|
|
<p><font size="4">Track data:</font> </p>
|
|
|
|
<p>The actual track data follows the header and can be viewed
|
|
with a hex editor showing the raw data on the track. If the
|
|
virtual disk doesn't have bits 6 or 7 set of byte 4 of the disk
|
|
header then each single density data byte is written twice, this
|
|
includes IDAMs and CRCs (the CRCs are calculated as if only 1
|
|
byte was written however). The IDAM and sector data each have
|
|
CRCs, this is just like on a real disk. </p>
|
|
|
|
<p>Modification should not be done since doing so without
|
|
updating the CRCs would cause data errors. Modification
|
|
could be done however to create protected tracks for importing
|
|
protected disks to virtual disk format. Examples of disks created
|
|
using this technique are the TRS-80 programs "Super Utility+
|
|
3.0" and "Forbidden City". </p>
|
|
|
|
<p><a href="../../~dmkeil/coco/cocodoc.htm#Contents">Return to contents:</a> </p>
|
|
|
|
<hr align="left">
|
|
|
|
<p><a name="Technical-JV1-disks"></a><font size="5"><b>Technical
|
|
info - JV1/JV3 type virtual disks:</b></font> </p>
|
|
|
|
<p>This emulator is capable of reading and writing to JV1/JV3
|
|
type virtual disks. Support for this type of virtual disk is
|
|
limited by both the limits of the format type and this emulators
|
|
support of it. </p>
|
|
|
|
<p>The emulator supports read sector, read address and write
|
|
sector commands to the JV1 type virtual disk. JV1 disks are
|
|
single density (Model 1) and double density (COCO), only. They
|
|
can be up to 254 tracks long and always have a protected
|
|
directory track at track 17. Read track and write track commands
|
|
are not supported for this disk type. This disk type can be
|
|
write protected from the "virtual floppy disk selection
|
|
screen" but the write protect status will always default to
|
|
off when ever a JV1 disk is opened. </p>
|
|
|
|
<p>The emulator supports read sector, read address and write
|
|
sector commands to the JV3 type virtual disk. JV3 disks are
|
|
single/double density and can be up to 96 tracks long. Read track
|
|
and write track commands are not supported for this disk type.
|
|
This disk type can be write protected from the
|
|
"virtual floppy disk selection screen" but the write
|
|
protect status will always default to what ever status is in the
|
|
the JV3 virtual disk file (byte 21FFh) when the disk is opened,
|
|
the write protect status is not updated. The density and CRC
|
|
error flags are also supported but not updated. DAM types FB/F9
|
|
report FB and F8/FA report F8. Sector writes that change the DAM
|
|
type from what is in the virtual disk file are not supported.
|
|
This will not cause problems unless you try to change the
|
|
protection status of a directory track. Standard IBM sector sizes
|
|
are supported of 128, 256, 512 & 1024 bytes. A second sector
|
|
header block is not supported. </p>
|
|
|
|
<p><a href="../../~dmkeil/coco/cocodoc.htm#Contents">Return to contents:</a> </p>
|
|
|
|
<hr align="left">
|
|
|
|
<p><a name="Technical-REAL-disks"></a><font size="5"><b>Technical
|
|
info - REAL COCO floppy disks:</b></font> </p>
|
|
|
|
<p>This emulator is capable of reading, writing and formatting
|
|
REAL COCO floppy disks in compatible PC floppy drives. Support
|
|
for this is limited by both the limits of the NEC type floppy
|
|
disk controller and this emulators support of it. </p>
|
|
|
|
<p>Depending on compatibility of your PC you should be able to
|
|
read/write single density & double density 5.25" and
|
|
3.5" disks in 360k and 720k PC floppy drives (commonly known
|
|
as low/double density drives, DD). You should be able to
|
|
read/write double density 5.25" and 3.5" disks in
|
|
1.2meg and 1.44meg PC floppy drives (commonly known as high
|
|
density drives, HD). </p>
|
|
|
|
<p>Eight fixed sector length REAL floppy specification virtual
|
|
disks are supplied to read/write 256 byte/sector floppies in a
|
|
PC's A: and B: drives. </p>
|
|
|
|
<table border="1" width="100%" cols="2">
|
|
<tr>
|
|
<td width="20%">FDD0_360.DSK</td>
|
|
<td width="80%">Reads 35/40 track disks on a PC A: 360k
|
|
(DD) drive.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FDD1_360.DSK</td>
|
|
<td width="80%">Reads 35/40 track disks on a PC B: 360k
|
|
(DD) drive</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FHD0_360.DSK</td>
|
|
<td width="80%">Reads 35/40 track disks on a PC A: 1.2meg
|
|
(HD) drive. (double steps head)</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FHD1_360.DSK</td>
|
|
<td width="80%">Reads 35/40 track disks on a PC B: 1.2meg
|
|
(HD) drive. (double steps head)</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FHD0_720.DSK</td>
|
|
<td width="80%">Reads 80 track disks on a PC A: 1.2meg
|
|
(HD) drive.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FHD1_720.DSK</td>
|
|
<td width="80%">Reads 80 track disks on a PC B: 1.2meg
|
|
(HD) drive.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">F350_720.DSK</td>
|
|
<td width="80%">Reads 80 track 3.5" disks on a PC A:
|
|
1.44meg (HD) drive.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">F351_720.DSK</td>
|
|
<td width="80%">Reads 80 track 3.5" disks on a PC B:
|
|
1.44meg (HD) drive.</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>Eight variable sector length REAL floppy specification virtual
|
|
disks are supplied to read/write 128-1024 byte/sector floppies in
|
|
a PC's A: and B: drives. These specification disks are slower
|
|
than the fixed length ones and should only be used on disks
|
|
un-readable with the fixed length specification disks. </p>
|
|
|
|
<table border="1" width="100%" cols="2">
|
|
<tr>
|
|
<td width="20%">VDD0_360.DSK</td>
|
|
<td width="80%">Reads 35/40 track disks on a PC A: 360k
|
|
(DD) drive.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">VDD1_360.DSK</td>
|
|
<td width="80%">Reads 35/40 track disks on a PC B: 360k
|
|
(DD) drive</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">VHD0_360.DSK</td>
|
|
<td width="80%">Reads 35/40 track disks on a PC A: 1.2meg
|
|
(HD) drive. (double steps head)</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">VHD1_360.DSK</td>
|
|
<td width="80%">Reads 35/40 track disks on a PC B: 1.2meg
|
|
(HD) drive. (double steps head)</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">VHD0_720.DSK</td>
|
|
<td width="80%">Reads 80 track disks on a PC A: 1.2meg
|
|
(HD) drive.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">VHD1_720.DSK</td>
|
|
<td width="80%">Reads 80 track disks on a PC B: 1.2meg
|
|
(HD) drive.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">V350_720.DSK</td>
|
|
<td width="80%">Reads 80 track 3.5" disks on a PC A:
|
|
1.44meg (HD) drive.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">V351_720.DSK</td>
|
|
<td width="80%">Reads 80 track 3.5" disks on a PC B:
|
|
1.44meg (HD) drive.</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>Because of the limitations of the PC's NEC type floppy disk
|
|
controller the PC cannot read most protected disks. The emulator
|
|
does not support the track read commands with REAL floppies.
|
|
Because of limitations of the PC's controller most disk zap
|
|
utilities (like Hyperzap and Super Utility) cannot work with REAL
|
|
floppies. Also the write track command has to translate format
|
|
data to the PC's controller form and is therefore unable to
|
|
format anything but standard sectors. Because of the translation
|
|
for PC disk I/O, access to real TRS-80 disks is apt to be slow,
|
|
formatting in some cases can take as long as 8 seconds/track.
|
|
This is unavoidable and should not present problems since REAL
|
|
disk support is mainly for importing your existing COCO disks and
|
|
transferring data and programs to the COCO. If your PC has a hard
|
|
time reading your COCO disks then use the emulator to format a
|
|
disk on the PC and then copy the disk on the COCO to the PC
|
|
formatted disk, this should correct most problems. </p>
|
|
|
|
<p>Some PC's cannot read any COCO disks without errors. This is a
|
|
compatibility problem with different PC controllers and not a
|
|
problem with the emulator. Try using a different brand of PC or
|
|
an older model PC. If you are still unable to read your disks and
|
|
really need the data converted, e-mail me and maybe I can convert
|
|
the disk for you (my PC has been able to read every disk I've
|
|
tried so far). </p>
|
|
|
|
<p><a href="../../~dmkeil/coco/cocodoc.htm#Contents">Return to contents:</a> </p>
|
|
|
|
<hr>
|
|
|
|
<p><a name="Technical-HDV-disk"></a><font size="5"><b>Technical
|
|
info - Virtual hard disks:</b></font> </p>
|
|
|
|
<p>This information on what are known as the HDV virtual hard
|
|
disks is provided for users wanting to better understand the
|
|
operation of the emulator and for programmers writing their own
|
|
emulators wanting to add support for this format and/or the
|
|
creation of PC utilities to work with the HDV virtual disk
|
|
format.</p>
|
|
|
|
<p>Currently the COCO emulator does not support hard disks. This
|
|
is the current HDV format that is used by other TRS-80 emulators
|
|
and is provided so a compatible hard disk driver can be written
|
|
for the COCO.</p>
|
|
|
|
<p>The existing HDV format has been extended to support 1024
|
|
cylinder hard drives using the WD1010 hard drive controller
|
|
emulation.</p>
|
|
|
|
<p><font size="4">Disk header:</font> </p>
|
|
|
|
<p>Virtual hard disks have a 256 byte disk header which is
|
|
initialized when the user creates a new virtual disk. This header
|
|
may be modified before or after a virtual disk has been formatted
|
|
to change some of its characteristics. </p>
|
|
<div align="center"><center>
|
|
|
|
<table border="1" width="100%">
|
|
<tr>
|
|
<td width="15%">Byte 0 & 1</td>
|
|
<td width="85%">Identifier 56h & CBh</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 2</td>
|
|
<td>Version: set to 11h when file created (version 1.1)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 3</td>
|
|
<td>Checksum of bytes 0-31 (excepting byte 3) XORed with
|
|
4Ch</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 4</td>
|
|
<td>Number of 256 byte blocks in header: should be 1<br>
|
|
(anything other than 1 is not supported by this emulator)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 5</td>
|
|
<td>-unused- Currently set to 4 for compatibility</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 6</td>
|
|
<td>Media type: 0 for hard disk</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 7</td>
|
|
<td>Bit 7 set if hard disk is write protected, all other
|
|
bits -unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 8 & 9</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 10</td>
|
|
<td>FFh = created with this emulator</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 11</td>
|
|
<td>-unused- (DOS type)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 12</td>
|
|
<td>Creation month</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 13</td>
|
|
<td>Creation day</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 14</td>
|
|
<td>Creation year (offset from 1900)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 15-26</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 27</td>
|
|
<td>If 'byte 10' = FFh then bits 0-1 contains high bits
|
|
of cylinder count (max value 1024)<br>
|
|
else -unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 28</td>
|
|
<td>If 'byte 10' = FFh then contains low byte of cylinder
|
|
count<br>
|
|
else contains total number of cylinders on disk </td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 29</td>
|
|
<td>Number of sectors per cylinder<br>
|
|
This value must be divisible by 32. A value of 00h = 256
|
|
sectors</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 30</td>
|
|
<td>-unused- but is set to 'byte 29' divided by 16 when
|
|
file created (granules per cylinder)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 31</td>
|
|
<td>-unused- but is set to 1 when file created (directory
|
|
cylinder)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 32-63</td>
|
|
<td>Volume label, set to TRS80 or COCO when file is
|
|
created (31 bytes terminated by 00h)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 64-71</td>
|
|
<td>-unused- (Creation filename)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>Byte 72-255</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
</table>
|
|
</center></div>
|
|
|
|
<p><font color="#FF0000"><strong>WARNING: </strong>Once hard disk
|
|
support is added to the COCO emulator this file layout may have
|
|
minor changes.</font></p>
|
|
|
|
<p><a href="../../~dmkeil/coco/cocodoc.htm#Contents">Return to contents:</a> </p>
|
|
|
|
<hr align="left">
|
|
|
|
<p><a name="Technical-MC6809"></a><font size="5"><b>Technical
|
|
Info - Enhanced MC6809 instructions</b></font></p>
|
|
|
|
<p><font size="3">The emulator has a set of enhanced MC6809
|
|
instructions. These instructions allow COCO programs to interface
|
|
with the PC's disk drives, ports, memory and other hardware.
|
|
These instructions also add high level math functions to the
|
|
MC6809 instruction set.</font></p>
|
|
|
|
<p><font size="3"><strong>NOTE: </strong>These instructions are
|
|
only available in the emulators.</font></p>
|
|
|
|
<p>The following links contain a list of the enhanced
|
|
instructions and documentation for each instruction.</p>
|
|
|
|
<p><a href="../../~dmkeil/coco/coco6809.htm">Enhanced Instruction Documentation</a>
|
|
(on-line)</p>
|
|
|
|
<p><a href="../../~dmkeil/coco/coco6809.doc">Enhanced Instruction Documentation</a>
|
|
(Microsoft Word 96k)</p>
|
|
|
|
<p><a href="../../~dmkeil/coco/cocodoc.htm#Contents">Return to contents:</a> </p>
|
|
|
|
<hr>
|
|
|
|
<p><a name="Technical-I/O"></a><font size="5"><b>Technical Info -
|
|
Memory mapped PC I/O commands</b></font></p>
|
|
|
|
<p><font size="3">In addition to the enhanced MC6809 instructions
|
|
described above the emulator can also interface with the PC using
|
|
memory mapped commands. These commands provide an easier to use
|
|
interface when writing programs in BASIC or other high level
|
|
language eliminating the need for machine language calls.</font></p>
|
|
|
|
<p><font size="3">The memory mapped I/O commands allow access to
|
|
the I/O functions between $10 and $1F as defined in the </font><a
|
|
href="../../~dmkeil/coco/coco6809.htm">Enhanced Instruction Documentation</a>.
|
|
Access to the other enhanced instructions 00-$0F are also
|
|
possible but are less useful in BASIC programs.</p>
|
|
|
|
<p>These memory mapped I/O commands also allow access to the PC's
|
|
hardware clock, PC's I/O ports & PC mouse.</p>
|
|
|
|
<p>These memory mapped functions use the MC6809 memory address
|
|
$FFE0-FFEF:</p>
|
|
|
|
<hr width="50%">
|
|
|
|
<p>Memory addresses $FFE0-$FFE7 allow access to up to 16
|
|
different sets of I/O data. These data sets can be either 8bit or
|
|
16bit values. The set of data available is determined by memory
|
|
address $FFEF. When a value between 0 and 15 is written to $FFEF
|
|
the desired set of data is mapped into memory $FFE0-FFE7. When
|
|
the data set is 16bit, each memory address must be read/written
|
|
twice to load/store the 16 bit value.</p>
|
|
|
|
<p>When accessing 16bit values, each read/write of memory
|
|
$FFE0-FFE7 toggles which 8bits are available. Therefore when
|
|
accessing 16bit data knowing which 8bits are currently available
|
|
is very important. To make this possible, anytime $FFEF is
|
|
written to, the high 8bits of the 16bit word is always selected.
|
|
Then by accessing each memory address twice the programmer will
|
|
always know which 8bits of the 16bit value are available.</p>
|
|
|
|
<p>For example to write the 16bit value of $1234 to $FFE0 do the
|
|
following:</p>
|
|
|
|
<p>POKE &HFFEF, 3: REM TO INSURE THE HIGH 8BITS OF DATA SET 3
|
|
ARE SELECTED<br>
|
|
POKE &HFFE0,&H12<br>
|
|
POKE &HFFE0,&H34</p>
|
|
|
|
<p>After writing &H34 to the low 8bits of &HFFE0,
|
|
$FFE0-$FFE7 are again pointing to the high 8bits. To read the
|
|
data back, writing to $FFEF is not necessary since we know which
|
|
8bits are selected. A read or write to any address $FFE0-$FFE7
|
|
controls which 8bits all the memory addresses $FFE0-$FFE7 point
|
|
to. </p>
|
|
|
|
<p>For example executing the following:</p>
|
|
|
|
<p>POKE &HFFEF, 3: REM TO INSURE THE HIGH 8BITS OF DATA SET 3
|
|
ARE SELECTED<br>
|
|
PRINT PEEK(HFFE0)<br>
|
|
POKE &HFFE1,0</p>
|
|
|
|
<p>would print the high 8bit value of the 16bit value stored in
|
|
$FFE0 and then write a zero to the low 8bits of the 16bit value
|
|
stored at $FFE1. This is more than likely not what the programmer
|
|
wanted.</p>
|
|
|
|
<hr width="50%">
|
|
|
|
<p>Writing to memory address $FFEE is used to execute enhanced
|
|
MC6809 instructions. Valid values are $00-$1F. Each value
|
|
corresponds to the second byte of an enhanced instruction. A
|
|
write to $FFEE of a valid command executes the corresponding
|
|
enhanced instruction. The instruction uses the values stored in
|
|
memory addresses $FFE0-$FFE7 instead of the work area defined by
|
|
register U and memory addresses $FFE8-$FFE9 instead of registers
|
|
A & B that the instruction would have used when executed
|
|
using assembler language. Memory addresses $FFE0-FFE9 must be
|
|
initialized before execution of an enhanced instruction.</p>
|
|
|
|
<p>Reading from memory address $FFEE will return the status of
|
|
the last enhanced instruction executed.</p>
|
|
|
|
<p>Memory addresses $FFE0-$FFE7 must be initilized to data set 0
|
|
by writing zero to $FFEF. Then, the up to 8 bytes of data used by
|
|
the enhanced instruction is loaded into memory addresses
|
|
$FFE0-$FFE7. Memory address $FFE8-$FFE9 always point to the last
|
|
values sent to or returned by the last enhanced instruction
|
|
executed, regardless of the setting of $FFEF.</p>
|
|
|
|
<p>The values stored in memory address $FFE8-$FFE9 are loaded
|
|
into register A & B when executing enhanced MC6809
|
|
instructions. After an enhanced instruction's execution $FFE8
|
|
contains the register A value and $FFE9 contains register CC
|
|
(condition codes) returned by the enhanced instruction.</p>
|
|
|
|
<hr width="50%">
|
|
|
|
<p>Some program listings of BASIC programs are available as
|
|
examples of using the memory mapped I/O commands:</p>
|
|
|
|
<p><a href="../../~dmkeil/coco/cocobas.htm">BASIC Examples</a></p>
|
|
|
|
<p><a href="../../~dmkeil/coco/cocodoc.htm#Contents">Return to contents:</a> </p>
|
|
|
|
<hr>
|
|
|
|
<p><a name="Technical-mouse"></a><font size="5"><b>Technical info
|
|
- Memory mapped PC mouse functions:</b></font> </p>
|
|
|
|
<p>The PC's mouse can be accessed from BASIC, assembler and other
|
|
COCO languages through memory mapped I/O (see previous topic).
|
|
Through simple reads and writes to COCO memory a COCO program can
|
|
read the PC's mouse buttons and get its X & Y coordinates.</p>
|
|
|
|
<p>Writing a value of 4 to $FFEF will make the mouse I/O values
|
|
available for access. The mouse values are 16bit and require two
|
|
reads or writes to access all the values except for the buttons
|
|
and sensitivity. These two 8bit values are also 16bit but the
|
|
8bit value is mirrored so a single read or write will access
|
|
these values.</p>
|
|
|
|
<p>To read the PC mouse the program needs to read memory address
|
|
$FFE0. This will load the X & Y coordinate values and return
|
|
the current button status.</p>
|
|
|
|
<p>The button status shows which buttons have been pushed and
|
|
which are currently pushed. Once a particular button has been
|
|
pushed that flag will remain set until it is cleared by writing a
|
|
zero to its bit at memory address $FFE0.</p>
|
|
|
|
<p>To get the current X & Y coordinates the program must read
|
|
$FFE1 (X coordinate) and $FFE2 (Y coordinate) twice. For example
|
|
the X coordinate is, the first value read at $FFE1 multiplied by
|
|
256 plus the second value read at $FFE1. The same is true for the
|
|
Y coordinate.</p>
|
|
|
|
<p><strong>Note: This assumes that the high byte of the 16bit
|
|
value is available first. A read from memory address $FFEF will
|
|
insure this condition. From that point on as long as the program
|
|
always reads or writes each mouse I/O address twice the program
|
|
will always be sure of the value available at each address.</strong></p>
|
|
|
|
<p>The X & Y coordinate value returned is based on the PC's
|
|
mouse movement and the minimum, maximum and sensitivity values
|
|
loaded for the X & Y coordinates. The coordinate returned
|
|
will always be in the range of the minimum and maximum values.
|
|
The min/max values are 16bit values and are read and written the
|
|
same way the actual coordinates are. The sensitivity is an 8bit
|
|
value. The low 4bits the X axis sensitivity, the high 4bits the Y
|
|
axis sensitivity. The larger the value the more sensitive that
|
|
axis is.</p>
|
|
|
|
<p>Once the minimum, maximum and sensitivity values are loaded a
|
|
program only need read $FFE0 to read the PC mouse buttons and
|
|
update the X & Y coordinates then read $FFE1 & $FFE2 to
|
|
read the X & Y coordinates. The emulator will insure the
|
|
returned X & Y coordinates are always within the defined
|
|
range. A program can also move the mouse to a new position by
|
|
writing that new position to the X & Y coordinates. Note: no
|
|
check is done to insure the new position is within the defined
|
|
range, this must be done by the program.</p>
|
|
|
|
<p>See the BASIC programming examples, PGM4 for an example of how
|
|
to use the PC mouse I/O function.</p>
|
|
|
|
<p><a href="../../~dmkeil/coco/cocobas.htm">BASIC Examples</a></p>
|
|
|
|
<p><a href="../../~dmkeil/coco/cocodoc.htm#Contents">Return to contents:</a> </p>
|
|
|
|
<hr>
|
|
|
|
<p><a name="Technical-keymaps"></a><font size="5"><b>Technical
|
|
info - Keyboard maps:</b></font> </p>
|
|
|
|
<p>The COCO emulator support two keyboard maps. These files
|
|
determine the relationship between the PC keyboard and the COCO
|
|
keyboard. Each key on the PC keyboard can be mapped to a key on
|
|
the COCO keyboard. More than one PC key can be mapped to the same
|
|
COCO key (ex. Backspace & left arrow are both mapped to left
|
|
arrow on the COCO keyboard).</p>
|
|
|
|
<p>Each keyboard map file contains 512 bytes which are organized
|
|
in pairs. The first 128 byte pairs are unshifted keys the last
|
|
128 are the same keys shifted. The PC communicates with its
|
|
keyboard using scancodes. Each PC key has a scancode and each
|
|
scancode has a matching 2 byte value in the keyboard map. For
|
|
example the 'ENTER' key has a scancode of 28, therefore the 2
|
|
keyboard map values at 2 times 28 plus 1 (57), contains the COCO
|
|
keyboard value for an unshifted 'ENTER' key. The map values 2
|
|
times 28 plus 257 (313), contains the COCO keyboard value for a
|
|
shifted 'ENTER' key.</p>
|
|
|
|
<p>Below is a graphic of a standard PC keyboard layout showing
|
|
the scancodes for each key. All the scancodes shown correspond to
|
|
a keyboard map entry. The PC key's table entry can be found by
|
|
multiplying the scancode by 2 and adding 1 for unshifted values
|
|
or adding 257 for shifted values.</p>
|
|
|
|
<p>Note: The scancodes for the cursor keys are not the actual
|
|
scancodes but the scancode plus 32 because the actual scancodes
|
|
are the same as for the number pad. The PC prefixes these keys
|
|
with a special code. The emulator adds 32 to these prefixed
|
|
scancodes so they can have their own keyboard map entries.</p>
|
|
|
|
<table border="2" cellpadding="4" cellspacing="0"
|
|
bordercolor="#000000">
|
|
<tr>
|
|
<td><img src="../../~dmkeil/images/pckey.gif" width="868"
|
|
height="238"></td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>As said before each scancode points to a two byte pair. The
|
|
second byte is the entry type, it has the following values:</p>
|
|
<div align="left">
|
|
|
|
<table border="2">
|
|
<tr>
|
|
<td align="center" width="5%">bit 0</td>
|
|
<td>If clear then this is an unshifted COCO key<br>
|
|
When this key is pushed a value corresponding to the
|
|
first byte of this map entry will be stored in the COCO
|
|
keyboard memory matrix.</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center">bit 0</td>
|
|
<td>If set then this is a shifted COCO key<br>
|
|
When this key is pushed a value corresponding to the
|
|
first byte of this map entry will be stored in the COCO
|
|
keyboard memory matrix.<br>
|
|
A shift will also be stored in the matrix.</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center">bit 1</td>
|
|
<td>-reserved-</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center">bit 2</td>
|
|
<td>If bit 2 is set then this key is also used as a
|
|
joystick emulator key. Bits 4-6 is the joystick value
|
|
that the key will change. Values for bits 4-6 are:<p>000
|
|
- joystick up<br>
|
|
001 - joystick down<br>
|
|
010 - joystick left<br>
|
|
011 - joystick right<br>
|
|
100 - right joystick button<br>
|
|
101 - left joystick button<br>
|
|
110 - extra button<br>
|
|
111 - extra button</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="2"><font color="#FF0000"><strong>The
|
|
above bits are valid only if bit 7 is clear</strong></font></td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" width="5%">128</td>
|
|
<td>No function<br>
|
|
Pushing this key does nothing in the emulator</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" width="5%">129</td>
|
|
<td>Command function<br>
|
|
These keys execute emulator command functions like
|
|
rebooting the emulator (F10). These map entries should
|
|
not be modified. Incorrect entries to this type of entry
|
|
can result in emulator functions not working, emulator
|
|
lockups and system crashes.</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" width="5%">130</td>
|
|
<td>Shift Key<br>
|
|
Whenever this key is pushed and held the emulator will
|
|
use the second half of the keyboard map. The first byte
|
|
of this type of entry contains the type of shift key. For
|
|
the COCO this value should always be 1.</td>
|
|
</tr>
|
|
</table>
|
|
</div>
|
|
|
|
<p>The following table is to be used to find the first byte of
|
|
the keyboard map value for entry type 0. The values in this table
|
|
are in hex.</p>
|
|
|
|
<p><img src="../../~dmkeil/coco/images/cocokey1.gif" width="511" height="129"></p>
|
|
|
|
<p>For example. If you look at the PC scancode graphic you will
|
|
see that the 'ESC' key has a scan code of 1. If you look at the
|
|
3rd byte of the PCCOCO keyboard map file you will see a value of
|
|
38 (26 hex). Looking at the able above shows a value of 26H
|
|
represents the COCO 'BREAK' key. The 'BREAK' key is in row 6
|
|
column 2 for the COCO keyboard matrix.</p>
|
|
|
|
<p>The 4th byte of the keyboard map file is a zero. This means
|
|
the key is unshifted. If this value was 1 then anytime 'BREAK'
|
|
was pushed the emulator would also push the COCO's shift key.
|
|
This features allows keys that are not shifted on a PC keyboard
|
|
to be shifted on the COCO keyboard (like '=') or shifted keys to
|
|
be unshifted (like "@").</p>
|
|
|
|
<p>The following table is to be used to find the first byte of
|
|
the keyboard map value for entry type 1. The values in this table
|
|
are in hex.</p>
|
|
|
|
<p><img src="../../~dmkeil/coco/images/cocokey2.gif" width="511" height="129"></p>
|
|
|
|
<p>For example. If you look at the PC scancode graphic you will
|
|
see that the '= +' key has a scan code of 13. If you look at the
|
|
27th byte of the PCCOCO keyboard map file you will see a value of
|
|
85 (55 hex). Looking at the able above shows a value of 55H
|
|
represents the COCO '- =' key. The '- =' key is in row 5 column 5
|
|
for the COCO keyboard matrix.</p>
|
|
|
|
<p>The 4th byte of the keyboard map file is a one. This means the
|
|
key is shifted. When this key is pushed the COCO will be sent the
|
|
'- =' key along with a shift key.</p>
|
|
|
|
<p>Most of the PC keys mapped to the COCO layout in the first
|
|
half of the keyboard map will have an entry type of 0 since this
|
|
section is used when neither of the PC shift keys are pushed.
|
|
Most of the PC keys mapped to the COCO layout in the second half
|
|
of the keyboard map will have an entry type of 1 since this
|
|
section is used when either of the PC shift keys are pushed.
|
|
Also, in most cases the first byte of a key entry in the first
|
|
half of the map will be the same as the one in the second part of
|
|
the map since it is just the shifted value of the other. Some of
|
|
the PC keys however will have very different values in each half
|
|
of the map (like' = +') for example because of the differences
|
|
between the PC and COCO keyboard layouts.</p>
|
|
|
|
<p>I hope this documentation will give users the information
|
|
needed to create custom keyboard layouts.</p>
|
|
|
|
<p><a href="file:///C:/My%20Documents/trsdoc.htm#Contents">Return
|
|
to contents:</a> </p>
|
|
|
|
<hr align="left">
|
|
|
|
<p><a name="Technical-CAR file"></a><font size="5"><b>Technical
|
|
info - Cartridge .CAR files</b></font></p>
|
|
|
|
<p><font size="3">The emulator supports cartridge ROM images.
|
|
These images are raw dumps of an actual cartridge ROM. The load
|
|
address is assumed to be $C000 and the length is assumed to be
|
|
the actual file length with a maximum length of $3F00.</font></p>
|
|
|
|
<p><font size="3">Because PC-DOS filenames are not very
|
|
descriptive and a cartridge may contain hardware in addition to
|
|
the ROM there needed to be a way to maintain this information
|
|
easily and without having to modify the actual ROM image. To do
|
|
this the emulator creates and maintains .CAR files. These files
|
|
contain important information about a cartridge. This file is
|
|
created when a cartridge ROM is first loaded and most of its
|
|
information can be changed by the user.</font></p>
|
|
|
|
<p><font size="3">Below is the actual file structure. Most of the
|
|
items can be changed within the emulator on the Multi-Pak screen.
|
|
The rest should never need to be changed but can be by using a
|
|
hex file editor the file layout below .</font></p>
|
|
<div align="center"><center>
|
|
|
|
<table border="1" width="100%">
|
|
<tr>
|
|
<td width="15%">Byte 0-3</td>
|
|
<td width="100%">Identifier 'CART' </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 4</td>
|
|
<td width="100%">Write protect:<br>
|
|
If this byte is zero, the emulator automatically updates
|
|
any changes to the .CAR file when a cartridge is removed
|
|
or upon exiting the emulator.<br>
|
|
If this byte is non-zero changes made to a loaded
|
|
cartridge's options are not saved.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 5 & 6</td>
|
|
<td width="100%">Length of ROM image:<br>
|
|
This value is created when a cartridge ROM image is
|
|
loaded for the first time. It contains the actual length
|
|
of the image to a maximum of $3F00.<br>
|
|
If this value is modified and is smaller then the actual
|
|
ROM image length only the number of bytes in this field
|
|
will be loaded.<br>
|
|
If the value is modified to a value larger than the
|
|
actual ROM image length this field will be changed to the
|
|
actual ROM image length the next time the cartridge is
|
|
loaded.<p>WARNING: Bytes are entered in reverse order
|
|
(ex. $2000 would be entered, byte 5=00, byte 6=20).</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 7</td>
|
|
<td width="100%">Cartridge label color:<br>
|
|
Contains a value between 0 & 15.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 8</td>
|
|
<td width="100%">Cartridge label text color:<br>
|
|
Contains a value between 0 & 15.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 9</td>
|
|
<td width="100%">Hardware options addressed using SCS*
|
|
(spare select signal)<br>
|
|
Bit 0: Floppy Disk Controller<br>
|
|
Bit 1-7: reserved for additional hardware</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 10</td>
|
|
<td width="100%">Hardware options addresses using CTS*
|
|
(cartridge select signal)<br>
|
|
Bit 0-6: reserved for addition hardware<br>
|
|
Bit 7: cartridge interrupt signal
|
|
(enabled if set)<p>By default the cartridge interrupt
|
|
signal is set enabled when the .CAR file is initalized
|
|
for a new ROM image.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 11</td>
|
|
<td width="100%">Hardware options addressed whenever
|
|
cartridge is inserted in Multi-Pak Interface:<br>
|
|
Bit 0: Orchestra-90 Music
|
|
Synthesizer<br>
|
|
Bit 1-7: reserved for additional hardware</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 12</td>
|
|
<td width="100%">reserved</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">Byte 14-37</td>
|
|
<td width="100%">Cartridge description #1 (zero
|
|
terminated)</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="15%">byte 38-61</td>
|
|
<td width="100%">Cartridge description #2 (zero
|
|
terminated)</td>
|
|
</tr>
|
|
</table>
|
|
</center></div>
|
|
|
|
<p>All the fields in the .CAR file are user modifiable within the
|
|
emulator except bytes 4-6.<br>
|
|
The proper hardware option field is automatically updated when
|
|
the user enables a hardware option.</p>
|
|
|
|
<p><a href="../../~dmkeil/coco/cocodoc.htm#Contents">Return to contents:</a> </p>
|
|
|
|
<hr align="left">
|
|
|
|
<p><a name="Technical-mem"></a><font size="5"><b>Technical Info -
|
|
Emulator memory map:</b></font> </p>
|
|
|
|
<p>The Color Computer emulator memory map is as follows: </p>
|
|
|
|
<table border="1" width="100%" cols="3">
|
|
<tr>
|
|
<td width="20%"><b>Memory range</b></td>
|
|
<td width="40%"><b>Read</b></td>
|
|
<td width="40%"><b>Write</b></td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FF00</td>
|
|
<td width="40%">PIA #0 data port A</td>
|
|
<td width="40%">PIA #0 data port A</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FF01</td>
|
|
<td width="40%">PIA #0 control port A</td>
|
|
<td width="40%">PIA #0 control port A</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FF02</td>
|
|
<td width="40%">PIA #0 data port B</td>
|
|
<td width="40%">PIA #0 data port B</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FF03</td>
|
|
<td width="40%">PIA #0 control port B</td>
|
|
<td width="40%">PIA #0 control port B</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FF04-FF1F</td>
|
|
<td width="40%">mirrors of FF00-FF03</td>
|
|
<td width="40%">mirrors of FF00-FF03</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FF20</td>
|
|
<td width="40%">PIA #1 data port A</td>
|
|
<td width="40%">PIA #1 data port A</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FF21</td>
|
|
<td width="40%">PIA #1 control port A</td>
|
|
<td width="40%">PIA #1 control port A</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF22</td>
|
|
<td>PIA #1 data port B</td>
|
|
<td>PIA #1 data port B</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF23</td>
|
|
<td>PIA #1 control port B</td>
|
|
<td>PIA #1 control port B</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF24-FF3F</td>
|
|
<td>mirrors of FF20-FF23</td>
|
|
<td>mirrors of FF20-FF23</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF40-FF47</td>
|
|
<td>Disk select register</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF48</td>
|
|
<td>FDC status register</td>
|
|
<td>FDC command register</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF49</td>
|
|
<td>FDC track register</td>
|
|
<td>FDC track register</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF4A</td>
|
|
<td>FDC sector register</td>
|
|
<td>FDC sector register</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF4B</td>
|
|
<td>FDC data register</td>
|
|
<td>FDC data register</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF40-FF5F</td>
|
|
<td valign="top">SCS - spare select signal</td>
|
|
<td>SCS - spare select signal<p>Used by bank switched ROM
|
|
cartridges<br>
|
|
Bit 0 = A14<br>
|
|
Bit 1 = A15<br>
|
|
Bit 2 = A16<br>
|
|
Bit 3 = A17</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF68 & FF6C</td>
|
|
<td>Receiver data register</td>
|
|
<td>Transmit data register</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF69 & FF6D</td>
|
|
<td>Soft reset</td>
|
|
<td>Status register</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF6A & FF6E</td>
|
|
<td>Command register</td>
|
|
<td>Command register</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF6B & FF6F</td>
|
|
<td>Control register</td>
|
|
<td>Control register</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#FF0000">Deluxe
|
|
RS-232 Program Pak $FF68-$FF6B<br>
|
|
Direct Connect Modem Pak $FF6C-$FF6F</font></td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF7A</td>
|
|
<td>-unused-</td>
|
|
<td>Orcherstra-90 (left channel)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF7B</td>
|
|
<td>-unused-</td>
|
|
<td>Orchestra-90 (right channel)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FF7F</td>
|
|
<td>Multi-Pak programming register<br>
|
|
Get active slots<p>bits 0-1: number of active SCS slot
|
|
(FDC)<br>
|
|
bits 4-5: number of active CTS slot (ROM)<br>
|
|
bits 2,3,6,7: all set means value given is select switch
|
|
setting</p>
|
|
</td>
|
|
<td>Multi-Pak programming register<br>
|
|
Set active slots<p>bits 0-1: number of active SCS slot
|
|
(FDC)<br>
|
|
bits 4-5: number of active CTS slot (ROM)<br>
|
|
</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFC0-FFC5</td>
|
|
<td>-unused-</td>
|
|
<td>Graphics mode V0-V2</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFC6-FFD3</td>
|
|
<td>-unused-</td>
|
|
<td>Video page offset</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFD8-FFD9</td>
|
|
<td>-unused-</td>
|
|
<td>CPU speed (.895mhz / 1.78mhz)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFDE-FFDF</td>
|
|
<td>-unused-</td>
|
|
<td>ROM enable/disable</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFF0-FFF1</td>
|
|
<td>reserved</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFF2-FFF3</td>
|
|
<td>SWI3 vector</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFF4-FFF5</td>
|
|
<td>SWI2 vector</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFF6-FFF7</td>
|
|
<td>FIRQ vector</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFF8-FFF9</td>
|
|
<td>IRQ vector</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFFA-FFFB</td>
|
|
<td>SWI vector</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFFC-FFFD</td>
|
|
<td>NMI vector</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFFE-FFFF</td>
|
|
<td>Reset vector</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#FF0000"><strong>All
|
|
vectors are mapped to Color BASIC ROM address $BBF2-$BBFF</strong></font></td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>The Color Computer emulator support an enhanced memory map as
|
|
follows: </p>
|
|
|
|
<table border="1" width="100%" cols="3">
|
|
<tr>
|
|
<td width="20%"><b>Memory range</b></td>
|
|
<td width="40%"><b>Read</b></td>
|
|
<td width="40%"><b>Write</b></td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FFE0-FFE7</td>
|
|
<td width="40%">up to 16 sets of 8bit or 16bit I/O data</td>
|
|
<td width="40%">up to 16 sets of 8bit or 16bit I/O data</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FFE8</td>
|
|
<td width="40%">CPU register A used by enhanced
|
|
instructions</td>
|
|
<td width="40%">CPU register A used by enhanced
|
|
instructions</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FFE9</td>
|
|
<td width="40%">CPU register B used by enhanced
|
|
instructions<br>
|
|
-or-<br>
|
|
CPU register CC returned by enhanced instructions</td>
|
|
<td width="40%">CPU register B used by enhanced
|
|
instructions</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%">FFEA-FFED</td>
|
|
<td width="40%">-unused-</td>
|
|
<td width="40%">-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFEE</td>
|
|
<td>Enhanced instruction status register</td>
|
|
<td>Enhanced instruction command register<br>
|
|
Valid command are $00-$1F</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFEF</td>
|
|
<td>Bits 0-3: equal<br>
|
|
current data set for $FFE0-$FFE7<p>Bit 4: if set means<br>
|
|
$FFE0-$FFE7 are 16bit values</p>
|
|
<p>Bit 5-7: -unused-</p>
|
|
</td>
|
|
<td>Bits 0-3: set the current data set for $FFE0-FFE7<p>Bit
|
|
4-7: -unused-</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#FF0000"><strong>Anytime
|
|
$FFEF is accessed the high/low 8bit toggle for 16bit
|
|
values is set to the high 8 bits.</strong></font></td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#0000FF">Memory
|
|
address $FFEF equal $00</font></td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE0-FFE7</td>
|
|
<td>Work area used by enhanced instructions</td>
|
|
<td>Work area used by enhanced instructions</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#0000FF">Memory
|
|
address $FFEF equal $01</font></td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE0</td>
|
|
<td>seconds in BCD format</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#FF0000">Reading
|
|
this address loads $FFE0-$FFE6 with the PC's system date
|
|
and time.</font></td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE1</td>
|
|
<td>minutes in BCD format</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE2</td>
|
|
<td>hours in BCD format</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE3</td>
|
|
<td>year in BCD format</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE4</td>
|
|
<td>day in BCD format</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE5</td>
|
|
<td>month in BCD format</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE6</td>
|
|
<td>century in BCD format (19 or 20)</td>
|
|
<td>-unused-</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#0000FF">Memory
|
|
address $FFEF equal $02</font></td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE0-FFE7</td>
|
|
<td>Read PC port</td>
|
|
<td>Write PC port</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#FF0000">The
|
|
PC port read or written is defined by the 16bit values
|
|
stored in $FFE0-$FFE7 when $FFEF equal $03</font></td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#0000FF">Memory
|
|
address $FFEF equal $03</font></td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE0-FFE7</td>
|
|
<td>16bit PC port address</td>
|
|
<td>16bit PC port address</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#0000FF">Memory
|
|
address $FFEF equal $04</font></td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE0</td>
|
|
<td>read PC mouse and load buttons and current X & Y
|
|
coordinates<p>bit 0: left button was pushed<br>
|
|
bit 1: right button was pushed<br>
|
|
bit 2: middle button was pushed</p>
|
|
<p>bit 4: left button is pushed<br>
|
|
bit 5: right button is pushed<br>
|
|
bit 6: middle button is pushed</p>
|
|
</td>
|
|
<td valign="top">set mouse buttons<p>bit 0: set/clear
|
|
left button was pushed<br>
|
|
bit 1: set/clear right button was pushed<br>
|
|
bit 2: set/clear middle button was pushed</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#FF0000">Reading
|
|
this address load $FFE1 & FFE2 with the current mouse
|
|
X & Y coordinates.<br>
|
|
These coordinates will always be greater than or equal to
|
|
the minimum and less than or equal to the maximum.</font></td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE1</td>
|
|
<td>get mouse current X coordinate</td>
|
|
<td>set mouse current X coordinate</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE2</td>
|
|
<td>get mouse current Y coordinate</td>
|
|
<td>set mouse current Y coordinate</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE3</td>
|
|
<td>get mouse min X coordinate</td>
|
|
<td>set mouse min X coordinate</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE4</td>
|
|
<td>get mouse min Y coordinate</td>
|
|
<td>set mouse min Y coordinate</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE5</td>
|
|
<td>get mouse max X coordinate</td>
|
|
<td>set mouse max X coordinate</td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE6</td>
|
|
<td>get mouse max Y coordinate</td>
|
|
<td>set mouse max Y coordinate</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#FF0000">Make
|
|
sure that the minimum value is less than the maximum
|
|
value or the X & Y coordinates will be unknown.</font></td>
|
|
</tr>
|
|
<tr>
|
|
<td>FFE7</td>
|
|
<td>get mouse sensitivity<p>bits 0-3: X axis (0-15)<br>
|
|
bits 4-7: Y axis (0-15)</p>
|
|
</td>
|
|
<td>set mouse sensitivity<p>bits 0-3: X axis (0-15)<br>
|
|
bits 4-7: Y axis (0-15)</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#FF0000">All
|
|
X & Y coordinate values are 16bit. The mouse buttons
|
|
and sensitivity are 8bit values mirrored into 16 bits.<br>
|
|
<br>
|
|
<strong><u>WARNING</u></strong><strong><br>
|
|
Memory mapped mouse functions are disabled when COCO
|
|
joystick emulation is set to PC mouse.</strong></font></td>
|
|
</tr>
|
|
<tr>
|
|
<td align="center" colspan="3"><font color="#FF0000"><br>
|
|
</font><font color="#0000FF">Memory address $FFEF equal
|
|
$05 - $0F<br>
|
|
-undefined-</font><font color="#FF0000"><br>
|
|
</font></td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p><a href="../../~dmkeil/coco/cocodoc.htm#Contents">Return to contents:</a></p>
|
|
</body>
|
|
</html>
|