Checking wikipedia, that was needed because the display was 100% bit-mapped. You just can't push that much data around on an 8-bit processor for vertical scrolling. On a TRS-80 Color Computer, if you used every register possible with PSHS/PULS, scrolling 6K of bitmapped video data 8 pixels at a time was almost tolerable. The Amstrad had 23K.
And I'm still mad at myself for not buying up the two or three PCWs I saw at thrift stores back in the '90s, because I later found out that it used the same 3" floppy drive as the Famicom Disk System.
I can see how that could be true and even sensible for a graphics mode on character-oriented display hardware, but the Apple II had that as part of its text mode row counters. IIRC from having seen the screen cleared many times long ago, hi-res did it with the same number of scan lines as text.
The summary said "most microcomputers". Two or three out of a one or two dozen isn't "most". And I wasn't "attacking" you, I was summarizing you and the other two or three people who responded as showing TFS being way off the mark.
So... we have two or three minor examples, hardly the "most microcomputers" as stated in the summary. TRS-80 didn't, Atari (with its complex display line modes) let you do whatever you wanted, Commodore didn't, and no big-iron S-100/SS-50 had non-sequential row mapping. Those were the "most microcomputers" up until the time of the IBM PC in 1982, which also had sequential video row mapping. Also, TMS-9918-based systems and MSX used a video chip with separate RAM, very much sequentially mapped. And ditto for all game consoles of the day.
BBC Micro (not even available outside of one country) with some modes that did, and couple of Sinclairs (all toy computers from the end of the 8-bit era) hardly a make majority.
Not having seen the details of what it did in the Apple II, I would not be surprised to find that it was designed to somehow optimize DRAM refresh. No Z-80 computer needed help with DRAM refresh for 16K DRAMs, but it looks like ZX Spectrum being from the late 8-bit era had a 128K option, but not until after it had been 16K/32K for a while.
most microcomputers used an interlaced frame buffer where adjacent rows were not stored sequentially in memory
First of all, I know a lot about micros from the late '70s and early '80s (I was there, maaaan!), and I can't remember a single one other than the Apple II series that didn't display rows sequentially.
This approach allowed Steve Wozniak to avoid read/write collisions with the video memory without additional circuitry.
I'm pretty sure the story I heard was that it saved one TTL chip in the counter chain to do it that way, which was just the kind of thing Woz would do.
Collisions? Exactly what kind of collisions are you talking about? IIRC, the Apple II used interleaved access, where the 6502 would access RAM on every other clock, and the video would access it in between. (This method was also used on the original Macintosh, though the 68000 sometimes needed a wait state.) But that has nothing to do with the funky row counters.
Yeah, TVGOS OTA died because it got bought out by a company called "Rovi", formerly known as "Macrovision", who didn't just shut down the OTA version, they all but sent in goons to pull the gear from engineering rooms in TV stations across the country.
I have an old Channel Master DVR that used TVGOS, which I stopped using after I set up a MythTV. You can still set its clock (I think it also tries to auto-set the clock from in the TV signal, but most stations don't use accurate clocks for that), and it can use the regular ATSC guide information, but it loses the descriptions a lot. (Not that MythTV isn't infamous for scrambling the descriptions, but that seems to mostly be due to thread-unsafe code that can be fixed.) The major problem with ATSC guide is that while TVGOS was two whole weeks (that was REAL nice), the ATSC guide is usually set to 12 hours because so many TV sets had crap code that would freak out with so much guide data. If you're lucky, a station will set it for 24 or 36 hours. Either way, it keeps you on your toes to get new shows added to your schedule.
But making it the only way to set the clock, that was top stupid. Fuck Sony. A non-Sony equivalent device? Still usable. Fuck you ATRAC, Memory Stick, and a couple others I don't remember. Even fuck you Blu-Ray for only winning by buying out the competition.
Usually those ad links are done after page load by a script. If you can find out which script is doing that, it's not hard to tell Ad Block Plus to block it. Stuff like that gets a whole-domain block from me because the domain is usually from a company that does nothing other than web ads, thus nothing of value is lost.
The support is in there, it's just that it uses a whitelist, which happens to be very small, probably only to U00FF if that much. There are also likely problems on the client side where the user's browser posts in the wrong encoding.
If there had been no side-mounted configuration, there would have been no disaster, whether or not the O-rings failed, or ice fell off of the ET. The basic design of the Shuttle stack prevented any form of crew escape, period, and it also subjected the crew vehicle to damage from the launch vehicle. Fortunately we're going back to capsules on top that can perform an emergency escape from the launch vehicle. It's not as sexy as an OMG SPACE PLANE but that was more trouble than it was worth.
And that's why it's a good thing that FH will be using the same parts as F9, only with a few struts added. Don't need heavy launches? Simply don't strut it together, and make three regular launches!
But don't limit your thinking to what we do now with what we have now. Just like with oil reserves increasing as the price of oil goes up (due to cost of recovery), the things people will want to launch rockets for will increase as the cost of launches goes down. And likewise, as the cost of heavy launches comes down, people will start building bigger stuff (or stacking multiple payloads) to make use of it.
I've only bought one LED bulb so far. It lasted maybe 3-4 years, but I would leave it on a good portion of the day. Of course the LEDs will last that long, but the weakest link is the power supply, specifically any electrolytic capacitors in it. I took it apart so I can play with the LEDs but haven't gotten around to it yet. I replaced it with an extra CFL I had lying around. Maybe I've been lucky, but I haven't had much problem with CFLs dying. If I had been having problems with CFLs, I would have bought more LED bulbs by now.
It works really well for embedded programming, especially when you don't have a heap. And anywhere you would consider using a bunch of function pointers, using virtual methods instead will make for a lot cleaner code. Also, classes can be used as an API for hardware devices, something I learned after being introduced to mbed.
3. Throw rocks or beanbags or some other kind of projectiles at it.
4. Point frickin' lasers at it, especially if it has a camera.
And #2 assumes that it would use GPS for guidance. If it's a video link to a human operator, it's not going to much. Better yet if the drone has a camera and computer vision using the street grid and buildings as a reference of where it is. After all, you only really need GPS when you're in the middle of nowhere.
Slashdot Mirror
Checking wikipedia, that was needed because the display was 100% bit-mapped. You just can't push that much data around on an 8-bit processor for vertical scrolling. On a TRS-80 Color Computer, if you used every register possible with PSHS/PULS, scrolling 6K of bitmapped video data 8 pixels at a time was almost tolerable. The Amstrad had 23K.
And I'm still mad at myself for not buying up the two or three PCWs I saw at thrift stores back in the '90s, because I later found out that it used the same 3" floppy drive as the Famicom Disk System.
I can see how that could be true and even sensible for a graphics mode on character-oriented display hardware, but the Apple II had that as part of its text mode row counters. IIRC from having seen the screen cleared many times long ago, hi-res did it with the same number of scan lines as text.
The summary said "most microcomputers". Two or three out of a one or two dozen isn't "most". And I wasn't "attacking" you, I was summarizing you and the other two or three people who responded as showing TFS being way off the mark.
But the 6809 was the best. (inb4 6309 which no computer ever shipped with)
It is unfortunate that Motorola didn't use it as the basis of the 6811 and 6812, but it was probably harder to express the 6809 in microcode.
BBC Micro (not even available outside of one country) with some modes that did, and couple of Sinclairs (all toy computers from the end of the 8-bit era) hardly a make majority.
Not having seen the details of what it did in the Apple II, I would not be surprised to find that it was designed to somehow optimize DRAM refresh. No Z-80 computer needed help with DRAM refresh for 16K DRAMs, but it looks like ZX Spectrum being from the late 8-bit era had a 128K option, but not until after it had been 16K/32K for a while.
most microcomputers used an interlaced frame buffer where adjacent rows were not stored sequentially in memory
First of all, I know a lot about micros from the late '70s and early '80s (I was there, maaaan!), and I can't remember a single one other than the Apple II series that didn't display rows sequentially.
This approach allowed Steve Wozniak to avoid read/write collisions with the video memory without additional circuitry.
I'm pretty sure the story I heard was that it saved one TTL chip in the counter chain to do it that way, which was just the kind of thing Woz would do.
Collisions? Exactly what kind of collisions are you talking about? IIRC, the Apple II used interleaved access, where the 6502 would access RAM on every other clock, and the video would access it in between. (This method was also used on the original Macintosh, though the 68000 sometimes needed a wait state.) But that has nothing to do with the funky row counters.
That's why Californians need to stay where they are and do NOT move to central states.
But is it known to cause cancer?
Apparently his eyes have gone bad over the years. The serial to parallel conversion is done in the game code.
Yeah, TVGOS OTA died because it got bought out by a company called "Rovi", formerly known as "Macrovision", who didn't just shut down the OTA version, they all but sent in goons to pull the gear from engineering rooms in TV stations across the country.
I have an old Channel Master DVR that used TVGOS, which I stopped using after I set up a MythTV. You can still set its clock (I think it also tries to auto-set the clock from in the TV signal, but most stations don't use accurate clocks for that), and it can use the regular ATSC guide information, but it loses the descriptions a lot. (Not that MythTV isn't infamous for scrambling the descriptions, but that seems to mostly be due to thread-unsafe code that can be fixed.) The major problem with ATSC guide is that while TVGOS was two whole weeks (that was REAL nice), the ATSC guide is usually set to 12 hours because so many TV sets had crap code that would freak out with so much guide data. If you're lucky, a station will set it for 24 or 36 hours. Either way, it keeps you on your toes to get new shows added to your schedule.
But making it the only way to set the clock, that was top stupid. Fuck Sony. A non-Sony equivalent device? Still usable. Fuck you ATRAC, Memory Stick, and a couple others I don't remember. Even fuck you Blu-Ray for only winning by buying out the competition.
The Case for the Empire
Are the "Rebels" in the Star Wars universe terrorists?
10 Reasons The Galactic Empire Wasn’t As Bad As Everyone Thinks
Who were the bad guys in Star Wars' original trilogy?
Your Terrorists Are Our Freedom Fighters (Warning: TVTropes link)
Usually those ad links are done after page load by a script. If you can find out which script is doing that, it's not hard to tell Ad Block Plus to block it. Stuff like that gets a whole-domain block from me because the domain is usually from a company that does nothing other than web ads, thus nothing of value is lost.
The support is in there, it's just that it uses a whitelist, which happens to be very small, probably only to U00FF if that much. There are also likely problems on the client side where the user's browser posts in the wrong encoding.
Launching is not the priority, maintaining Shuttle-era pork is the priority. So SNAFU.
If there had been no side-mounted configuration, there would have been no disaster, whether or not the O-rings failed, or ice fell off of the ET. The basic design of the Shuttle stack prevented any form of crew escape, period, and it also subjected the crew vehicle to damage from the launch vehicle. Fortunately we're going back to capsules on top that can perform an emergency escape from the launch vehicle. It's not as sexy as an OMG SPACE PLANE but that was more trouble than it was worth.
Oh Facebook, you so silly!
Bing Explorer
If he really believed climate change was not real, he would want to INCREASE NASA's budget
Except for the minor detail that it's the House that does the budgetary stuff.
And that's why it's a good thing that FH will be using the same parts as F9, only with a few struts added. Don't need heavy launches? Simply don't strut it together, and make three regular launches!
But don't limit your thinking to what we do now with what we have now. Just like with oil reserves increasing as the price of oil goes up (due to cost of recovery), the things people will want to launch rockets for will increase as the cost of launches goes down. And likewise, as the cost of heavy launches comes down, people will start building bigger stuff (or stacking multiple payloads) to make use of it.
To be completely fair, it wasn't the SRBs that killed Challenger, it was the side-mounted configuration that killed both Challenger and Columbia.
Sure, if you don't mind waiting for it to get there. For a manned mission, probably not so much.
I've only bought one LED bulb so far. It lasted maybe 3-4 years, but I would leave it on a good portion of the day. Of course the LEDs will last that long, but the weakest link is the power supply, specifically any electrolytic capacitors in it. I took it apart so I can play with the LEDs but haven't gotten around to it yet. I replaced it with an extra CFL I had lying around. Maybe I've been lucky, but I haven't had much problem with CFLs dying. If I had been having problems with CFLs, I would have bought more LED bulbs by now.
Also the fragile base class problem.
It works really well for embedded programming, especially when you don't have a heap. And anywhere you would consider using a bunch of function pointers, using virtual methods instead will make for a lot cleaner code. Also, classes can be used as an API for hardware devices, something I learned after being introduced to mbed.
3. Throw rocks or beanbags or some other kind of projectiles at it.
4. Point frickin' lasers at it, especially if it has a camera.
And #2 assumes that it would use GPS for guidance. If it's a video link to a human operator, it's not going to much. Better yet if the drone has a camera and computer vision using the street grid and buildings as a reference of where it is. After all, you only really need GPS when you're in the middle of nowhere.