Demon Attack cartridge (26-3099) has a small bug when running on a CoCo 3. The Programmer’s credit and version information is drawn using garbage rather than the correct data from the ROM.

This has to do with setting bit 3 of $FF90 causing RAM to appear at $FExx. This does not happen on a CoCo 1 or 2.

The second PIA has a smaller mirror in the CoCo 3 than the CoCo 1/2. It goes from $FF20 to $FF2F. The CoCo 1/2 mirror is from $FF20 to $FF3F.

Recently I was challenged to find a citation for this information. But I could not. Tepolt has this wrong. So I decided to create a test program and accompanying video to document this first hand.

Here is the test program.

It is a menu driven program that allows you to choose a specific mirror address for PIA 2, then allows you to choose one of three tests.

Test ‘S’ produces a square wave using the CoCo’s DAC. This DAC is connect to port A of the PIA.
Test ‘B’ produces a square wave using the CoCo 1 bit sound source. This is connected to bit 1 of port B of the PIA.
Test ‘V’ toggles the A/G line of the VDG. This is connected to bit 7 of port B of the PIA.

When using this program on a CoCo 3 you will find the the second PIA only responds from $FF20 to $FF2F. And the VDG test only responds to $FF20 to $FF23, because the GIME only see writes to these specific addresses.

This is a proposal to the people who make FPGA version of the CoCo 3′s GIME chip.

I was recently reading about the Amiga’s Copper chip. I thought something similar could be added to a GIME implementation. The following is my idea, for what it’s worth.

Function

If enabled, during the vertical retrace, the 24 bit table start address is loaded. Then the first byte of the table is deference. If the scan line value (table byte 0) is $FF, then the new value is written to the register number. The table pointer is advanced (by three bytes) and writes are repeated until the scan line is no longer $FF. This allows you to set any video registers before they are latched for the frame.

During every Horizontal retrace the scan line declared in the table is compared to the current scan line. If there is a match, the table value is written to the specified GIME register. Then the next table entry scan line is loaded.

If the scan line does not match, the process is paused until then next horizontal retrace.

If there is time, multiple GIME registers can be changed during horizontal retrace.

