Slashdot Mirror

The only epileptics I've ever known have a GENETIC disorder, inherited and suffered from birth. There is no way to "treat the underlying problem" as you suggest.

The same is true of migraines.

However, it turns out the reason no one has ever suffered bi-polar in my family is because in my case, it was caused by a 3-month stint of bad drug interactions that no one knew about when I was prescribed the deadly combination of SSRIs and Triptans that led to Seratonin Syndrome damage to my brain, resulting in a PERMANENT bi-polar condition.

The way I see it, I'm a literal victim of the drug war, caught in the cross-fire. I'd never have used the pharmacorp meds that caused my bi-polar if I'd known cannabis was a safer, more effective, and more reliable medication than any Triptan ever was.

I've been poisoned: How the Cannabis war made me bi-polar

And yes, I'm serious. I was literally poisoned. There may not have been any malicious intent, but I'll suffer the consequences for the rest of my life.

The cancelled study I keep mentioning was supposed to be done over 10 years ago in Canada, and was cancelled by Harper's then-minority government. The government has long since deleted the information from the Canadian government web servers, but I was able to find a copy of the relevant information in a Yahoo cache. I've copied it to my personal webserver in case someone decides to clear the Yahoo cache.

Health Canada - CIHR Medical Marijuana Research Program

If you block the research, the doctors and medical associations can keep crying that there's no research. Catch-22.

The TS-1000 is basically a Sinclair ZX81 with extra RAM (the ZX81 had 1k). It has a Z80 CPU (actually an NEC clone, because that was cheaper).

The Z80 is much nicer to program than the 6502. It has more registers and register pairs for doing 16-bit arithmetic. The two index registers (IX and IY) are 16-bit and so is the stack pointer (SP). The 8-bit accumulator, A, is sometimes paired with F, the flags register. The other register pairs are BC (a 16-bit loop counter), DE, a 16-bit source address register, and HL, the 16-bit accumulator. They can be used for general storage too.

The Z80 has separate IO and data buses, so IO devices don't have to take up space in the memory map.

