Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment Re:Vector? (Score 2) 184

Vector games did not have very high resolution, and did not draw pure 'analog' vectors. Go take a look at the schematic for Asteroids.... There is a pair of line drawing state machines that steer the X-Y position of the beam at a resolution of 1024. Technically, +- 512 because the DAC output is run through a buffer Amp that takes the output of the DAC and centers it around zero. The input to the DAC is treated as a 10-bit signed integer. There is a bit more magic upstream to generate the clock pulse chains that get sent to the position accumulators. They were just drawing lines. If you want the gory details you can read about them here from one of the engineers that worked at Atari on these games:

Comment Re:Fundamental problem with this project... (Score 1) 172

How is he supposed to KNOW that the bits in the cartridge are correct?

Radiation and high-temperatures still effect ROM memory. Otherwise, why would we need rad-hardened ROM memory on satellites? And what is space? Just a more dangerous version of what we have on Earth--but Earth still has some radiation. Now add DECADES of sitting around absorbing background radiation, with periods of sitting thrown around on top of someone's table under hot sunlight.

There's a reason super-long-term storage is not as simple as burning a CD.

Now, yes, yes, the practical cure of things like boot loaders, ROM hacks, poor early dumps, and all that crap. Sure. I'm clearly NOT debating that. But tiny artifacts in sprites? Single bit changes in code? Maybe not so much...

Bullshit. You have no idea what you are talking about.

Mass manufactured Carts use mask-programmed ROM devices. Such devices are literally hardwired during fabrication with the bit pattern using a metallization layer. EPROMs are only used for Prototypes because compared to Masked-ROMs they are hideously expensive. Masked ROMs don't lose their bits. The only way to get a bit flip there would be from de-capping the device an physically altering the mask. In ROM failures part of the address decode logic or an I/O line are damaged, from over-voltage, or static discharge. That kind of failure would make a Cart completely dead (crash the CPU, or the graphics would be mangled.

Rad-hard ROMs used in high radiation applications have specially designed transistors in the decode logic to prevent reading the wrong word in the array. The array of bits is just a mask of metallization on the die that wires up the 1 or 0 for each bit cell. Those bits will only change if the array is mechanically damaged.

