Viso

This does have a number of difficulties. You have to use more RAM, decide what can and cannot be configured, write much more complex code to figure out what to do with the PSX controller input, debug it, and try to avoid latancy issues. I'm doing this with the adapter I'm working on, and it isn't easy, especially when I can't spend much time on it. On the positive end, I'm also making my adapter so that the firmware can be upgraded by sending new code over an RS-232 serial connection (no physical replacing of anything) and I'm planning on using menus on a common 20x4 alphanumeric LCD for configurability. The bootloader (to upgrade firmware) and LCD menu code work and is availble on my website. So I can see that Clay Cowgill may well have made the better choice by not allowing such configurability. I'm stubborn though.

I think it's a marketing scam. The PS2 Dual Shock I bought for testing seems to be spitting back the same datastream as the PS One version I have. They both send the same number of bits back, and since I know what all those do there doesn't appear to be any pressure sensitivity fields that I can see. Maybe the extra PS2 functions are only enabled by sending a command to the control or something... I'm quite certain you are correct -- a command must be sent to a Dual Shock 2 controller to make it act like a Dual Shock 2 rather than a Dual Shock. This allows complete backwards compatibility. I have been working on a PSX controller adapter for the 2600, 7800, and NES, and I'm seeing the same behavior. I haven't bothered to figure out the command sequence with the help of my PS2 because for the systems I'm targeting I don't see pressure sensitive buttons as useful. Besides, they take a fair amount of practice to use, and even then it is hard to use the pressure sense well. Just go play Gran Turismo 3 and try to moderate your throttle with Sony's Dual Shock 2 controller. They should have allowed the use of the second analog stick for breaking and acceleration in that game, like in Burnout.

I wasn't planning on my adapter gizmo supporting the 5200 mostly because I don't have one. But then, I have never had an NES and I do plan to support it just because it should be easy and I have friends who would like it. I suppose I could be convinced, but I think my adapter will only be able to support one 5200 controller output because of the limited number of I/O pins (there are 33 on the microcontroller, and I found a use for each one). On the 2600, 7800, and NES, I plan to output to both console controller ports. As far as keypads go, I'm planning on supporting the 2600 variety and allowing buttons on the Playstation controller to be configured as keypad buttons. Star Raiders on a single controller! I'm only supporting a keypad in the right controller port so I can take advantage of an interrtupt feature on the microcontroller to detect and respond to keypad scanning. I'm not sure how well the 5200 keypad could be supported in this manner, but I wouldn't be surprised if it worked the same way. Do you know if the analog sticks on the 5200 work like the 2600's paddles (cheap current A/D), or more like old standard analog PC joysticks (voltage A/D)? I'm planning on supporting paddles (not an easy thing to do), but I doubt I can find room to add linear voltage A/D. So do want to convince me my adapter should support the 5200, too? Or should 5200 support wait for the contoller you want to design? What I learn while making the my adapter work will certainly help on other efforts to connect to the Atari consoles, and if the same line of microcontrollers are used (PIC) then even some of the source code I write could be used. Did I answer your question, or manage to miss it?

I've been working onmaking an adapter to connect Playstation controllers to Atari 2600, 7800, and NES (no relation to the recently released 5200 Master Control (I think that is what it is called) device). I'm planning on emulating all the 2600 controller types, and I'm finishing up code for the first emulation tests. Still, it is complex code, so I don't think I'll be connecting it to my 7800 for at least 2 weeks. If this project goes well, I'll be able to help with controller innards from off the self parts. However, I do not have access to any of those CAD gizmos. I wouldn't even know how to use them.

I just tried to get to atari7800.com with Mozilla 1.0 on Linux. The site came up without problems besides some formatting issues. I wonder if slimy007 is having problems with DNS. The GIF images at the top of the delta page that feature a 7800 look like they have been through severe JPEG compression. Of course, if they were JPEG images, they would be a lot smaller.

FYI: PCB stands for Printed Circut Board and is a generic term. Sounds like you're after the innards of a cartridge.

If anyone does port Doom to the 7800, I hope they do a better job with the colors! Else, you'll be playing partially blind.

In the mid eighties, Tangerine Dream used an Atari ST as a musical insturment for several recordings. It was definately not used to just play back digitized audio samples, but such samples could have been involved as they are with MOD files. Of course, that doesn't really answer the original question.

I really liked Burnout -- racing through a city in traffic is a lot more fun when you don't have to worry about death! I found it to be addictive, along with Wipeout 3 (PS1), so I bet Wipeout Fusion is great. I also seem to be one of the few who enjoyed Gungriffion Blaze, Thunderstrike (I have to blow things up occasionally), and Sky Odyessy (I like flight, even without blowing things up). Escape from Monkey Island was a lot of fun for me, too.