There are block move and compare instructions (LDIR, CPIR, LDDR, CPDR), bit shifts and rotations, a vectored interrupt mode in addition to the simpler ones...and an alternate register set that can be switched in and out quickly for low-latency interrupt handling (EX AF, AF' and EXX).

The Z80 is binary backwards-compatible with the intel 8080.

The extra registers, 16-bit arithmetic and wide index registers are luxury compared to the 6502. I really can't understand by the 6502 is so revered on slashdot...

I wrote a story once where this was done (here. I kind of got tired of so many SF stories and movies solving traumatic injury with some sort of magical "healing tank" (maybe with effortless "nanobots") that I wondered to myself what sort of effort would really be needed to put someone together from just a bunch of pieces.

The closest similar stories I found were the beginning of "Neon", by Harlan Ellison in 1973, and an early chapter of "Count Zero" by William Gibson.

If you really care about CPU design and history, read Great Microprocessors of the Past and Present.

Chips that ran FORTH and Java, intel RISC chips from the 1980s, the M88k, Transputer, Alpha, you name it, it's there.

I was reading the Great Microprocessors list and it says AMD already did that back in the K5 days. It had a mode where it can natively execute the RISC-like instructions. Nobody used it, so I don't know whether current gen AMD chips support it.

article

Well, for a start:

http://www.sasktelwebsite.net/jbayko/cpu3.html

Read the whole thing, it's interesting. But this is the most relevant chapter.

Granted, IBM had a large hand in the big mis-steps of the early PC era; but Microsoft's offering of DOS did in fact set back the general state of the PC for a decade, if not more.

Consider the fact that many other OSes were concurrently available that had multi-user/multi-tasking capabilities; real processes with fine-grained priority schedulers; unified I/O models; and proper division between the kernel, device drivers and userspace processes. I'm not going to do your research for you. Google for Desqview, OS-9, FLEX, etc. These were all available around the time of the PC's inception AFAIK and were far superior in design and capabilities to DOS.

These are not concepts that originated with Windows 95. So yes, Microsoft (with IBM) did a hell of a lot to set back the general state of computing. I suppose one could blame the public as well for accepting something they perceived as 'good enough', when it really wasn't good enough at all (why do people accept that PCs just crash naturally?) but that isn't really fair, as most people didn't have degrees in computing (and still don't).

I admire the charity work being done, but I think this is still 'blood money' that really wasn't worth what society has paid in terms of general progress.

Don't be concerned. I may have changed my signature, but the PFHT is still available:
http://sask.sasktelwebsite.net/petfoilhat.html

I've not yet tested the foil hat on sharks, but it is good underwater, so I see no reason it can't work on large fish.

I have no less than 32 processes running on my workstation. I doubt that 90% of systems have less. I know that our small database server often has 50 client threads running at any one time.
A Spark T1 is a very useful system for many tasks. Does it go head to head with the Itanium? Well if you try to us an Itanium for typical server tasks like SQL or web I would bet that T1 will beat it soundly. If you are using it for running a simulation or rendering? Itanium would probably beat the T1.
The Power and Ultrasparc really seems to handle both kind of tasks very well. I would love to see how a Power5 does vs an Itanium for FPU and how it does vs a T1 for SQL.

What everyone is glossing over is the real problem with the Itanium. Compiler technolgy did deliver the speed that the Itanium promised.
Just like Intel's last disaster the 80860 http://www.sasktelwebsite.net/jbayko/cpu5.html#Sec 5Part3. The 80860 was supposed to be very fast and was on carefuly hand opmized code. The performace using standard compiled code was only so so. The Itanium was pretty much in the same boat. It was fast for very specific tasks but in general it was slow, hot, and expensive.
As a rule it looks like general purpose CPUs that require very special compilers don't work out well.
I find it interesting that with the exception of the x86 and the 8051 Intel has had one disaster after the other. Even the 8080 line was eclipsed by the Z-80 much as the X86 is being beat by the AMD64 line.
If you take a look at the list of the "next big things" from Intel that have flopped it is pretty long.
The 432, Rambus, 80860, and the Itanium and yes the Itanium is currently a failure. Has it made money? Is it growing in market share? I think not.

...late '80s/very early '90s there was something called the ACE Consortium.

This was formed by the likes of DEC, Compaq and SCO at the time when IBM had not long brought out the dreadfully underpowered, expensive and proprietary PS/2 line of personal computers running the pathetic MS-DOS and mediocre OS/2.

Most people were running PeeCees which were essentially 16-bit with a single user, single tasking operating system running on dreadfully slow CISC (8086, 80286, 80386) processors will pitifully small amounts of RAM (512k-1MB) and nary a GUI.

The ACE consortium was designing a MIPS-based (32-bit RISC) open specification for a replacement to the IBM-PC and PS/2 architectured which would run a UNIX SYSVR4 derivative and a nice GUI (was it with X?).

The project died a death. I can't remember why.

When I was 15 I longed for a RISC UNIX workstation in the house instead of the 12MHz Compaq SLT/286 we had (for business use).

MIPS lived on in post-VAX pre-Alpha workstations at DEC and then at SGI. itanic Kool Aid all but killed off MIPS. The only two major RISC architectures from the era which survive are SPARC and POWER/PowerPC, and for a couple of years it looked like SPARC was dead too.

The spirit of Alpha lives on in Athlon and Opteron.

"We are targeting the official release of Firefox for Intel Mac OS X in late March with the Firefox 1.5.0.2 update," Mozilla software engineer Josh Aas told ZDNet Australia.

One thing I enjoy about Free Software organizations, but especially Mozilla, is that they give plenty of information about their release goals and we can trust them. After all, we can just download the nightly files and make our own, or check on the progress.

It would be interesting to see a comparision of target dates set by companies, and see how well the initial target date was met. Microsoft vs. Apple vs. Mozilla vs. Opera for instance.
--
Stop Sparky's brain from being probed by Bush

They might do something crazy and start making their own:
http://sask.sasktelwebsite.net/wordporn.html

And after all the money I spent on these? Sigh...

Apart from some hard-wired devices (simple sound clip recorders) or downclocked low-end devices, I don't see how defective chips can be used.

The 486 DX->SX example has been making rounds on this article a lot lately. A better example is a multicore chip: produce a bunch of four-core versions, then kill a two cores when one's got a flaw and sell it as the 2-core version on the cheap. Remember, everyone's going multicore this week.

Another example from multiple points in the dark nether-reaches of history are chip designs which implement "extra features" at the very edges of an IC grid, because in old fab processes those grids' edge sizes varied slightly. Extra testing and verification circuitry was a frequent choice; there is an apocryphal story that there was a chip which actually implemented CFAD which ISTR seeing a reference to, but for the life of me can't find. At any rate, the extra edge circuitry tactic shows up half a dozen times here.

I suspect that modern-day audio and video datastreams are becoming more fragile as they carry more metadata, highly compressed data, DRM, software, etc.

That's why streams are seperated, and have been since the MPEG-1 era. (Remember mpeg layer 3 = mp3? ever wonder why those things were layered? See also AVI = audio video interleave - it's not playing one stream, it's playing three at once. That's where those synch problems in networks with bandwidth blips come from.)