Submission + - Microsoft Anti-Porn Workers Sue Over PTSD (

An anonymous reader writes: When former Microsoft employees complained of the horrific pornography and murder films they had to watch for their jobs, the software giant told them to just take more smoke breaks, a new lawsuit alleges. Members of Microsoft’s Online Safety Team had “God-like” status, former employees Henry Soto and Greg Blauert allege in a lawsuit filed on Dec. 30. They “could literally view any customer’s communications at any time.” Specifically, they were asked to screen Microsoft users’ communications for child pornography and evidence of other crimes. But Big Brother didn’t offer a good health care plan, the Microsoft employees allege. After years of being made to watch the “most twisted” videos on the internet, employees said they suffered severe psychological distress, while the company allegedly refused to provide a specially trained therapist or to pay for therapy. The two former employees and their families are suing for damages from what they describe as permanent psychological injuries, for which they were denied worker’s compensation. “Microsoft applies industry-leading, cutting-edge technology to help detect and classify illegal images of child abuse and exploitation that are shared by users on Microsoft Services,” a Microsoft spokesperson wrote in an email. “Once verified by a specially trained employee, the company removes the image, reports it to the National Center for Missing and Exploited Children, and bans the users who shared the images from our services. We have put in place robust wellness programs to ensure the employees who handle this material have the resources and support they need.” But the former employees allege neglect at Microsoft’s hands.

Comment OMG the stupid around here... it burns... (Score 1) 248

On the 3.5 mm port:
    It is a lot more than just a TRS stereo jack. There are about 4 configurations of contacts and switches in the one Apple used going back to the iPod days. To make that sucker robust enough to work over the life of the phone, it used a lot of internal space, and it also was susceptible to damage from foreign objects getting into it. So future phones might get slimmer without the 3.5mm port. And yes apple wants to sell licensed dongles, and probably has a deal with the **AA asshats to close the analog loophole.

Breakage of the lightning port is much easier to avoid. It was designed so that the connector on the peripheral will shear off, rather than damage the socket. Removing pocket lint and other contamination from the lighting port is much easier than removing it from a 3.5mm port. Adding more conductors to the lightening port is a fairly simple design change. Adding more conductors to a 3.5mm jack is a fucking nightmare. There is a lot of win with the lightening port design.

On the barometer:

If Apple added the barometer in isolation of the other sensors on the device it would be useless. However there are a lot of other sensors on the phone that in concert with a barometer become more useful. It has a 3 axis accelerometer, 3 axis gyro, 3 axis compass, GPS, a mic array, two or three cameras, several temp sensors, and now a barometer. By using all of these sensors together, the phone can tell a huge amount about the environment it is in and correlate that with mapping, and weather data. Adding a barometer made all of the other sensors FAR more useful and makes the entire suite of sensors more reliable and accurate. All of the other sensors make a barometer much easier to calibrate and interpret.

The fanboi/hater circle jerk has grown to so dominate the discussion here that almost no one here has any legitimate geek credibility. Turn in your geek card? GTFO... Most of you never had one.

Comment Whiners: You know what? Fuck you. (Score 1) 54

TL;DR: Shut up about the fucking camera. That is not why Juno is there, and it is the best camera we know how to build for that environment.
Juno is not there to fill your porn cache with superficial visible light dick pics Jupiter.

Juno is orbiting in the second most actively destructive (for a probe) orbital environment in this solar system. The only one worse is the coronal atmosphere of Sol.... and there is nothing we know how to build that would survive there for long enough to justify the attempt. It will be amazing if Juno lasts long enough to finish its primary mission. The hard radiation environment around Jupiter is ripping that probe apart atom by atom and it corrupts the signal quality in every system on Juno at insane levels... Juno is built as a $1.2B gold brick because it has to be.

Why don't you get pretty pictures? Because that is not why Juno is there. It is there to probe Jupiter with RADAR, and measure its gravitational field, and record the EMF environment. If you knew a god-damn thing about image sensors you'd know that trying to get the camera to work at all in an environment that has so much hard radiation in it, is a huge compromise. Imagine trying to use a normal, commercial image sensor in a camera that has a housing made of material that leaks light. It leaks so much fucking light that the exposure has more input from this leakage, than light from the subject that the lens system is focused on! That is what a hard radiation environment does to a camera system that cannot for, mass reasons be properly shielded to keep the noise floor sane.

At first I was a little underwhelmed by the pictures too. But then I saw some info about what that image sensor has to deal with to get any meaningful output. It is a miracle of just enough shielding and some really good signal processing that the images we got back don't look like over-exposed dental x-rays of the of the camera housing. So, yeah, the pictures are going to lack dynamic range and resolution. As others have pointed out the only reason it has a camera is because of you whiney fools. Well you got your insanely expensive camera that can take pictures in the second hardest natural radiation environment in the solar system... Now, you shut up at the kids table and enjoy your mediocre pictures. Maybe some nerd at JPL will figure out how to pull some insane Instagram shit to make them pop later.

Meanwhile, at the adult table, we await the output and learned interpretation, from the more interesting instruments on Juno.

Comment Re:Isn't the aux already analog? Also, levels vs D (Score 1) 385

You got this only partially right. Headphone driver amps, line input amps, line power amps, etc have a fixed gain to output. What that volume knob you turn does is change the input attenuation to the amp.

At max volume you get minimum attenuation. At minimum volume you get maximum input attenuation.

input_voltage x input_attenuation x fixed_amp_gain = output_voltage

So for a power amp we might have a fixed gain of 17.. so 1 volt input multiplied by attenuation of 0.1 is 0.1V to the amp... output is 1.7V.
If attenuation is 0.5: 1V * 0.5 * 17 = 8.5

That is how audio volume controls actually work. Otherwise your explanation of clipping, and other audio signal mismatching is correct.

Comment Re:Why I thought... (Score 1) 359

You make really good points. I'm pleased that you took it seriously enough to address it as an exercise, as I have tried to do. I think your assessment is relevant. And looking at How EVE handles starship combat makes the issues tractable by mapping the capabilities of SW and ST vessels into EVE.

What makes or breaks the case it wether SW is defending SW space or SW is invading ST space. I think you make a good point. IF ST is defending Earth... they lose to SW hands down. Imperial fleet warps in and blockades Sol... done. But if ST is invading, there is more flexibility and SW has a rougher fight. This is all very silly on its face for a lot of reasons, but to explore thought experiments like this might lead to more interesting games in the future.

Neither the Imperium nor Star Fleet appear to have warp/hyper-space disruptors. So Interdiction vessels don't apply to either faction. Ion Cannons appear to be only possible on planetary platforms. From existing story arcs AFAIK there are no examples of a star destroyer mounting an ion canon on the scale that the Battle for Hoth depicted: That is head-shot to a star destroyer. So turbo lasers and limited guided weapons. For ST ships both energy weapons and guided weapons are primary, with guided weapons being more destructive than phasers. For SW energy weapons are primary, and guided weapons are secondary. Not sure if it matters as you point out we have no idea how they scale between the factions.


Comment Re:Why I thought... (Score 1) 359

>>The relative weapon strengths also would tend to favor the fewer but more powerful SF weapons. SDs are fit with large numbers of weapons designed to attack frigate sized ( 300m targets. There is some effect in 'sand blasting' the target, but this really doesn't create a huge threat to SF vessels. They are not going to get stomped by a large weapon from the SDs... so SF has predictable interval to apply damage and get off grid before their shields fail.

Should read:

The relative weapon strengths also would tend to favor the fewer but more powerful SF weapons. SDs are fit with large numbers of weapons designed to attack frigate sized and smaller ( 100m) targets. They have few weapons that are designed to do significant damage to anything bigger than 300m. There is some effect in 'sand blasting' the target, but this really doesn't create a huge threat to SF vessels. They are not going to get stomped by a large weapon from the SDs... so SF has predictable interval to apply damage and get off grid before their shields fail. This allows SF vessels to repeatedly engage and warp off with little threat of getting volleyed off the field... during a fleet scale engagement.

Comment Re:Why I thought... (Score 1) 359

Your comments support what I was trying to get to. But I don't think the outcome is as assured as scale and numbers of ships suggest.
The lack of a comparable jump-drive capability does indeed limit the reach of Star Fleet to a small number of adjacent systems. They clearly cannot engage freely across the SW universe.

However I think the Imperial Navy would have a huge headache trying to subdue Star Fleet, and here's why.

The jump capability of imperial SDs doesn't support changing destinations in mid-jump. ST ships gain a strategic and tactical advantage in controlling their engagements that the Imperial ships don't have. Once an SD fleet is in system it really isn't going anywhere fast. It stays put or it jumps. This is actually a big deal. Controlling engagement ranges and speeds makes up for a lot of asymmetry is scale and numbers. ST ships can quickly enter and exit warp at any time to establish position.. SD fleets cannot apparently do that.

The defensive screens on the SDs are weak and the armor, while tough, is ablative. SF ships use regenerative shields and they are capable of taking quite a bit of damage even from more powerful ships. This is also a big deal. They can disengage easily and restore shields, while the SDs have no choice but to stay put. If they try to jump after the SF ships they are going to miss every time. This gives SF a huge advantage in controlling the terms of engagement.

The relative weapon strengths also would tend to favor the fewer but more powerful SF weapons. SDs are fit with large numbers of weapons designed to attack frigate sized ( 300m targets. There is some effect in 'sand blasting' the target, but this really doesn't create a huge threat to SF vessels. They are not going to get stomped by a large weapon from the SDs... so SF has predictable interval to apply damage and get off grid before their shields fail.

SD tractor beams are only useful once an opponents engines have been damaged. I don't think it will prevent any class of SF vessel from warping off when it needs to assuming that it doesn't get too badly damaged before attempting to disengage.

Imperial fighters and support ships ( 50m) are not going to be a significant threat to any SF class of ship even in large numbers. The SF ships can easily kite them, and SF vessels don't have small unshielded systems that a fighter is going to be able to damage. The threat from fighters to an SD is very real as the fighters can take out enough turret weapons to make the SD toothless. Smaller SF classes can fill this role as basically over-sized fighters.

Canon-wise ST ships don't take significant damage until their shields are compromised, and that takes being hit with something big. Short of suicide frigates, and fighters, SDs don't have any weapons that are a direct threat to SF vessels. SD screens seem to be used to minimize damage, but are not themselves damaged. To compare it with something in EvE.... SD screens are more like armor hardeners than shields.

Jedi/Sith are only useful in limited contexts that can be countered by comparable talent in the ST universe. I consider this to be a push. No advange to either side.

TL;DR Imperial Navy vs Star Fleet would be a guerrilla war that Star Fleet would likely lose, and would be hideously expensive for the Imperial Navy to win.

Comment Re:Why I thought... (Score 1) 359

Voyager is a cruiser. Defiant is a light cruiser. Enterprise (NCC-1701) was also a light cruiser. Enterprise NX-1 would be closer to a destroyer, or frigate. Enterprise NCC-1701-A was more like a heavy cruiser. 1701- B - D Are definitely battle ships, but not the largest ships in the fleet. The largest ships regularly depicted were in the 150m to 450m beam length. Engagement doctrines parallel earth navies pre-WW II. Relatively small numbers of vessels with heavy weapons intended to engage similarly fit opponents or fortified stations/planetary installations. Typical example: A few Klingon destroyers are enough to trump any of the Enterprise instances, if they gain initiative.

Star Wars ships especially the Imperial navy are comparatively much larger. The smallest 'star destroyer' class ships started at 450m and go up in size from there. They are all carriers, with multi-role support for every imaginable type of engagement. Engagement doctrines parallel post-WW II earth navies.

Where things get confusing is trying to map SW and ST into the same engagement. The Imperial navy has a wide range of tactical capabilities. But they do not have transporter tech, and their defensive screens seem to only be useful against large weapon types. So we can kind of classify Star Destroyers as being largely armor and practically speaking they are buffer tanked. Comparatively, ST ships are active shield tanked.

For the engagement classifications I'll draw on EvE Online, since it does a good job of depicting a large variety of engagement types. ST is shield tanked sub Caps (mostly cruisers and battle cruisers) with energy weapons and guided weapons(rockets to torpedoes) . SW is armor buffer tanked battle ships and carrier class capital ships with lots of fighters/drones with a mix of turret types, but very little use of guided weapons. Occasionally Imperial Navy has a shield buffer tanked super cap available for planet crushing duty.

I think The Federation and their Allies would have a tough time keeping their fleet numbers large enough to engage an Imperial Fleet successfully. But they could easily nab solo Star Destroyers or small battle groups. Star Fleet would be better off using their transporter tech to infiltrate star destroyers, crippling the capital ships from the inside, rather than engaging then directly.

ST would

Comment Re:How about... (Score 1) 99

If you want to play on a private server, go ahead. There's plenty of them.

But if you want to play on a full Blizzard server, then you need a whole datacenter tracking MANY players, that's multiple machines, not just one, all interconnected. That's the world of warcraft- millions of players who can communicate instantly, and interact in game instantly. The reason everyone is connecting to these datacenters is because they provide a service you can't repeat locally. It's not about upload bandwidth, it is about latency, and a distributed network is inherently terrible at that. It is very much about processing power, and RAM, and these are serious machines all hooked together doing that to support that many players.

Just think about designing it for a second- if I move my character from X to Y, on the live system my client tells the wow server what I did, which validates it (so I'm not teleport hacking), updates its internal state, figures out which players are close to me, and then sends data needed to draw my character to them. This means that your client doesn't need to know the whole of the world, it just needs the section you can see, etc.

Now try this distributed. Every distributed node needs a constant copy of the world, and all must be in sync. You need a way to figure out how to resolve disputes, and if some of the nodes are compromised you need to find a way to figure that out. You have the same problems that bitcoin does, but you need to do it instantly and simultaneously. It's laughable.

WoW is divided into shards. Each shard might have a few thousand client subscriptions of which only a few hundred are online at any time. Most MMOs operate this way. What this means is that millions of WoW players do not interact in the same world, and they cannot even chat between the different shards. In fact the only place all WoW players can interact together is on the Community Forum.

If you want a real MMO experience where all* the players are in the same persistent, real time, game instance (single Shard), you'd have to be playing EvE Online. ~300,000 subscriptions and at any given moment between 15000 and 35000 are logged in.

*There is one caveat: China has it's own EvE Online instance that does not interact with the rest of the EvE Universe, because China.

Comment Don't Turn It On; Take It Apart... (Score 1) 515

Started at about 7 disassembling dead TVs, radios, clocks, calculators (electromechanical), and typewriters. By 12 I'd learned how to wire up 74xxx TTL devices and build some basic circuits. About that time a neighbor/mentor friend of mine bought an Apple II+ to experiment with an early CNC package. He didn't get far with it, but he would let me dink around on the computer. At first I was just into thew gaming aspects, BBSs lead to exposure to the thriving software cracking and swapping communities. A few lucky finds got me interested in 'serious' programming APPLESOFT BASIC wasn't cutting it, and it wasn't long before I had a copy of LISA (Lazer's Interactive Symbolic Assembler) an early 6502 macro assembler IDE. It had a decent disassembler. After that I was off to the races, learning how to write 6502 assembly code from articles, disassembling chunks of commercial games and so on. By 15 I got my first exposure to a mandatory class in computer programming. The class was going to be teaching Business BASIC... on the department mini. When I finished the first month's homework while sitting in class by the end of the first week, the instructor had the good sense to pull me and a few other more advanced students into a separate work group that swapped lessons in programming assembly language for our respective platforms of choice.

By my junior year a few friends and I would get together for hacking sessions. This led to a simply dizzying explosion of projects, reverse engineering, hardware experiments, software development, and also dumpster diving the lucrative back alleys of the business parks in the south Bay Area.

By the end of my senior year I'd picked up a contract at Apple developing software to test Software... At first on the Apple ][ line and firmware testing on the Apple //gs and later Macintosh, and culminating with a test engineering spot on the HyperCard development team.

Along the way I'd picked up 68k assembly, C, etc, but it took a long time before I had any decent skill in software design. Eventually I ended up working for Microsoft in the early to mid 90's... That experience killed my enthusiasm for the software industry. I went back to my roots... bare metal... and electronics.

Comment Fixed LTE... (Score 1) 74 what Rock Island Communications ( calls it. It comes in two flavors 2100MHz (B12) and 700MHz (B4). With T-Mobile's help they are deploying it throughout the San Juan County, WA. area. The Cell sectors operate at up to 30 watts, and the CPE operates at about 0.2 watts. Throughput is much better than any DSL service available. It fits perfectly into Rock Island's fiber deployment strategy because they gain a foothold in a community using LTE and then later expand fiber coverage in the area to reclaim LTE spectrum. This provides improved communications for EMS, Fire, Sheriff, County and other public services that rely on radio communications in the region for dispatch. It also weans the residents off the incumbent RBOC, and mobile carriers that won't upgrades their core networks, and can't even be bothered to maintain their 911 services to Federal standards. Added bonus: visitors to the region who have T-mobile phones that support B12 and B4 find that they get coverage almost everywhere in the county. A year ago, no mobile provider had passable coverage out side of the population centers in the county.

Disclaimer: I'm an employee of Rock Island Communications. My opinions do not necessarily reflect those of my employer.

Slashdot Top Deals

"The only way for a reporter to look at a politician is down." -- H.L. Mencken