Varan, nice tie-in with the avatar! So, in this game, does the player play the role of those liquidy-rock like aliens, whose name I cannot remember, that control the monsters in an attempt to conquer the Earth? Or is the only thing that the game has in common with the movie the name? When I saw the pictures from E3 taken by Digital Press (lined on AtariAge a while back), I really wanted the game because I like Godzilla movies made in Japan (I have 17 on DVD and VHS, and I do laugh at them). But, I got a PS2 over a year ago, and now I'm on such a tight buget, I won't consider getting a Game Cube. I don't know that I would get it over a single game anyway. Still, I do hope it is a good game. I'm not sure I can buy another monster game while another good one exists with Toho's monsters. I also hope the game uses the sounds Toho used in their films and didn't go through any process to make them sound somehow better or different. It'll problably be more fun with some of those old silly B-ish Sci-fi sounds.

Unless I'm mistaken, with the unlikely exception of the RF modulator, there isn't a point in the Atari where there is even 25 volts. Put in your capacitor and see what happens, if you can.

I looked at the AtariAge schematics. They only list the capacitors on the PAL schematics. If the ill system is a PAL system, or if the capacitor designations match up with the NTSC units (my guess is they don't), then the capacitor is in an oscillation circut for the TIA. Without it, there will be no video signal, and since the games sync to the video signal, there will be no game. The schematics claim the capacitor has 820pF of capacitance. Because it is in an oscillation circut, it should be replaced with a capacitor of the same or similar capacitance. It should also be the same kind. ulikemeinoit indicated a tantalum type capacitor. The voltage spec of the capacitor does not matter much; anything above 5v will likely work, and above 15v will surely work. That is true even if the capacitor is used for something else. Of course, all this is made on the assumption of good schematics on AtariAge and that the PAL schematics properly identify C241. I took a look at those schematics, and they look very suspicious. First of all, it looks like the output voltage is listed as +6 volts (looks closer to +&) which is not correct. It should be +5. Secondly, the voltage regulator part is listed as a 7906, which produces -6 volts when connected to common ground and between -8 to -15 or so volts. It could still be connected to act like +6 volts, but the potential difference is still one volt too much. In any case, lack of the capacitor would only cause the voltage regulator to heat up more from voltage fluctuations on the power input (and AC with unregulated AC to DC power supplies). Without the capacitor, the proper voltage should still be output, at least until the voltage regulator overheats. But since these schematics look wrong, that may well be a moot point. A 50 volt capacitor should work, assuming its other aspects, as I mentioned above, are suitable. Also, you don't need a battery operated capacitor. Really.

Actually, monopolies are created by very successful people working within capitalism. However, since monopolies don't have to play by capitalism's primary rule, competition, they operate somewhat outside of capitalism. I resent that corporations with money can get laws passed and regulations made that most people would disagree with, even in a democracy. Maybe when Hollywood starts telling these people what they can and cannot do with their home computers they'll stop being apathetic about it (most are, anyway, think Mr & Mrs Average; people reading this are likely not so apathetic on the issue, if apathetic at all). So that is why I hate Microsoft. But that might not stop me from buying an X Box. MS makes something like $10 +/-$5 per game. They were losing money on each console sold before they dropped the price, so now they're losing $100 more. So, I wouldn't mind buying an X Box. I'll wait till I know I can run Linux on it and probably won't buy any games for it. Meanwhile, Sony and Nintendo are making a small profit on each console, even after the lateset price drop. They used enough proprietary hardware in their consoles that they can redesign them for cheaper manufacturing. There are fewer components in a PS2 bought now as compared to one bought a year ago. MS will have quite a bit of trouble getting Intel and NVidia to put the CPU and GPU on the same chip, so the cost of manufacturing an X Box isn't declining as fast as the cost for the PS2 and GC. Of course, MS has $40 billion plus in cash, so losing all this money isn't really going to hurt them much.

So, you were going to include all the 5200 & 7800 hardware just so your system could run the old games? That is silly. You should use a fast enough processor so that you can emulate the Atari consoles. There may also be some address space overlap between the 5200 and 7800, so if the various chips from those systems were used, they'd also need to be dynamically disconnected from the data bus to prevent two things from using the same address space. As for using microcontrollers to emulate the 2600, it would take a high-end microcontroller to run emulation in real-time. Most microcontrollers don't have enough performance. Also, the 6502 is not a Motorola invention, but it was made by ex-Motorola engeneers.

That makes it look like the old Atari Force now plays football (soccer, whatever)!

Sure, but I can't imagine that being horribly difficult. I'm about to start implementing this kind of emulation, except that the output is going to an Atari 2600 / 7800. The biggest problem is the timing, but I already know how I'm going to deal with that. I can't see why it would mess the system up, especially if the game software is given free reign over the system, which is still common on modern consoles. If game software cannot have free reign, then more care will be needed in the design of the OS and its API's. You may wish to consider using parts of, or even a whole, Open Source OS on the system rather than make an entirely new OS. It'll still take a fair amount of work to get running on the new hardware, but the result will be a more mature OS with support for a good number of goodies, like TCP/IP and ethernet, and lots of useful tools will be a compile away. There are some versions of Linux for embedded systems that might work well. Of course, these typically don't support a GUI, but that may be prefered for your system. That said, you'll need to maintain a workable balance between complexity, capability, and cost. If you run an OS with a game, the system will likely need more RAM. To run an OS at all it will help to have something a good amount faster than the CPU's in any Atari system. The faster CPU will help run software written in C, so that will also help on the ease of coding issue. If you go with a nice OS, having more than 16-bits of address space for an 8-bit bus may become a nessecity. Going to a 16-bit bus doubles the amount of addressable data, but 128Kb may still be limiting. Bank switching could make it difficult for the OS to run programs, unless the OS just runs a program at a time and provides API's the rest of the time, like DOS. I don't know how much complexity or cost you are willing to deal with or what ideas you have come up with, so the following might not be useful. I just checked out DigiKey. They sell 33MHz 386DX's for under $14, and 33MHz 486GX's (I don't know what a GX is) for $33. Those might make for a nice CPU in your system. There may be other processors that will work better, though, but these will provide the performance you're looking for and some more. You might need to write the 6502, 6507, TIA, POKEY, etc... emulators in assembly, though. Structure it right and you can use that code in the creation of an NES emulator. Cool! Sounds interesting and fun! I have to admit I haven't messed with robotics, just PIC microcontrollers and digital logic chips mostly. Still, they can do plenty, they just can't move.

