Colecovision revisited

[Henk Berends]

I built the SC203 Z180 kit this winter and recently put together the propeller graphics card. It all works very nicely and I learned some new things about the different CP/M versions and Z180 specifics.

So I wondered, could I play Colecovision games on this retro computer? And to my surprise.. yes, it is possible.

For this I made some Coleco BIOS modifications:
- Use a keyboard (via serial) to replace or in addition to a game controller
- Use the propeller graphics card with the TMS9918A emulation
- Use a 50Hz timer to replace the tms vsync nmi

I also made a few small changes in the SCM debug version for Coleco/SC126.

Coleco games that use the BIOS are likely to work, games that use their own I/O routines won't.

Optionally adding the game controller and SN76489A sound card enhances the experience.

Sources:
https://github.com/b3rendsh/cvload

Henk

[Marco Maccaferri]

Il 30/03/23 17:06, Henk Berends ha scritto:

> I built the SC203 Z180 kit this winter and recently put together the
> propeller graphics card. It all works very nicely and I learned some new
> things about the different CP/M versions and Z180 specifics.
>
> So I wondered, could I play Colecovision games on this retro computer? And
> to my surprise.. yes, it is possible.
>
> For this I made some Coleco BIOS modifications:
> - Use a keyboard (via serial) to replace or in addition to a game controller
> - Use the propeller graphics card with the TMS9918A emulation
> - Use a 50Hz timer to replace the tms vsync nmi
>
> I also made a few small changes in the SCM debug version for Coleco/SC126.
>
> Coleco games that use the BIOS are likely to work, games that use their own
> I/O routines won't.

That's awesome, well done!

Best regards,
Marco

[Henk Berends]

Thanks Marco,

Your graphics card is also a nice introduction for me to the parallax universe.

Theoretically it looks possible to add a few screen modes to your TMS9918A firmware, like MSX2 screen 5 (256h x 212v x 16 colors, 26.5K) and/or 80 columns in screen 0 (text mode). This would make it a TMS9918A-plus or V9938-light with a wider range of applications on the retro computer.

Also I noticed that sprites handling is not 100% compatible yet, with the coincidence bit and 5th sprite detection missing. Many games are playable without this anyway. One question, is following feature implemented?
"Sprite processing is terminated if the VDP finds a value of 208 (D0H) in the vertical position field of any entry in the Sprite Attribute Table." (chapter 2.4.5 or page 2-27 of the TMS 9900 Data Manual)

Henk

[Marco Maccaferri]

Il 04/04/23 12:51, Henk Berends ha scritto:

> Theoretically it looks possible to add a few screen modes to your
> TMS9918A firmware, like MSX2 screen 5 (256h x 212v x 16 colors,
> 26.5K) and/or 80 columns in screen 0 (text mode). This would make it
> a TMS9918A-plus or V9938-light with a wider range of applications on
> the retro computer.

Yes, the problem is that the cog code space is very limited and there
isn't much space left for additions.

> Also I noticed that sprites handling is not 100% compatible yet, with
> the coincidence bit and 5th sprite detection missing. Many games are
> playable without this anyway. One question, is following feature
> implemented? "Sprite processing is terminated if the VDP finds a
> value of 208 (D0H) in the vertical position field of any entry in the
> Sprite Attribute Table." (chapter 2.4.5 or page 2-27 of the TMS 9900
> Data Manual)

Yes, D0 is supported.

Also the 4 sprites per scanline limit is supported (although not
signaled in the status register), however I think there is a bug in that
case that may be the cause of the issues you found in some games.
Sometime ago I wrote a ColecoVision emulator for the Parallax P2 and
while porting the TMS9918 code from the P1 I found that the rendering
order was not entirely correct (don't remember exactly now...).

The coincidence bit is not supported, adding it may be problematic
because of the code size limit.

Best regards,
Marco

[Henk Berends]

Okay, good to know what the limitations are.

I did some testing and could replicate the bug:

1. If a sprite has a transparent color it should still be counted with the 4 sprite limitation per scan line.

2. The order in which sprites are shown on the screen is reversed. The 1st sprite should be on the top layer.

See attachments for the differences and test program I used.

Henk