New emulator for the Mac (and shortly Linux); enjoy composite video!

[ThomH]

Hi everyone. I know that there's no substantial need for another ColecoVision emulator, but here's a new one just in case.

 

It makes a very genuine attempt to:

• be cycle accurate, including all TMS memory accesses and read/write availability;
• produce and decode genuine composite video, for genuine composite artefacts (no RF implemented at the time of writing);
• also otherwise generally emulate a CRT rather than just pushing frame captures: there's phosphor decay and the thing is pumped by the refresh rate of your monitor, not that of the ColecoVision. If you have a 120Hz or a 144Hz monitor, you should get 120 or 144 distinct frames a second, with the substantially reduced latency that implies;
• similarly, audio is sampled at megahertz and low-pass filtered down to whatever your machine can output. So if you can output 192Khz audio, your emulated ColecoVision will generate 192Khz audio for you.

It's a multimachine emulator, so a lot of it is more battle tested than the sudden announcement might imply, but large parts of the ColecoVision implementation are entirely new.

 

The emulator actually has two established targets: the Mac, and anything UNIXy. However I'm being bitten by my historic laziness in dealing with joystick-type input so on the Mac the ColecoVision is controllable via the joystick, on UNIX machines there's no joystick input at all. But if you enjoy watching game title screens, this is definitely for you.

 

On the Mac it's a fully native document-centric Mac app with no extraneous interface. So when you launch it, nothing will be displayed. Use File -> Open... to open a game. Open twenty if you like — each will open individually, in its own window, for independent sizing. Full screen them, put them into tabs, do anything you'd normally do with a normal Mac app.

 

However, since I have not yet implemented support for physical joysticks, use the cursor keys and A/S (or space for left fire). 0–9 do what you want, but to type a * or a # you're going to need to actually type that. So on my US machine with a UK keyboard mapping, I press star by typing shift+8 and # by typing option+3. But just do whatever you'd normally do to type a * or a #. This is very work in progress.

 

For UNIX systems it's an SDL app with an arbitrarily resizeable window, but expects to be launched once per title you want to play simultaneously, from the command line. The expectation is that you'll just set up the correct file association, and double click from your favourite file manager to launch. Exactly as if the ColecoVision games were just native applications.

 

That's really the whole ethos of the thing: my assumption is that a user wants to play classic games, not learn about an emulator. So it seeks to be as discreet as possible.

 

Feedback is always strongly appreciated, no matter how critical.

 

Because it's pretending to be a real CRT, it's often hard to get a good screenshot. Some efforts are nevertheless attached. Like a real CRT, you don't really perceive it as the shots appear. Try it and see.

[ThomH]

To try to compensate for the look of the still images, here's a video. Suffice to say, I did not write this emulator because I am really excellent at Galaxian.

[ThomH]

I've made a quick further release, available from the usual place.

 

The SDL version now also uses the keyboard as a joystick when running the ColecoVision. Much the same controls as documented above for the Mac target.

 

So, requirements are:

• SDL 2.x;
• SConstruct, to build; and
• an OpenGL 3.2+-capable graphics card.

Then it should be usable under Linux, BSD, etc. The OpenGL requirement is a result of the composite encode and decode — both are handled by the GPU.

 

If there is a way to edit this thread's title that I'm failing to spot, please don't hesitate to let me know.

Edited March 4, 2018 by ThomH

[ThomH]

Minor update on this: it has come to my attention that I've drawn an incorrect conclusion in declaring within the emulator that .col and .rom are the only file extensions that might imply a ColecoVision cartridge. A forthcoming update will add .bin. It's very slightly more work than it sounds because that'll mean disambiguating files named .bin that are images of ColecoVision titles and files called .bin that are images of Atari 2600 titles. Shouldn't be too big a deal as the emulator already invests quite heavily in various mechanisms that should allow it to make that distinction*, but a small amount of finesse might be required. As I'm off on holiday from Friday, I guess look for that in a few weeks; until then renaming your files to .col or .rom is the trick.

 

* for the technical nerds: both static and dynamic analysis. It'll try and almost always succeed to make a decision up front before launching a machine but it also has the fallback of just trying all the possibilities simultaneously, presenting only the transiently most likely, and continuing until it's pretty obvious which was the right choice. In this case I'm confident that it'll be achievable statically by a simple ahead-of-time disassembly. But we'll see.

[ThomH]

While attacking easily-completable tasks before I go away, I discovered a small error that could severely affect the precision of Super Game Module AY audio. So a new release is out. This really really probably is it for a few weeks.

[ThomH]

