Jump to content

DanBoris

Members
  • Posts

    1,164
  • Joined

  • Last visited

Everything posted by DanBoris

  1. The build it TIA sound chip gives 2 voices, and a POKEY chip could be added to carts which gave an additional 4 voices. quote: Originally posted by -^Cro§Bow^-: Don't forget that while the 7800 could handle lots of sprites...it is also still a scanline renderer like the 2600. It is a scanline renderer, BUT unlike the 2600 the graphics hardware does all the work, not the processor. There is no solid answer to how many sprites the 7800 can handle. Put simply, for each scanline on the screen that graphics chip reads a list of "objects" that appear on that line and copies thier graphics data from memory to a scanline buffer, which will be displayed on the next scanline. So the graphics chip has the duration of one scanline to copy data from memory to the buffer, that's the only real limitation on how many objects (sprites) can appear on each line. Dan
  2. Since Atari's problem was never really with the technology, but with marketing, mis-management, etc., they probably would have killed the NES. I doubt the NES would have become as succesful as it did if Atari had, had it's hands in it. Dan
  3. Unlike the 5200, the 7800 does NOT have a vertical blank interrupt. A way around this is to put a single line region at the very end of your display list and set a Display List Interrupt on that line. This way you will get an NMI to the processor at the end of the display list. Dan
  4. If you haven't already, be sure to check out the Programming message board here at Atari Age. There are a couple people there working on 5200 games and we have some pretty active discussions on the topic. Dan
  5. This may have just been a typo, since you seem to have the idea: cmp joy_down should have beeb cmp #joy_down Dan
  6. quote: Originally posted by AtariDude: Assuming that someone could get a program to work with an emulator, would that program work on a real Atari 2600 / 7800 machine, assuming that the bin file could be converted to a real game cartridge? Star Fire obviously works because it's been tested, but in general the answer to this question is not necessarily. Just because a game runs on an emulator doesn't mean it will run properly on the real hardware. Dan
  7. Since we are talking about Synapse games how about Protector (I and II), Fort Apocalypse, Shaums and Zepplin, all great games! Dan
  8. SPOT0 equ $11 and SPOT0 = $11 are just two ways of doing the same thing, they both work the same way. org $19 tempLow ds 1 tempHigh ds 1 Here's how this works. DS stands for Declare Space, and normally has a suffix with the variable size, for example DS.B for bytes. Since there is no suffix it defaults to byte. When the assembler hits org $19 it sets it's internal address counter to $19. When it hits the next line it allocates one byte at address $19, and points tempLow to it. The third line allocates another byte, this time at address $1A and point tempHigh to that. SEG.U variables sets the name of the current segment. For the most part this command doesn't do much, but the important part is the .U which means Uninitialized. In the third example above, if you didn't use the .U, the assembler would write bytes to the output file for each DS command which is really undesirable since your finished binary should only represent ROM code. FCB2 is a piece of code in the BIOS: FCB2: pla ; FCB3: tay ;Restore Y FCB4: pla ; FCB5: tax ;Restore X FCB6: pla ;Restore A FCB7: rti ; Just restores the registers and exits the interrupt. Dan [ 12-26-2001: Message edited by: Dan Boris ]
  9. Yeah, to check for a single bit you would want to use the AND statement. So to check if bit 1 is set you would do this: LDA P2PLCOL AND #$02 BNE COLLIDE 'Branch if the bit is set Dan
  10. It also appears that Atari had intended to put internal speakers in the original 2600. You can see the round area for them in the case top along with slots in the circular area for the sound to get out. The TIA chip in the 2600 does have two sound channel outputs so they could have done stereo. Dan
  11. The graphic capabilities of the G7000 are far more limited then the 2600. One of the biggest problems with the G7000 graphically is that other then the 4, 8x8 sprites there are no other graphics objects for which you have full control of the shape. The backgrounds are created by a grid where you can turn each segment on and off, the all the character based objects come from a fixed character set built into the system. This limitation was an especially big problem when trying to do ports of arcade titles. On the plus side the display is much easier to handle then on the 2600 so the processor has much more time to do other stuff. The system has 128 bytes of external RAM just like the 2600, but it also has an additional 64 bytes of RAM inside the processor. Dan
  12. quote: Originally posted by Ze_ro: 3. For the plug-in ROM... what exactly is this? I remember seeing somewhere about a guy who tried soldering in a Combat rom, and as a consequence, he could only play Combat (though he no longer needed a cartridge). Is that what this ROM is? (Damn! The trackball is complicated!) --Zero This has always been an intersting point of discussion. I believe Atari had originally planned to make the 2600 with a built in game (probably Combat). As you pointed out putting a ROM chip in that slot will work. The odd thing is there is no way of switching between the internal ROM and the cart slot, so if a game was going to be built into the unit it's unclear how that switching would have been done. Dan
  13. There are so many, but my favorite was probably MULE. I remeber playing this with three friends, boy did we have a blast! For solo games, I would go with Ultima 4, spent a LOT of hours playing that one. Dan
  14. I wouldn't put the game calculations in the vblank since these can be done anytime. Just leave the hardware oriented stuff in the VBLANK. Dan
  15. waitvb: Just to clarify, waitvb in my code waits for the START of VBLANK. I do this by waiting for the low byte of the software timer to role over. VBI sequence: When a vertical blank interrupt occurs, a jump is made to the immediate VBI vector at $202. By default the BIOS immediate VBI does a couple things: 1. updates the RTC and attract timers 2. if the critical code flag is set, exit from the interrupt 3. update the shadow registers 4. Jump to the deffered VBI vector at $204 By default the deffered VBI does nothing, so this is where your VBI handler should be. Collision handling: As the screen is being painted by the GTIA chip, the graphics data from each player and playfield color are being checked against each other, and if a collision is detected it's immediatly latched into one of the collision registers. So a collision isn't actually registered until the moment a P/M is actually displayed on the screen. If the the P/M is at the bottom of the screen, and you check for a collision at the top of the screen, you will never see it. Also note that the collision bits will continue to accumulate until your clear them with HITCLR. So, the best way of checking collisions is, at the end of VBLANK, hit HITCLR so the collision registers are clear. Then at the start (or somewhere in the middle) of the next VBLANK, look for the collision. The HITCLR need to occur AFTER you read the collision registers, but BEFORE the next screen starts getting painted. Dan
  16. This would be very difficult, if not impossible to do. First off on the 6502 there is no way to "translate memory calls", short of scanning the code at startup and changing all the addresses. Even this would be difficult since the only place you could point memory writes is to a RAM location, which would be a problem since a lot of writes (to the TIA for example) need to trigger things to happen immediatly. You would also have to translate all the jump addresses in the 2600 program since you probably wouldn't be able to load the cartridge data at the exact same memory location that it would appear at on the 2600. Sound would be another problem. The POKEY chip in an Atari 800 is probably close enough to the TIA where you could easily translate from one to the other, but on a machine like the c-64 you would still have to emulate the TIA which would take a lot of time. Finally, as someone pointed out, the processor emulation is not a huge part of the total execution time. Sound and video emulation eat up a lot processor time. Dan
  17. I like this thread from 1992 about writing an Atari 2600 emulator: Atari 2600 Emulator Thread and I especially like this quote from the thread: "Once this emulator is written, then what? Is this going to be an underground thing, where people illegally copy the code stored on the carts and pass it around to people with the emulator who can run the games?" Nah! That would never happen
  18. If you want to know how durable 2600 carts are check out this: http://www.videogames.org/html/2600Stuff/Durability
  19. "ACTUAL CART DATA STARTS HERE" isn't part of the orignal cart data, it's part of a special header that I developed when I wrote my Atari 7800 emulator. I wanted something in the header that made it clear where the header ended. Dan
  20. The pause button on the 7800 doesn't really pause anything, it's just a switch that the processor can read. It's up to each game to read the switch and pause the game when it's pressed. As someone mentioned this is the same switch as the B/W switch on the 2600. So 2600 games interpret this as a B/W switch instead of a pause switch. Dan
  21. There was also Maria, the name of the graphics chip in the 7800. Dan
  22. The only Absolute game I have (F18 Hornet) doesn't have this chip. How big is the chip, how many pins can you see? If you see 12 or 14 pins on one side of the chip then it may be an extra ROM or RAM chip. If it has less the 12 it may be a logic chip to control bank switching. Dan
  23. I can discredit this pretty easily, here is the reply I posted to the message: "I don't think this proves it's fake, there are a number of 7800 games that have ascii text in the cart data, Ace of Aces and Alien Brigade to name just two. I assume that when the 7800 programmers developed a character set it just made sense for the characters to be in Ascii. Also, the encryption wouldn't have anything to do with text being viewable or not, since the encryption doesn't change the cart data, it just appends a key to the end of it." Also, I just noticed, if you look at the release version of Asteroids the text "TOO CLOSE GCC© 1984" still appears at the end of the rom, just the first part is chopped off. Dan [ 12-03-2001: Message edited by: Dan Boris ]
  24. The only statements that the author (I assume that's who it is) makes about the game in this thread is that the resolution is 80x48 and the Player-missiles are not used for the weapon that appears in one of the pictures. The 80x48 res confused me for a minute since there isn't an 80x48 mode on the 8-bit. What I bet they are doing is using a higher resolution mode (maybe one of the GTIA modes) but only using 80x48 of it to display the game. With a screen that small rendering the 3D display wouldn't be to hard. Dan
×
×
  • Create New...