I guess it depends on when the team is able to bring one of their balls onto the field. If they get to pick the ball at the start of a play when they have possession, then the only time they'd be playing with the other team's ball is on an interception.

Or am I missing something here?

There's no shortage of people ragging on the code. "It's not C++ enough to be called C++," "there's not enough comments", "it uses C stdio.h", etc. Get over it.

This looks like the sort of program I might dash out over an afternoon (maybe two) to satisfy some intellectual curiosity. Programming as play. This isn't production code, it's fun code, written to satisfy oneself.

Is it perfect? WHO CARES! That's not important. That misses the point. If you doodle in your notepad and it brings you a smile, does anyone care it's not as good as the Mona Lisa? You sure as heck don't. And that's what this code is. A doodle. It just happens to be in simple, straightforward procedural C/C++ code.

I personally think playing with programming is important. Sure, you'll write a lot of dreck. But, you'll also learn a lot. You learn real lessons when you do write dodgy code, and the dodgy code actually bites you. You also can try new things fearlessly. After all, you're programming a toy for oneself, and you're under no deadline pressure. There's no spec you have to fulfill. You can experiment and enjoy it.

Programming as play still helps build your programming reflexes. If and when you do sit down to write professional grade software, all of that play will make the basic work of programming natural. Rather than focusing your energy on the basic details of programming, you can instead focus your energy designing maintainable code that meets the business requirements and documenting that design. Writing the code just flows naturally.

So, yeah, I'm impressed. This Sudoku solver brought a smile to my face. It's incredibly cool that the prime minister shared a code doodle with us.

If you stick to the intersection of "documented interface" and "clearly optimized code paths," you're likely OK. But yeah, having an optimization guide as part of the docs would be better, if it also stays up to date with the source. But, as we all know, the only thing that stays up to date with the source is the source itself.

The difference is on my corporate-issue Windows 7 box, even though I'm nominally Administrator, there are things I can't disable / shut off that I could if I were root in UNIX / Linux.

Yep. I've disabled both Flash and PDF plugins, both of which are common attack vectors. I also run AdBlock, as compromised ad servers are a very common attack vector. Net result is that I've hit 'cancel' once on a UAC prompt that I didn't think was justified.

The thing is, even after a stint as a UNIX admin at a university—a hostile environment if there ever was one—and even finding a couple Solaris security holes that lead to root escalation, I still managed to eventually, one day, get a UAC prompt that didn't make sense to me, and so I mashed 'cancel'. I don't even remember what it was, but it points to the fact that you always, always need to be on your guard.

I really dislike the lack of control I feel when using a Windows box. All my personal machines at home are Linux boxes, except one WinXP system I use for specific tasks that require Windows. And on those Linux boxes, I do damn near everything as an unprivileged user. I only sudo to install packages that come from a verified source, such as the latest GCC.

UAC pops up very infrequently for me. The few places it does, I expect it to. I would actually be a little squicked if it didn't.

Given the amount of piggy-back and drive-by malware out there for Windows, I actually kinda like it. Sure, I think I've hit 'Cancel' exactly once on a UAC prompt, but I've never had my Windows box infected with a trojan.

And yes, I consider myself a power-user. Hell, I've been running Linux on my personal machine since '93, and have at least two Solaris patches that I can point to for root exploits I've helped uncover. I architected the security system on an entire family of processors.

I came here to say pretty much exactly what you did. The funky addressing saved a chip. It's pretty widely documented / known.

Yes, the video used opposite bus phases from the CPU (and doubled as refresh counter for the DRAMs), so there were no wait states due to video fetch. But as you point out, that has nothing to do with the Apple ]['s weird video memory map.

I've hidden Easter Eggs in all the Intellivision games I've sold, and in at least one program I've written for internal use at work.

I don't get to touch the software my company sells. At least not the software that would lend itself to Easter eggs.

But for my Intellivision game work, I've hidden a rendition of my face, a modified "hot pepper" version of a menu, entire other games, and dedications to family. I don't intend to stop.

The Atari 2600 uses a 6507, which is a 6502 die in a smaller package—fewer address lines pinned out.

The Ricoh chips in the NES use an exact copy of the 6502 die layout, plopped in a larger chip. Go have a look. You can see the 6502 portion in the lower right hand corner. (Here's the original MOS 6502 for reference.)

When I say exact, I mean darn near exact: They differ by 5 transistors, apparently, representing a surgical excision of decimal mode.

So yes, the part number is technically not 6502. But, that's really a technicality. It's the same layout and everything, packaged in an SoC. The relevant part to the programmer is that they can pull up a 6502 opcode chart / timing chart and start crackin' away and it'll work just as they expect, undocumented opcodes and all.

True, but that was a 6502 core with an integrated I/O port. I'm pretty sure it largely reused the NMOS 6502 datapath, given that all the 6510 variants are compatible, including undocumented opcodes. At least, so claims Wikipedia.

If you read up on the architects, they intended for the zero page to be "like registers," to allow the accumulator architecture to be reasonable to program. Look at all the addressing modes (direct, indirect, indirect-indexed, and indexed-indirect) that leverage the zero page quite heavily, and compare those to the various indexed addressing modes on, say, an x86.

The low cost of zero-page access made those addressing modes practical.

Sure, calculation results always landed in A, and you quite often needed to move A to other places, but direct access to the zero page was very, very cheap. To do math without it would have required additional data registers.

Thank you for the detailed discussion. I don't have a lot to add at this point.

I will say that your comment on virtualized DMA engines is very interesting to me, however.