My previous post, about Cocktail #1, clearly documents the “easy one.”   This second one is gonna be another story.  It has a very dead monitor, and a non-functional board.  I have not yet benched the monitor, but it has no neck glow, which is never a good sign.

The board has problems, but at least I know it is not the CPU as I already swapped it, and I know that it is not a power problem on the second Cocktail, because the board has the same behavior in Cocktail #1.

Swapped all socketed chips to no effect — they all work on the other board.  Power points seemed right on the board, but I put it into my working cabinet to verify… and while doing so I managed to cross GND with a +5v trace and smoked R30 quite nicely on my AR-II board.

I have replaced it, but am still getting voltages that are too high.  Gonna have to hunt other likley suspects…

As far as the board goes, I am gonna have to break out the Fluke 9010 to work on this one…  Right after building an adapter for it so I cam power it up on the bench.

The monitor I should know more about once I have it on the bench and take a good look at it while I am capping it (and doing the sync upgrade).

So I have started playing around with the Guide, signed-in user preferences and information, and the UI features in XNA.  Gotta say, I am impressed so far…

I am currently punting and using the text input feature to get a player’s high score name, defaulting it to the configurd player’s name.  When the game is done, I want to provide a custom-drawn GUI that allows the user to use the gamepad to select and enter letters, just like an old-school game does. 

I am thinking of showing a visual keyboard and allowing the user to select characters from there.  I believe it will be quicker than just using up/down to change the character at the cursor’s position.  Uses either approach allows me to control the characters used, but I think the former will be more fun and a better learning experience.

So I find myself in the middle of a posting frenzy regarding a story on The Daily WTF: http://thedailywtf.com/Comments/A-Problem-at-the-Personal-Level–More.aspx.

The point of my posts was that by withholding the assumptions made by the interviewer with his “one right answer”-kind of question, you put the interviewee in a bad position. (The link above explains the scenario.) IME, in the absence of specific details, one is likely to draw upon their experience to formulate a solution.

So when I read that according to the interviewer, the one right answer was to use a move operation to relocate the complete data file to where the watcher was looking for it. Of course, my first question was if the move was atomic or not. Far too many posters claimed that it always(!) was, other more intelligent ones indicated that it should be.

So my first post there was asking about different filesystems. For example, the average Linux filesystem can support many different filesystem types: ext2, ext3, ffs, UFS, RiserFS, FAT32, NTFS, etc., and can have filesystem locations on different partitions, drives, and even network locations… So what if the source and destination locations are not on the same device/partition? Are the moves still atomic? My experience with both Linux and Win32 filesystem driver code tells me no, so that is what I posted, indicating that the assumption that everything is on one filesystem/partition must be known.

This post started to draw out lots of interesting people… One started talking about how the POSIX specification states that renames (and moves?) must be atomic, but did not know enough to realize that some systems may play fast-and-loose with the specification (Hello, Windows!). Another started talking about how the rename(…) syscall (the syscall!) is atomic. Well duh – most C-style functions are… it may return to the caller only after the rename (or move) is complete, but that does not mean that the behind-the-scenes action is atomic to an outside (filesystem) observer.

It amazes me how so many people just do not “get it.” Maybe I am not just a good communicator…

Or maybe these people really should stay away from a keyboard as much as possible… :)

© 2010 James R. Twine's Blog Site Suffusion WordPress theme by Sayontan Sinha