It's almost embarrassing to have made the job so complicated for myself, but I've just provided a release that accepts ColecoVision .bin images. It also makes a fix to audio output so negligible that I don't think it would ever have been audio: I was pegging audio events to the start of the machine cycle rather than the proper moment of action. But consistently so, so unless you've a variety of code paths that hit the AY and which often intermingle, it would be unlikely to make any audible difference whatsoever.

 

Re: discerning ColecoVision .bin and Atari 2600 .bin, I gave up on doing this ahead of time in more than a negligible proportion of cases. So in practice what'll probably happen when you launch a ColecoVision .bin is:

• emulator inspects, spots the 0x55/0xaa signature and decides a ColecoVision would accept this .bin;
• lacking much useful information, it also can't rule out that an Atari 2600 would accept it too;
• it therefore runs the .bin in both the ColecoVision and Atari 2600 simultaneously;
• after a couple of frames or so, it realises that this definitely isn't an Atari 2600 game and stops running the Atari 2600.

So if you instrument it, you'll see a burst of processor activity when launching a .bin that you don't see when you launch a .col but it's so transient that you won't care.

[ThomH]

Minor update: having checked the schematics and the data sheet for the SN76489 I now believe there should be a three-cycle penalty when accessing the thing. So I've added that to the emulator.

 

Download from the same place as previously.

[ThomH]

There have been a couple of further minor adjustments that affect the ColecoVision in the latest release:

• there was a bug in my TMS implementation whereby sometimes 8px-wide sprites could show garbage in the 8 pixels to their right, which has now been fixed; and
• I've added joystick input for the macOS port, bringing it up to parity with the SDL version that Linux users encounter.

So to recap all emulator features because otherwise there's a lot of reading up there:

• it's a cycle-accurate ColecoVision emulator with Super Game Module support;
• that produces output via genuine composite video (i.e. the real composite signal is encoded and decoded; this isn't some hokey post-processing 'NTSC filter');
• that is not frame-bound: it scales display with your monitor's refresh rate; audio lag is somewhat independent of that (much moreso under macOS than SDL though); and input lag is equal to whichever of those is lower; and
• that doesn't take any shortcuts in audio processing — a full megahertz order-of-magnitude output is calculated, then lowpass-filtered down for output (on macOS: to whatever your hardware supports; on SDL always 48Khz).

[ColecoJoe]

Looks and plays great. How do I run a SGM game on it?

[ThomH]

Looks and plays great. How do I run a SGM game on it?

 

 

It shouldn't be any harder than just opening the ROM; I've tested Mecha 8 and the Super Game Module Test provided with CoolCV but not a great deal beyond that so if something is faulty let me know. It's a relatively new and unused emulator, so latent bugs are a definite possibility.

[ColecoJoe]

They don't open. I'll check it out later and send you a log if I find something.

[ThomH]

Cool. Sorry for the hassle.

 

If the failing files are publicly available then I will definitely check them out specifically.

 

Otherwise, the rules for identifying that a ROM image is intended for the ColecoVision are:

• it must be 12kb exactly, or else less than 8 bytes more than a multiple of 8kb; and
• if it is a 32kb ROM then the first two bytes must be either AA 55 or 55 AA; or
• if it is greater than 32kb then the two bytes that are 16kb from the end must be either AA 55 or 55 AA.

If the emulator reports an error instead of launching, something in the logic or implementation of those tests is at fault. Likely the same if it launches some non-ColecoVision machine and doesn't in a short amount of time switch to a ColecoVision. If it starts up as a ColecoVision, title screen and all, but then doesn't function then clearly there's a mistake in my implementation of the ColecoVision.

 

EDIT: if the problem is the wrong machine starting up, renaming from .rom to .col should help to disambiguate. Though the sanity checks above are still applied as currently implemented.

 

Any cartridge larger than 32kb is treated as a MegaCart, but I guess that's orthogonal to Super Game Module support. A hypothetical 32kb MegaCart would fail to work, because it wouldn't be recognised as a MegaCart and the two 16kb parts would appear in memory the wrong way around, but I can't imagine such a thing would exist.

Edited July 26, 2018 by ThomH

[ThomH]

Too late to edit the previous, but could the problem be the cartridge size? I had a poke around the forums and found at least a couple of instances of modern developed software that is provided as a ROM file of an arbitrary size.

 

So I don't think my attempt to distinguish ColecoVision ROM files from others by normal ROM chip configuration is appropriate. It will be revoked in a future release.

 

Until then, padding up to 12kb or any multiple of 8kb above that should do the trick.

[ThomH]

Supposing the issue was overly-strict file size validation, that should now be fixed. The new rule is:

• if file size is in the range 32–32.5 kb, truncate to 32kb;
• otherwise, round up to the next multiple of 8kb.

Then if the cartridge is greater than 32kb in size it's treated as a MegaROM. This logic seemed to be more appropriate for the various homebrew titles I found on these forums.

 

Downloads here.