DanBoris

Back in they day, I had a few of them break. They are built pretty good, but the part of the plastic core that actually pushes down on the buttons inside the stick tends to break. Dan

Not sure why you would use a 50/50 mixture of water and alcohol. I have worked in electronics and I always clean with pure alchohol, the purer the better. You might want to go back and try cleaning the ones that don't work a little more aggressivly. If the alchohol doesn't work you may want to run over the contact with a pencil eraser, then re-clean with alcohol. It's very rare, at least in my experience, to see a bad cartidge that can't be fixed by just cleaning it. Out of the 1000 or so carts I have for all my classic systems I have only found 2 or 3 that still didn't work after cleaning. Dan

I have this same problem on my system, never was able to find a solution to it, but I have been using Atari800win Plus which is based on the same source as Atari800win, but dosen't exhibit the problem you are having. You can get it here: http://www.a800win.atari-area.prv.pl/ Dan

The 320 pixel modes are more limited in the number of colors per sprite then the the 160 modes, but different sprite on each line can use different colors so you can get a pretty good color mix in 320 modes, but it's not as easy as in the 160 modes. The screen memory isn't a limitation in 320 mode since the 7800 doesn't have any screen memory, except for the line buffer in the MARIA chip. The other limitation to the 320 modes is that you can only position sprites on 2 pixel increments. Dan

Yeah, I love that quote! I personally thing the 7800 hardware was more powerful then the NES hardware. But as we have seen so many times the best technology isn't necessarily the one that becomes successful. Dan

Atari Basic was a very capable language for games, and with the addition of a few assembly routines here and there (called via USRs or interrupts) you can actually make some nice, commercial quality arcade games with it. There where a lot of commercial games written in Atari Basic, and I can personally recal a few good arcade games written in Basic. Atari Basic was actually one of the fastest basics at it's time. Obviously it's not appropriate for all games, and you will always be able to do more with assembly, but don't discount it as a language for writing games.

There has been some discussion of this on the Stella programmers list. With the density of today's FPGA's it should be no problem to put the entire logic of the TIA on one FPGA. It also would probably be fairly easy to put the RIOT chip in the same FPGA since it's a fairly simple chip. As someone mentioned above there is some analog circuitry in the TIA (for the paddles and video output) so these would have to be re-created outside the chip. The hardest part of all this is finding someone with the tools, time, expertise, and desire to do the work. Dan

quote: Originally posted by Cafeman: oh! I never thought of staying in the loop. Are there any negative side-effects to staying in the DLI and not returning control back to the Display List? This really isn't an issue. The ANTIC chip runs the display list entirely indepedant of the processor so you aren't taking control away from the display list. Taking away the CPU cycles isn't a big deal unless you really need them to be doing other things. You have plenty of time during the VBLANK and the non-display areas before and after each frame to do all you other processing. Dan

None that I have seen. A graphics tool would be very useful because of the unusual way graphics data has to be orginized on the 7800. Dan

quote: Originally posted by Cafeman: [QB]oK, thanks. So that reveals one thing about 5200 game coding -- you can't use DLI's for extra colors on a player when using Mode4. Because you can only change the colors every 8 scanlines and it would bad and inconsistent. QB] This isn't actually true. You can change color on every scanline in mode4 but just staying in your DLI routine. You would set a DLI towards the top of the screen, hit a WSYNC to get you to the start of the next line, update the colors for that line, hit another WSYNC to get you to the next line, change colors again, etc. This is how the Atari logo on startup is done, there is only one DLI at the start of that screen but it runs for almost the entire screen. Dan

This is an interesting issue. I see two approaches to doing this. The way you describe is how Robotron does it. With 128 bytes for each DL you can get either 128/4 = 32 or 128/5 = 25 sprites on each line. For most games this isn't a big limitation since each a game like robotron doesn't have more then 50 or so sprites total, you just have to be careful that a situation doesn't come up in the game where you overrun one of the DLs. The advantage to this method is that it is easy to implement in your sprite engine. The disadvantages are that it wastes a lot or RAM since it any one time most of the DL memory area is empty, and the limited number of sprite per line. The second method would be to build the DLs one by one, placing each right after the other in memory. You would go through your sprite list, find each one that appears in the first region and build that DL. You would then repeat the process for the second DL, etc. The advantage to this method is that it takes less memory and you don't have the limitation of how many sprite go on each line. The disadvantage is that the sprite engine would have to be more complex and would take much longer to execute. Also remeber that there is a physical limitation to how many sprites can be on a line. The MARIA chip has a limited amount of time to generate each line. Dan

Also note that there is a plastic ring that actually hold the rubber boot in place. You can remove this easily with a small flat screwdriver. Look at the inside of the top cover, directly above, below and to the left and right on the hole where the stick goes are 4 small rectangular holes. Pushing the screw driver into each of these will unsnap the ring. Dan