Something tells me that the manufacturers that use semi-defective chips are going to lose all their savings on product returns, warranty costs, and technical support.

Much to the chagrin of TFA, the practice is actually old-hat. This has been going on for thirty years already. This is why crappy stereos and crappy answering machines sound like crap. There's nothing to see here; move along.

Given the low cost of most consumer electronics chips and the high cost of service labor, I doubt they will want the hassles of unreliable products.

So what you're saying is, you've never bought Realistic?

intel tried wierd, complicated and over-engineered architectures in the past that also died a death.

Unfortunately, one of their very best processors, the i860, never gained wide acceptance either and was condemned to niche markets.

If only the Motorola 68000 had been ready on time, IBM would not have chosen the 8086 for the PeeCee and the world would be a better place.

The itanic is based on ideas that were popular amongst supercomputer designers in the late 1970s. However, when RISC CPUs came along, and transistor budgets increased, things like superscalar processors, out-of-order execution, register renaming, branch prediction etc. were all developed as time went on. These all address issues that are very hard, or impossiblem for a compiler to deal with. intel bloody-mindedly ignored this (who can guess why) and persevered with this 1970's folly, which was only every really applicable to a very small market niche anyway.

Look what's happened.

itanic has all but sunk and intel has been forced to implement AMD's 64-bit extensions to the 386 architecture. The instruction set wars are over. All moder CPUs are some sort of highly-superscalar RISC internally, some with instruction set translators to implement crufty old instruction sets (i.e. 386) and some with translators that can be reprogrammed like Transmeta's offerings.

intel tried wierd, complicated and over-engineered architectures in the past that also died a death.

Unfortunately, one of their very best processors, the i860, never gained wide acceptance either and was condemned to niche markets.

If only the Motorola 68000 had been ready on time, IBM would not have chosen the 8086 for the PeeCee and the world would be a better place.

The itanic is based on ideas that were popular amongst supercomputer designers in the late 1970s. However, when RISC CPUs came along, and transistor budgets increased, things like superscalar processors, out-of-order execution, register renaming, branch prediction etc. were all developed as time went on. These all address issues that are very hard, or impossiblem for a compiler to deal with. intel bloody-mindedly ignored this (who can guess why) and persevered with this 1970's folly, which was only every really applicable to a very small market niche anyway.

Look what's happened.

itanic has all but sunk and intel has been forced to implement AMD's 64-bit extensions to the 386 architecture. The instruction set wars are over. All moder CPUs are some sort of highly-superscalar RISC internally, some with instruction set translators to implement crufty old instruction sets (i.e. 386) and some with translators that can be reprogrammed like Transmeta's offerings.

intel tried wierd, complicated and over-engineered architectures in the past that also died a death.

Unfortunately, one of their very best processors, the i860, never gained wide acceptance either and was condemned to niche markets.

If only the Motorola 68000 had been ready on time, IBM would not have chosen the 8086 for the PeeCee and the world would be a better place.