From what I understand, Kale has half of the frying explination. The other half is that, without a circut known as a brown-out reset, a CPU running on some, but too low a voltage, acts like it is on drugs. So, while the memory isn't able to properly maintain its contents, the CPU keeps trying to run the program. The important part here is that the program doesn't start running from the begining after proper power is restored. If that happened, no frying effect would occur.

Sounds like it could be an exciting project. I'd say that if you're looking for more than compatibility with the older systems, you should think about doing the following: * Providing video memory to cover the full screen and maybe some extra for buffered graphics. Makes programming easier. * Support for the full TV resolution and some lower resolution modes. This should allow for some very nice graphics or for graphics that that have the look of an older system. * Support for digitized sound samples to be played back as instruments, like the old mod file. The Amiga has a chip that plays mod files directly. * A processor that can support games written in C. This goes a long way to providing the ease of programming Kale mentioned. C libraries to use the hardware will be needed at some point, too. * Support for loading new game software, and maybe even the Atari game software, without a cartridge. Using ethernet would work well for those of us with computers, and that can be done with low-end processors. * If using ethernet as mentioned above, allow new games access to the TCP stack, or at least the ethernet hardware (in which case the games could provide their own stack). * Support for a generally availble controller for another modern game console rather than requiring the use of old controllers or controllers that are specific to this system. I recommend Playstation controllers -- they're pretty easy to use. BTW: While Kale is a software person, I'm a software person that tinkers with electronics. I've been playing with PIC microcontrollers lately and I have one reading data out of a Playstation controller and putting the results on an alphanumeric LCD. This is part of what I've been doing for fun over the past month or so.

