Documentation-based ColecoVision emulator

[carmiker]

Hello ColecoVision community,

 

I am working on a ColecoVision emulator with a focus on verbose documentation, to be used as an educational resource and reference - a sort of code as documentation project. I knew few of the fine details about the hardware a few weeks ago, but now I have an emulator written that is compatible with 100% of original, officially licensed games (aside from ones requiring special controllers I have not emulated, though as far as I can tell, those do run). It was written mostly by referencing datasheets, but also some .txt files that have been written by fans of the system -- I have avoided looking at other emulators' sources because I want this to be based on documentation that may be easily referenced with explanations of every last detail. Unfortunately, I have run up against some stone walls, and I was hoping that perhaps someone from this community could help me fill in some knowledge gaps.

 

1. I have noticed that all ColecoVision emulators I have tried have the wrong pitch for PCM sample playback, with the exception of CoolCV. Some don't play anything at all. I have this working with the wrong pitch, and there is nothing about it in the datasheet or the documentation available from SMSPower! that I used to write my SN76489AN code. When the tone generator's frequency for a channel is set to a value of 1, this enables PCM sample playback by rapidly adjusting volume and not changing the sign bit or "frequency flip-flop" as it is called in the datasheet, but there is no reference to pitch.

 

2. I have not found any documentation on non-standard controllers. I actually figured out the bits on my own for the standard one by using Antarctic Adventure and "voodoo programming" to brute force most of the information. I would like to emulate the Driving and Roller controllers but documentation seems sparse, so perhaps someone here could direct me to where I may find some information about these, rather than using the voodoo programming method.

 

3. Do any commercial releases, or even homebrew releases, use the VDP's undocumented video modes?

 

4. Is there any documentation or research on the RAM's startup state? Is this supposed to be a certain value or random garbage?

 

I hope to make a public release very soon, but I would like to see if I can tie these loose ends up before I do that. I would be very appreciative of any information anyone is willing to share!

 

Cheers

Edited August 1, 2020 by carmiker
Add another question

[ChildOfCv]

5 hours ago, carmiker said:

1. I have noticed that all ColecoVision emulators I have tried have the wrong pitch for PCM sample playback, with the exception of CoolCV. Some don't play anything at all. I have this working with the wrong pitch, and there is nothing about it in the datasheet or the documentation available from SMSPower! that I used to write my SN76489AN code. When the tone generator's frequency for a channel is set to a value of 1, this enables PCM sample playback by rapidly adjusting volume and not changing the sign bit or "frequency flip-flop" as it is called in the datasheet, but there is no reference to pitch.

If the programmer takes direct control of the output, then the programmer sets the pitch implicitly by the alternation of the volume.  If you cycle the volume 1000x per second, then you output a 1000Hz signal.  That's just inherent to sound generation.

 

Quote

2. I have not found any documentation on non-standard controllers. I actually figured out the bits on my own for the standard one by using Antarctic Adventure and "voodoo programming" to brute force most of the information. I would like to emulate the Driving and Roller controllers but documentation seems sparse, so perhaps someone here could direct me to where I may find some information about these, rather than using the voodoo programming method.

The driving controller uses the quadrature inputs for the steering wheel.  The foot pedal is just the button.  Roller Controller uses both players' quadrature inputs.  Off the top of my head, horizontal goes to player 1 and vertical to player 2.  The two buttons on the RC correspond to the 2 buttons on the standard controller.

 

Well, Roller Controller actually has 2 modes:  In one mode, it does as said above.  In the other, it emulates joystick inputs based on direction of roll.

 

Quote

3. Do any commercial releases, or even homebrew releases, use the VDP's undocumented video modes?

I've heard that some do, but I couldn't tell you which ones.

Quote

4. Is there any documentation or research on the RAM's startup state? Is this supposed to be a certain value or random garbage?

RAM, like any other IC, starts up in indeterminate states.  Each chip manufactured may have preferences for certain bits at startup, but some bits will still be random.  Between chips, there will be no commonality.

 

Some games rely on randomness to give you a different game each time, such as a casino cartridge.  And one infamous home-brew checks if memory is randomized to its taste, as a form of DRM.

 

Edited August 1, 2020 by ChildOfCv

[carmiker]

4 hours ago, ChildOfCv said:

If the programmer takes direct control of the output, then the programmer sets the pitch implicitly by the alternation of the volume.  If you cycle the volume 1000x per second, then you output a 1000Hz signal.  That's just inherent to sound generation.

