Which is a problem with the OS. When you use a higher DPI, it only seems to scale some objects while others remain the same size.
The solution would be to map bitmap objects onto a texture and then scale it in proportion to the desktop scale factor. Vector objects are then rendered to scale and merged in. Applications should actually be DPI agnostic since it is the job of the desktop rendering engine to scale.
Obviously scaling bitmap objects upward isn't ideal, but there are plenty of ways to compensate for the quality issues. Just look at all of the scaling choices you get when using old emulator programs.
I always considered the 65816 to be a weird beast. It was a hybrid between a 16-bit and 24-bit memory architecture. It used bank paging to move a 64KB window around for most ops and a few 24-bit long operations tossed in for fun.
I never understood why Mensch or some other second source just didn't go with a flat 24-bit memory architecture. For a college project, I developed a 65C02 derived processor that was just that. All 16-bit address modes were converted to 24-bit, branches could use either 8-bit or 16-bit displacements, stack and direct page could be relocated to any bank aligned (256 byte) offsets and a few extra JMP and JSR modes were added to support jump tables. The emulator wasn't too hard, but the dual pass assembler (for assessing branch displacements) was a PITA.
The downside was that extra byte needed for memory addresses added some bloat, but the ability to relocate zero page helped offset it somewhat since you could now use ZP (now called direct page) everywhere.
Just imagine a C64, C128 or CBM-II with a flat 16MB memory bus and no more congestion in ZP.
If you ever look at a MOS 65xx op-code map, you'll see that a good deal of codes are unused. Supposedly the original MOS 65xx team wanted to come back at a later time and develop a revised core that would be more friendly for non-embedded solutions. Commodore management balked at the idea and several members of the core 65xx eventually left. They saw in Commodore management the same short-sighted thinking that drove them from Motorola. The result was that the processor core used in the original 6501 remained relatively unchanged throughout all of Commodore's NMOS and CMOS variants, bugs and all.
Development of the 65xx series came from sources outside of Commodore. Bill Mensch, a former member of the MOS 65xx team, founded his own semiconductor company (Western Design Center), releasing upgraded cores such as the 65C02 and 65816. Undocumented ops went from weird behavior to NOPs, more ops were added for transferring values between registers, registers and memory locales could be zeroed out, the zero page and stack page could be relocated to offsets other than $0000 and $0100, the zero page index roll bug was fixed, flags had a predictable state after a RTI, etc...
It wasn't until the CSG 65CE02 and derived CSG 4510 processors that Commodore finally gained modern 65xx processors.
I sometimes wonder how nice the C64 would have been to program with a 65C02 or 65CE02.
I've heard that part of the problem with the C64- and the reason Tramiel was forced to leave C= - was that Tramiel was *so* aggressive with the price and driving competitors out of the market
"Computers for the masses, not the classes" -- Jack Tramiel
There is a fine line between being thrifty and penny-wise and being cheap. Tramiel was cheap. He had this paranoia that the Japanese and Texas Instruments were going to swoop in and crush him as they had done in the calculator market. The result was a series of short-sighted business decisions.
Take the VIC-20 as an example. It was profitable, but the decision to use the 22-column MOS 6560/6561 video chip and 5KB of SRAM made it quickly obsolete. But Tramiel had a warehouse filled with spare SRAM chips. And there are various stories about how he had the core for the 6560/6561 kicking around since '77 and didn't want it to go to waste.
Imagine instead if they had used a modified 40-column MOS 6562/6563 (but with DRAM refresh) and 16KB of DRAM. That would have been a very nice entry machine. And rather than the Commodore 16/116/232/264/Plus4 soup, releasing something like the 232 but with backwards compatibility with the old VIC. Chances are, sales of the "VIC-16" wouldn't have dropped as sharply in sales when the C64 was released and the "VIC-32" would have been much more successful than the Commodore 16/116/232/264/Plus4 series.
First, that's why I used the qualifier "somewhat" in my sentence.
The Apple III was actually a fairly good attempt by Apple in releasing a successor to the Apple II series. It included a number of software and hardware advancements and included backwards compatibility with Apple II software. But the bean counters intentionally crippled some aspects of the backwards compatibility (no support for bank switching in A// emulation mode). Meanwhile, Steve Jobs and his Asperger-like weirdness botched the hardware design, making it expensive and prone to heat failure. While it may have been a commercial failure, many design innovations from the Apple III made their way into later Apple models (such as the IIe and IIgs) and Apple operating systems (such as ProDOS and GS/OS). So the Apple III really lived on as later Apple II enhancements.
The Apple Lisa was simply too much hardware for a desktop machine for its time. A 68000 processor and 1MB of memory in early 1983 were incredibly expensive. At the same time, it was too slow and too unrefined to compete with workstations such as the Sun 100 desktop. I dunno what Apple gained from it, other than to ensure that the Macintosh was priced correctly for its target market. So yes, it was an utter failure. But Apple had the Macintosh in their back pocket.
Since you bring up the Lisa, it is only fair to bring up the Commodore CBM 900. It was a workstation powered by a Zilog Z8000 and ran a UNIX V7 clone. It was a very odd beast. Had Commodore not canceled it in favor of the newly acquired Amiga, it could have made huge waves in the low-end workstation segment. Or it could have been a disastrous, expensive mess. It just happens that Commodore was more prone to cancel projects than Apple, so we'll never know.
There are a number of reasons why Commodore is now a side note in history.
First, Commodore really only had two major hits: the Commodore 64 and the Commodore Amiga 500. The Commodore VIC20 and Commodore Amiga 1200 sold well, but not to the degree needed to be remembered by the mainstream media. The rest of their product line-up, while sometimes revolutionary for the time, often had even less commercial success. In short, Commodore was either hot or not with their end-user products.
The second issue was fragmentation. While Apple had a somewhat smooth transition from the Apple II through the II+, IIc, IIe and IIgs, Commodore's 8-bit era was a frenzied smorgasbord of products: the PET series, SuperPET, VIC20, MAX Machine, C64, CBM-II, C16/Plus4 and C128. Little to no unifying naming scheme, cross-platform binary compatibility, or cross-platform source code compatibility. Commodore got better with the Amiga and Tramiel got better with the Atari ST, but in the history books, the damage to Commodore's early days was done.
The third issue is that discrete component supplies often get little notoriety. Commodore's MOS Technologies subsidiary may have been revolutionary at the time, but was too early in the game to get the sort of notoriety that Intel, AMD, 3Dfx, IBM, SiS, Nvidia and ATI received in the modern desktop world. Branding played a part, too. It was a number of years before they renamed the subsidiary to Commodore Semiconductor Group and even longer until they stopped stamping MOS on their chips. It may have been necessary to keep companies such as Apple, Atari, Sinclair Research and the like happy since it was a more neutral name, but it fragmented the Commodore brand.
The fourth issue is that the Commodore name essentially died when they went bankrupt. Atari is still an active game publisher, even after purchase from Infogrames. So is Sega Corporation. Apple, IBM and Nintendo are still active hardware manufacturers. The Compaq name has only recently been phased out by HP. History is written by the winners and people tend to have short memories.
The last issue is very open to debate, but part of it may be because of embarrassment. Amiga users were zealots. People joked about the fanboi culture that existed within the Amiga community. "I can format a floppy disk while playing Marble Madness!". Even today, when I point out that I used to own Amigas in my younger days, it will occasionally be met with a chuckle by whoever I'm talking to. In short, nobody wants to talk about you when they think you're a joke.
I'd think they could leapfrog 32-bit, and go directly from 16-bit to 64 bit... the old 16-bit Amiga DOS.
The Motorola 68000 was actually a 32-bit processor internally. Data registers were all 32-bits in width and the ALU performed math operations at that size. Address registers, including the stack pointer and program counter, were also 32-bits in width.
The only part of the 68000 that was 16-bits in width was its external data bus. It could perform 32-bit reads and writes, but had to do so using two fetches, one low and one high. The 68020 was the first processor of the family to have a full 32-bit wide external data bus.
it's interesting to think about what it would be like if it had sold well enough to become a viable alternative.
There is a good chance that it would look nothing like the OS we used on legacy Amiga hardware.
The reason the OS was so bloody fast was because it used a flat non-protected memory space. IPC was often done by passing pointers via registers. You could eavesdrop into any other task's memory space, even if its memory was not flagged with MEMF_PUBLIC. The majority of the kernel ran outside of 68K supervisor mode with function calls being made via a jump table as opposed to a software interrupt.
One of the largest complaints about desktop multitasking operating systems of the 80s and 90s was that they crashed too much. That was a huge complaint with Windows 95 and was also a common complaint with AmigaOS. To continue being a viable OS, AmigaOS would have needed memory protection bolted on at some point.
Using a fully virtualized protected memory model like UNIX and NT would have been incompatible with the foundation of AmigaOS since it would break IPC. You'd need stick with a flat address space, simply marking some memory sections as R/O. Program code sections could be R/O for everything except the kernel (that'd prohibit self-modifying code, but SMC was already incompatible with the data cache in 68020+ processors). Tasks could then allocate private memory, public memory or even semi-private memory by granting limited R/O or R/W access to other tasks.
Main problem I see with that route is that you'd bump into the 4GB barrier much faster than fully virtualized memory models, especially since a large chunk of that 4GB would also be allocated to memory mapped hardware and other PCI peripherals. You'd need a processor with a 48-bit or 64-bit memory address space sooner than later.
I agree with you. I've done blind tests between 48kHz and 96kHz and I cannot hear a difference. I used to hear a difference between 44.5kHz and 48kHz when I was younger, but it is getting harder as I age. Personally, I cannot see why 192kHz samples would be released outside of the studio.
I can hear the difference between 16-bit and 20-bit, but not so much between 20-bit and 24-bit. At that point, the noise floor for the media has gone below that of other components, so you really can't tell.
Having used AMD processors since the Am586, I have generally had good luck with motherboards made for AMD processors. However, I stuck with major brands that had a reputation for quality at the time of the purchase. I also avoided entry level motherboards, using mid-grade boards for friends/family and entry-enthusiast boards for myself. Lastly, I stuck with popular chipsets.
Some friends ended up with problem AMD boards, but they bought the cheapest thing they could find from fly-by-night companies. Every AMD board I've ever used from Mach Speed has been crash prone, for example.
My last AMD motherboard for my personal system (before switching to a Core i7) was a Gigabyte board with an AMD 790X chipset. Even with my Phenom-X2 overclocked from 3.1 to 3.6, I never experienced a single BSoD or freeze under Windows XP x86-64 edition. I also have a bunch of MSI boards with AMD 785G chips in them around the house for the wife and media PC running Windows 7 x86-64 edition. Never seen a BSoD or freeze with either of them either.
Come to think of it, the last time I had a rash of BSoDs with an AMD system was in the really old days (NT4, W2K) when ATI released really crappy video drivers for their cards. Once I ditched the ATI cards for Nvidia, the problems went away. And I've never experienced a crash under Windows with their recent stuff.
Just a few systems I had for myself with little or no issues: K6/500 in a ALI MVP3 based Gigabyte board Athlon Thoroughbred in a VIA KT133A based Abit board Athlon Barton in a Nv nForce2 based Abit board Athlon Orleans in a Nv nForce4 based MSI board Athlon Windsor in an AMD 785G based MSI board and Nv 730a based EVGA board Phenom Kuma in an AMD 790X based Gigabyte board
The decision to have a GPU division was completely logical. The decision to purchase ATI was the questionable part.
There is a trend in the laptop and desktop markets to move towards complete SoC designs. The quantity of support chips and number of duties that they perform are dwindling. Have you noticed in the past decade how features traditionally handled by a northbridge chip are now being handled by the CPU?
The GPU is no different. With each new generation, the GPU is turning more and more into a general purpose FP processor. Eventually, it just makes sense to consolidate the FP power of the GPU with the FP power of the CPU to lower costs.
The larger question is, did AMD attempt this merging of environments too early? Should they have simply started with moving the GPU under the same hood as the CPU as Cyrix did with their MediaGX series of processors? From the sound of the article, it sounds like they did jump the gun.
Then comes the AMD aspect. They could have licensed GPU cores until they finalized their strategy. Instead, they overpaid for a company that they became shackled to. They gambled and appear to have lost. It will most likely be their downfall.
Farmers and ranchers in remote areas have been using portable VHF radios for communications for a number of decades now. Last I checked, such radios were still available and offered superior reception and battery life when compared to UHF cellular phones.
Furthermore, the dead zones in the western US states and Canadian provinces aren't solely the fault of private telecommunications companies. The last I checked, neither government has allocated a range in the lower UHF or upper VHF bands for cellular communication. Everything is in the middle to upper UHF band (the lowest we go is 700MHz). Recall that for any given power level, range decreases as frequency increases.
This is in contrast to Nordic and eastern Europe, much of Latin America, Africa and Asia that has a range around 450MHz for GSM and CDMA cellular communication. In the US, that range is reserved for GMRS and FRS. If the federal government reallocated that range for mobile cellular communication, the costs to cover lightly populated areas would go down sharply. The free market would hotly fight for those bands as it would make rural coverage cheaper to deploy.
Yeah, but that takes a human artist to manipulate the image. Imagine taking a face, entering a set of modifications, and then having the software do it for you.
I'm waiting for inexpensive applications for home PCs where you can easily change your appearance, sort of like digital plastic surgery. Want to see what you'd look like with a nose job? How about as the other sex? I would assume something like that would be a heck of a lot more complex than mapping somebody face onto somebody else's head.
Regardless of the method of transmission, television is dying, and the culprit is dumb content. People have more entertainment choices than ever before and television just can't keep up.
One major problem is that television content is dumbed down. Advertisers know that their commercials have less effect on intelligent people who are better at critical analysis, so they instead target kids, teens, seniors and the unwashed masses. Broadcast networks need content that will pull in those demographics. Make your content too complex and nuanced and you'll lose your targeted demographics. The result is a partnership between networks and advertisers that aim for the lowest common denominator sitting in front of the screen.
For a few decades, we had niche programming channels that offered something that wasn't stupid, but those channels have mostly been bought out by networks that have discovered that the LCD model is more profitable. Now those stations are content deserts, filled with little else besides reality shows about midgets, vagina clown cars, crabs and motorcycles. PBS is still around, but their programming is a niche within a niche. So we get this downward spiral where smart people are turned off by television, content gets dumber, more mainstream people are turned off by television, content gets dumber, and the IQ bar keeps falling.
The other major problem is that the way we receive content is dumb. Intelligent people have been buying gadgets for years that give us on-demand access to information. As the price has come down and those systems became more mainstream, everyday people got used to it as well. But television content mostly comes from unintelligent sources. On-demand IPTV might change that, but the content owners are fighting it. It is why streaming sites like Hulu and Netflix, as well as cable TV on-demand systems are hodge-podge patchworks of content.
I can't count the number of times that I have been frustrated because of the distribution methods of media. Netflix will have a series available for streaming, but then you hit one episode that is available only via disc rental. Hello, Bittorrent. Hulu will have content for streaming, but then you missed the cutoff for how long a new episode remains up. Hello, Bittorrent. I'll want to record two shows to my DVR that play the same time/night, but I only have one tuner card in my PVR. Know where I'm going by now?
The last problem is more of an issue limited to North America, but our OTA DTV system just doesn't play well with small, portable devices. We have too many channels that broadcast on VHF bands that require large antenna. The ATSC standard doesn't work well in areas bombarded with multipath interference or with moving devices (although it has gotten much better). Granted, the VSB standard was picked because it is more efficient over large areas, but it would be nice if any ATSC extensions would add OFDM as well. Large cities could have a low power UHF OFDM SFN (single frequency network) mesh for mobile handsets and apartment dwellers, while suburban and rural areas would still receive the main transmitter on the VHF-Hi VSB bands with their roof mounted aerials. Too bad that DTV for the VHF-Lo bands sucks and that the military occupies the area right above channel 13 on the VHF-Hi band.
BD movies would fill a tb drive in 20-40 movies. That's bad, but not crippling.
You can easily double that capacity by recoding both the video and audio streams at lower bitrates.
For my own Blu-ray archival, I convert all of the Dolby TrueHD and DTS-HD audio tracks to AAC 5.1-channel 640kbps or 2-channel 224kbps using eac3to. Next, I convert all of the H.262, H.264 and VC1 video tracks to H.264 using a constant quality value of "16" and the "slower" encoder preset using x264. Lastly, I convert the graphical PGS subtitles to text SRT using SupRip. For a two hour 1080p movie, I average around 11GB.
There are a few dark grainy movies where I had to use a higher CRF value of 14 or 15, but the resulting file is still smaller than the original M2TS file.
Maybe in six or seven years when 6TB and 8TB drives are the norm and I've upgrade my 42" 1080p plasma, I'll go back and grab the original streams. Until then, I'm fine watching the recodes.
The video from a good quality DE-15 VGA cable of reasonable length is nearly indistinguishable from that of a lossless digital connection such as DVI when using sane resolutions. It is mainly when you are utilizing substandard cables, unusually long lengths or very high resolutions (the kind that workstation GPUs push out) that the cable becomes an impairment. KVMs are also major signal killers.
Digital panels also introduce benefits and drawbacks regarding analog inputs. Many flat panels operate with 60Hz refresh rates, so the bandwidth required to transmit the signal is lower than in the days of CRTs when you often had refresh rates in excess of 85Hz. That means that you can get away with a cheaper cable for the same resolutions. On the other hand, you're now reliant on the quality of the A/D converter in the flat panel monitor. You're also reliant on the quality of the monitor calibration software. I find that many monitors suck on the second task unless you use anything other than a background of alternating black and white pixels (like the default X background).
As for the article itself, they are correct in claiming that it is outright BS. I have to go all the back to my old S3 Trio64 discrete video card before I find something that can't drive my flat panel at its native 1680Ã--1050 resolution at 32bpp. Every discrete video card and integrated onboard chipset I've had in the past decade can do it. Heck, both the Geforce FX5500 and Radeon 8500 AGP cards I have for my old K6/500 system drive my HD plasma in its native 1080p.
Do they drive them well? Picture quality wise, they're no different than the latest Nv or AMD card around. However, they do tend to chug a bit. The Radeon 8500 is especially bad under Windows 7 since I'm using hacked Vista drivers since it isn't a DX9 card, which is a requirement for Win7 (I'm sure the K6 doesn't help). But that isn't what the picture at Dell's site is showing.
Android-based smartphones from Verizon also use Bing as the default search provider. So it appears that Google will allow carriers to customize that aspect of the phone.
The main questions are: did Verizon have to put up a fight with Google over the change, or did Google not really care? Is there much interest from the carriers in changing the default search engine? Are any other carriers even making this change (like Chinese carriers using Baidu as opposed to western search engines)?
Hotmail could go one step further. As opposed to just checking against a blacklist of common passwords, they could use a whitelist of acceptable password types. Must be 8 or more characters in length, must be mixed case and must contain one or more digits. Then you run that against the blacklist to weed out people picking "Passw0rd" or "t1nkerB3ll".
While I still own a Commodore 128 and an Amiga 3000, I find that I rarely boot up the original systems anymore.
It is a heck of a lot easier to simply use emulators. If you're trying to revisit an old arcade game, it is often better to get the game for MAME since ports to home computers were often subpar. If you're trying to revisit games specifically for the home, it is better to get whatever system was considered the best at the time. For the earlier years, that'd be an Amiga emulator like WinUAE. For anything post 1990, that'd be a PC emulator like DOSBox. C64 and Atari 8-bit emulators tie for stuff that is ancient.
I generally agree with your statement, but there are a few variables that can make it false. If you don't operate the computer for long periods of time or if your utility rates are low or nil, then the long-term power savings may not be worth it, especially if the legacy hardware was incredibly inexpensive or free.
Then you have the minority of people who like their computer to be a space heater. Any reduction in radiated heat from their PC will be countered by a ceramic space heater. A story a few years back noted how natural gas use in Canada was up because so many people switched to CFL and the central heating systems had to compensate.
You see this a bit more in the mainframe and server world. Releases see very long support cycles, often exceeding a decade. However, updates are usually limited to break/fix and security patches as opposed to feature enhancements. Much of that comes from the conservative nature of those environments. The premium pricing of product and support contracts reflects that environment.
For desktop and workstation markets, a decade is a long time. Microsoft is well within its rights to reallocate those resources from the XP team for other projects. Sure, many applications still work under Windows XP. But the same argument could be made about Windows 2K. Heck, the majority of my productivity applications run under NT4SP6 with a few tweaks. Doesn't mean that I should still be running NT4.
Having said that, I do have a double standard about being able to use old stuff. While I believe that people should be upgrading their software, I do believe that people should be able to keep their older hardware (within reason). Keeping that stuff out of landfills is a good thing, and many people with limited budgets are more than happy to have it.
I wish that Microsoft would have released a consumer version of its Windows 7 Thin Client Edition. Windows 7 Home Edition will work with something as old as a Pentium-II/266 or K6/266 (you need an ACPI compliant motherboard, a DirectX 9 video card and enough memory), but it chugs a bit (I wouldn't recommend anything less than 500MHz). Having a version where the compiler is tuned for older procs and smaller memory footprints, while having non-essential programs and services disabled would help. I assume they don't do it because people that cheap would refuse to pay for an OS, and I assume Microsoft wouldn't discount their OS enough for them to bite.
An Android Java applet should be able to run on any processor that Android has been ported to, may it be ARM, x86-64 or any other proc series.
Having said that, Java does allows you to load an external library via the System.loadLibrary() method, which could be a native binary. There are several examples on the web of how to use this for Android applets.
I could see situations where you wanted to use native Advanced Vector Extension (AVX) ops in a program for an embedded x86-64 processor because those ops were either not supported or poorly supported by the native Java bytecode interpreter. You lose portability in exchange for performance or other efficiencies.
Slashdot Mirror
Which is a problem with the OS. When you use a higher DPI, it only seems to scale some objects while others remain the same size.
The solution would be to map bitmap objects onto a texture and then scale it in proportion to the desktop scale factor. Vector objects are then rendered to scale and merged in. Applications should actually be DPI agnostic since it is the job of the desktop rendering engine to scale.
Obviously scaling bitmap objects upward isn't ideal, but there are plenty of ways to compensate for the quality issues. Just look at all of the scaling choices you get when using old emulator programs.
I always considered the 65816 to be a weird beast. It was a hybrid between a 16-bit and 24-bit memory architecture. It used bank paging to move a 64KB window around for most ops and a few 24-bit long operations tossed in for fun.
I never understood why Mensch or some other second source just didn't go with a flat 24-bit memory architecture. For a college project, I developed a 65C02 derived processor that was just that. All 16-bit address modes were converted to 24-bit, branches could use either 8-bit or 16-bit displacements, stack and direct page could be relocated to any bank aligned (256 byte) offsets and a few extra JMP and JSR modes were added to support jump tables. The emulator wasn't too hard, but the dual pass assembler (for assessing branch displacements) was a PITA.
The downside was that extra byte needed for memory addresses added some bloat, but the ability to relocate zero page helped offset it somewhat since you could now use ZP (now called direct page) everywhere.
Just imagine a C64, C128 or CBM-II with a flat 16MB memory bus and no more congestion in ZP.
Umm, the 6502 *did* wither because of Tamiel.
If you ever look at a MOS 65xx op-code map, you'll see that a good deal of codes are unused. Supposedly the original MOS 65xx team wanted to come back at a later time and develop a revised core that would be more friendly for non-embedded solutions. Commodore management balked at the idea and several members of the core 65xx eventually left. They saw in Commodore management the same short-sighted thinking that drove them from Motorola. The result was that the processor core used in the original 6501 remained relatively unchanged throughout all of Commodore's NMOS and CMOS variants, bugs and all.
Development of the 65xx series came from sources outside of Commodore. Bill Mensch, a former member of the MOS 65xx team, founded his own semiconductor company (Western Design Center), releasing upgraded cores such as the 65C02 and 65816. Undocumented ops went from weird behavior to NOPs, more ops were added for transferring values between registers, registers and memory locales could be zeroed out, the zero page and stack page could be relocated to offsets other than $0000 and $0100, the zero page index roll bug was fixed, flags had a predictable state after a RTI, etc...
It wasn't until the CSG 65CE02 and derived CSG 4510 processors that Commodore finally gained modern 65xx processors.
I sometimes wonder how nice the C64 would have been to program with a 65C02 or 65CE02.
I've heard that part of the problem with the C64- and the reason Tramiel was forced to leave C= - was that Tramiel was *so* aggressive with the price and driving competitors out of the market
"Computers for the masses, not the classes" -- Jack Tramiel
There is a fine line between being thrifty and penny-wise and being cheap. Tramiel was cheap. He had this paranoia that the Japanese and Texas Instruments were going to swoop in and crush him as they had done in the calculator market. The result was a series of short-sighted business decisions.
Take the VIC-20 as an example. It was profitable, but the decision to use the 22-column MOS 6560/6561 video chip and 5KB of SRAM made it quickly obsolete. But Tramiel had a warehouse filled with spare SRAM chips. And there are various stories about how he had the core for the 6560/6561 kicking around since '77 and didn't want it to go to waste.
Imagine instead if they had used a modified 40-column MOS 6562/6563 (but with DRAM refresh) and 16KB of DRAM. That would have been a very nice entry machine. And rather than the Commodore 16/116/232/264/Plus4 soup, releasing something like the 232 but with backwards compatibility with the old VIC. Chances are, sales of the "VIC-16" wouldn't have dropped as sharply in sales when the C64 was released and the "VIC-32" would have been much more successful than the Commodore 16/116/232/264/Plus4 series.
First, that's why I used the qualifier "somewhat" in my sentence.
The Apple III was actually a fairly good attempt by Apple in releasing a successor to the Apple II series. It included a number of software and hardware advancements and included backwards compatibility with Apple II software. But the bean counters intentionally crippled some aspects of the backwards compatibility (no support for bank switching in A// emulation mode). Meanwhile, Steve Jobs and his Asperger-like weirdness botched the hardware design, making it expensive and prone to heat failure. While it may have been a commercial failure, many design innovations from the Apple III made their way into later Apple models (such as the IIe and IIgs) and Apple operating systems (such as ProDOS and GS/OS). So the Apple III really lived on as later Apple II enhancements.
The Apple Lisa was simply too much hardware for a desktop machine for its time. A 68000 processor and 1MB of memory in early 1983 were incredibly expensive. At the same time, it was too slow and too unrefined to compete with workstations such as the Sun 100 desktop. I dunno what Apple gained from it, other than to ensure that the Macintosh was priced correctly for its target market. So yes, it was an utter failure. But Apple had the Macintosh in their back pocket.
Since you bring up the Lisa, it is only fair to bring up the Commodore CBM 900. It was a workstation powered by a Zilog Z8000 and ran a UNIX V7 clone. It was a very odd beast. Had Commodore not canceled it in favor of the newly acquired Amiga, it could have made huge waves in the low-end workstation segment. Or it could have been a disastrous, expensive mess. It just happens that Commodore was more prone to cancel projects than Apple, so we'll never know.
There are a number of reasons why Commodore is now a side note in history.
First, Commodore really only had two major hits: the Commodore 64 and the Commodore Amiga 500. The Commodore VIC20 and Commodore Amiga 1200 sold well, but not to the degree needed to be remembered by the mainstream media. The rest of their product line-up, while sometimes revolutionary for the time, often had even less commercial success. In short, Commodore was either hot or not with their end-user products.
The second issue was fragmentation. While Apple had a somewhat smooth transition from the Apple II through the II+, IIc, IIe and IIgs, Commodore's 8-bit era was a frenzied smorgasbord of products: the PET series, SuperPET, VIC20, MAX Machine, C64, CBM-II, C16/Plus4 and C128. Little to no unifying naming scheme, cross-platform binary compatibility, or cross-platform source code compatibility. Commodore got better with the Amiga and Tramiel got better with the Atari ST, but in the history books, the damage to Commodore's early days was done.
The third issue is that discrete component supplies often get little notoriety. Commodore's MOS Technologies subsidiary may have been revolutionary at the time, but was too early in the game to get the sort of notoriety that Intel, AMD, 3Dfx, IBM, SiS, Nvidia and ATI received in the modern desktop world. Branding played a part, too. It was a number of years before they renamed the subsidiary to Commodore Semiconductor Group and even longer until they stopped stamping MOS on their chips. It may have been necessary to keep companies such as Apple, Atari, Sinclair Research and the like happy since it was a more neutral name, but it fragmented the Commodore brand.
The fourth issue is that the Commodore name essentially died when they went bankrupt. Atari is still an active game publisher, even after purchase from Infogrames. So is Sega Corporation. Apple, IBM and Nintendo are still active hardware manufacturers. The Compaq name has only recently been phased out by HP. History is written by the winners and people tend to have short memories.
The last issue is very open to debate, but part of it may be because of embarrassment. Amiga users were zealots. People joked about the fanboi culture that existed within the Amiga community. "I can format a floppy disk while playing Marble Madness!". Even today, when I point out that I used to own Amigas in my younger days, it will occasionally be met with a chuckle by whoever I'm talking to. In short, nobody wants to talk about you when they think you're a joke.
I'd think they could leapfrog 32-bit, and go directly from 16-bit to 64 bit ... the old 16-bit Amiga DOS.
The Motorola 68000 was actually a 32-bit processor internally. Data registers were all 32-bits in width and the ALU performed math operations at that size. Address registers, including the stack pointer and program counter, were also 32-bits in width.
The only part of the 68000 that was 16-bits in width was its external data bus. It could perform 32-bit reads and writes, but had to do so using two fetches, one low and one high. The 68020 was the first processor of the family to have a full 32-bit wide external data bus.
it's interesting to think about what it would be like if it had sold well enough to become a viable alternative.
There is a good chance that it would look nothing like the OS we used on legacy Amiga hardware.
The reason the OS was so bloody fast was because it used a flat non-protected memory space. IPC was often done by passing pointers via registers. You could eavesdrop into any other task's memory space, even if its memory was not flagged with MEMF_PUBLIC. The majority of the kernel ran outside of 68K supervisor mode with function calls being made via a jump table as opposed to a software interrupt.
One of the largest complaints about desktop multitasking operating systems of the 80s and 90s was that they crashed too much. That was a huge complaint with Windows 95 and was also a common complaint with AmigaOS. To continue being a viable OS, AmigaOS would have needed memory protection bolted on at some point.
Using a fully virtualized protected memory model like UNIX and NT would have been incompatible with the foundation of AmigaOS since it would break IPC. You'd need stick with a flat address space, simply marking some memory sections as R/O. Program code sections could be R/O for everything except the kernel (that'd prohibit self-modifying code, but SMC was already incompatible with the data cache in 68020+ processors). Tasks could then allocate private memory, public memory or even semi-private memory by granting limited R/O or R/W access to other tasks.
Main problem I see with that route is that you'd bump into the 4GB barrier much faster than fully virtualized memory models, especially since a large chunk of that 4GB would also be allocated to memory mapped hardware and other PCI peripherals. You'd need a processor with a 48-bit or 64-bit memory address space sooner than later.
I agree with you. I've done blind tests between 48kHz and 96kHz and I cannot hear a difference. I used to hear a difference between 44.5kHz and 48kHz when I was younger, but it is getting harder as I age. Personally, I cannot see why 192kHz samples would be released outside of the studio.
I can hear the difference between 16-bit and 20-bit, but not so much between 20-bit and 24-bit. At that point, the noise floor for the media has gone below that of other components, so you really can't tell.
I somewhat disagree.
Having used AMD processors since the Am586, I have generally had good luck with motherboards made for AMD processors. However, I stuck with major brands that had a reputation for quality at the time of the purchase. I also avoided entry level motherboards, using mid-grade boards for friends/family and entry-enthusiast boards for myself. Lastly, I stuck with popular chipsets.
Some friends ended up with problem AMD boards, but they bought the cheapest thing they could find from fly-by-night companies. Every AMD board I've ever used from Mach Speed has been crash prone, for example.
My last AMD motherboard for my personal system (before switching to a Core i7) was a Gigabyte board with an AMD 790X chipset. Even with my Phenom-X2 overclocked from 3.1 to 3.6, I never experienced a single BSoD or freeze under Windows XP x86-64 edition. I also have a bunch of MSI boards with AMD 785G chips in them around the house for the wife and media PC running Windows 7 x86-64 edition. Never seen a BSoD or freeze with either of them either.
Come to think of it, the last time I had a rash of BSoDs with an AMD system was in the really old days (NT4, W2K) when ATI released really crappy video drivers for their cards. Once I ditched the ATI cards for Nvidia, the problems went away. And I've never experienced a crash under Windows with their recent stuff.
Just a few systems I had for myself with little or no issues:
K6/500 in a ALI MVP3 based Gigabyte board
Athlon Thoroughbred in a VIA KT133A based Abit board
Athlon Barton in a Nv nForce2 based Abit board
Athlon Orleans in a Nv nForce4 based MSI board
Athlon Windsor in an AMD 785G based MSI board and Nv 730a based EVGA board
Phenom Kuma in an AMD 790X based Gigabyte board
The decision to have a GPU division was completely logical. The decision to purchase ATI was the questionable part.
There is a trend in the laptop and desktop markets to move towards complete SoC designs. The quantity of support chips and number of duties that they perform are dwindling. Have you noticed in the past decade how features traditionally handled by a northbridge chip are now being handled by the CPU?
The GPU is no different. With each new generation, the GPU is turning more and more into a general purpose FP processor. Eventually, it just makes sense to consolidate the FP power of the GPU with the FP power of the CPU to lower costs.
The larger question is, did AMD attempt this merging of environments too early? Should they have simply started with moving the GPU under the same hood as the CPU as Cyrix did with their MediaGX series of processors? From the sound of the article, it sounds like they did jump the gun.
Then comes the AMD aspect. They could have licensed GPU cores until they finalized their strategy. Instead, they overpaid for a company that they became shackled to. They gambled and appear to have lost. It will most likely be their downfall.
You're assuming something's broken.
Farmers and ranchers in remote areas have been using portable VHF radios for communications for a number of decades now. Last I checked, such radios were still available and offered superior reception and battery life when compared to UHF cellular phones.
Furthermore, the dead zones in the western US states and Canadian provinces aren't solely the fault of private telecommunications companies. The last I checked, neither government has allocated a range in the lower UHF or upper VHF bands for cellular communication. Everything is in the middle to upper UHF band (the lowest we go is 700MHz). Recall that for any given power level, range decreases as frequency increases.
This is in contrast to Nordic and eastern Europe, much of Latin America, Africa and Asia that has a range around 450MHz for GSM and CDMA cellular communication. In the US, that range is reserved for GMRS and FRS. If the federal government reallocated that range for mobile cellular communication, the costs to cover lightly populated areas would go down sharply. The free market would hotly fight for those bands as it would make rural coverage cheaper to deploy.
Yeah, but that takes a human artist to manipulate the image. Imagine taking a face, entering a set of modifications, and then having the software do it for you.
I'm waiting for inexpensive applications for home PCs where you can easily change your appearance, sort of like digital plastic surgery. Want to see what you'd look like with a nose job? How about as the other sex? I would assume something like that would be a heck of a lot more complex than mapping somebody face onto somebody else's head.
This comic sums it up nicely.
Regardless of the method of transmission, television is dying, and the culprit is dumb content. People have more entertainment choices than ever before and television just can't keep up.
One major problem is that television content is dumbed down. Advertisers know that their commercials have less effect on intelligent people who are better at critical analysis, so they instead target kids, teens, seniors and the unwashed masses. Broadcast networks need content that will pull in those demographics. Make your content too complex and nuanced and you'll lose your targeted demographics. The result is a partnership between networks and advertisers that aim for the lowest common denominator sitting in front of the screen.
For a few decades, we had niche programming channels that offered something that wasn't stupid, but those channels have mostly been bought out by networks that have discovered that the LCD model is more profitable. Now those stations are content deserts, filled with little else besides reality shows about midgets, vagina clown cars, crabs and motorcycles. PBS is still around, but their programming is a niche within a niche. So we get this downward spiral where smart people are turned off by television, content gets dumber, more mainstream people are turned off by television, content gets dumber, and the IQ bar keeps falling.
The other major problem is that the way we receive content is dumb. Intelligent people have been buying gadgets for years that give us on-demand access to information. As the price has come down and those systems became more mainstream, everyday people got used to it as well. But television content mostly comes from unintelligent sources. On-demand IPTV might change that, but the content owners are fighting it. It is why streaming sites like Hulu and Netflix, as well as cable TV on-demand systems are hodge-podge patchworks of content.
I can't count the number of times that I have been frustrated because of the distribution methods of media. Netflix will have a series available for streaming, but then you hit one episode that is available only via disc rental. Hello, Bittorrent. Hulu will have content for streaming, but then you missed the cutoff for how long a new episode remains up. Hello, Bittorrent. I'll want to record two shows to my DVR that play the same time/night, but I only have one tuner card in my PVR. Know where I'm going by now?
The last problem is more of an issue limited to North America, but our OTA DTV system just doesn't play well with small, portable devices. We have too many channels that broadcast on VHF bands that require large antenna. The ATSC standard doesn't work well in areas bombarded with multipath interference or with moving devices (although it has gotten much better). Granted, the VSB standard was picked because it is more efficient over large areas, but it would be nice if any ATSC extensions would add OFDM as well. Large cities could have a low power UHF OFDM SFN (single frequency network) mesh for mobile handsets and apartment dwellers, while suburban and rural areas would still receive the main transmitter on the VHF-Hi VSB bands with their roof mounted aerials. Too bad that DTV for the VHF-Lo bands sucks and that the military occupies the area right above channel 13 on the VHF-Hi band.
BD movies would fill a tb drive in 20-40 movies. That's bad, but not crippling.
You can easily double that capacity by recoding both the video and audio streams at lower bitrates.
For my own Blu-ray archival, I convert all of the Dolby TrueHD and DTS-HD audio tracks to AAC 5.1-channel 640kbps or 2-channel 224kbps using eac3to. Next, I convert all of the H.262, H.264 and VC1 video tracks to H.264 using a constant quality value of "16" and the "slower" encoder preset using x264. Lastly, I convert the graphical PGS subtitles to text SRT using SupRip. For a two hour 1080p movie, I average around 11GB.
There are a few dark grainy movies where I had to use a higher CRF value of 14 or 15, but the resulting file is still smaller than the original M2TS file.
Maybe in six or seven years when 6TB and 8TB drives are the norm and I've upgrade my 42" 1080p plasma, I'll go back and grab the original streams. Until then, I'm fine watching the recodes.
The video from a good quality DE-15 VGA cable of reasonable length is nearly indistinguishable from that of a lossless digital connection such as DVI when using sane resolutions. It is mainly when you are utilizing substandard cables, unusually long lengths or very high resolutions (the kind that workstation GPUs push out) that the cable becomes an impairment. KVMs are also major signal killers.
Digital panels also introduce benefits and drawbacks regarding analog inputs. Many flat panels operate with 60Hz refresh rates, so the bandwidth required to transmit the signal is lower than in the days of CRTs when you often had refresh rates in excess of 85Hz. That means that you can get away with a cheaper cable for the same resolutions. On the other hand, you're now reliant on the quality of the A/D converter in the flat panel monitor. You're also reliant on the quality of the monitor calibration software. I find that many monitors suck on the second task unless you use anything other than a background of alternating black and white pixels (like the default X background).
As for the article itself, they are correct in claiming that it is outright BS. I have to go all the back to my old S3 Trio64 discrete video card before I find something that can't drive my flat panel at its native 1680Ã--1050 resolution at 32bpp. Every discrete video card and integrated onboard chipset I've had in the past decade can do it. Heck, both the Geforce FX5500 and Radeon 8500 AGP cards I have for my old K6/500 system drive my HD plasma in its native 1080p.
Do they drive them well? Picture quality wise, they're no different than the latest Nv or AMD card around. However, they do tend to chug a bit. The Radeon 8500 is especially bad under Windows 7 since I'm using hacked Vista drivers since it isn't a DX9 card, which is a requirement for Win7 (I'm sure the K6 doesn't help). But that isn't what the picture at Dell's site is showing.
Android-based smartphones from Verizon also use Bing as the default search provider. So it appears that Google will allow carriers to customize that aspect of the phone.
The main questions are: did Verizon have to put up a fight with Google over the change, or did Google not really care? Is there much interest from the carriers in changing the default search engine? Are any other carriers even making this change (like Chinese carriers using Baidu as opposed to western search engines)?
Hotmail could go one step further. As opposed to just checking against a blacklist of common passwords, they could use a whitelist of acceptable password types. Must be 8 or more characters in length, must be mixed case and must contain one or more digits. Then you run that against the blacklist to weed out people picking "Passw0rd" or "t1nkerB3ll".
Is that the residential rate or commercial rate? I know in many locations, the commercial rates for power can be as much as twice that of residential.
While I still own a Commodore 128 and an Amiga 3000, I find that I rarely boot up the original systems anymore.
It is a heck of a lot easier to simply use emulators. If you're trying to revisit an old arcade game, it is often better to get the game for MAME since ports to home computers were often subpar. If you're trying to revisit games specifically for the home, it is better to get whatever system was considered the best at the time. For the earlier years, that'd be an Amiga emulator like WinUAE. For anything post 1990, that'd be a PC emulator like DOSBox. C64 and Atari 8-bit emulators tie for stuff that is ancient.
I generally agree with your statement, but there are a few variables that can make it false. If you don't operate the computer for long periods of time or if your utility rates are low or nil, then the long-term power savings may not be worth it, especially if the legacy hardware was incredibly inexpensive or free.
Then you have the minority of people who like their computer to be a space heater. Any reduction in radiated heat from their PC will be countered by a ceramic space heater. A story a few years back noted how natural gas use in Canada was up because so many people switched to CFL and the central heating systems had to compensate.
You see this a bit more in the mainframe and server world. Releases see very long support cycles, often exceeding a decade. However, updates are usually limited to break/fix and security patches as opposed to feature enhancements. Much of that comes from the conservative nature of those environments. The premium pricing of product and support contracts reflects that environment.
For desktop and workstation markets, a decade is a long time. Microsoft is well within its rights to reallocate those resources from the XP team for other projects. Sure, many applications still work under Windows XP. But the same argument could be made about Windows 2K. Heck, the majority of my productivity applications run under NT4SP6 with a few tweaks. Doesn't mean that I should still be running NT4.
Having said that, I do have a double standard about being able to use old stuff. While I believe that people should be upgrading their software, I do believe that people should be able to keep their older hardware (within reason). Keeping that stuff out of landfills is a good thing, and many people with limited budgets are more than happy to have it.
I wish that Microsoft would have released a consumer version of its Windows 7 Thin Client Edition. Windows 7 Home Edition will work with something as old as a Pentium-II/266 or K6/266 (you need an ACPI compliant motherboard, a DirectX 9 video card and enough memory), but it chugs a bit (I wouldn't recommend anything less than 500MHz). Having a version where the compiler is tuned for older procs and smaller memory footprints, while having non-essential programs and services disabled would help. I assume they don't do it because people that cheap would refuse to pay for an OS, and I assume Microsoft wouldn't discount their OS enough for them to bite.
Or of PowerBroker. We use it on our SunOS and Linux boxes at work, and it offers both fine grained delegation of rights as well as advanced logging.
An Android Java applet should be able to run on any processor that Android has been ported to, may it be ARM, x86-64 or any other proc series.
Having said that, Java does allows you to load an external library via the System.loadLibrary() method, which could be a native binary. There are several examples on the web of how to use this for Android applets.
I could see situations where you wanted to use native Advanced Vector Extension (AVX) ops in a program for an embedded x86-64 processor because those ops were either not supported or poorly supported by the native Java bytecode interpreter. You lose portability in exchange for performance or other efficiencies.