The itanic is based on ideas that were popular amongst supercomputer designers in the late 1970s. However, when RISC CPUs came along, and transistor budgets increased, things like superscalar processors, out-of-order execution, register renaming, branch prediction etc. were all developed as time went on. These all address issues that are very hard, or impossiblem for a compiler to deal with. intel bloody-mindedly ignored this (who can guess why) and persevered with this 1970's folly, which was only every really applicable to a very small market niche anyway.

Look what's happened.

itanic has all but sunk and intel has been forced to implement AMD's 64-bit extensions to the 386 architecture. The instruction set wars are over. All moder CPUs are some sort of highly-superscalar RISC internally, some with instruction set translators to implement crufty old instruction sets (i.e. 386) and some with translators that can be reprogrammed like Transmeta's offerings.

intel tried wierd, complicated and over-engineered architectures in the past that also died a death.

Unfortunately, one of their very best processors, the i860, never gained wide acceptance either and was condemned to niche markets.

If only the Motorola 68000 had been ready on time, IBM would not have chosen the 8086 for the PeeCee and the world would be a better place.

The itanic is based on ideas that were popular amongst supercomputer designers in the late 1970s. However, when RISC CPUs came along, and transistor budgets increased, things like superscalar processors, out-of-order execution, register renaming, branch prediction etc. were all developed as time went on. These all address issues that are very hard, or impossiblem for a compiler to deal with. intel bloody-mindedly ignored this (who can guess why) and persevered with this 1970's folly, which was only every really applicable to a very small market niche anyway.

Look what's happened.

itanic has all but sunk and intel has been forced to implement AMD's 64-bit extensions to the 386 architecture. The instruction set wars are over. All moder CPUs are some sort of highly-superscalar RISC internally, some with instruction set translators to implement crufty old instruction sets (i.e. 386) and some with translators that can be reprogrammed like Transmeta's offerings.

intel tried wierd, complicated and over-engineered architectures in the past that also died a death.

Unfortunately, one of their very best processors, the i860, never gained wide acceptance either and was condemned to niche markets.

If only the Motorola 68000 had been ready on time, IBM would not have chosen the 8086 for the PeeCee and the world would be a better place.

The itanic is based on ideas that were popular amongst supercomputer designers in the late 1970s. However, when RISC CPUs came along, and transistor budgets increased, things like superscalar processors, out-of-order execution, register renaming, branch prediction etc. were all developed as time went on. These all address issues that are very hard, or impossiblem for a compiler to deal with. intel bloody-mindedly ignored this (who can guess why) and persevered with this 1970's folly, which was only every really applicable to a very small market niche anyway.

Look what's happened.

itanic has all but sunk and intel has been forced to implement AMD's 64-bit extensions to the 386 architecture. The instruction set wars are over. All moder CPUs are some sort of highly-superscalar RISC internally, some with instruction set translators to implement crufty old instruction sets (i.e. 386) and some with translators that can be reprogrammed like Transmeta's offerings.

As has already been posted you can find an updated version here.

Yes, it looks lie someone too the Great Microprocessors page and stripped out everything interesting and then added random factually-challenged commentary to pad it out.

Like this:

Where is the 68000 now?
As the 68000 was reaching the end of its life, Motorola entered into the Apple-IBM-Motorola "AIM" alliance which would eventually produce the first PowerPC® chips. Motorola ceased production of the 68000 in 2000.

The 68000 as a chip is no longer in production, but there are dozens of 68000-family processers available, and Motorola sells them by the boatload.

Motorola 68010 (and friends)
Motorola had already introduced the MC 68000, which had a 32-bit architecture internally, but a 16-bit pinout externally. It introduced its pure 32-bit microprocessors, the MC 68010, 68012, and 68020 by 1985 or thereabouts

The 68010 and the rare 68012 had 16-bit data buses just like the 68000. The 68020 was a complete redesign, with a 32-bit bus and new instructions and addressing modes.

Read the Great Microprocessors page. This article is bumf.

That article has a great deal of IBM bias, as one might expect. Great Microprocessors of the Past and Present is a much more detailed, comprehensive and informative look at microprocessor history. It deals with some very strange and innovative designs that the IBM article doesn't mention.