People are getting their panties in a bundle because Microsoft is fixing bugs in their software and auto-patching. How else are they going to try to keep this stuff patched? Otherwise they end up with a hundred-and-one different XBox software versions out there.
Perhaps Microsoft should put in patches the way that the rest of the game consoles do it - you put the updated libraries onto the individial game discs that need them.
Using the hard drive to hold patches just brings us back to Windows DLL Hell. This is considered acceptable on a desktop, but on a game console, it can be the death of the machine. People tolerate crashes on their PC's, they don't tolerate them on game machines.
Microsoft should not be patching the XBox's without notifying the user if they use the hard drive in such a way. If my favorite game was no longer playable because of an update, I'd be super pissed.
This was one major issue that we support engineers discussed around Sega. We concurred that using the hard drive for holding the operating system would be problematic, as would automatic patching.
I worked for a telemarketing company, as a temporary job before I got my "big break" in Silicon Valley. It was during the summer between my fourth and fifth years in university, just after the computer store that I worked at closed down.
The way that the pay structure worked for the company I worked for was that we got paid an hourly rate (in my case, $8 per hour, a 40-hour work week), and we got a bonus for achieving certain quotas. This was in Ontario, Canada, and $8 per hour was pretty good, considering that most other student jobs were starting at minimum wage (which at that time, I believe was $6.45 per hour).
Nonetheless, these people running the telemarketing are a bunch of dishonest cheaters. Among the things that they did: 1. They forced us to come in Canadian holidays, instead giving us American holidays off (I believe that the Ontario Ministry of Labor gave them flak for that). 2. Some of the telemarketers had very questionable tactics, yet the company did not discipline them (even when management was aware that it was a problem). 3. The company tried to avoid giving out the bonuses at all costs. If a particular salesperson was close to meeting the quotas, they would put that salesperson on a different call list, where they were almost assured to not meet the quotas. 4. If somebody actually made the quota, they rarely got the bonus check. I know somebody who this personally happened to.
I only spent two months working as a telemarketer, but I absolutely hated it. When I got home at night I felt awful about the products I was selling, and some of the tactics that people were using. But it was either have a job or get kicked out of the apartment, so I kept doing it. I didn't really have time to find a better job, considering that I was going back to school in another couple of months (but then I got a job in the Valley and didn't go back).
People get into it probably because it's an easy job to do, it's not menial labor and the pay is (in most cases) better than minimum wage, which is pathetic.
What? You mean Commodore actually did something to the 1541C, other than take a 1541 and paint it white? (to match the 64C)?
Seriously though, I'd be willing to bet that the 1541C was a major design change, like the 64C (they put in completely different chips, and screwed up on the SID). I also seem to recall that definitely when the 1571 came out (and maybe even the 1541-II), that there were numerous complaints about the drive not being 100% 1541 compatible which caused some problems with some of the newer copy protection schemes (possibly why the sensor was disabled in later ROMs, it certainly wasn't for the "Drive Music" program). And let's not even touch the 1570, that oddball drive.
I wish that I had a 1571, but I wanted a 1581 even more. The reason that I liked the 1541-II and the 1571 was because they made the power supply a seperate unit from the drive. Made the drive smaller, and it didn't overheat as much, I had a 1541 overheat on me, the power rectifier (IIRC) blew on me. Not only did it cost me somewhere around $70 to fix, but I couldn't code demos for about two weeks!:)
It was a good thing that I could write a terminal program in about four lines of code so that I could hit the BBS'.
Unfortunately by the time my older 1541 drive started going out of alignment, there was no such thing as a "Commodore Authorized Repair Center", and I didn't have the necessary tools to accurately mess with the stepper motor.
Re-aligning the drive at that point consisted of loosening two screws on the stepper motor and running a program that would constantly query the drive to see where the drive thought the heads were, versus where the program thought that they were. Alignment was achived when you reached as close to the two numbers as you could.
I could never get the drive fully aligned, I was always a half-track off, either on the upper tracks or the lower tracks. But, it worked well enough.
The 1541 series drives (and even the later ones) were excellent pieces of machinery. They were completely programmable, the head could recognize half-tracks, and because of their programmaility, you could do all sorts of neat stuff with GCR data (densities, etc.), making disks that the drive itself couldn't write, but could still read.
What happened is that when the drive detected an error, it used the "bump" job-code command (0xc0) to move the drive head back to track 1, so that it had a known reference point. The method for doing this was to move the head all at once until it slammed against the stopper - that's what caused the banging noise.
Newer models of the 1541 (even before the 1541C and the 1541-II) put in a spring stopper so that when you moved the head back to track 1, the head would hit, but be cushioned by the spring.
Luckily I had the newer drives, so the head never had that same loud rattle... It rattled, but it wasn't quite as loud. The alignment still went on the thing after about 10 years.
My guess is that the Commodore engineers figured that it would either cost too much, or be pointless to put in a sensor, per se. The index hole in the floppies isn't used in Commodore 1541 drives (from what I remember), and the head was so volatile that a sensor might actually misbehave once the drive starts going out of alignment (all if takes is for somebody to try to read track 41, and that can mess up the head).
Yep, and then they started making the manuals with dark blue text on burgandy paper (well, the code number sections, anyway) so that you couldn't photocopy it. By the time you can actually read the code number to enter to play the game, you've completely screwed up your vision.:)
I had two Konami games on the C64 that used this method. After about five times of going through this pain, I cracked the damn games. What was great was that the copy protection code in both games was the same, and they even ever so nicely made it easy to find the protection (the border color changed after the code was correctly validated). Three byte patch (JMP $XXXX) and hacked game.
The 1541 drive itself was actually quite fast, reading an entire sector in much less than a second (if you set the job code directly in the drive). It was the serial transfer that was super slow (as you stated).
Unfortunately, the fast loaders assuming that the CPU and the drive both ran at exactly the same speed was a cause for problems. The PAL version of the C64 ran at a different speed (a bit slower, I believe), thus making fast loaders either NTSC or PAL specific (although there may have been one or two that could actually take the clock speed into consideration). The same fault meant that fast loaders sometimes didn't work with some variants of the drives (different CPU's, all supposedly 6502 compatible, but not necessarily so).
Additionally, because these fast loaders required exact timing, something had to be done with the VIC-II (interrupts from it would cause the 6510 in the C64 to lose it's timing) - usually the screen was blanked (basically turning off the VIC-II), or at the least, turning off sprites (sprites by the way, while nice, were a PITA becuase they disrupted everything, including raster timing).
Commodore did screw things up... They had four (or was it six?) connectors on each end of the cable, they could have made it at least quai-parallel, rather than the serial with handshaking. Unfortunately, they only hooked up two, CLK (handshaking clock) and DATA (for the data bit). However, seeing as the 1541 was the same hardware mechanism as the 1540 (it's predecessor for the VIC-20) and contained most of the same software (you could use a "user" command to change the speed for the VIC-20), they couldn't just go out and change the design. I almost get the feeling that they took the serial bus from the VIC-20, put it in the C64, figuring that they'd be able to use the 1540 drive. Then at the last minute, they realized that it wouldn't work and they made the 1541, as well as a ROM upgrade for the 1540 to work with the C64.
While getting rid of the handshaking and transferring an extra bit over that line made sense then, with modern computers, I wouldn't trust it. There's too many components from too many manufacturers, and I really like my MP3 and pr0n collections too much to lose them to one bit being corrupted.
I worked at Sega, and although my only experience with consoles with a hard drive is owning an XBox, they don't have to get it right the first time.
Every game console that I know of boots the OS off it's cartridge ROM or the actual CD/DVD in the drive. The benefits of this are that every game can have the OS customized towards it. If a particular game needs a bug fix that would break another title, it's not a problem.
So, ATi just has to get the drivers working on a game-by-game basis (though it's preferable that it just works with everything).
It was quite common when I was at Sega for developers to swap out libraries for new hardware support, or bug fixes for particular titles.
The compnay that I worked for (Com21) used only vxWorks, mainly because it worked for us, and we didn't have the time or money to invest in another operating system.
However, Broadcom has heavily invested in Linux, as it saves them a ton of money in licensing fees from WindRiver (believe me, WindRiver writes their royalty contracts like it's the dotcom boom). Because it takes more than your average individual to make use of these images, I think that they're hoping that nobody will reverse engineer it and see what they're doing.
In fact, it wouldn't surprise me if Linksys were using straight Broadcom reference code, with their own webpages (for their own logos) put in place. This was quite common in the cable modem market - some Taiwanese CM manufacturers would use straight Broadcom reference code, a BRCM reference board and then just design their own plastic molding.
Nah, you're fine. The reason is that you'll have difficulty finding it!:)
I haven't used P2P since Napster, and the main reason I stopped is because I was frustrated at the quality of the files (crappy rips, static, pops, etc).
A lot of the stuff that I listen to is 80's, not easily available (I either have to find a compilation CD that has 10 other songs I already have, or order online, and that's if it's available). Especially if it was a one-hit wonder.
Oh, and let's not forget the Canadian bands that I liked but can't find the albums here in the U.S., because they're considered "imports" (according to Amazon.com).
Erm, the person asked for a solution that let them use videoconferencing with NAT, I provided one. Yes, NAT breaks these protocols (H323 was poorly designed anyway, even firewalling breaks it), but that wasn't the point of my message.
Face it, the United States doesn't care yet, because they have tons of address space. I've heard of entire countries getting only one class C, and all of the ISPs having to use NAT for their customers. Yeah, it bugs me, but I can't do squat about it. As long as there is a shortage of IP addresses, they're (in theory) worth more.
Now then, the manual for my SonicWall defines "One-To-One NAT" as such: "One-to-One NAT creates a relationship which maps valid external addresses to internal addresses hidden by NAT. Machines with an internal address may be accessed at the corresponding valid IP address."
Bascially, One-To-One NAT isn't quite standard NAT, in that it is designed to give a machine that has an internal IP address an external IP address. Standard NAT is meant to aggregate internal traffic from the inside, send it out, and forward the resulting incoming data. It doesn't care about unrequested incoming traffic, and that's why it's broken. Whereas, One-To-One NAT is more of a tunnel, meant specifically for external connections.
In this case, I am behind a NAT (my IP addresses on the LAN are in the 192.168.1.x range). The person you make the call to must not be using NAT themselves (so that you can make the call). So, the call is initiated from the person using NAT to the person not using NAT (or who has forwarded the proper ports and is using NAT, good luck though).
The H323 protocol is awful in that it is neither firewall or NAT friendly. The only way to allow incoming H323 transmissions when you are on NAT is to forward all ports on the NAT router (above port 1024) to the one and only PC. There might be software that works around this, but I'm not certain.
That's where SonicWall's One-To-One NAT feature works - for every public IP address you have, you can forward all traffic on it to a machine behind the NAT.
The problem is not with the application (most of the time), the problem is with NAT itself.
When you initiate the outgoing connection first, then it's not usually a problem. For something like HTTP, everything is done in a sequence (client to server, server to client, etc.), so it's easy for the NAT router to handle this. As long as the NAT side initiates the connection, and the other side responds back to the port that the NAT router specified, all is fine. Thus, many people can run ICQ (or even a web browser) behind NAT because the NAT router gives each connection a different originating port. The NAT router can then route data that comes back on this port to the proper PC.
An example: You have three PC's behind NAT, 192.168.1.x, where x is 1..3. * PC 1 requests slashdot.org, PC 2 requests microsoft.com and PC 3 requests newegg.com. * PC 1 sends out a request on it's local port (say 1024), the NAT router rewrites the packet to look like it's coming from 1.2.3.4, port 50000. * PC 2 sends out it's request, and the NAT router rewrites it to be from 1.2.3.4, port 50001.... etc.
Now then, when slashdot.org responds, it responds to 1.2.3.4, port 50000. The NAT router gets this, looks in it's table and realizes that it needs to send to 192.168.1.1, port 1024, and forwards the traffic there. When microsoft.com responds, it responds to 1.2.3.4, port 50001. The NAT router looks up in the tables, and forwards the traffic to 192.168.1.2, whatever port the data came from.
The problem comes in when you want an external machine to be able to hit something behind the NAT router, since the NAT router doesn't have the entries in the table to forward the traffic. Thus, you need to manually create the ruleset.
Even if the application allows you to configure ports to use, the NAT router still has to have rules that tell it to forward the traffic to the correct PC.
So, for every instance of the app running (say 10 instances on ports 2000-2009), you have to have a rule, so 10 rules on the NAT box, doing basically this (where 1.2.3.4 is your public IP address): forward from 1.2.3.4 port 2000 to 192.168.1.1 port 2000 forward from 1.2.3.4 port 2001 to 192.168.1.2 port 2001 forward from 1.2.3.4 port 2002 to 192.168.1.3 port 2002... and so on.
I used to do this a few years ago, where my OpenBSD NAT machine would forward e-mail to one PC (e-mail server), send web requests to another PC (web server) and FTP requests to yet another dedicated FTP server machine.
However, for any normal-sized network (bigger than the five machines we keep in the basement), this becomes a pain.
For videochat, I highly recommend a SonicWall hardware firewall. It does NAT and has a DHCP server.
The only catch is that you have to initiate the call (unless you have multiple static IP's and can thus run One-To-One NAT). But, given that restriction, it works fine, I've tested it with both NetMeeting and GnomeMeeting, video and audio were fine.
Not an employee of SonicWall (although I have applied for a position there and am waiting for them to get back to me), just a happy user of their products.
Direct P2P is a problem though, you typically have to do manual port forwarding, hence it only works on one machine on the network. The SonicWall device that I have (a SOHO one) doesn't support manual port forwarding, that is a downside.
Well, I can't speak about many of these companies, but I can tell you that AT&T (12.x.x.x) does use a fair amount of it's IP space. Many of the 12.x.x.x addresses are used for their cable modem subscribers (I'm one, and I get a 12.x.x.x address, but only because my CPE device doesn't match the MAC address I gave them).
You also missed IBM, which uses the 9.x.x.x address space (last time I checked), and they use it. Most of it is firewalled off, but those machines can access the rest of the net. The actual IP addresses are divided between the various offices around the world (at least that's the way it was when I worked there about six years ago).
I don't remember Windows 98 because I haven't used it in so long. I went to a DirectX conference, and in exchange for answering some questions about my employer's embedded offerings, I got a free copy of Windows 2000 from Microsoft, so I've been using that ever since.
XP Home came with my laptop, so that's what I've been using lately, although Microsoft did (does?) have some sort of licensing policy (I saw it on their website at one time), where if you have an XP license, you can use Windows 2000 in it's place. I haven't put Windows 2000 back on the laptop yet because XP boots so quickly.
Windows 2000 does not seem to blow away the MBR on me, but who's to say that it doesn't for others?
My Compaq Presario 2715US came with Windows XP on a series of three CD's that will wipe everything before putting them back on. As far as I know, this is fairly common practice nowadays. The twist here is that all of the Microsoft applications (XP and Works) and the drivers are within the image, all of the other apps that came with it (WinDVD, Symantec Anti-Virus, etc.) are included on their own CD's.
It's easy to make a dual-boot. Resize the NTFS partition, and then install Linux into the empty space. GRUB or LILO will then install into the MBR, and presto, dual-boot!
The thing that I hate about XP versus Windows 2000 (and earlier, I believe) is that XP seems to deliberately clobber the MBR. For example, if I install Linux (and GRUB or LILO), then install XP afterwards, GRUB/LILO is gone, I have to use a boot-disk to get back into Linux. This pisses me off to no end.
As for those images... If you get Windows 2000 or Windows XP images, you've almost got a full-bootable copy. The image for my laptop was made with (I think) DriveImage, and I was able to get an evaulation copy of it, and it allowed me to extract the i386 (CABs) directory. From there, I just had to borrow a few files (like setup.exe, etc.) from a friends' XP installation CD (which indicently came with a Dell laptop he bought), and make it bootable according to Bink's page
Of course, not knowing fully about how Windows XP's activation works, I didn't want to just make a copy of his XP install CD, in case it was keyed for a Dell laptop. And, just in case, it somehow cut him off.:)
As much as I'd like to believe this, it doesn't hold water.
The truth is (as has been pointed out to me many times by my various managers), if you don't get the product out when marketing needs it, you won't have customers, because somebody else *will* deliver.
Granted, if you're the only maker of the product, you have some lee-way. However, a lot of software and/or hardware products are in a commodity market. Being the first to market with a new feature generally insures sales, despite how well the functionality works.
Unfortunately, the motto in tech seems to be, "Ship first, fix it later".
Or, like me, you'll find yourself out of a job because your company couldn't compete because the codebase for the project was so crappy that it couldn't be fixed. As such, your competitors ate your lunch.
Then again, I am glad to not be fixing my co-workers problems anymore. It's a bad sign when during the weekly status meetings the same person, every week, has missed their deadline, and is constantly making excuses for it...
It's been about five years since I've worked at IBM, but I recall at IBM Canada, they were heavily standardized on Token Ring, OS/2 and using their own brand of PC's. The IT people had the job of putting in a 4/16 Token Ring card in every new PC that came into the building. Many of the PC's didn't even have Ethernet cards (they were mostly useless in the building).
If they're still on Token Ring now though, somebody should shoot them. I remember, it used to be fun whenever somebody kicked out their Token Ring connection. Also, as I recall, it was not very fault tolerant... I was running an application that relied on LAN connections, but kicked out the Token Ring by mistake. Not only was their a loud beeping that everybody in the classroom could hear, but the program couldn't re-establish it's connection. It was a pain to go to each machine by hand and grab the test results. Now yes, I realize that it could have been an application problem, but that problem seemed to plague many applications running on the Token Ring network.
Sorry, the Commodore 64 did have 64K of RAM. It also had (I believe) 20K of ROM (8K BASIC interpreter, 8K kernel ROM and 4K character ROM) mapped in at various addresses. However, the RAM "underneath" the ROMs is available, but only in machine language.
The BASIC interpreter is mapped in at $A000, the character ROM is mapped in at $D000 (I think, I don't quite remember), and the kernel ROM is mapped in at $E000. Due to the way that the VIC-II works, being able to access only 16K at a time, the character ROM is also mapped in at $1000 and $9000, but only the VIC-II sees it this way, the 6510 sees the RAM there.
Now then, to map out the ROM's, you need to play with the MMU, which is at memory location 1. Also, like I said, you have to be in machine language, because using any of these methods, you end up mapping out either the BASIC interpreter, BASIC and the kernel, or all of the ROM's, and if you're in BASIC, unless you've copied the ROM to RAM, you'll crash the machine.
These values will work, although you shouldn't just set them, since they also set some of the Datasette lines as well. Set the MMU (memory location 1) to these values to get the RAM: $36: Map in the RAM under the BASIC interpreter (8K at $A000) $35: Map in the RAM under the BASIC interpreter (8k at $A000) and under the kernel (8K at $E000) $34: All 64K of RAM. There are other values as well, but I don't remember how they work, as I didn't use them very often.
Note that when you map out the kernel or use all 64K of RAM, you MUST disable interrupts. The 6510, when it receives an interrupt, jumps to the vector pointed at $FFFC ($FFFA for NMI's), and for IRQ, this is $EA31 (I don't remember the NMI). If the CPU does it's JMP($FFFC), and there's garbage there, well, your C64 goes off into never-never land.
Also when you map in all 64K of memory, you only have about 63K of memory. That's because most of zero page (0-255) is reserved, $100-$200 is the stack (you don't want to mess with that unless you really know what you're doing), and $300 contains some semi-important pointers (file I/O, IRQ, etc.). But from $400 up, you're all clear.
Of interesting note... The game Impossible Mission (by Epyx) used all but 1K of RAM. And yes, I'm a former C64 demo coder, I've set the machine to use all 64K of RAM many times.
Although reverse engineering is generally defined as reversing software's machine code back to the source code, Baystate claims it looked only at Bowers' user interface in order to improve its CAD software product. "There was no evidence of cracking encrypted source code or anything of that nature," said Bob Kann, Baystate's lawyer, of Bromberg and Sunstein, in Boston. "This may cause havoc in the industry. Before this case, it was perfectly legal to evaluate a competitor's product."
and
Meeker noted that Baystate had reproduced a handful of errors in Bowers program. Kann, Baystate's lawyer, said all the errors came from Bowers' user interface, not the underlying code.
Unfortunately, the article doesn't specify what types of UI errors really occured, only an allegation that code was copied. It could be something as simple as a couple of menu items misspelled. Without more details, it's hard to comment
Okay, now yes, in your example (which, since I'm not too familar with Windows GDI programming, I do UNIX and vxWorks embedded, I presume adds a handler for a scrollbar up arrow being clicked on), I would be more suspicious.
Personally, I don't have a problem with people copying look and feel. Where I do draw the line is actually copying code from existing products when you do not have the license to do so (copyright violation).
The company that I used to work for was making a router-type product for the cable internet industry. Seeing as Cisco is considered the industry leader, it was highly desirable to copy the Cisco CLI commands, down to the exact command syntax (where possible).
The reverse engineering in my particular case involved typing in commands at the Cisco CLI, and then looking at either the configuration file, or SNMP MIBs to see the results (which is considered reverse engineering, even though I didn't look at any Cisco code).
Now, suppose I put in a very counter-intuitive command, or even a command which was considered to be "in error" (i.e. confusing syntax, whatever). Would you say that something fishy is going on? We're just trying to keep the interface as similar to Cisco as possible.
The article said that the error looked to be in the UI and not in any underlying code. Of course, the question is, were both programs done in the same language, use the same GUI toolkit, etc? Look and feel alone do not constitute full-blown "code-ripping", as we used to call this years ago.
This isn't surprising (the part about FreeBSD developers on the payroll).
While the core OS itself was written from scratch, a lot of the periphery code (i.e. network stack, device drivers, etc.) come from one of the BSD's (I can't tell which one though, since I haven't bothered to read all of the code). And, judging by some of the dates in the changelog, they haven't been updated in a *long* time.
NT4 did have Plug and Play support, but only for PCI devices under the default installation. There was a way to enable ISA Plug and Play, but it wasn't considered mature enough.
ISA, on the other hand, was a different story. Here's how to enable ISA PnP as part of adding a SoundBlaster PnP card: NT4 Plug and Play More NT4 ISA PnP Info
I used this method with no problems on a SoundBlaster AWE64 ISA card. Note though that this was pretty much only for PnP sound cards. Back then for PnP ISA network cards, I just made the card non-PnP, and set it up with manual resources. The reason for this is that it made using Linux easier at that time (back in the 2.0.37 or so days, when I was first experiementing with RedHat).
Slashdot Mirror
People are getting their panties in a bundle because Microsoft is fixing bugs in their software and auto-patching. How else are they going to try to keep this stuff patched? Otherwise they end up with a hundred-and-one different XBox software versions out there.
Perhaps Microsoft should put in patches the way that the rest of the game consoles do it - you put the updated libraries onto the individial game discs that need them.
Using the hard drive to hold patches just brings us back to Windows DLL Hell. This is considered acceptable on a desktop, but on a game console, it can be the death of the machine. People tolerate crashes on their PC's, they don't tolerate them on game machines.
Microsoft should not be patching the XBox's without notifying the user if they use the hard drive in such a way. If my favorite game was no longer playable because of an update, I'd be super pissed.
This was one major issue that we support engineers discussed around Sega. We concurred that using the hard drive for holding the operating system would be problematic, as would automatic patching.
-- Joe
I worked for a telemarketing company, as a temporary job before I got my "big break" in Silicon Valley. It was during the summer between my fourth and fifth years in university, just after the computer store that I worked at closed down.
The way that the pay structure worked for the company I worked for was that we got paid an hourly rate (in my case, $8 per hour, a 40-hour work week), and we got a bonus for achieving certain quotas. This was in Ontario, Canada, and $8 per hour was pretty good, considering that most other student jobs were starting at minimum wage (which at that time, I believe was $6.45 per hour).
Nonetheless, these people running the telemarketing are a bunch of dishonest cheaters. Among the things that they did:
1. They forced us to come in Canadian holidays, instead giving us American holidays off (I believe that the Ontario Ministry of Labor gave them flak for that).
2. Some of the telemarketers had very questionable tactics, yet the company did not discipline them (even when management was aware that it was a problem).
3. The company tried to avoid giving out the bonuses at all costs. If a particular salesperson was close to meeting the quotas, they would put that salesperson on a different call list, where they were almost assured to not meet the quotas.
4. If somebody actually made the quota, they rarely got the bonus check. I know somebody who this personally happened to.
I only spent two months working as a telemarketer, but I absolutely hated it. When I got home at night I felt awful about the products I was selling, and some of the tactics that people were using. But it was either have a job or get kicked out of the apartment, so I kept doing it. I didn't really have time to find a better job, considering that I was going back to school in another couple of months (but then I got a job in the Valley and didn't go back).
People get into it probably because it's an easy job to do, it's not menial labor and the pay is (in most cases) better than minimum wage, which is pathetic.
-- Joe
What? You mean Commodore actually did something to the 1541C, other than take a 1541 and paint it white? (to match the 64C)?
:)
Seriously though, I'd be willing to bet that the 1541C was a major design change, like the 64C (they put in completely different chips, and screwed up on the SID). I also seem to recall that definitely when the 1571 came out (and maybe even the 1541-II), that there were numerous complaints about the drive not being 100% 1541 compatible which caused some problems with some of the newer copy protection schemes (possibly why the sensor was disabled in later ROMs, it certainly wasn't for the "Drive Music" program). And let's not even touch the 1570, that oddball drive.
I wish that I had a 1571, but I wanted a 1581 even more. The reason that I liked the 1541-II and the 1571 was because they made the power supply a seperate unit from the drive. Made the drive smaller, and it didn't overheat as much, I had a 1541 overheat on me, the power rectifier (IIRC) blew on me. Not only did it cost me somewhere around $70 to fix, but I couldn't code demos for about two weeks!
It was a good thing that I could write a terminal program in about four lines of code so that I could hit the BBS'.
-- Joe
Unfortunately by the time my older 1541 drive started going out of alignment, there was no such thing as a "Commodore Authorized Repair Center", and I didn't have the necessary tools to accurately mess with the stepper motor.
Re-aligning the drive at that point consisted of loosening two screws on the stepper motor and running a program that would constantly query the drive to see where the drive thought the heads were, versus where the program thought that they were. Alignment was achived when you reached as close to the two numbers as you could.
I could never get the drive fully aligned, I was always a half-track off, either on the upper tracks or the lower tracks. But, it worked well enough.
The 1541 series drives (and even the later ones) were excellent pieces of machinery. They were completely programmable, the head could recognize half-tracks, and because of their programmaility, you could do all sorts of neat stuff with GCR data (densities, etc.), making disks that the drive itself couldn't write, but could still read.
-- Joe
What happened is that when the drive detected an error, it used the "bump" job-code command (0xc0) to move the drive head back to track 1, so that it had a known reference point. The method for doing this was to move the head all at once until it slammed against the stopper - that's what caused the banging noise.
Newer models of the 1541 (even before the 1541C and the 1541-II) put in a spring stopper so that when you moved the head back to track 1, the head would hit, but be cushioned by the spring.
Luckily I had the newer drives, so the head never had that same loud rattle... It rattled, but it wasn't quite as loud. The alignment still went on the thing after about 10 years.
My guess is that the Commodore engineers figured that it would either cost too much, or be pointless to put in a sensor, per se. The index hole in the floppies isn't used in Commodore 1541 drives (from what I remember), and the head was so volatile that a sensor might actually misbehave once the drive starts going out of alignment (all if takes is for somebody to try to read track 41, and that can mess up the head).
-- Joe
Yep, and then they started making the manuals with dark blue text on burgandy paper (well, the code number sections, anyway) so that you couldn't photocopy it. By the time you can actually read the code number to enter to play the game, you've completely screwed up your vision. :)
:)
I had two Konami games on the C64 that used this method. After about five times of going through this pain, I cracked the damn games. What was great was that the copy protection code in both games was the same, and they even ever so nicely made it easy to find the protection (the border color changed after the code was correctly validated). Three byte patch (JMP $XXXX) and hacked game.
Ahhh, the days of 8-bit computing.
-- Joe
The 1541 drive itself was actually quite fast, reading an entire sector in much less than a second (if you set the job code directly in the drive). It was the serial transfer that was super slow (as you stated).
Unfortunately, the fast loaders assuming that the CPU and the drive both ran at exactly the same speed was a cause for problems. The PAL version of the C64 ran at a different speed (a bit slower, I believe), thus making fast loaders either NTSC or PAL specific (although there may have been one or two that could actually take the clock speed into consideration). The same fault meant that fast loaders sometimes didn't work with some variants of the drives (different CPU's, all supposedly 6502 compatible, but not necessarily so).
Additionally, because these fast loaders required exact timing, something had to be done with the VIC-II (interrupts from it would cause the 6510 in the C64 to lose it's timing) - usually the screen was blanked (basically turning off the VIC-II), or at the least, turning off sprites (sprites by the way, while nice, were a PITA becuase they disrupted everything, including raster timing).
Commodore did screw things up... They had four (or was it six?) connectors on each end of the cable, they could have made it at least quai-parallel, rather than the serial with handshaking. Unfortunately, they only hooked up two, CLK (handshaking clock) and DATA (for the data bit). However, seeing as the 1541 was the same hardware mechanism as the 1540 (it's predecessor for the VIC-20) and contained most of the same software (you could use a "user" command to change the speed for the VIC-20), they couldn't just go out and change the design. I almost get the feeling that they took the serial bus from the VIC-20, put it in the C64, figuring that they'd be able to use the 1540 drive. Then at the last minute, they realized that it wouldn't work and they made the 1541, as well as a ROM upgrade for the 1540 to work with the C64.
While getting rid of the handshaking and transferring an extra bit over that line made sense then, with modern computers, I wouldn't trust it. There's too many components from too many manufacturers, and I really like my MP3 and pr0n collections too much to lose them to one bit being corrupted.
-- Joe
I worked at Sega, and although my only experience with consoles with a hard drive is owning an XBox, they don't have to get it right the first time.
Every game console that I know of boots the OS off it's cartridge ROM or the actual CD/DVD in the drive. The benefits of this are that every game can have the OS customized towards it. If a particular game needs a bug fix that would break another title, it's not a problem.
So, ATi just has to get the drivers working on a game-by-game basis (though it's preferable that it just works with everything).
It was quite common when I was at Sega for developers to swap out libraries for new hardware support, or bug fixes for particular titles.
-- Joe
Yep, this is true.
The compnay that I worked for (Com21) used only vxWorks, mainly because it worked for us, and we didn't have the time or money to invest in another operating system.
However, Broadcom has heavily invested in Linux, as it saves them a ton of money in licensing fees from WindRiver (believe me, WindRiver writes their royalty contracts like it's the dotcom boom). Because it takes more than your average individual to make use of these images, I think that they're hoping that nobody will reverse engineer it and see what they're doing.
In fact, it wouldn't surprise me if Linksys were using straight Broadcom reference code, with their own webpages (for their own logos) put in place. This was quite common in the cable modem market - some Taiwanese CM manufacturers would use straight Broadcom reference code, a BRCM reference board and then just design their own plastic molding.
-- Joe
Nah, you're fine. The reason is that you'll have difficulty finding it! :)
I haven't used P2P since Napster, and the main reason I stopped is because I was frustrated at the quality of the files (crappy rips, static, pops, etc).
A lot of the stuff that I listen to is 80's, not easily available (I either have to find a compilation CD that has 10 other songs I already have, or order online, and that's if it's available). Especially if it was a one-hit wonder.
Oh, and let's not forget the Canadian bands that I liked but can't find the albums here in the U.S., because they're considered "imports" (according to Amazon.com).
-- Joe
Erm, the person asked for a solution that let them use videoconferencing with NAT, I provided one. Yes, NAT breaks these protocols (H323 was poorly designed anyway, even firewalling breaks it), but that wasn't the point of my message.
Face it, the United States doesn't care yet, because they have tons of address space. I've heard of entire countries getting only one class C, and all of the ISPs having to use NAT for their customers. Yeah, it bugs me, but I can't do squat about it. As long as there is a shortage of IP addresses, they're (in theory) worth more.
Now then, the manual for my SonicWall defines "One-To-One NAT" as such:
"One-to-One NAT creates a relationship which maps valid external addresses to internal addresses hidden by NAT. Machines with an internal address may be accessed at the corresponding valid IP address."
Bascially, One-To-One NAT isn't quite standard NAT, in that it is designed to give a machine that has an internal IP address an external IP address. Standard NAT is meant to aggregate internal traffic from the inside, send it out, and forward the resulting incoming data. It doesn't care about unrequested incoming traffic, and that's why it's broken. Whereas, One-To-One NAT is more of a tunnel, meant specifically for external connections.
-- Joe
In this case, I am behind a NAT (my IP addresses on the LAN are in the 192.168.1.x range). The person you make the call to must not be using NAT themselves (so that you can make the call). So, the call is initiated from the person using NAT to the person not using NAT (or who has forwarded the proper ports and is using NAT, good luck though).
The H323 protocol is awful in that it is neither firewall or NAT friendly. The only way to allow incoming H323 transmissions when you are on NAT is to forward all ports on the NAT router (above port 1024) to the one and only PC. There might be software that works around this, but I'm not certain.
That's where SonicWall's One-To-One NAT feature works - for every public IP address you have, you can forward all traffic on it to a machine behind the NAT.
-- Joe
The problem is not with the application (most of the time), the problem is with NAT itself.
... etc.
... and so on.
When you initiate the outgoing connection first, then it's not usually a problem. For something like HTTP, everything is done in a sequence (client to server, server to client, etc.), so it's easy for the NAT router to handle this. As long as the NAT side initiates the connection, and the other side responds back to the port that the NAT router specified, all is fine. Thus, many people can run ICQ (or even a web browser) behind NAT because the NAT router gives each connection a different originating port. The NAT router can then route data that comes back on this port to the proper PC.
An example:
You have three PC's behind NAT, 192.168.1.x, where x is 1..3.
* PC 1 requests slashdot.org, PC 2 requests microsoft.com and PC 3 requests newegg.com.
* PC 1 sends out a request on it's local port (say 1024), the NAT router rewrites the packet to look like it's coming from 1.2.3.4, port 50000.
* PC 2 sends out it's request, and the NAT router rewrites it to be from 1.2.3.4, port 50001.
Now then, when slashdot.org responds, it responds to 1.2.3.4, port 50000. The NAT router gets this, looks in it's table and realizes that it needs to send to 192.168.1.1, port 1024, and forwards the traffic there. When microsoft.com responds, it responds to 1.2.3.4, port 50001. The NAT router looks up in the tables, and forwards the traffic to 192.168.1.2, whatever port the data came from.
The problem comes in when you want an external machine to be able to hit something behind the NAT router, since the NAT router doesn't have the entries in the table to forward the traffic. Thus, you need to manually create the ruleset.
Even if the application allows you to configure ports to use, the NAT router still has to have rules that tell it to forward the traffic to the correct PC.
So, for every instance of the app running (say 10 instances on ports 2000-2009), you have to have a rule, so 10 rules on the NAT box, doing basically this (where 1.2.3.4 is your public IP address):
forward from 1.2.3.4 port 2000 to 192.168.1.1 port 2000
forward from 1.2.3.4 port 2001 to 192.168.1.2 port 2001
forward from 1.2.3.4 port 2002 to 192.168.1.3 port 2002
I used to do this a few years ago, where my OpenBSD NAT machine would forward e-mail to one PC (e-mail server), send web requests to another PC (web server) and FTP requests to yet another dedicated FTP server machine.
However, for any normal-sized network (bigger than the five machines we keep in the basement), this becomes a pain.
-- Joe
For videochat, I highly recommend a SonicWall hardware firewall. It does NAT and has a DHCP server.
The only catch is that you have to initiate the call (unless you have multiple static IP's and can thus run One-To-One NAT). But, given that restriction, it works fine, I've tested it with both NetMeeting and GnomeMeeting, video and audio were fine.
Not an employee of SonicWall (although I have applied for a position there and am waiting for them to get back to me), just a happy user of their products.
Direct P2P is a problem though, you typically have to do manual port forwarding, hence it only works on one machine on the network. The SonicWall device that I have (a SOHO one) doesn't support manual port forwarding, that is a downside.
-- Joe
Well, I can't speak about many of these companies, but I can tell you that AT&T (12.x.x.x) does use a fair amount of it's IP space. Many of the 12.x.x.x addresses are used for their cable modem subscribers (I'm one, and I get a 12.x.x.x address, but only because my CPE device doesn't match the MAC address I gave them).
You also missed IBM, which uses the 9.x.x.x address space (last time I checked), and they use it. Most of it is firewalled off, but those machines can access the rest of the net. The actual IP addresses are divided between the various offices around the world (at least that's the way it was when I worked there about six years ago).
-- Joe
This could very well be.
I don't remember Windows 98 because I haven't used it in so long. I went to a DirectX conference, and in exchange for answering some questions about my employer's embedded offerings, I got a free copy of Windows 2000 from Microsoft, so I've been using that ever since.
XP Home came with my laptop, so that's what I've been using lately, although Microsoft did (does?) have some sort of licensing policy (I saw it on their website at one time), where if you have an XP license, you can use Windows 2000 in it's place. I haven't put Windows 2000 back on the laptop yet because XP boots so quickly.
Windows 2000 does not seem to blow away the MBR on me, but who's to say that it doesn't for others?
-- Joe
As others have stated, this is a non-issue.
My Compaq Presario 2715US came with Windows XP on a series of three CD's that will wipe everything before putting them back on. As far as I know, this is fairly common practice nowadays. The twist here is that all of the Microsoft applications (XP and Works) and the drivers are within the image, all of the other apps that came with it (WinDVD, Symantec Anti-Virus, etc.) are included on their own CD's.
It's easy to make a dual-boot. Resize the NTFS partition, and then install Linux into the empty space. GRUB or LILO will then install into the MBR, and presto, dual-boot!
The thing that I hate about XP versus Windows 2000 (and earlier, I believe) is that XP seems to deliberately clobber the MBR. For example, if I install Linux (and GRUB or LILO), then install XP afterwards, GRUB/LILO is gone, I have to use a boot-disk to get back into Linux. This pisses me off to no end.
As for those images... If you get Windows 2000 or Windows XP images, you've almost got a full-bootable copy. The image for my laptop was made with (I think) DriveImage, and I was able to get an evaulation copy of it, and it allowed me to extract the i386 (CABs) directory. From there, I just had to borrow a few files (like setup.exe, etc.) from a friends' XP installation CD (which indicently came with a Dell laptop he bought), and make it bootable according to Bink's pageOf course, not knowing fully about how Windows XP's activation works, I didn't want to just make a copy of his XP install CD, in case it was keyed for a Dell laptop. And, just in case, it somehow cut him off. :)
-- Joe
As much as I'd like to believe this, it doesn't hold water.
The truth is (as has been pointed out to me many times by my various managers), if you don't get the product out when marketing needs it, you won't have customers, because somebody else *will* deliver.
Granted, if you're the only maker of the product, you have some lee-way. However, a lot of software and/or hardware products are in a commodity market. Being the first to market with a new feature generally insures sales, despite how well the functionality works.
Unfortunately, the motto in tech seems to be, "Ship first, fix it later".
-- Joe
Ha!
Or, like me, you'll find yourself out of a job because your company couldn't compete because the codebase for the project was so crappy that it couldn't be fixed. As such, your competitors ate your lunch.
Then again, I am glad to not be fixing my co-workers problems anymore. It's a bad sign when during the weekly status meetings the same person, every week, has missed their deadline, and is constantly making excuses for it...
-- Joe
It's been about five years since I've worked at IBM, but I recall at IBM Canada, they were heavily standardized on Token Ring, OS/2 and using their own brand of PC's. The IT people had the job of putting in a 4/16 Token Ring card in every new PC that came into the building. Many of the PC's didn't even have Ethernet cards (they were mostly useless in the building).
If they're still on Token Ring now though, somebody should shoot them. I remember, it used to be fun whenever somebody kicked out their Token Ring connection. Also, as I recall, it was not very fault tolerant... I was running an application that relied on LAN connections, but kicked out the Token Ring by mistake. Not only was their a loud beeping that everybody in the classroom could hear, but the program couldn't re-establish it's connection. It was a pain to go to each machine by hand and grab the test results. Now yes, I realize that it could have been an application problem, but that problem seemed to plague many applications running on the Token Ring network.
Just a rant about my good old times at IBM...
-- Joe
Sorry, the Commodore 64 did have 64K of RAM. It also had (I believe) 20K of ROM (8K BASIC interpreter, 8K kernel ROM and 4K character ROM) mapped in at various addresses. However, the RAM "underneath" the ROMs is available, but only in machine language.
The BASIC interpreter is mapped in at $A000, the character ROM is mapped in at $D000 (I think, I don't quite remember), and the kernel ROM is mapped in at $E000. Due to the way that the VIC-II works, being able to access only 16K at a time, the character ROM is also mapped in at $1000 and $9000, but only the VIC-II sees it this way, the 6510 sees the RAM there.
Now then, to map out the ROM's, you need to play with the MMU, which is at memory location 1. Also, like I said, you have to be in machine language, because using any of these methods, you end up mapping out either the BASIC interpreter, BASIC and the kernel, or all of the ROM's, and if you're in BASIC, unless you've copied the ROM to RAM, you'll crash the machine.
These values will work, although you shouldn't just set them, since they also set some of the Datasette lines as well. Set the MMU (memory location 1) to these values to get the RAM:
$36: Map in the RAM under the BASIC interpreter (8K at $A000)
$35: Map in the RAM under the BASIC interpreter (8k at $A000) and under the kernel (8K at $E000)
$34: All 64K of RAM.
There are other values as well, but I don't remember how they work, as I didn't use them very often.
Note that when you map out the kernel or use all 64K of RAM, you MUST disable interrupts. The 6510, when it receives an interrupt, jumps to the vector pointed at $FFFC ($FFFA for NMI's), and for IRQ, this is $EA31 (I don't remember the NMI). If the CPU does it's JMP($FFFC), and there's garbage there, well, your C64 goes off into
never-never land.
Also when you map in all 64K of memory, you only have about 63K of memory. That's because most of zero page (0-255) is reserved, $100-$200 is the stack (you don't want to mess with that unless you really know what you're doing), and $300 contains some semi-important pointers (file I/O, IRQ, etc.). But from $400 up, you're all clear.
Of interesting note... The game Impossible Mission (by Epyx) used all but 1K of RAM. And yes, I'm a former C64 demo coder, I've set the machine to use all 64K of RAM many times.
-- Joe
Although reverse engineering is generally defined as reversing software's machine code back to the source code, Baystate claims it looked only at Bowers' user interface in order to improve its CAD software product. "There was no evidence of cracking encrypted source code or anything of that nature," said Bob Kann, Baystate's lawyer, of Bromberg and Sunstein, in Boston. "This may cause havoc in the industry. Before this case, it was perfectly legal to evaluate a competitor's product."
andMeeker noted that Baystate had reproduced a handful of errors in Bowers program. Kann, Baystate's lawyer, said all the errors came from Bowers' user interface, not the underlying code.
Unfortunately, the article doesn't specify what types of UI errors really occured, only an allegation that code was copied. It could be something as simple as a couple of menu items misspelled. Without more details, it's hard to comment
Okay, now yes, in your example (which, since I'm not too familar with Windows GDI programming, I do UNIX and vxWorks embedded, I presume adds a handler for a scrollbar up arrow being clicked on), I would be more suspicious.
Personally, I don't have a problem with people copying look and feel. Where I do draw the line is actually copying code from existing products when you do not have the license to do so (copyright violation).
-- JoeNot necessarily.
The company that I used to work for was making a router-type product for the cable internet industry. Seeing as Cisco is considered the industry leader, it was highly desirable to copy the Cisco CLI commands, down to the exact command syntax (where possible).
The reverse engineering in my particular case involved typing in commands at the Cisco CLI, and then looking at either the configuration file, or SNMP MIBs to see the results (which is considered reverse engineering, even though I didn't look at any Cisco code).
Now, suppose I put in a very counter-intuitive command, or even a command which was considered to be "in error" (i.e. confusing syntax, whatever). Would you say that something fishy is going on? We're just trying to keep the interface as similar to Cisco as possible.
The article said that the error looked to be in the UI and not in any underlying code. Of course, the question is, were both programs done in the same language, use the same GUI toolkit, etc? Look and feel alone do not constitute full-blown "code-ripping", as we used to call this years ago.
-- Joe
This isn't surprising (the part about FreeBSD developers on the payroll).
While the core OS itself was written from scratch, a lot of the periphery code (i.e. network stack, device drivers, etc.) come from one of the BSD's (I can't tell which one though, since I haven't bothered to read all of the code). And, judging by some of the dates in the changelog, they haven't been updated in a *long* time.
-- Joe
NT4 did have Plug and Play support, but only for PCI devices under the default installation. There was a way to enable ISA Plug and Play, but it wasn't considered mature enough.
ISA, on the other hand, was a different story. Here's how to enable ISA PnP as part of adding a SoundBlaster PnP card:
NT4 Plug and Play
More NT4 ISA PnP Info
I used this method with no problems on a SoundBlaster AWE64 ISA card. Note though that this was pretty much only for PnP sound cards. Back then for PnP ISA network cards, I just made the card non-PnP, and set it up with manual resources. The reason for this is that it made using Linux easier at that time (back in the 2.0.37 or so days, when I was first experiementing with RedHat).
-- Joe