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
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.
If a cell fails, you can't read or write that cell.
If a gate fails in a page, you lose access to the page.
If a gate fails in the overall control logic, you lose access to the whole device.
Is there something I'm missing? Did you think there were oil changes or brake shoes? It's one silicon chip with metal on it.
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.
Atom comes in two variants, the 'netbook' and the 'embedded' (can't remember the marketing-speak for them right now)
Given that he is coming from Xscale, I'd bet it's one of the embedded modules using the US15W chipset, which are quite different from the netbook ones.
There are a few patches from moblin required to get the 2.6 kernel fully running on the US15W. AFAIK those patches haven't been backported. I would recommend starting from 2.6.
"Noise Reduction Techniques in Electronic Systems" by Henry Ott.
I've heard "Transistor Circuit Approximations" by Malvino is good. I don't have it, but I liked his style in some other books.
I've also heard the "GE transistor handbook" from days of yore has good stuff in it.
(Searching on that gave a link to an e-bay auction of 8 dvds of scanned old books, which looked like a treasure trove of good stuff. not my auction, no connection to it)
I would second a thumbs up for "Handbook of Digital Black Magic" by Johnson and Graham. Not exactly what you wanted, but a good book.
"Art of Electronics" is an OK book, but very broad, and doesn't seem to fit with your request.
Usually the way BIOS gets done is the mfg. buys a kit from Phoenix or General Software or whomever, and they run a customization program (which super-IO chip, what flash, you want to allow clocking modifiers, a zillion other options) and maybe add a few specific files for their setup and then compile an image.
I'm willing to bet that some firmware engineer was under the gun to crank out a release. He skipped over the section for configuring ACPI for anything but windows and some bogus defaults were left in a config file somewhere. They got compiled into the image.
QA says "what do we have to test?", marketing says "windows xp and vista", and they go ahead and test that by playing solitaire and minesweeper. They ship to make their quarterly number. The customer e-mails, support handles it badly, blogs are posted, and slashdotting ensues.
When Foxconn acts as a contract manufacturer for the likes of Apple or HP, you can bet that their output has to pass test procedures designed by the company selling the goods, so I worry less about the stuff they make for others and more about the company that is selling the goods.
It's clear that their own products' QA is lacking and their front line support people are ill-trained.
The xilinx fpga tools run just fine (perhaps better) from the command line, and have native ports to linux. I believe the same is true for Altera. If you run the xilinx gui tool with the command line log file turned on, it will give you a look at what's required.
IIRC, screen has a pretty detailed man page and has been around a very long time, so should be pretty easy to find examples of setting it up.
For X, usually the real pig is the display server. If you have to run X read up on using the DISPLAY environment variable and just run the X clients on the box and run the server somewhere else - that's what it was made for;-)
I have done several designs with the part, and for the most part it's well thought out and it works really well. Unfortunately it's getting a bit long in the tooth and could do with some upgrading.
(just got this in my mail from the OpenBSD mailing list)
Various developers are busy implimenting workarounds for serious bugs in Intel's Core 2 cpu.
These processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code.
As is typical, BIOS vendors will be very late providing workarounds / fixes for these processors bugs. Some bugs are unfixable and cannot be worked around. Intel only provides detailed fixes to BIOS vendors and large operating system groups. Open Source operating systems are largely left in the cold.
- We bet there are many more errata not yet announced -- every month
this file gets larger.
- Intel understates the impact of these erraata very significantly.
Almost all operating systems will run into these bugs.
- Basically the MMU simply does not operate as specified/implimented
in previous generations of x86 hardware. It is not just buggy, but
Intel has gone further and defined "new ways to handle page tables"
(see page 58).
- Some of these bugs are along the lines of "buffer overflow"; where
a write-protect or non-execute bit for a page table entry is ignored.
Others are floating point instruction non-coherencies, or memory
corruptions -- outside of the range of permitted writing for the
process -- running common instruction sequences.
- All of this is just unbelievable to many of us.
An easier summary document for some people to read:
Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us. Some of these are things that cannot be fixed in running code, and some are things that every operating system will do until about mid-2008, because that is how the MMU has always been managed on all generations of Intel/AMD/whoeverelse hardware. Now Intel is telling people to manage the MMU's TLB flushes in a new and different way. Yet even if we do so, some of the errata listed are unaffected by doing so.
As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are.
For instance, AI90 is exploitable on some operating systems (but not OpenBSD running default binaries).
At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year). Intel must be come more transparent.
(While here, I would like to say that AMD is becoming less helpful day by day towards open source operating systems too, perhaps because their serious errata lists are growing rapidly too).
Hardware alone can do lots of things (albeit hard to change) but software alone can do nothing:-)
Seriously, hardware/software partitioning is key in product design, and it affects everything. I'm curious as to what they are proposing, and how it will affect product cost and development schedules. TFA is completely uninformative.
Dude, schematics are like TOTALLY so 80's. Most chips are designed using Verilog or VHDL (or systemC, superlog, etc) all text based languages.
He said he found some architectural weirdnesses using jtag to debug stuff. No biggie. The thing is between some external packets coming in and exploiting an architectural misfeature is a bunch of OS software, so it seems like there should be plenty of opportunities to squash whatever bugs he's going to come up with.
Slashdot Mirror
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.
If a cell fails, you can't read or write that cell.
If a gate fails in a page, you lose access to the page.
If a gate fails in the overall control logic, you lose access to the whole device.
Is there something I'm missing? Did you think there were oil changes or brake shoes? It's one silicon chip with metal on it.
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...
the OP just said an "Atom" COM express module.
Atom comes in two variants, the 'netbook' and the 'embedded' (can't remember the marketing-speak for them right now)
Given that he is coming from Xscale, I'd bet it's one of the embedded modules using the US15W chipset, which are quite different from the netbook ones.
There are a few patches from moblin required to get the 2.6 kernel fully running on the US15W. AFAIK those patches haven't been backported. I would recommend starting from 2.6.
"Noise Reduction Techniques in Electronic Systems" by Henry Ott.
I've heard "Transistor Circuit Approximations" by Malvino is good. I don't have it, but I liked his style in some other books.
I've also heard the "GE transistor handbook" from days of yore has good stuff in it.
(Searching on that gave a link to an e-bay auction of 8 dvds of scanned old books, which looked like a treasure trove of good stuff. not my auction, no connection to it)
I would second a thumbs up for "Handbook of Digital Black Magic" by Johnson and Graham. Not exactly what you wanted, but a good book.
"Art of Electronics" is an OK book, but very broad, and doesn't seem to fit with your request.
They went out of their way and expended extra effort to prevent Linux from working on their system.
I doubt the issue is active malice from Foxconn (trade name for Hon Hai Precision Industry Co. LTD ).
Usually the way BIOS gets done is the mfg. buys a kit from Phoenix or General Software or whomever, and they run a customization program (which super-IO chip, what flash, you want to allow clocking modifiers, a zillion other options) and maybe add a few specific files for their setup and then compile an image.
I'm willing to bet that some firmware engineer was under the gun to crank out a release. He skipped over the section for configuring ACPI for anything but windows and some bogus defaults were left in a config file somewhere. They got compiled into the image.
QA says "what do we have to test?", marketing says "windows xp and vista", and they go ahead and test that by playing solitaire and minesweeper. They ship to make their quarterly number. The customer e-mails, support handles it badly, blogs are posted, and slashdotting ensues.
When Foxconn acts as a contract manufacturer for the likes of Apple or HP, you can bet that their output has to pass test procedures designed by the company selling the goods, so I worry less about the stuff they make for others and more about the company that is selling the goods.
It's clear that their own products' QA is lacking and their front line support people are ill-trained.
The xilinx fpga tools run just fine (perhaps better) from the command line, and have native ports to linux. I believe the same is true for Altera. If you run the xilinx gui tool with the command line log file turned on, it will give you a look at what's required.
IIRC, screen has a pretty detailed man page and has been around a very long time, so should be pretty easy to find examples of setting it up.
For X, usually the real pig is the display server. If you have to run X read up on using the DISPLAY environment variable and just run the X clients on the box and run the server somewhere else - that's what it was made for ;-)
AMD no longer owns the Alchemy product line, they sold it to Raza Microelectronics. Specs for the chip used (Au1550) are here:
http://www.razamicroelectronics.com/products_alchemy/au1550_overview.htm
I have done several designs with the part, and for the most part it's well thought out and it works really well. Unfortunately it's getting a bit long in the tooth and could do with some upgrading.
http://ecos.sourceware.org/assign.html
has the form that eCos (open source RTOS) has been using to assign copyright. Maybe this will give you some ideas.
http://www.emporis.com/en/wm/bu/?id=35eastwackerdrive-chicago-il-usa
http://www.ci.chi.il.us/Landmarks/numbers/35EWacker.html
(just got this in my mail from the OpenBSD mailing list)
d t/31327914.pdf
d uo_errata__2006_01_21__full.gif
Various developers are busy implimenting workarounds for serious bugs
in Intel's Core 2 cpu.
These processors are buggy as hell, and some of these bugs don't just
cause development/debugging problems, but will *ASSUREDLY* be
exploitable from userland code.
As is typical, BIOS vendors will be very late providing workarounds /
fixes for these processors bugs. Some bugs are unfixable and cannot
be worked around. Intel only provides detailed fixes to BIOS vendors
and large operating system groups. Open Source operating systems are
largely left in the cold.
Full (current) errata from Intel:
http://download.intel.com/design/processor/specup
- We bet there are many more errata not yet announced -- every month
this file gets larger.
- Intel understates the impact of these erraata very significantly.
Almost all operating systems will run into these bugs.
- Basically the MMU simply does not operate as specified/implimented
in previous generations of x86 hardware. It is not just buggy, but
Intel has gone further and defined "new ways to handle page tables"
(see page 58).
- Some of these bugs are along the lines of "buffer overflow"; where
a write-protect or non-execute bit for a page table entry is ignored.
Others are floating point instruction non-coherencies, or memory
corruptions -- outside of the range of permitted writing for the
process -- running common instruction sequences.
- All of this is just unbelievable to many of us.
An easier summary document for some people to read:
http://www.geek.com/images/geeknews/2006Jan/core_
Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare
the hell out of us. Some of these are things that cannot be fixed in
running code, and some are things that every operating system will do
until about mid-2008, because that is how the MMU has always been
managed on all generations of Intel/AMD/whoeverelse hardware. Now
Intel is telling people to manage the MMU's TLB flushes in a new and
different way. Yet even if we do so, some of the errata listed are
unaffected by doing so.
As I said before, hiding in this list are 20-30 bugs that cannot be
worked around by operating systems, and will be potentially
exploitable. I would bet a lot of money that at least 2-3 of them
are.
For instance, AI90 is exploitable on some operating systems (but not
OpenBSD running default binaries).
At this time, I cannot recommend purchase of any machines based on the
Intel Core 2 until these issues are dealt with (which I suspect will
take more than a year). Intel must be come more transparent.
(While here, I would like to say that AMD is becoming less helpful day
by day towards open source operating systems too, perhaps because
their serious errata lists are growing rapidly too).
Obviously written by a software guy...
:-)
Hardware alone can do lots of things (albeit hard to change) but
software alone can do nothing
Seriously, hardware/software partitioning is key in product design,
and it affects everything. I'm curious as to what they are proposing,
and how it will affect product cost and development schedules. TFA is
completely uninformative.
Dude, schematics are like TOTALLY so 80's. Most chips are designed using Verilog or VHDL (or systemC, superlog, etc) all text based languages.
He said he found some architectural weirdnesses using jtag to debug stuff. No biggie. The thing is between some external packets coming in and exploiting an architectural misfeature is a bunch of OS software, so it seems like there should be plenty of opportunities to squash whatever bugs he's going to come up with.