Why these measurements

MAME’s Ensoniq Mirage emulation (ensoniq/enmirage.cpp, sound/cem3328.cpp) works, but several of its numbers are estimates from the schematic and datasheets. Each measurement below replaces one of those estimates with a real value. The most valuable are marked priority.

Part numbers and pins refer to the DSK-8 main board schematic, drawing 4010003401, sheets 1 (analog, rev G, 1985) and 2 (digital). Please note your board’s revision if it differs.

Equipment: a two-channel oscilloscope (20 MHz or better), a multimeter, a MIDI interface, and a Mirage OS boot disk. A frequency counter or a scope with a frequency readout saves time.

Safety: the power supply carries mains voltage. Everything here is on the main board’s low-voltage side (+5 V, +12 V, ?8 V). Clip the scope ground to board ground, never to a supply rail.

1. VIA and MIDI clocks (priority)

These confirm that the 6522 VIA runs at 2 MHz and that its PB7 output makes the 500 kHz MIDI clock. MAME’s change to the 6522 core rests on this. Measure after the OS has loaded from disk.

Also useful: whether SERCLK is present before the disk loads, and when it first starts.

2. Filter control voltages

These check the chain from the CV DAC (U41, AD7524) to each filter’s control pins. The emulation assumes the DAC spans 0 to +5.08 V (about 19.9 mV per step) and that the hold buffers have unity gain.

The pin 2 line is the most useful: three or four readings of VF1 against pin 2 confirm the 27K / 160K / 1K network.

3. CEM3328 filter response (priority)

The filter model uses the datasheet’s typical figures: 20 mV per octave, and about 105 Hz at 0 V on pin 2 with the Mirage’s parts. A self-oscillating filter makes a clean sine at its cutoff, so its frequency can be read straight off the output.

1. Cutoff curve. Set a sound’s resonance to maximum so voice 1 oscillates. Step the filter cutoff parameter through five or more values from low to high. At each step record U67 pin 2 (DC) and the frequency at U67 pin 9 (output). This gives the real scale factor and base frequency.
2. Oscillation threshold. With the cutoff mid-range, raise resonance one step at a time. Record U67 pin 10 at the first step that oscillates. Datasheet: 2.7 to 3.7 V, typically 3.2 V.
3. Oscillation level. At maximum resonance, record the peak-to-peak voltage at U67 pin 9. Datasheet: about 2.3 V.
4. Resonance curve. At three or four resonance settings below oscillation, play a note and record the output level relative to resonance off. The datasheet only calls this a “reverse audio taper”, and the model’s curve is a guess.
5. Voice-to-voice spread. With all voices at the same cutoff and maximum resonance, record each voice’s oscillation frequency (VCF1–8: U67, U68, U62, U63, U57, U58, U52, U53, pin 9). This shows how far real chips differ.

4. Audio levels (priority)

The emulation assumes a full-scale voice drives the CEM3328 to its rated 6.5 V p-p, because the DOC’s output current isn’t on the schematic. Measuring the real levels replaces that assumption.

Use one sustained note at maximum velocity, with the filter fully open and resonance off. Record peak-to-peak voltage at each point, then repeat with eight notes held.

Please note the volume knob position and the sound used.

5. Filter calibration at boot

Right after the OS loads, the firmware tunes each filter: it makes the filter oscillate, counts the cycles through the ADC, and adjusts the cutoff until 4 periods take about 130 ADC reads. MAME has no way to feed real filter output to its ADC, so it substitutes a modeled sine for each oscillating filter.

1. Trigger on the disk motor stopping after the OS load. Capture the summer output (U56 pin 7) and the ADC input path (U45 pin 13, COM X) for the next second.
2. Record the waveform’s amplitude and frequency at the ADC input. The firmware’s thresholds are $90 and $70, so the signal must swing well past both.
3. Record whether all eight voices oscillate together, or one at a time. The firmware leaves earlier voices at full resonance while tuning later ones, which suggests all together.
4. Record each voice’s final oscillation frequency once calibration ends, from its pin 9.

6. Keyboard controller link

The keyboard’s R6500/11 has an undumped internal ROM, so MAME imitates it from the main CPU’s side. Each key sends three bytes ($90 down or $80 up, key number 0–60, velocity) into the VIA shift register. The CPU acknowledges each byte with a low pulse on CA2. The timing and the velocity values are guesses.

Capture SCLK (U9 pin 18, CB1) and SDATA (U9 pin 19, CB2) on the two channels, then SCLK and SACK (U9 pin 39, CA2).

1. Shift clock rate, and the gap between bytes within one message.
2. Whether the controller waits for each CA2 pulse before sending the next byte, and the pulse’s width.
3. The velocity byte for a very soft, a medium and a very hard press of the same key. Decode it from SDATA, most significant bit first.
4. What the sustain pedal sends when pressed and released. The OS understands $B8 and $B9.
5. Any bytes sent at power-on, before a key is pressed, and the state of VIA PB4 (U9 pin 14, which also resets the controller) during boot.

Sending results

Partial results help: sections 1, 3 and 4 alone would settle the biggest open questions.

