I used to design hardware for slot machines some years ago. It's my understanding that what you describe is illegal in all the jurisdictions I know of (adjusting the payouts to meet a certain ratio as the game goes on). The odds for each individual play are fixed which sets the payout ratio by averaging over time.

The heart of the game is a big random number generator. There are many more possible outcomes than can be represented by the numbers/symbols on the reels. There is a mapping between the random numbers and what the payouts are, this sets the odds. After the next random number is determined, the machine decides what it wants to show on the reels. Usually it likes to show some kind of near miss to keep up player interest. There are other algorithm adjustments you can make to make a machine make frequent small payouts, or occasional big payouts.

When I was working on stuff, there was a place called GLI (Gaming Labs Inc I think) where you submitted your games for testing. Usually the state gaming commissions would accept GLI testing as proof (or at least partial proof) that your machine was okay. Sort of a underwriters labs for gaming.

I really doubt the casino is trying to rip them off. This is horrible publicity for them. They are usually very happy to pay if the claim is legit - they know it just adds to the draw, and they'll get the money back from you :-)

Well, if you want to get real pedantic, he messed up completely. Real RS-232 has DTE and DCE. In DTE (data terminal equipment) circuit BA (transmitted data) is an output. In DCE (data communication equipment), circuit BA is an input. Vice versa for circuit BB (received data). Straight from my copy of EIA RS-232-C from 1969 :-)

The flow control comment is well taken, and certainly fertile ground for screwups.

Yet another display technology being touted. Like FED's, OLEDs, microdisplays, DLP, etc. All are ok technology, but have been massively overhyped and take way longer than their proponents say to reach mass market. Evolution rules the display market, and I don't see LCD being dethroned any time soon.

The reason to do this is the markup on mil-spec parts. I am working with a TI DSP, it costs around $8 for the commercial version, around $30 for the "Enhanced Plastic" version that goes from -55 to +125, and about $300 for the full spec part in a ceramic package. The availability is often low on mil-spec stuff, so that also plays into it - people will pay a premium to not wait 20 weeks for a production order to come through.

It must be really cheap to remark things. I've run across counterfeit MOSFETS - the original part was only $0.50, but were in short supply. Purchasing bought some through a 'broker' (pretty much scumbags as far as I can tell).

We kept blowing them up, and finally sent some off for failure analysis. The xray showed the replacement part was totally different and only had one bond wire in places where the real part had 3.

A bit old, but a book called "How You Really Get Hired" has a great section about how to handle the 'do you have any questions' part of the interview(s). The basic idea is to use the time to show them you're interested, that you've done your homework about the company, and how to use the time as an opportunity to sell yourself or address perceived weaknesses.

Sounds like an argument against VHDL to me... Verilog PLI (programming language interface) was for years one of the things that made verilog better than VHDL. (And it's not just C, there are PLI bindings for scripting languages, too). Not to mention using a simulator like ModelSim you can write Tcl code to interact with the simulation without resorting to tricks like this.

I assume the intent is to teach about how to get your logic into an FPGA, what the internal structures look like, how synthesis maps from language into implementation, etc.

Any good designer has a mental model of what logic is going to get synthesized by a particular snippet of code, I find verilog gets in the way of expressing that model a lot less than VHDL, so I would say verilog is a better choice, in that you can get to the subject you want to teach much faster. Way less time explaining all the VHDL verbosity just to get to a working example.

I'd guess there's at least a few billion dollars difference between a reasonably up-to-date fab and the people/infrastructure it requires, and what is required to cast and CNC chunks of metal (unless it's something like sub propellers). If Apple was throwing around that kind of cash it wouldn't be a secret.

Flash memory requires additional processing steps in wafer fabrication and is usually run on a special process optimized for making floating gate transistors. Controller chips are usually run on a logic process. Mixing the two styles usually results in a bunch of compromises.

Making the NAND flash generic also gives economies of scale to the memory mfg. The memory on a USB stick is just like that on a SD card, a CF card, and inside an mp3 player. Many of them seem to work on the "we'll make the losses up in volume sales" model

google 'tin whiskers' and 'RoHS solder failures'

There's no redundancy or self healing in the hardware of a common USB flash stick. The illusion that there is comes from a flash controller chip that does a mapping between disk sectors and flash sectors and shuffles things in and out so you don't notice the failures until it can't compensate for them anymore.

Conceptually at least, there are several parts to worry about:

1 - the OS & storage driver
2 - the USB driver
3 - the flash controller
4 - the flash memory

At the flash memory cell level the usual failures are breakdown of the dielectric materials and trapping charges in the memory cell that prevent an erase from happening and yield 'stuck' cells. This is normal for /all/ flash chips and is why they all have an erase cycle rating. There are certainly more exceptional ways for the chips to fail (soldering, wire bond failure, static damage, etc).

The flash controller is supposed to be doing wear leveling, error detection and correction on the flash, to get around those problems with the flash chips, and also talking USB. These chips usually have a microcontroller in them somewhere, and there's probably bugs in that code, no doubt more in the parts that get exercised the least, like error paths :-)

The OS and drivers just have the garden variety bugs and features that we all know and love...

Looking at what they're doing, it doesn't look like these are really new parts, just requalified for an extended temp. range and put in a package that is more robust and less expensive to use.

It failed because of bad soldering? Methinks our lab techs must be moonlighting again...