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.

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.

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.

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).

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.

Per the SN76489 data sheet, it needs 4 cycles to load a data value. I note from the schematic that its ready line is connected to the Z80's WAIT input. I notice that the Z80 OUT will have been asserting the write input for 1.5 cycles before it tests WAIT. So it looks to me like it should end up inserting three WAIT cycles, making the entire machine cycle seven cycles long. Or, in net, adding three cycles to any OUT that is decoded to access the SN76489. Is that a correct reading?

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.

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.

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.

It looks like this list is now entirely unmaintained (?), but emulators to add: Bee Clock Signal The latter is mine, so allow appropriately for bias.

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.

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.

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.

I'm late to say so, but mine arrived seemingly† in good shape, thanks! I also have the Lynxman cart, so I guess I'm making a habit of this. † I'm presently Lynxless. I may not have planned ahead very well on this one.

Ah, my understanding was that the play field has the same clocking delay. So if you were to hit reset 68 colour cycles after a WSYNC without having issued an HMOVE you'd expect the ball to appear in the second column of the screen, not the fifth (though the CPU will have done another 1.33 cycles of work by then). I have the starts and stops delayed by four cycles (or five for the players), but enabled/player pixel lookups not delayed at all. It's sounding more and more like I may have misread what documentation there is. I felt it strongly implied the opposite with "therefore we can say that player grahpics are delayed by 1 CLK (this is why the leftmost possible start position for a RESP0 is pixel 1, not pixel 0. You can HMOVE the player further left though, if necessary.)"; how could you use RESP0 to place a player in pixel 1 if you weren't issuing it in the blank area? If there's no flaw in my logic, I accept that reading too much into a throwaway statement would also be a potential hazard. Also, option three for determining edge-case behaviour: ask an altruistic member of an internet forum. Thanks for everything you've helped with already!

I think these tests might have revealed that the issue is comprehension, not coding. Or, at least, that comprehension is a first issue. E.g. I see in the ball test that the following causes the initial ball positioning: F0A3 85 02 STA $02 F0A5 84 09 STY $09 F0A7 85 14 STA $14 So that's a WSYNC, then a background colour set, then a ball reset. In Stellarator the ball first appears in the third pixel column. In my emulator it first appears right at the left edge of the screen. Which is also where I would place it if working by hand: STA $02 activates the ready line. The CPU attempts to read the opcode at FOA5 but ready is asserted, so it pauses. TIA stops asserting the ready line upon entering the right-hand blank area and the CPU resumes. It spends three cycles performing the STY that changes the background colour. So it is now 9/228ths beyond the start of the right-hand blank area. Two cycles pass while it reads the STA to $14. On the third cycle it does the write that will reset the ball position. So the ball is reset during the three colour cycles that begin 15/228ths beyond the start of the right-hand blank area. And, because it's the ball, even a programmatic reset causes a start drawing signal. So that all happens outside of the visible portion of the screen. And HMOVE has not been triggered. So if you asked me, the human being, what happens: the counter is now reset, but isn't currently clocked; it will not receive any further clocks until pixels resume; once it receives a clock input, it will begin drawing; it'll be clocked at the same time as the play field and has the same output delay, so that means it'll appear in the first pixel column. I believe that I've made a mistake somewhere in this reasoning, because my results do not agree with Stellarator's and, in any case, show issues elsewhere. Can anybody tell me what my error is?

Cool, thanks! In an ideal world I'll find time to boil those down to providing a version of how the output should look in data (my internal representation is nothing exotic; a six-bit bit field per output pixel); if so then I'll contribute back, naturally. With something I'll probably end up wanting to optimise, automated testing should be a win.

Clearly my terminology is askew; the coefficients I'm using were derived from pointing a camera at a screen. So it's partly decay, partly a time integral (via shutter time), then a not unreasonable amount about what works well on a GPU. Which all makes it sound much fancier than the implementation actually ends up being, but is at least a real basis. It's an attempt to leverage the things computers can do now which were not realistic previously; a terrible attempt possibly but hopefully that's instructive as to motive.

Here's a video mostly showing the current flaws, mostly as identified above (but also featuring some other errors that I'm aware of but didn't mention); I'll try those other ROMs and see what happens.