You in fact cannot save stuff from a PS1 game onto a PS2 memory card, unless the PS1 game included specific support for this. I think it is technically possible for a PS1 game to support the PS2 cards (I've been working with related technical details lately), but I haven't seen any do this. Also, while you can use PS1 controllers on the PS2, some PS2 games may have trouble with it. Others won't care.

First of all, all the consoles meet criterion 1. Second of all, criterion 2 is subjective, and it is possible for any of the consoles to meet it, too. So, go to some place like Electronics Boutique and browse the games for all the systems. Or find some web site and browse there. Find some nice shooting games you think you'd enjoy, and buy the system with the best ones. As for unusual aspects outside the criteria: GC uses proprietary disks. In the distant future when people are doing hobbyist development on what are now the latest systems, the GC will be left out. The X Box will have online games run on a Microsoft operated service. Because the way it is handled, some game companies are reluctant to produce online titles for the X Box, like Electronic Arts. In contrast, Nintendo and Sony are letting the game companies do as they please. The PS2 has some hobbyist development for it now. Sony relesed a Linux kit for their console. Although the kit doesn't quite meet criterion 1, it has already attracted many developers to spend their free time developing software for the PS2. Probably better for real-time strategy games than shooting games.

That particlar time is rather important for some reason. To this day, just about any computer system that records time stamps in the form of seconds or milliseconds since some specific date use midnight, Jan 1 1970 as the specific date. This method of dating is common in file systems, clocks, etc... You can find it on all forms of Unix, as well as Mac, OS/2, and Windows. Because of this, a number of computer systems (but not all software running on such systems) lacked a year 2000 date problem, with the exception of a lot of hardware based RTC's. For instance, counting in seconds using a 32-bit unsigned integer, the date won't overflow until sometime in Feb 2106.

I'm a bit confused about the speed of the 6507. Lots of places list it as 1.19MHz like that is its clock speed, but programming documentation I have seen suggests it is really 1.19 MIPS, which would likely mean a higher clock rate. Otherwise, it would be running one instruction per clock cycle, and I don't think the 6507 can manage that. Clock speeds aren't everything. The PS2 isn't terribly far behind in graphics performance and it is clocked at only 300MHz. But the PS2 does a lot of processing in parallel. More than any other device found in the home, except for brains (pets' or humans'). 32-bit color may be 24-bit color with an 8-bit alpha channel or some pallete thing. 24-bit color allows for 16,777,216 different colors and is generally accepted to cover about the whole range of human color perception. WARNING: I mean for my tone in this message to be informative, not flaming. I'm not getting mad, I'm just putting forth my thoughs and observations. The words might be read to sound otherwise, but to do so is to violate my rights on this intellectual property and I'll send my lawyers to beat you up!! Now, back to the topic . . . :-) The more complex the program, the greater the possibility for bugs. Game software is fairly complex, and I'm surprised that more games don't crash. I'm not limiting that statement to the X Box. The X Box should have a lot less trouble than Windows because there will be less updating to the system. I also imagine that the games come with all the code they use -- quite common elsewhere on game consoles. This should go a long way to eliminating trouble caused by having multiple versions of some code, like Windows DLL hell. Although Microsoft hasn't been making the greatest quality software, so there is still plenty of room to make a mistake or ten. As for the "bad coding" in programs you mentioned, who decides that? A bunch of falible people trying to figure out if there is any posible condition, of which there are *plenty*, that will cause trouble. Console game software has done remarkably well here, especially compared to computer software. But with hard drives and internet access comes the ability to dynamically and periodically send new code to a console. Some developers might get lazy with quality control with this upcomming ability. Of course, that won't just affect the X Box. In any case, what I'm saying here is that there is a posibility of one that the X Box (and PS2, and GC, etc) can crash. To say that there is a simple condition that if always met would always ensure that the system would not crash is like saying some particular boat will never sink. And even if the console itself doesn't really crash doesn't mean that the game software will screw up and become unusable until after a reset (or reboot, if you want to call it that). My used copy of Burnout for my PS2 does this occasionally. Now for the disclaimer: I am a software developer, so I am familiar with the process of making software, the mistakes that can occur, and with crashing in general. I have not used an X Box and have not heard anything about it crashing outside of early demo units in stores. My brother just got one (less than 12 hours ago) so I suppose I'll be hearing in the next week or two if the X Box crashes.

I'm willing to make a little extra money adding the S-video modification, but I lack the soldering skill to make connections to the PCB. I spent an hour making the circut that can add S-video out to an Atari 2600 or 7800 (not a difficult thing to make, I'm just not fast at it), and I couldn't connect it to the system. Bother.

Ah, Ninja Golf. A great game. A couple friends of mine think it is insane -- probably has something to do with why I like it. Once you've played golf this way, you'll see Tiger Woods as a sissy.

So you mean a thing that runs a 2600 game and allows Java code to interact with the game? I suppose that could be done, but it wouldn't be easy at all. Also, the Java code that interacts with the game would likely have to be written with intimate knowledge of how the game works. This way, it could alter the right data in the 2600's memory at the proper time. It might be better to re-write the game. Then the game could be made with things like extensible objects and interfaces that would allow the game to be altered without intimate knowledge of all its internal workings and could eventually be done like a scripting language. As for amish behavior, remember all the modern things used daily (digital clocks, VCR's, microwaves, cars (electronic controlled fuel injection)) that work because of microcontrollers. Some with less processing power than the 2600. To make a game with the 2600 seems to be an exercise in doing more with less. I'm always impressed by people who can succeed doing more with less. MS makes a huge database with their software and runs it on 120 some PCs in 6 months. IBM implements the same database in a week on 10 PCs. Pontiac (?) makes some car with a 2.5L V6 engine that produces a maximum of no more than 160HP. Honda makes a 2.0L I4 engine that can do 240HP. The first is ok, the second is impressive.