I have this somewhat working, since I followed the documentation. The problem is that I have results similar to every emulator but CoolCV. So, there must be some tiny detail missing from the documentation that almost every emulator developer has missed. This youtube video was recorded using real hardware, so one can observe how the PCM samples should sound: https://www.youtube.com/watch?v=Dg65_jCThKs . Compare this to most emulators, and the emulators are 2x the pitch. I have been considering that there must be some other quirk beyond simply not changing the sign bit/frequency flip flop for PCM sample playback, but it's hard to figure out what that is. Experimenting has yielded nothing so far.

 

Quote

The driving controller uses the quadrature inputs for the steering wheel.  The foot pedal is just the button.  Roller Controller uses both players' quadrature inputs.  Off the top of my head, horizontal goes to player 1 and vertical to player 2.  The two buttons on the RC correspond to the 2 buttons on the standard controller.

 

Well, Roller Controller actually has 2 modes:  In one mode, it does as said above.  In the other, it emulates joystick inputs based on direction of roll.

Thank you, this helps my understanding quite a bit.

 

Quote

RAM, like any other IC, starts up in indeterminate states.  Each chip manufactured may have preferences for certain bits at startup, but some bits will still be random.  Between chips, there will be no commonality.

 

Some games rely on randomness to give you a different game each time, such as a casino cartridge.  And one infamous home-brew checks if memory is randomized to its taste, as a form of DRM.

This is what I had assumed, so thank you for confirming this to be the case. Yolk's on You requires the bits to be random, but I am assuming you're talking about Risky Rick here.

[youki]

15 hours ago, carmiker said:

 

 

3. Do any commercial releases, or even homebrew releases, use the VDP's undocumented video modes?

 

 

I think in all my homebrews, i use the "the screen mode 2  'Text'  ".    Some detail on this thread from 11 years ago when i was developping Ghost'n Zombie

 

 

looking forward for your emulator , mainly if it emulate well Driving controller and Roller Controller!    (i guess it will be emulated with a Mouse?)

 

[ChildOfCv]

11 hours ago, carmiker said:

I have this somewhat working, since I followed the documentation. The problem is that I have results similar to every emulator but CoolCV. So, there must be some tiny detail missing from the documentation that almost every emulator developer has missed. This youtube video was recorded using real hardware, so one can observe how the PCM samples should sound: https://www.youtube.com/watch?v=Dg65_jCThKs . Compare this to most emulators, and the emulators are 2x the pitch. I have been considering that there must be some other quirk beyond simply not changing the sign bit/frequency flip flop for PCM sample playback, but it's hard to figure out what that is. Experimenting has yielded nothing so far.

Do you implement the SN76489AN access delay correctly?  When you first raise CS for the chip, it raises WAIT for a number of clock cycles.  The CPU will wait until that line goes inactive again before it finishes the data write cycle.

[carmiker]

6 minutes ago, ChildOfCv said:

Do you implement the SN76489AN access delay correctly?  When you first raise CS for the chip, it raises WAIT for a number of clock cycles.  The CPU will wait until that line goes inactive again before it finishes the data write cycle.

No, I haven't emulated that. That seems like it could be a likely source of the problem though. Thanks for bringing this up.

[carmiker]

It looks like that's what it was. The datasheet says 32 cycles, so I delay 32 cycles on PSG register writes and everything sounds right! Thanks, ChildOfCv.

[carmiker]

https://gitlab.com/jgemu/jollycv

I pushed my code publicly a little while ago. Please note that the emulator is a "core" for my emulation framework, so you do need a development environment to use this currently, but I am perhaps open to building it as a standalone binary if there is sufficient interest. Currently there is no support for the spinner interface that is used for non-standard input devices or Super Game Module support, but I plan to add these things soon.

 

I have a few more questions:

 

1. Lord of the Dungeon shows garbage on the title screen as in other emulators. Is this due to lack of SRAM support in these emulators or would other things be causing this?

 

2. Jungle Hunt's menu screen shows different colours in every emulator. Is this also the case with every different physical console? I played around with VDP register default values and found changing values in Control Register 1 can influence the colours, but cycle timing seems to be another factor here.

 

3. I am having issues with the homebrew games Black Onyx and Boxxle. Are there any known quirks with these games that I would need to handle?

[mumbai]

45 minutes ago, carmiker said:

2. Jungle Hunt's menu screen shows different colours in every emulator. Is this also the case with every different physical console? I played around with VDP register default values and found changing values in Control Register 1 can influence the colours, but cycle timing seems to be another factor here.

The coloration of the difficulty selection screen for Jungle Hunt varies with each restart on an actual console, so it is by design.

[carmiker]

https://gitlab.com/jgemu/jollycv

I have implemented Super Game Module emulation. It works well from what I can see!

Next up will be support for the spinner interface, which will lead to the emulator being feature complete.

[carmiker]

Let's add some screenshots. Pretty pictures are nice!