Robotron actually uses 16 line high regions on the screen not 8. The sprite data is padded out with extra 0's to make each sprite 16 lines high. The beauty of the 7800 is that you never have to touch this data like you do on the 5200/8-bits. You move the sprite up and down in each region by chaning the pointer to the sprite data in each DL entry. I am not sure how Robotron handles crossing region boundries but it shouldn't be to hard to do: 1. Determine which region the sprite starts in. 2. Write the DL entry into the first region with the memory pointer adjusted to the correct point in the sprite data so the image starts on the correct line. 3. Caluclate if the the sprite spans into a second region. 4. Write the DL entry into the second region with the memory pointer adjusted into the graphics data so it picks up where the first region left off. This sounds more complicated then it really is. Since the display regions should ideally by 8 or 16 lines high the calulation needed above should be quite easy. This is also where Holey DMA comes in, which I admit that I didn't understand until I started thinking about the sprite engine. When you need to move a sprite down in a region it is necessary to point the memory pointer to an address that actually outside the graphics data. Holey DMA causes these reads outside the graphics data to return a 0 instead of garbage graphics. Next thing I need to turn my mind to is how scrolling is done on the 7800, should be fun Dan

There seems to be a little confusion here. According to Atari-History.com, the successor to the 2600 with it's 10-bit processor was called the 3200 (also called at various times Sylvia, Super-Stella, and System-X). The 3600 was the original name for the 7800, and from the documents appearing on the site it appears that only the name changed from 3600 to 7800 and the hardware was identical. Dan

The Tramiels didn't enter the picture until 1984, well into the later part of the 2600's lifetime. Don't really know how much Alcorn was involved with the 2600 design. The two big players in the design of the 2600 hardware where Jay Miner and Joe Decuir. Dan [ 10-23-2001: Message edited by: Dan Boris ]

I might be wrong about that, there may only be two games that used the Pokey. It was an interesting choice for Atari to leave the Pokey out of the 7800. The way the system was designed the PCB is pretty tightly packed with components definitly not enough room for the 40 pin Pokey chip. So to fit in on Atari would have had to make the board, and probably the whole unit a little bigger thus increasing the cost of the system. At that point in time I think the price of the system was a far more sensitive issue then the price of the games, so putting the Pokey on the cart probably made sense. It's also interesting to note that the Pokey 7800 carts don't have any additional components on them for extra RAM or bank switching like a lot of the other 7800 carts have, so the price to make a Pokey cart would probably have been the same as to make any of the other carts with special features. Dan

I haven't heard from anyone who is actively working on programming the 7800 so you would be a pioneer if you got into it. I think the system will be fairly easy to program once someone comes up with a good sprite engine for it. Once that is figured out it will definitly be easier then the 2600 to program and may even be easier then the 5200 especially if you want to have a lot of sprites on the screen at one time. Dan

quote: Originally posted by Atari-Jess: If the 2600 needs a rom why isn't there a 7800 emulator with the rom file built in too? I think there might be some confusion here. The 2600 doesn't have a BIOS ROM like other systems do, but it does require a cartridge ROM image to run. Dan

quote: Originally posted by Atari-Jess: i think its cause it doesn't need a Rom file for it to run...i could be wrong. No, the 2600 does require a ROM to run. The reason there is no 2600 support in MESS is that the 2600 is a VERY hard system to emulate properly. Yes, there is source code for 2600 emulators available, but you can't just plug these into MESS, it take a lot of work to adapt the emulation to the way MESS does things. Someone did start work on a 2600 driver for MESS (I helped them out with this) but I don't think it is very far along. Dan

The 7800 used the same (fairly old) sound chip as the 2600, so the sound was not up to the standards of other systems of that time, or even the 5200 for that matter. There was the option of putting the POKEY sound chip (the one used in the 5200) onto the 7800 carts to get better sound but I think there were only 3 carts that ever did this. Dan

The 5200's pause button was also handled in software not hardware. Since a Pause button was put on the controller, Atari probably encouraged (if not required) the authors of the games to use it. Dan

This was actually a good business choice. Since the AC adaptor is one of the more likely components of the system to fail, by having a propritery connector you can only get them from Atari, thus they get some extra income from selling the replacements. Dan

In the 2600 the main clock goes into the TIA chip and is distributed from there to the other two chips in the system. So cutting the clock to the TIA in theory would freeze the system, and then re-enabling the clock should allow it to re-start exactly where it was. As I mentioned about the display would not remain if you did this. The sound would probably also go off (not leave an annoying tone as someone mentioned above) becasue to get sound you need oscillations of the output and without a clock you wouldn't get the oscillations. The pause key on the 7800 takes the place of the B/W switch in the 2600. For the pause to have any effect on a game (2600 or 7800) the game has to be explicitly programmed to recognize it. Dan

There really isn't a way to add a pause function to the hardware that would also leave the picture on the screen. The processor in the 2600 sends the display data to the TIA line by line, so even if you stopped the processor the display would get messed up. If you didn't care about the display you probably could pause the system by stopping the clock input to the TIA, which in turn provides the clock to the CPU. Dan

No, you can't play 7800 games on a 2600, but you CAN play (most) 2600 games on a 7800. I believe you can use a 2600 controller on a 7800 but you won't have access to the second button the 7800 controllers have. Dan