ThomH

Hi again; sorry — I'm trying to figure out exactly how the TIA maps a colour to a chrominance signal. Sadly I'm trying to work this out without access to an oscilloscope so my information sources aren't fantastic. From Google I grabbed RGB constants for the 16 NTSC Atari colours at maximum intensity (my assumption being that luminance and chrominance are handled orthogonally). I mapped those to NTSC's IQ colour space, quadrature encoded that and plotted a whole colour cycle. That created the leftmost graph in the attached image. I noted that they are all, as implied in various posts here, phase shifts and different amplitudes of a sine curve. I calculated the phase offset of each of these. That created the centre graph. I calculated the amplitude. That created the rightmost graph. Likely I got a slightly off set of RGB constants, probably derived by somebody from a frame capture and therefore are subject to rounding errors; I'm therefore happy to assume that the phase offset is a triangle wave (with colour zero having any phase whatsoever, given that amplitude is zero). However the amplitude doesn't look to be doing anything too obvious. Does anybody know what's meant to be going on there? Is there a clean function for that? I accept that colour zero is probably handled as a special case. EDIT: attached the source data for those graphs in the very proprietary Apple Numbers format; the Excel-format version was not an acceptable attachment for this forum. Added a PDF version so that at least other people can see the numbers, if not the formulas. atari colours.numbers.zip atari colours.pdf

How frustrating. The only thing I'm consciously aware of currently definitely being wrong is that I apply the player number — the bottom two bits of $04 and $05 — to the player objects only, not to the missile objects. Hopefully that sometimes missing second pixel comes from one of those. Otherwise it could still be any one of about a thousand other things. Cool. Then that makes a lot more sense. But you'd still have to disable the colour carrier to get greyscale, wouldn't you?

I'm very late to the party; have I missed my chance to join in? Vaguely related question: does any of my Navigator code survive in Stardreamer? If my memory isn't at fault in thinking you had any interest in it. Naturally, it being about a decade later, I'm a much better programmer now and would probably wince if I were to review it myself.