I'm aware of all of that, but my issues are distinct for the reasons as given. My simulated CRT simulates something closer to the real physics of phosphor — exponential decay, most recently painted thing most prominent — and works by decoding a genuine NTSC or PAL signal. So it's only ever dealing with a 1d signal, discriminating syncs and painting stripes of data with a defined width. If you had a 144Hz monitor, it will paint 144 different frames per second. Just like if you pointed a 144Hz camera at a CRT, you'd get 144 different frames per second. The phosphors themselves are effectively an infinite impulse response filter. Except that they're in a computer so obviously they underflow. I would dare imagine you're getting traces of four to five frames worth, though very little of the older ones remains. It's not actually doing "I have a complete new frame, let's add it to the queue of frames and then mix them", or any other sort of frame-based-timing. Even if it were, they wouldn't be evenly weighted because they're not in real life. The major disadvantage is that I need smarter filtering. In this case I'm possibly picking up a beat frequency but, more likely, as DirtyHairy guesses, I'm probably just suffering from frame skipping. So e.g. I'm sometimes seeing more of those where Kong's background is the most recently painted thing (and therefore more prominent) than where Kong's features are the most recently painted thing. It certainly seems to vary over time. I'll try to grab a new video. But key point: emulation of the real device. No workarounds, no hacks. So, yeah, noble intentions. But probably I've written a cheque I'll never be able to cash. Though in theory all of the following would be emulated correctly: given that programmatic sync and the automatic horizontal sync are exclusive ORd, using the programmatic one to eliminate the built in one (and placing it elsewhere, hopefully); generating an interlaced display; deliberately introducing roll as a video effect. ... plus the stated intention of latency reduction if the user has spent the money on their hardware. With much better PAL display than naive 5->6 mapping being a side effect. (appropriate observation: that'd all be lovely if, you know, the actual chips were good emulations too) Oh, it's okay, when Meltdown's running you can clearly see it alternating between a left frame and a right frame, perceptually to create something much closer to round. But since real phosphors aren't an equal weighting of the two most recent frames and then an instant drop off before the third, it doesn't look like that in a screenshot. Pitfall 2 and Double Dragon are showing missiles on the final column before right border which I think means they're being triggered a clock early. I don't think it's an unobserved hardware feature, I think it's just that my code does not conform to spec. Ditto Yars'. Clearly an issue entirely of my own making, not an interesting new observation. But if I'm going to sit here explaining what I've tried to do, it would be an omission not also to mention the things I've so far failed to do.

When I'm actually playing the game, the individual nuclei are sized independently, so I'm fairly confident that one works†. I don't know when it started working or why, but I'm intending to treat NUSIZ correctly — the sprite size affects when the pixel clock increments, the decision being made on each pixel clock††. A bunch of other games throw up a bunch of other mysteries, but I'm optimistic that implementation errors rather than false structural assumptions underly all of them. Though time will tell. I need to start to track the test cases you've been putting together, as they seem excellent. Hopefully I can find a way to automate them. Immediate mysteries off the top of my head: both Pitfall 2 and Double Dragon appear to enable and disable the missiles at the same time as the corresponding players, expecting the missiles to be hidden entirely by the action of HMOVE. But the first pixels of mine show up in column 159, likely an off-by-one counting error somewhere; during its first display of the game screen, the players in Yars' Revenge whizz around the screen to indicate some other mistake in HMOVE. But at some point they become their expected static selves. Since this problem suddenly arose without warning, and appears to vanish at some point with the same kernel, uninitialised state is guess number one. DK VCS also flickers quite extravagently. My emulator has the full CRT emulation in it, which fully decouples when your computer displays a frame and when the Atari or whatever generates one, such that if you have a 144Hz gaming monitor then the emulator will produce 144 different frames per second. All part of the war on latency, but it means that this isn't necessarily as trivial to avoid as if I were forcing a frame buffer into the middle. † though there seems to be a scaling error somewhere in my CRT emulation in which some columns end up a different width from others, which might psychologically suggest incorrect symmetry. My NTSC and PAL decoding has been through several changes in the last two years but right now is based upon scaling an input wave to a fixed grid of four samples per colour clock. Which for an Atari should be an integer scale. I may have made a precision error somewhere, but then I'd expect colour artefacts from wandering of phase. So who knows? †† ideologically, anyway, though I'm a batch-it-up guy. The TIA, like every other component in the emulator, is written such that the inner loop runs for n cycles assuming no new input, and accepts input only between those runs. Which sounds like a classic trading of accuracy for code simplicity, except that n isn't fixed. If you write to the TIA at cycle a, then write to it at cycle b then the internal code will ignore the TIA completely until you hit it again, then run it for b - a cycles, then post the write. You could repeatedly ask it to run for a single cycle if you wanted but it'd be slower.

Bump of my own volition, to note merely that this is still being worked on, though there's still not much of interest in a world where Stella already exists. It's become a multi-machine emulator and gained support for all of the real-world bank-switching schemes except, ironically, the Supercharger. So I should look at that again. I've been publishing binaries for a while at GitHub. It's still no special cases, no workarounds, but pleasingly Meltdown works. Though there are some oddities elsewhere, mostly things being a small distance from where they should be, which I'm at a loss immediately to explain other than to say that it's not any of the most obvious things.

If Wikipedia is trustworthy then Sirius Software, the developer of both titles, is at least partly known for "its ... quick collapse in 1984 after 20th Century Fox ... failed to pay over USD$18 Million in owed royalties". So if the answer isn't something as simple as Fox not being interesting in home computer rights, possibly some element of acrimony is involved?

Maybe I'm way off, but I think it's helpful: internally the Atari directly generates composite video, and audio, two signals that contain one image; the TV modulator takes the video and audio and combines them into a radio frequency ('RF') signal, one signal that could contain all the terrestrial channels, which is supposed to look to a TV indistinguishable from the input it'd get from a real PAL transmission received via a real aerial. An unmodified Atari has only the modulator output — that's the thing that comes out of the closed metal box that probably has a red sticker on top. You'd plug that into the aerial socket on your analogue TV and tune to the location in the pretend radio spectrum that the Atari was pretending to broadcast on. You could reasonably expect that to do something at least with any TV built prior to 2012. In 2012 the final analogue transmissions were switched off so a newer TV probably doesn't have decoding circuitry for analogue PAL. It'll still have the aerial socket because it's still expecting to receive radio transmissions, it just thinks they'll be Freeview digital. If your TV has an RCA socket, it's probably expecting composite video. Unless your TV has very peculiar wiring, it's very unlikely that plugging an aerial output into an RCA socket will do anything. A VCR should have worked since they all need to be able to demodulate RF in order to be able to record it, and usually offer SCART output, which carries RGB, composite, and a bunch of other options. So aerial to VCR; SCART from VCR to TV is a normal arrangement. I cannot think of a reason why a TV might be able to pick up audio but then lose it, for all time. But if you're looking for a hardware modification, I'd dare imagine that just extracting the audio and sending that to external speakers while muting your TV would be the easiest thing.

Shorter than a certain threshold, the more likely a game is to roll on different screens. For each screen it's probably just a yes or no decision versus its particular threshold.