Register number zero refers to $FF90 (Initialization register #0). It goes up from there.

Register numbers $FE will trigger an FIRQ or IRQ. Nothing will be written to an internal register. Bit 6 will determine which interrupt is generated ($FF92 or $FF93).

Register number $FD will cause the GIME to reload the video start address from $FF9D and $FF9E. Nothing will be written to an internal register.

Example Programs

I implemented the above in a private MAME branch. I wrote some demos and made these screen captures. All this code can be found here.

COLOR64/BAS:

In BASIC, switch to HSCREEN 2 and draw a grid of 64 circles. Eight every row, for 8 rows. Use palette index 1 to 8 for every row. Load in an assembly language program to install a horizontal sync table to update the palette color to show all 64 colors on the screen at the same time.

Color64

JOY/BAS:

In BASIC, switch to HSCREEN 2, then load a binary file. This file contains:
1. Image data to be loaded in the Hi-res screen memory.
2. The first 52 lines are 128 bytes wide
3. The rest are 256 bytes wide.
4. Hsync table to switch to 256 byte wide video at line 52.
5. Code to install hsync table and turn it on.
Then the BASIC program will update the horizontal scroll register in the table to match the horizontal joystick position.

Joy

DUAL/BAS:

In BASIC switch to HSCREEN 2, Draw random circles. Load hsync table and enable it. Near the bottom of the screen the GIME is instructed to switch to text mode and change the display address to be the bottom of the 40 column text screen.
Repeat drawing circle to the graphics screen and printing text to the 40 column screen.

Dual

INT/BAS:

In BASIC load binary from disk, wait for disk to stop spinning. Switch to HSCREEN 2 and have BASIC draw random circles. Setup horizontal table to trigger IRQ interrupt on scan line 100.

Interrupt service routine quickly sets all palette registers to zero. Then immediately restore RGB palette values. Repeat on next frame.

Int

I’m not a C64 guy. But I do play their games for a little show I do with my sister. Recently we played this game. https://www.lemon64.com/game/laurel-and-hardy

We usually do a poor job of playing complicated game we don’t know. But both of us decided to really learn this game and try to play it well. The game has a sprawling world and I quickly decided I needed a map. So I made one. I like to share so here it is.

Laurel and Hardy Map.

It was recently brought to my attention that Darren Atkinson has a really good summary of the invalid register exchange and transfer opcodes in the 6809.

So good, that I should use the information to make MAME’s 6809 better match real hardware.

That will be a future post. In the mean time, I wrote a little program to exercise all of the invalid combinations and print results to the CoCo’s screen memory. This way I can, eventually, verify the implementation.

The software package is here: Test-Exg-TFR.zip

Here is a screen shot from a real CoCo 2B with a 6809 running my program:

And here is a screen shot form a real CoCo 3 with a 6309 running the same program:

By “invalid”, I mean the combinations of registers that Motorola didn’t document. Combinations like specifying different width registers when exchanging or transferring. Or the use of the register bit patterns not defined by Motorola.

I was recently informed of some inaccuracies with the various VDG text screens emulated in MAME. I also recently acquired an RGB2HDMI. This device is a very configurable retro computer video to HDMI device. One nice feature it has is to write the frame buffer to a PNG file.
Using this device I can capture pixel perfect pictures of my CoCos and compare them to what MAME currently produces.

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

The stem of the number ’3′ is too short in MAME.
The “E” stem is too short.
The “F” stem is too short.

Next is the CoCo 2B in normal mode.

Over all the characters need to be pushed one pixel to the right and one pixel up to properly fit in their boxes.
The ‘@’ has an extra pixel.
The ‘G’ is the wrong shape.
The ‘J’ has an extra pixel.
The pound sign has extra pixels.
The dollar sign has extra pixels.
The apostrophe is missing some pixels.
The comma is missing some pixels.
The period is missing some pixels.
The three is missing a pixel on it’s stem.
The ’6′ is the wrong shape.
The ’9′ is the wrong shape.
The colon is missing some pixels.
The semi-colon is missing some pixels.

Next is the CoCo 2B in lowercase mode.

Over all the characters need to be moved one pixel up and to the right. Except the lowercase J. It only needs to be moved one pixel to the right.
The lowercase letter g is the wrong shape.
The lowercase letter m has an extra pixel.
The lowercase letter p is the wrong shape.
The lowercase letter q is the wrong shape.
The lowercase letter t is the wrong shape.
The lowercase letter w is the wrong shape.
The lowercase letter y is the wrong shape.
The pound sign has extra pixels.
The dollar sign has extra pixels.
The apostrophe is missing some pixels.
The comma is missing some pixels.
The period is missing some pixels.
The ’3′ is missing a pixel on it’s stem.
The ’6′ is the wrong shape.
The ’9′ is the wrong shape.
The ‘@’ has an extra pixel.
The colon is missing some pixels.
The semi-colon is missing some pixels.
The ‘G’ is the wrong shape.
The ‘J’ has an extra pixel.

Next is the CoCo 3 in normal mode.

Over all, the characters need to be moved a pixel up.
The comma also needs to be moved one pixel to the right.
The number 9 has an extra pixel.

Last is the CoCo 3 in lowercase mode.

Over all the characters need to be moved one pixel up.
The lowercase letter g is the wrong shape.
The lowercase letter i is the wrong shape.
The lowercase letter j is the wrong shape.
The lowercase letter m has an extra pixel.
The lowercase letter p is the wrong shape.
The lowercase letter q is the wrong shape.
The comma need to be moved to the right one pixel.
The numeral 9 has an extra pixel.

Special thanks to Pedro Pena for a screen capture.

MAME 0.246 is the first version to contain the fixes for the above.

An interesting bug appeared on MAME Testers recently. The bug linked here is really simple. OS-9 wont boot on a copy protected disk image. The solution also was simple: properly emulate the delay between issuing a write command, and the INTRQ that happens when the write protect notch is covered.
But how long of a delay should it be? The floppy disk controller chip data sheet does not specify what is normal. I wish I had an oscilloscope to measure things like this, but I don’t. So I had to get tricky.
I wrote a Color Computer program that writes to a write protected disk on purpose. Normally after you issue the command to write to a sector, you prepare to start writing and then wait until the disk is ready. But if you know the disk write will error becuase of a write protect notch, all you really have to do is count. That is what I did, initiate write and then count forever:


    pragma 6809
    opt cd

vector_return
    stb count
    lda $ff48
    sta error
    andcc #$AF enable interrupts
    rts
    end begin


The loop will not actually count forever. When the write fails, the Floppy Disk Controller will produce an Interrupt Request signal. On the Color Computer this is tied to the Non-Maskable Interrupt line. This will stop the loop and run my NMI handler. The records the counter and status to make available to a BASIC program for further processing.

I now have two results from different Floppy Disk Controllers: 20 and 19. With a 5 cycle loop counter, this comes to a delay of about 111 microseconds. I show my work here.

Thanks to a few friends I’ve been able to upgrade my hi-res tester to support the CoCo Max III interface. It is a device similar to the Tandy Hi-res interface, but is triggered differently.

Here is what MAME is doing as of today for the CoCo Max III interface:

After going over the data here is what I am going to change MAME to do:

You can see the new values are nearly the same as the previous values, but I think it is an improvement to use values verified on actual hardware.

I was recently told about a bug in MAME’s implementation of the Tandy Hi-Res Joystick interface. The author of C-III Pages (an early desktop publishing application for the Color Computer) discovered the mouse cursor would only go 7/8th across the width of the screen.
This means it is now time to really try to understand the device. Reading the code in MAME doesn’t really tell the whole story, and none of the values that are chosen are explained.
So I did what I always do, I wrote a test program to run on real hardware. https://github.com/tlindner/HiRes-Interface-Test
This program uses a slightly modified version of the sampling code found in most software. It does not do any scaling of the returned values to fit within the screen width or height. It leaves them raw.
I have in my possession four “joysticks” to test. A black beauty, a delux joystick, a C&H joystick, and a Koala Touchpad. The testing procedure was to start the program and wiggle the joystick while looking at the graphic screen (the G command). When I filled in as much as the four rectangles as I could, I returned to the text screen and took a screen shot.

Black Beauty

Deluxe Joystick

C&H Joystick

Koala Touch pad

The Kola touch pad had the weirdest response to both versions of the sampling routine. See the image below and notice how much noise is in the bitmaps:

Here is what MAME is doing as of today:

After going over the data here is what I am going to change MAME to do:

Hopefully this will fix the bug in MAME that affects C-III Pages and not cause any regressions.
If you want to run the program your self with your own interfaces and joystick, I would love more data. I am especially interested in what the 1 and 2 button Color Mice do.
I would also like to get values from the Color Max 3 hi-res interface. If uses the same method, but the RC values are different in the circuit.

The Color Disk EDTASM assembler has the option of writing a symbol table to the end of binaries it produces. You enable the feature by including the /WS switch during assembly to disk. The symbol table can be used by the stand alone ZBUG debugger.

Invoking the switch will add extra data after the LOADM post-amble. Here is how that data is formatted. First is the header. This is always 5 bytes in length.

Next you will find a table entry for each symbol and value pair.

And finally is the footer. a single constant byte:

It should be noted the Assembler and ZBUG pair can only handle symbols with a maximum of six characters.