• Contact me with your readings.
• Attach scope screenshots with the timebase and volts per division visible.
• Note your model (DSK-8 or DSK-1), board revision, OS disk version, and the date codes printed on the CEM3328 chips.
• If you measure several voices, say which VCF each reading came from.

As a reminder the first one was: here

This proposes adding a single hardware graphic cursor avaiable in both text and graphics modes. An emulated example is avaiable in this Mame feature branch in my fork: https://github.com/tlindner/mame/tree/ots

Here is an example program in BASIC to demo the feature:

10 WIDTH 40
15 ATTR 4,3
17 CLS
20 POKE &HFF97,2                 ' SYNC=1: begin shape upload
30 FOR X=0 TO 15
40 READ A
50 POKE &HFF96,A
60 NEXT X                        ' after 16 bytes, $FF96 auto-reverts to position mode
70 CTRL = &HB1                   ' EN=1, FG=palette1, BG=palette2, SIZE=1, (bit 2 now reserved)
80 POKE &HFF97,CTRL              ' one-time setup - no need to repeat per move
81 ? "Hello World!"
86 PALETTE 1,RND(63)
87 PALETTE 2,RND(63)
88 X = JOYSTK(0)*9:LOCATE0,0
90 POKE &HFF96,X/255             ' X high bits (0-3)
100 POKE &HFF96,X AND 255        ' X low byte - smooth left/right
110 POKE &HFF96,JOYSTK(1)*3      ' Y position
120 GOTO 85
1000 DATA &H80,&H80,&H40,&H80,&H60,&H80,&H70,&H80,&H78
1010 DATA &H80,&H7C,&H80,&H7E,&H80,&H00,&HFF

And here is a minty fresh quicktime showing it off:

