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.
SpaceX happens to have another barge for the Vandenberg launches. It still is a big deal in terms of landing in a desert, as you have the option of either trying to fly laterally to Mexico (with some international arms control problems with ITAR) or overfly Los Angeles and/or San Diego with that rocket.
Vandenberg happens to be located at a point where California sort of turns off to the east, and is used for polar orbits explicitly because there is a whole lot of nothing except for ocean between Santa Barbara County and Antarctica. Try to look at a map sometime and answer this question: Which city is further west: Los Angeles or Reno?
There is a landing pad being constructed both at KSC (in Florida) as well as at Vandenberg. Right now both NASA and more significantly the USAF (for Vandenberg especially) are waiting to see the results of landing on the barge first before formal approval for landing at the pads is going to be authorized.
It should be pointed out too that SpaceX does have a landing pad with several dozen square miles of desert to work in at Spaceport America in New Mexico. There was some construction work going on there at least in the recent past, and so far as I know the tests to be conducted there haven't been canceled although most of the current effort seems to be work on the revenue flights like this CRS-6 flight rather than the proposed test flights in New Mexico that were to be suborbital flights mainly going up really high and then coming back to the Earth with possibly a flight over White Sands (which is adjacent to Spaceport America and is both restricted airspace and ground access due to it being a military base). Flight clearance at that location is such that they can go much higher there than they can at their Texas test facility.
As long the launches are at KSC or Vandenberg, however, the recovery at the moment will simply need to be at sea. Physics also plays a part as other than returning to the original launch site, down range from either launch site is simply ocean as far as you can go in the general flight path.
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.
Visual BASIC used to be a pretty decent programming environment, and definitely didn't need a single GOTO command. There are other variants, although some of the later versions of Visual BASIC (to name one variant) have far too much influence from C++ developers in my opinion and has basically ruined a perfectly fine language.
Other than compiling the language to P-code or some other interpreted middle-language (something that is definitely not unique to the language either), I fail to see what real drawbacks those with complaints about BASIC have. It certainly can be used as the primary development language for any modern application on any current computer platform including desktop computers or tablets and is simply a choice in a programmer's toolbox as well as based on the whim of the project manager for whoever is developing the application.
The largest advantage of Scratch is the immediate results and the mixture of multimedia content that can be done with literally just a single click of a button. It can be extended to further complexity just one or two mouse clicks at a time.
For this, I completely disagree that Python is a viable replacement or even worse something that should be done instead of Scratch. Don't get me wrong, Python is a fine computer programming language and perhaps as a 2nd language to teach a kid it might be very useful. It is just lousy as an introductory environment for somebody in grade school or junior high school to learn the basic concepts of computer programming.
The other fun thing about Scratch that beats Python hands down is that Scratch is also multi-threaded with parallel processes happening as a major feature of the language. Kids doing stuff in Scratch don't even realize they are doing that kind of stuff until it is pointed out that some program/project they are making has nearly a dozen threads and even more event handlers being used. I don't see Python being nearly so easy to introduce such concepts.
But of course, every single employee who was hired at Google when the standard interviewing technique was to ask pointless brain-teasers is still one of the "world's best and brightest," no doubt? Smartest, brightest, most talented workforce in America? Changing the world, one day at a time?
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.