So, things are going reasonably well — e.g. the Cosmic Ark star field just works (it's against my nature and my objective to put in special cases, so there are none), but then vertically travelling asteroids are too far to the right so possibly I've got something wrong in my ready line timing but probably one of my 6502 parts is wrong. KC Munch Man just isn't doing much of anything — I get the occasional flash of an image but my CRT isn't syncing to it properly. Which is not an uncommon theme. Possibly I should have started with a hacky approach of just taking an enabling of the vertical sync output to magically cause the CRT to recognise a vertical sync but I'm sure I'll figure it out. E.T. at least displays something of a title screen so I'm probably going to take a detour into audio next, having the actual original above to compare to. However, quick TIA question: Of the 7 bit colour format, the lowest three bits are the luminance and the top four bits are a phase offset for the colour subcarrier. Resulting questions: it appears that a phase offset of zero is black, and that a luminance of 0 produces the blanking level. Therefore is there a special case that the colour subcarrier is disabled for chrominance 0? by what formula is the colour phase offset applied? Just add n/15th of a cycle?

Cool, thanks. I've yet even to implement paged ROM support so it'll be a while. Like any developer I definitely have my limits but one of the reasons I'm doing this is an unhealthy recent interest in all things NTSC and PAL — I would ideally get to a position where the Atari 2600 module spits out genuine composite which the CRT part of the emulator genuinely ingests, but right now the Atari 2600 is fictionally putting out RGBA video. All the CRT is doing is attempting to catch the syncs, put together its record of raster scans and associated data outputs, and pass that on to whomever knows about drawing to the host machine's display. While I'm kicking that final chunk over to the GPU it would not, taking a step back, be very difficult instead for the Atari to generate composite video, like real Ataris do, and for the GPU later to decode it, with colour artefacts emerging naturally (and some sort of transmission error being insertable if required; the physics of cables usually implies some sort of low-pass filter). The AM demodulation is the only part I lack the experience in, since on a GPU you'd want it to be purely functional, but it's pretty much guaranteed to end up being a weighted sum of nearby samples once I figure the maths out so it's definitely within a modern processing budget. Which is all very grand talk but right now either my Atari emulation isn't always producing correct sync signals or my CRT isn't always correctly recognising them. So I'm a long way from anything advanced. I've at least simulated what I think are the correct tests — edge triggered hsync, a pretend capacitor charge for vsync — so there's nothing phoney in my assumptions. Just some sort of error in implementation. As and when (and if) monochrome KC works, I'll get in touch. It definitely looks like one of the Atari masterpieces.

Okay, then unexpectedly that's something I may actually be capable of contributing constructively on. I'll see how I go. I was writing emulators back in the '90s too and have acquired some DSP experience in the interim so I'm aware of the difference between what we had to do then and what we can do now. My little effort doesn't have any sound code in it whatsoever at the time of writing though and I've not looked at the Stella code so the obvious caveat applies: at present there's no meaningful evidence that I can do any better than whatever Stella is already doing. Just a take-it-on-trust guess.

Thanks! Suffice to say, I won't need to bother Stephen any time soon.

Okay, so I was wrong about that. I was trying to make the point that I wasn't aware of anything substantially wrong with Stella and that I don't think I'm going to produce anything of value even close to Stella — in effect that I'm not intending to contribute to Stella because I'm not expecting to have anything to contribute. In practice I made the point that I definitely don't know enough about Stella to start contributing to it. Either one will do. But let's say this: if I find one day that my little thing is running Meltdown correctly, I'll get in touch with Stephen. (follow-up query: is Meltdown available for download? All I could find were references to the 1983 Fox prototype, which appears quite definitively not to have any invaders whatsoever) I'm primarily dumping display work onto the GPU. Which means using a high-level language for those parts that might have any effect on screen tearing. I'm specifically using GLSL because I know it (and it's the least platform-specific of the shading languages, which is a bonus). The output from the emulator is of the form "CRT gun started firing at (x, y), here's a sample buffer of what it fired during the run, it ended at (m, n)". So inherently stuff that the GPU is best equipped to handle. (follow-up query: KCMM was a recent commercial release; by what avenue might I be able to obtain it for emulator testing? Are copies still available? Ideally for less than $130,000!)

Stella is already perfect as judged by its objectives. It would be arrogant to think I could possibly have anything to add. Or, I guess, after twenty years you could argue that it's either already perfect or impossible to perfect. Which I think cuts to perfection not being objective. I don't see a substantial distinction between rewriting one thing and writing another that satisfies the same specification. But, more importantly, I don't see that there's anything much to add to Stella — it hits its goals excellently. The authors should be proud. I think there's a spectrum from Visual6502 that can provide a perfect electrical-level emulation to Stella which costs several orders of magnitude less to run but, technically, limits itself in the scope of its emulation (if "to all commercial software ever released and most non-commercial too" can be described as 'limited'). I think that the advances in processing power made available by the twenty years since Stella began have allowed some further movement towards full-system emulation* but that, no, it's not something that enough people care about to be worth pursuing other than for personal interest. This is all just for fun. * particularly: my emulator can run a full pretend CRT rather than attempting directly to map source pixels to destination pixels. It can produce a raw sound output at the 6507's clock rate and then lowpass filter it down to something a sound card can actually output. It can do these things most definitely not because I'm smarter or because anybody desperately wants these things but because it's 2015, not 1996.

For no reason other than fun, I am jumping on the Atari 2600 emulator bandwagon. It looks like you've had only one other this year (kudos, Zarek) so maybe it's a lean period? A couple of screenshots are attached. Issues that jump right out: Enduro shows that I'm probably doing something wrong with vertical sync — those four bright lines at the top are the machine starting to output data again while the vertical sync is still ongoing; ... though it appears as though horizontal sync is largely correct since the double scanned lines only slowly leave the correct horizontal area (and then if you look closely at the top, the emulated CRT gets back into phase with only a very slight roll; does the 2600 continue to output horizontal syncs while vertical sync is enabled, e.g. by pulsing blank appropriately?); both Enduro's score line and the exact position of the invaders in the interlace gif show that I'm probably getting the stuff behind CPU/TIA sync strobe at least slightly wrong. I had a check while I was writing this and have immediately spotted at least one of the problems: I've implemented RDY as though it were like e.g. the z80's HALT, when it should pause read cycles only. This probably isn't the only error there though since the Enduro score is quite a bit too far to the left. The 6502 itself has passed a bunch of test suites; can anybody advise on good test cases for specific video features?

By coincidence I just saw this picture of a Lynx on the Internet today. The control pad on that definitely appears to be more than merely painted — it's bevelled outward rather than inward, appears to be thinner and isn't obviously attached to the circular pad. That said, I'm just speculating from the picture.

I agree — while there's quite a bit of trial and error to games like Shadow of the Beast, Rick Dangerous does take it to quite an extreme. This is something I've actually researched; a hybrid forward/backward rendering engine with arbitrarily angled walls wouldn't be too hard but the lack of arbitrary clipping windows would make elevation changes very difficult to render efficiently. The limited storage available for enemy sprites would also likely limit them to a very low resolution.

I think the SNES can scale and rotate its background but can't do a thing with sprites. So you're in trouble as soon as you want more than one thing to scale distinctly. The Lynx has much more flexible video hardware than the SNES — the 16-color palette limitation is probably its most obvious weakness. Other thoughts: I wish I could compose music.

Coming from the Spectrum portion of the world, that's one of my favourite games! It'd be slightly more awkward on the Lynx because sprites are (usually) compressed — not by a lot but enough to make their size variable. So when doing a sprite swap you'd either have to make sure that each individual replacement image compressed to a size no greater than the corresponding original or dive into the code in order to make adjustments to the source locations for different bits of data. On the NES and most other similar platforms sprite data has a fixed size so you can just copy and paste replacement data and you're guaranteed everything will line up appropriately in memory. Not only is it better than Duke Nukem but Power Factor does a pretty good job of being Duke Nukem already, or at least close enough.

I don't know, ports have the benefit of not requiring any real design; all the graphics, art and level layouts are already done. So they're probably more likely to be completed.

I'd vote Rick Dangerous over Duke Nukem on the grounds that it rarely scrolls, making it more appropriate for the Lynx's screen. And I just plain like it more.

This is an eBay listing for Desert Strike here in the UK that will ship to Australia. Is that sort of thing helpful?

I can't assuage my guilt: I recently bought Double Dragon. On eBay. From Australia. To here in the UK. So I've actually made things a little harder for you. But on the plus side, I can vouch for rare titles turning up on eBay in Australia from time to time.

There are videos on YouTube; it's a rotation-by-ninety-degrees affair, similar to the way Xybots paints the display though more advanced in a bunch of ways, so would probably have emphasised the strategy even more than the Jaguar original.

In the context of games like Pit Fighter, Mortal Kombat, etc, digitised is a lazy synonym for photographic. Why, what did you think the source of Pit Fighters graphics were, if not photographs?

Yes, they're both retitled ports of the multi-platform game, The Humans.

Battlezone 2000, if you look up the cheat that gives you access to the proper version of the game rather than the severely watered-down version that plays normally.

The point I'm making is that bit count is irrelevant to judging the power of a computer or console. It's largely just a question of launch date and price point — bit counts are often a bit arbitrary as per the PC Engine example, and collapsing the question down to the number of data lines running to different components doesn't really achieve much. USB is a serial bus with two data lines. So by the standards of the early-90s gaming press, all your USB peripherals are 2-bit devices. Does that really mean anything? To the extent that we count bits nowadays, we look at the natural data size of the central programmable component and by that standard the 68000 is a 32-bit device. Is it helpful retroactively to label the ST, Amiga and Mega Drive 32 bit? Not really related, but I have the rare distinction of having owned a Sam Coupe, direct from MGT, during its natural lifetime. It's not a very well designed machine in my opinion; they put this huge frame buffer on the thing but with Spectrum-style contended access across all RAM (so RAM is unavailable for 7 of 8 cycles during pixel periods, eating into your processing time) and no hardware graphics help whatsoever — not even a hardware scroll. That's why Lemmings chugs along and almost nothing else even attempts scrolling.

That was deliberate. Car Wars is running on the TI-99/4A, a 16-bit machine!

Oh! Yes! I've 'won' in Cyberball my fair share of times. Never beaten Lemmings though, on any platform. Partly I think it's that I've never been organised to keep passwords for anything, but I doubt I could manage it even if that weren't an obstacle. I bow to you.