[video width=“960” height=“716” src=“http://tlindner.macmess.org/wp-content/uploads/2026/08/ots.mp4”]

Overview

The GIME video system can provide a hardware mouse cursor by adding a small independent cursor overlay. The cursor is not stored in normal CoCo memory and does not require software to modify the display memory.

The cursor is drawn after the normal video image is generated. Software only needs to provide:

• A cursor shape.
• A cursor position.
• Two palette selections.
• Enable/disable control.

This provides a fast, flicker-free cursor suitable for graphical user interfaces while requiring very little programming overhead.

The hardware cursor is especially useful for GUI applications because moving the mouse pointer no longer requires saving the background, drawing the cursor, restoring the background, or modifying screen memory.

Registers

The cursor uses two memory-mapped registers.

Cursor Control Register ($FF97)

Bit  7   6   5   4   3   2   1   0
    EN  W1  W0  B1  B0  --  SYNC SIZE

Bit 7: EN - Cursor Enable

0 = Cursor disabled
1 = Cursor displayed

Bits 6-5: W1:W0 - Foreground Palette Slot

Selects the GIME palette entry used for foreground cursor pixels.

Valid values:

00 = palette entry 0
01 = palette entry 1
10 = palette entry 2
11 = palette entry 3

Bits 4-3: B1:B0 - Background Palette Slot

Selects the GIME palette entry used for background cursor pixels.

Valid values:

00 = palette entry 0
01 = palette entry 1
10 = palette entry 2
11 = palette entry 3

Bit 2: Reserved

Unused. Reads back as 0. Reserved for future expansion.

Bit 1: SYNC - Enter Shape Upload Mode / Upload Status

SYNC is both readable and writable, and its meaning differs by direction.

Writing SYNC

Writing a one switches the Cursor Data register ($FF96) into shape-upload mode for the next sixteen writes, and resets the upload pointer to zero.

Write 0 = no action
Write 1 = begin (or restart) a 16-byte cursor shape upload

This is the only way $FF96 enters shape-upload mode. At all other times - including immediately after power-on, and immediately after the 16th shape byte is written - $FF96 is in position mode (see below). Software never needs to write SYNC to move the cursor; it is only needed when replacing the cursor’s image.

Reading SYNC

0 = A shape upload is in progress and not yet at byte zero
1 = $FF96 is ready for a fresh shape upload

In practice this reads as 1 essentially all the time, since $FF96 sits in position mode - upload pointer parked at zero - except for the brief window during an actual upload.

Position Mode (default state of $FF96)

Unlike shape upload, position mode is not something software enters - it is where $FF96 always is unless a shape upload is in progress. Every write to $FF96 while in position mode is consumed by a free-running, self-aligning 3-byte cycle:

Byte 0: Cursor X high bits
Byte 1: Cursor X low byte
Byte 2: Cursor Y position

…then it repeats: byte 3 is X high again, byte 4 is X low, and so on. No control-register write is needed to start, continue, or reset this cycle - software can simply POKE three bytes per cursor move, forever, with zero per-move overhead beyond the position data itself. This is the expected hot path for mouse polling.

The cursor position range is:

X: 0-639
Y: 0-199

The X high byte only uses the lower two bits:

Bit 1-0 = X bits 9-8

If a shape upload (triggered by SYNC) interrupts a position write partway through its 3-byte cycle, the position pointer is reset to zero as part of entering upload mode, and reset to zero again as part of leaving it. This guarantees the next 3 writes to $FF96 after an upload finishes are always a clean, aligned position triple - a position write can never be left half-consumed by an upload landing in the middle of it.

Bit 0: SIZE - Cursor Size

Selects cursor rendering size.

0 = 8x8 cursor
1 = 16x16 cursor

When 16x16 mode is selected, each cursor pixel is doubled horizontally and vertically.

The cursor image memory remains the same 8x8 image in both modes.

Cursor Shape Data Register ($FF96)

The cursor image is an 8x8 two-bit-per-pixel image.

The image requires sixteen bytes.

Each row uses two bytes:

Byte 0: Plane 0, Row 0
Byte 1: Plane 1, Row 0

Byte 2: Plane 0, Row 1
Byte 3: Plane 1, Row 1

...

Byte 14: Plane 0, Row 7
Byte 15: Plane 1, Row 7

Bits are arranged:

Bit 7 = leftmost pixel
Bit 0 = rightmost pixel

Each pixel is decoded as:

Clarification: XOR Mode Semantics

The original pixel decode table left the “Foreground XOR Background” result ambiguous — it could be read as either a fixed third color (foreground palette color combined with background palette color), or as a true XOR against whatever is already on screen. Only the latter reading satisfies the stated goal that “the cursor color remains visible over changing backgrounds,” so the specification is clarified as follows:

XOR pixel behavior

For pixels where both bitplanes are set, the cursor does not draw a color at all. Instead, it inverts whatever pixel is already present at that screen location: output_pixel = existing_pixel XOR $FFFFFF This is the same trick used by hardware cursors on other classic platforms (and by early VGA/Mac text cursors): because the operation is applied to the live framebuffer contents rather than to a fixed cursor color, the cursor pixel is guaranteed to differ from its background regardless of what that background is — solid color, photo, or another rapidly animating sprite. Inverting twice restores the original pixel, so no background save/restore buffer is required even in XOR regions.

Foreground and background palette slots (W1:W0 and B1:B0) have no effect on XOR pixels — those bits only apply to the solid-color (10/01) cases. XOR pixels are purely a function of the two bitplane bits and the framebuffer they land on.

Practical implication for cursor art

Because XOR pixels invert rather than paint, they read differently depending on the underlying pixel’s luminance and hue — a common tradeoff for XOR cursors. Designers using XOR pixels (e.g., a thin outline meant to “always show”) should expect variable, not fixed, apparent color, and treat it as a contrast trick rather than a color choice.

Uploading a Cursor Shape

A cursor shape is uploaded by:

1. Setting SYNC.
2. Writing sixteen bytes to Cursor Data.

After the sixteenth byte, $FF96 automatically reverts to position mode - no further register write is needed before moving the cursor again.

Example 6809 code:

CURSOR_CTRL  EQU $FF97
CURSOR_DATA  EQU $FF96

load_cursor:
        lda   CURSOR_CTRL
        ora   #%00000010      ; SYNC - begin shape upload
        sta   CURSOR_CTRL

        ldx   #cursor_shape
        ldb   #16

upload_loop:
        lda   ,x+
        sta   CURSOR_DATA
        decb
        bne   upload_loop
                               ; $FF96 is back in position mode here
        rts

Moving the Cursor

Cursor position is the default behavior of Cursor Data - no control register write is needed at all. Software simply writes three bytes, high-byte-first, matching the 6809’s natural big-endian storage order:

CURSOR_DATA  EQU $FF96

set_cursor_position:
        lda   cursor_x         ; X high bits (bits 9-8)
        anda  #%00000011
        sta   CURSOR_DATA

        lda   cursor_x+1       ; X low byte
        sta   CURSOR_DATA

        lda   cursor_y
        sta   CURSOR_DATA

        rts

Because this is the default mode of the register, the same three writes can be issued every frame from a mouse-polling loop with no per-move setup cost. A shape upload landing between two calls to this routine cannot desynchronize it - see SYNC above.

Example Cursor Shape: Black Arrow with White Outline

The cursor palette selections can be used to create a traditional high-contrast pointer.

For this example:

• Background palette slot = black
• Foreground palette slot = white
• Transparent pixels leave the underlying display unchanged.

The cursor image:

W.......
WB......
WBB.....
WBBB....
WBBBB...
WBBBBB..
WBBBBBB.
WWWWWWWW

Where:

• . = transparent
• B = solid black pixel (background palette color)
• W = white outline pixel (foreground palette color)

The cursor hotspot is always the top-left corner of the 8×8 cursor image. In this example, the active pointing location is the upper-left W pixel. Software positions the cursor by writing the desired screen coordinate of this corner.

The two bitplanes are:

Plane 0 (background/black pixels)

Row 0: 10000000  $80
Row 1: 01000000  $40
Row 2: 01100000  $60
Row 3: 01110000  $70
Row 4: 01111000  $78
Row 5: 01111100  $7C
Row 6: 01111110  $7E
Row 7: 00000000  $00

Plane 1 (foreground/white outline pixels)

Row 0: 10000000  $80
Row 1: 10000000  $80
Row 2: 10000000  $80
Row 3: 10000000  $80
Row 4: 10000000  $80
Row 5: 10000000  $80
Row 6: 10000000  $80
Row 7: 11111111  $FF

The cursor upload data is interleaved by row:

cursor_arrow:
        ; Plane 0, Plane 1

        fcb $80,$80
        fcb $40,$80
        fcb $60,$80
        fcb $70,$80
        fcb $78,$80
        fcb $7C,$80
        fcb $7E,$80
        fcb $00,$FF

When the SIZE bit is enabled, each cursor pixel is doubled horizontally and vertically, producing a 16×16 cursor while preserving the same top-left hotspot location.

Crosshair Cursor

Useful for drawing programs:

...X....
...X....
...X....
XXXXXXXX
...X....
...X....
...X....
...X....

Box Cursor

Useful for text selection:

XXXXXXXX
X......X
X......X
X......X
X......X
X......X
X......X
XXXXXXXX

Benefits

A hardware cursor provides several advantages:

• GUI applications no longer need to redraw the mouse pointer.
• Screen memory is never modified by cursor movement.
• Cursor movement requires only three writes, with no control-register overhead - position mode is the default state of Cursor Data.
• Cursor shape changes require only sixteen writes, plus one SYNC write to begin.
• The cursor works in all GIME display modes.
• No software background save/restore routines are needed.
• Cursor updates are independent of application graphics.

The interface requires only two registers while providing a complete programmable cursor system compatible with the GIME design philosophy.

The joystick buttons on the TRS-80 Color Computer 1 (CoCo 1) are connected to the PIA (Peripheral Interface Adapter). They can be read from memory location $FF00, which is decimal 65280.

In Color BASIC, the value can be read using PEEK:

B=PEEK(65280)

The joystick buttons are active low. This means that a button that is not pressed reads as a 1, and a pressed button pulls the bit to 0.

The button bits are:

Color BASIC supports bitwise AND, which makes checking the buttons straightforward:

10 B=PEEK(65280)
20 IF (B AND 1)=0 THEN PRINT "RIGHT BUTTON"
30 IF (B AND 2)=0 THEN PRINT "LEFT BUTTON"
40 GOTO 10

The parentheses are important. Color BASIC's operator precedence can produce surprising results if you write:

PEEK(65280) AND 128 = 0

This is not interpreted as:

(PEEK(65280) AND 128) = 0

Instead, the comparison happens first, effectively making it:

PEEK(65280) AND (128 = 0)

Since 128 = 0 is false, the expression becomes an AND with zero, which will always produce zero.

The correct way to test a bit is to put the bit operation inside parentheses:

(PEEK(65280) AND 128) = 0

The evaluation order is:

1. PEEK(65280) reads the hardware register.
2. AND 128 masks the desired bit.
3. = 0 tests whether that bit is clear.

This is a good habit for Color BASIC programming: whenever using bit masks in a comparison, put the masked expression in parentheses.

The CoCo's joystick interface is simple, but remembering that the buttons are active low and that Color BASIC's operator precedence is different from many modern languages will save a lot of debugging time.

The workflow was simple: scanned PDFs → OCR → text files → BBEdit search. The OCR output was fine structurally, with one line per paragraph, but reading it in BBEdit was unpleasant. Long lines ran off the right side of the window. Search still worked, but visual scanning was harder than it should be.

What I wanted was simple. Every OCR text file should open in BBEdit with Soft Wrap enabled.

BBEdit does not provide a setting for this at the file level. There is no xattr or modeline for it.

Where BBEdit stores document state

BBEdit stores per-file state in a property list here:

This file acts like a database. Each entry is keyed by file path, and contains a dictionary of state data for that file.

The setting I cared about is:

<key>SoftWrapText</key>
<true/>

It lives inside:

StateEntries_v1
    └── file path
        └── BBEditStateData

BBEdit uses this structure to store editor state per file.

Path matching matters

My first attempt did not work correctly.

I had entries like:

1981/08_rainbow.txt

But BBEdit was using full paths like:

/Volumes/ARCHIVE/Rainbows/1981/08_rainbow.txt

BBEdit matches state strictly by path. If the key does not match exactly, it is ignored.

The fix was to always normalize paths before writing them.

Files on external volumes stay absolute. Files inside the home directory can use ~/.

In Python, this is handled with:

path = path.resolve()

Automating Soft Wrap for many files

Once the structure was correct, I wrote a script that:

• finds all .txt files recursively
• computes the correct BBEdit key for each file
• sets SoftWrapText = true
• preserves existing BBEdit metadata

The key function is:

def bbedit_key_for(path: Path) -> str:
    path = path.resolve()

    try:
        rel = path.relative_to(Path.home())
        return f"~/{rel}"
    except ValueError:
        return str(path)

Everything else is plist editing.

Result

After running this across the OCR archive:

• all text files open with wrapping enabled
• BBEdit search still works normally
• no changes to the original files
• no need to insert line breaks into OCR output

The workflow is now easier to read without affecting how search behaves.

What this is doing

BBEdit stores per-file editor state in a plist that behaves like a small database keyed by file path.

Once that is visible, it becomes possible to automate editor behavior for large sets of files instead of adjusting settings manually.

This can be extended beyond Soft Wrap to other per-file state BBEdit tracks.

The Color Computer Speech/Sound Cartridge (S/SC) was one of the more ambitious peripherals Tandy produced for the CoCo line. It packed a TMS-7040 microcontroller, an SPO256-AL2 speech synthesizer, an AY-3-8913 programmable sound generator, and 2K of RAM into a single cartridge. It was complex enough that most CoCo owners never fully understood what it was doing.

I am a contributor to the Mame emulator project, and I maintain the CoCo SSC slot device. It emulates the TMS-7040, the SPO256, and the AY-3-8913 reasonably well. But there is one small piece of the hardware I had never properly emulated: an analog circuit that generates a single status bit indicating whether the PSG is currently producing sound. The bit is active low, lives at address $FF7E bit 5, and I called it the Sound Activity Circuit.

This is the story of how I figured out what it does, measured it on real hardware, and built a proper emulation of it.

The Schematic

The Sound Activity Circuit is a small analog section hanging off the AY-3-8913's audio output. Looking at the schematic, the signal chain goes like this:

The PSG's analog output feeds into an op-amp stage (one section of a quad NJM2058D) through a high-pass filter formed by C9 and R6. This strips the DC component and boosts the AC audio signal. The amplified signal then goes into a precision half-wave rectifier built from D2, D1, R1, and R2. This only passes positive half-cycles, and charges a 15µF tantalum capacitor C25 through the rectifier. C25 charges quickly when audio is present, and drains slowly through R9 (56K) when audio stops. Finally, a comparator stage with hysteresis (formed by R3 and R8) watches the voltage on C25 and snaps a clean digital output when C25 crosses the threshold.

In plain terms: the circuit answers the question "is the PSG making sound right now?" with a deliberate time delay on the answer going from yes to no. C25 stays charged for a while after the PSG goes quiet, so brief silences between sounds don't glitch the status bit.

From the RC values in the schematic, I calculated a charge time constant of about 150ms and a decay time constant of about 840ms. Those were my starting estimates.

The Initial Emulation

In Mame, I implemented this as a stacked audio filter device, cocossc_sac_device, inserted between the AY-3-8913's output and the speaker. Every time Mame calls sound_stream_update(), the filter sees the PSG's sample buffer, computes the RMS energy, and stores it in a small circular buffer. The sound_activity_circuit_output() function averages the circular buffer and applies a threshold to decide whether to assert the status bit.

bool cocossc_sac_device::sound_activity_circuit_output()
{
    float sum = std::accumulate(std::begin(m_rms), std::end(m_rms), 0.0f);
    float average = (sum / BUFFER_SIZE);
    return average < 0.317f;
}

This worked, in the sense that it compiled and ran. But the threshold of 0.317 was a magic number with no physical basis, and I had no idea how the decay timing related to real hardware. I was guessing.

I decided to measure the real hardware.

The Plan

The Sound Activity Circuit only responds to PSG output. The SP0256 speech chip bypasses it entirely. So the measurement is straightforward: start the PSG playing a tone, measure how long before the status bit asserts, let C25 fully charge, silence the PSG, then measure how long before the status bit deasserts.

Since I don't own an oscilloscope (I know, I know), I decided to use the CoCo itself as the measuring instrument. At 0.89MHz, a tight polling loop runs at roughly one iteration per 11 microseconds. More than enough resolution to measure a decay time in the hundreds of milliseconds.

I wrote a small test program in 6809 assembly, wrapped in a C program using CMOC, that would:

1. Reset the SSC to a known state
2. Put the SSC into PSG register mode
3. Program the AY-3-8913 for a 1KHz tone on channel A at maximum volume
4. Count polling loop iterations until the sound activity bit asserts (charge time)
5. Wait for C25 to fully charge
6. Silence the PSG
7. Count polling loop iterations until the sound activity bit deasserts (decay time)
8. Print the results

Simple enough in theory. In practice, it took a while to get right.

Pitfall One: The Busy Bit Is Active Low. So Is Everything Else.

The status byte at $FF7E has three active-low bits:

• Bit 7 ($80) - busy (low = busy)
• Bit 6 ($40) - speech active (low = speaking)
• Bit 5 ($20) - sound active (low = PSG making sound)

I initially wrote the busy-wait loop as:

bw1     lda     $ff7e
        bmi     bw1       ; wait while bit 7 set

But since busy is active low, bit 7 being set means not busy. The loop was waiting for the wrong condition. It would spin forever waiting for not-busy while the SSC was idle. The correct test is bpl (branch while plus), meaning while bit 7 is clear (busy):

bw1     lda     $ff7e
        bpl     bw1       ; wait while bit 7 clear = busy

Pitfall Two: The TMS-7040 Needs Time

The SSC uses a TMS-7040 microcontroller as an intermediary between the CoCo and all the other devices in the cartridge. When the CoCo writes a byte to $FF7E, it triggers an interrupt on the TMS-7040, which queues the byte and asserts the busy bit. When in the correct mode, the TMS-7040's main loop then dequeues the byte and writes it to the PSG, then clears busy.

I assumed that the busy bit clearing meant the TMS-7040 was truly ready for the next byte. It is not. The busy bit clears before the microcontroller is fully ready to accept another write. If you send the next byte too quickly, it gets dropped silently.

The BASIC manual's example program inadvertently works around this because the BASIC interpreter is slow. The overhead between a POKE and the next GOSUB is enough dead time that the TMS-7040 catches up. In tight assembly code, you have to add explicit delays.

Thru bisection I found that a delay loop of 49 iterations (at 8 cycles each, about 440 microseconds) was the minimum reliable inter-byte delay. I rounded up to 64 for safety. The WRPSG subroutine ended up looking like this:

WR2PSG
        ldx     #64
wp1lp   leax    -1,x
        bne     wp1lp
        pshs    a
bw1     lda     SSCDAT
        bpl     bw1
        puls    a
        sta     SSCDAT
WR1PSG
        ldx     #64
wp2lp   leax    -1,x
        bne     wp2lp
bw2     lda     SSCDAT
        bpl     bw2
        stb     SSCDAT
        rts

Pitfall Three: The Audio Is Not Routed Automatically

The CoCo has a sound multiplexer that selects the audio source for the internal speaker. By default it does not route cartridge audio. Before you can hear anything from the SSC, you need to configure the multiplexer:

*((unsigned char *)0xff01) = 0x34; // PIA 0 CA2 = 0 \_ Set mixer to CART
*((unsigned char *)0xff03) = 0x3f; // PIA 0 CB2 = 1 /
*((unsigned char *)0xff23) = 0x3c; // PIA 1 CB2 = 1 - Turn on sound

The BASIC example programs in the SSC manual does this as a matter of course, but it is easy to miss when writing a standalone C program. Without these writes, the PSG produces output that goes nowhere, and you hear nothing.

The Results

After working through all of those pitfalls, the test program finally ran correctly. The results from multiple runs on real hardware over a ten-minute thermal soak:

• Charge time: 740 iterations (approximately 8ms). Rock solid across all runs and the entire thermal soak
• Decay time: 12079-12163 iterations (approximately 133-134ms). Slowly increasing as the board warmed up, with ambient temperature affecting the value measurably. Running a fan near the CoCo during testing dropped the value by roughly 55 counts

The ratio of decay to charge is about 16:1, which is in the right ballpark compared to the schematic's predicted 6:1. The difference is likely due to component variation in the actual capacitor and resistors on my particular board.

The most interesting finding is that the decay time is 134ms, not the 840ms predicted by the schematic. Either C25 has drifted significantly from its marked value over 40 years, or the board revision I own uses different component values than the schematic I was working from. Either way, real hardware measurements beat schematic theory every time.

The Revised Emulation

Armed with real numbers, I rewrote the Mame emulation. The original RMS circular buffer approach had several problems:

• The window size had no relationship to the circuit's actual time constants
• It was sensitive to Mame's buffer update rate
• The AY-3-8913 emulation produces a DC offset at idle which the RMS accumulated, making the circuit appear permanently active
• The threshold of 0.317 had no physical basis

The analog circuit is fundamentally asymmetric. C25 charges quickly through the rectifier diode but drains slowly through the resistor network. The correct digital model is an envelope follower with asymmetric attack and decay coefficients, preceded by a high-pass filter to remove the DC offset, matching the real circuit's C9/R6 input filter.

void cocossc_sac_device::sound_stream_update(sound_stream &stream)
{
    int count = stream.samples();

    for (int sampindex = 0; sampindex < count; sampindex++)
    {
        float x = stream.get(0, sampindex);

        // High pass filter to remove DC offset (models C9/R6)
        float y = HPF_ALPHA * (m_hpf_prev_out + x - m_hpf_prev_in);
        m_hpf_prev_in = x;
        m_hpf_prev_out = y;

        // Envelope follower, asymmetric attack/decay (models C25)
        float rect = std::abs(y);
        if (rect > m_envelope)
            m_envelope += (rect - m_envelope) * ATTACK_COEFF;
        else
            m_envelope += (rect - m_envelope) * DECAY_COEFF;

        stream.put(0, sampindex, x);
    }
}

bool cocossc_sac_device::sound_activity_circuit_output()
{
    m_stream->update();

    if (m_sound_active && m_envelope < THRESH_OFF)
        m_sound_active = false;
    else if (m_envelope > THRESH_ON)
        m_sound_active = true;

    return !m_sound_active;  // active low
}

The attack and decay coefficients were derived from the hardware measurements and tuned against the emulated system:

static constexpr float HPF_ALPHA    = 0.99f;
static constexpr float ATTACK_COEFF = 0.0026f;  // models ~8ms charge time
static constexpr float DECAY_COEFF  = 0.0003f;  // models ~134ms decay time
static constexpr float THRESH_ON    = 0.05f;
static constexpr float THRESH_OFF   = 0.01f;

The envelope follower operates sample by sample, so it produces consistent results regardless of Mame's buffer update rate or the user's configured sample rate.

Conclusion

I have never encountered any CoCo software that actually polls the sound activity bit during normal operation. This entire exercise was in the service of correctness. If the hardware has the bit, the emulator should get it right.

The process turned out to be more interesting than I expected. What looked like a simple threshold comparison in the schematic revealed a carefully designed asymmetric envelope detector. And the busy-wait protocol had a hidden timing requirement. One that is documented in the manual, but easy to miss when writing tight assembly code.

If I had an oscilloscope, the waveforms on C25 charging and draining would have made a much better illustration for this post. Maybe next time.

The source code for the test program can be found here. The pull request for Mame is here.

Function

Example Programs

COLOR64/BAS:

JOY/BAS:

DUAL/BAS:

INT/BAS:

The Patch

First, here is the comparison between a real and MAME emulated CoCo 2.

Next is the CoCo 2B in normal mode.

Next is the CoCo 2B in lowercase mode.

Next is the CoCo 3 in normal mode.

Last is the CoCo 3 in lowercase mode.

JSR with no parameters

GameOverCondition

jsr GAMEOVER

jmp NextMiniGame

GAMEOVER

ldx #$50C

ldy #text

loop

lda ,y+

beq WaitGameOver

sta ,x+

bra loop

WaitGameOver

jsr [POLCAT]

beq WaitGameOver

rts

text fcn "GAME OVER"

JSR with calculated address

GameOverCondition

ldb randomNumber

aslb

ldx #gameOverTable

abx

jsr [,x]

jmp nextMiniGame

gameOverTable

fdb WaitGameOver1

fdb WaitGameOver2

WaitGameOver1

...

rts

WaitGameOver2

...

rts

Parameter passing

JSR fixed memory locations

GameOverCondition

ldx #text

stx textBufferAddress

ldx #$50C

stx textposition

jsr GAMEOVER

jmp NextMiniGame

GAMEOVER

ldx textposition

ldy textBufferAddress

loop

lda ,y+

beq WaitGameOver

sta ,x+

bra loop

WaitGameOver

jsr [POLCAT]

beq WaitGameOver

rts

textBufferAddress fdb 0 textposition fdb 0 text fcn "GAME OVER"

JSR register

GameOverCondition

ldy #text

ldx #$50C

jsr GAMEOVER

jmp NextMiniGame

GAMEOVER loop

lda ,y+

beq WaitGameOver

sta ,x+

bra loop

WaitGameOver

jsr [POLCAT]

beq WaitGameOver

rts

text fcn "GAME OVER"

JSR stack

GameOverCondition

ldx #text

pshs x

ldx #$50C

pshs x

jsr GAMEOVER

jmp NextMiniGame

GAMEOVER

puls u

puls x

puls y

loop

lda ,y+

beq WaitGameOver

sta ,x+

bra loop

WaitGameOver

jsr [POLCAT]

beq WaitGameOver

tfr u,pc

text fcn "GAME OVER"

JSR post data

GameOverCondition

jsr GAMEOVER

fdb $50C

fcn "GAME OVER"

jmp NextMiniGame

GAMEOVER

puls x

leay 2,x

ldx ,x

loop

lda ,y+

beq WaitGameOver

sta ,x+

bra loop

WaitGameOver

jsr [POLCAT]

beq WaitGameOver

tfr y,pc

1. Acknowledge the interrupt. 2. Write the new timer delay to the register 3. Enable the interrupt again. 4. Write the value to the DAC. 5. Determine the next timer delay and store it for the next interrupt.

tlindner$ ./mame -listmidi

MIDI input ports:
IAC Driver Bus 1 (default)

MIDI output ports:
IAC Driver Bus 1 (default)

tlindner$ ./mame coco2b -ext multi -listslots
SYSTEM           SLOT NAME        SLOT OPTIONS     SLOT DEVICE NAME
---------------- ---------------- ---------------- ----------------------------
coco2b           rs232            dec_loopback     RS232 Loopback (DEC 12-15336-00)
                                  ie15             IE15 Terminal
                                  keyboard         Serial Keyboard
                                  loopback         RS232 Loopback
                                  null_modem       RS232 Null Modem
                                  printer          Serial Printer
                                  pty              Pseudo terminal
                                  rs_printer       Radio Shack Serial Printer
                                  sunkbd           Sun Keyboard Adaptor
                                  swtpc8212        SWTPC8212 Terminal
                                  terminal         Serial Terminal

                 ext              cc2hdb1          CoCo2 HDB-DOS
                                  cc3hdb1          CoCo3 HDB-DOS
                                  ccpsg            CoCo PSG
                                  cd6809_fdc       Codimex CD-6809 Disk BASIC (1986)
                                  cp450_fdc        Prológica CP-450 BASIC Disco V. 1.0 (1984)
                                  dcmodem          CoCo Direct Connect Modem PAK
                                  fdc              CoCo FDC
                                  fdcv11           CoCo FDC v1.1
                                  games_master     CoCo Games Master Cartridge
                                  midi             CoCo MIDI PAK
                                  multi            CoCo Multi-Pak Interface
                                  orch90           CoCo Orch-90 PAK
                                  ram              Disto 1024K RAM Cartridge
                                  rs232            CoCo Deluxe RS-232 PAK
                                  ssc              CoCo S/SC PAK
                                  stecomp          Speech Systems Stereo Composer
                                  sym12            Speech Systems Symphony Twelve

                 ext:multi:slot1  ccpsg            CoCo PSG
                                  dcmodem          CoCo Direct Connect Modem PAK
                                  games_master     CoCo Games Master Cartridge
                                  midi             CoCo MIDI PAK
                                  orch90           CoCo Orch-90 PAK
                                  ram              Disto 1024K RAM Cartridge
                                  rs232            CoCo Deluxe RS-232 PAK
                                  ssc              CoCo S/SC PAK
                                  stecomp          Speech Systems Stereo Composer
                                  sym12            Speech Systems Symphony Twelve

                 ext:multi:slot2  ccpsg            CoCo PSG
                                  dcmodem          CoCo Direct Connect Modem PAK
                                  games_master     CoCo Games Master Cartridge
                                  midi             CoCo MIDI PAK
                                  orch90           CoCo Orch-90 PAK
                                  ram              Disto 1024K RAM Cartridge
                                  rs232            CoCo Deluxe RS-232 PAK
                                  ssc              CoCo S/SC PAK
                                  stecomp          Speech Systems Stereo Composer
                                  sym12            Speech Systems Symphony Twelve

                 ext:multi:slot3  ccpsg            CoCo PSG
                                  dcmodem          CoCo Direct Connect Modem PAK
                                  games_master     CoCo Games Master Cartridge
                                  midi             CoCo MIDI PAK
                                  orch90           CoCo Orch-90 PAK
                                  ram              Disto 1024K RAM Cartridge
                                  rs232            CoCo Deluxe RS-232 PAK
                                  ssc              CoCo S/SC PAK
                                  stecomp          Speech Systems Stereo Composer
                                  sym12            Speech Systems Symphony Twelve

                 ext:multi:slot4  cc2hdb1          CoCo2 HDB-DOS
                                  cc3hdb1          CoCo3 HDB-DOS
                                  ccpsg            CoCo PSG
                                  cd6809_fdc       Codimex CD-6809 Disk BASIC (1986)
                                  cp450_fdc        Prológica CP-450 BASIC Disco V. 1.0 (1984)
                                  dcmodem          CoCo Direct Connect Modem PAK
                                  fdc              CoCo FDC
                                  fdcv11           CoCo FDC v1.1
                                  games_master     CoCo Games Master Cartridge
                                  midi             CoCo MIDI PAK
                                  orch90           CoCo Orch-90 PAK
                                  ram              Disto 1024K RAM Cartridge
                                  rs232            CoCo Deluxe RS-232 PAK
                                  ssc              CoCo S/SC PAK
                                  stecomp          Speech Systems Stereo Composer
                                  sym12            Speech Systems Symphony Twelve

                 ext:multi:slot4:fdcv11:wd17xx:0 qd               5.25" quad density floppy drive
                 ext:multi:slot4:fdcv11:wd17xx:1 qd               5.25" quad density floppy drive
                 ext:multi:slot4:fdcv11:wd17xx:2 qd               5.25" quad density floppy drive
                 ext:multi:slot4:fdcv11:wd17xx:3 qd               5.25" quad density floppy drive

./mame coco2b -ext multi -ext:multi:slot3 midi

tlindner$ ./mame coco2b -ext multi -ext:multi:slot3 midi -listmedia
SYSTEM           MEDIA NAME       (brief)    IMAGE FILE EXTENSIONS SUPPORTED
---------------- --------------------------- -------------------------------
coco2b           cassette         (cass)     .wav  .cas  
                 printout         (prin)     .prn  
                 cartridge1       (cart1)    .ccc  .rom  
                 cartridge2       (cart2)    .ccc  .rom  
                 cartridge3       (cart3)    .ccc  .rom  
                 cartridge4       (cart4)    .ccc  .rom  
                 midiin           (min)      .mid  
                 midiout1         (mout1)    .mid  
                 midiout2         (mout2)    .mid  
                 cartridge5       (cart5)    .ccc  .rom  
                 floppydisk1      (flop1)    .dmk  .jvc  .dsk  .vdk  .sdf  .os9  .d77  .d88  .1dd  .dfi  .hfe  .imd  .ipf  .mfi  .mfm  .td0  .cqm  .cqi  
                 floppydisk2      (flop2)    .dmk  .jvc  .dsk  .vdk  .sdf  .os9  .d77  .d88  .1dd  .dfi  .hfe  .imd  .ipf  .mfi  .mfm  .td0  .cqm  .cqi  
                 harddisk1        (hard1)    .vhd  
                 harddisk2        (hard2)    .vhd  

tlindner$ ./mame coco2b -ext multi -ext:multi:slot3 midi -midiin "IAC Driver Bus 1"

Come Tumblin' Down It's a Mistake Who Can It Be Now? Overkill Down Under I'm Walking Here Be Good Johnny

Take My Breath Away The Metro No More Words Sex...(I'm A)

President Gas Love My Way Angels Don't Cry The Ghost in You Heartbeat Heaven Heartbreak Beat Pretty in Pink

Mad About You Head Over Heels I Get Weak Circle in the Sand Leave a Light On Our Lips Are Sealed We Got the Beat Heaven Is a Place on Earth

Enola Gay Secret Tesla Girls History of Modern (Part 1) If You Leave (Forever) Live and Die Joan of Arc So in Love Dreaming Locomotion Electricity

'-crop', $width."x".$height."+".$left."+".$top, '-resize','540x700'

'-crop', $width.'x'.$height.'+'.$left.'+'.$top, '-resize','540x700'

Mr. Perrette said NBC understands the potential resistance. “In the short term, this will not win us a lot of friends,” he said. “In the long term, the consumer wants there to be quality premium-produced content, and in order for that to continue to be a viable business, there needs to be significant protection around it.”