EricBall

I'm glad that you find Skeleton+ scary. One of my objectives with Skeleton was to build tension via sound effects. Ways to make Skeleton+ scarier: - play in the dark - set the left difficulty switch to A during the game to turn off the Undead Locator and use the sound to hunt / avoid the Skeleton - set the right difficulty switch to A during the game so the Skeleton speed is only reset every level - other difficulty settings

See A 7800 hack request for one tool.

It's a command line application usage: a78sprite filename.a78 filename.ppm

It would be very easy for me (or the other Homebrewers) to prove the opposite since it is clearly stated in the contract and my name is on the title screen.

You can't ground OE, because then the ROM will try to respond to all addresses, even zero page (where the RIOT RAM and TIA registers are). Since OE is almost always low enable, and you want the ROM to be active for only when A12 is high, you need an inverter. Because the original games used masked ROM, they could be created with high OE logic. Almost all bankswitching is based on the program accessing specific addresses (e.g. access 1FF8 to swap in bank 1, access 1FF9 to swap in bank 2). Again, the original games could include this logic into the ROM masks, but homebrews use external logic devices and standard EPROMs. The 6507 uses the address stored at $1FFC/$1FFD (LSB first) on startup (reset vector). Note: any bankswitched game should handle startup from any bank!

Check out the 6532 datasheets at www.6502.org, just remember that the 2600 doesn't use the interrupts. TIM64T sets & starts the timer counting down. INTIM reads out the current value. INTIM might be a random value on system startup, but is typically used by games to start & end VBLANK and VSYNC without counting lines.

Actually, I think it's kinda cool. GCC had some interesting constraints they had to work with, then build workarounds into the MARIA chip. Okay, start with the 2600, really with the 6507 & RIOT. The RIOT only has 128 bytes of RAM, and for the stack to work it has to be mapped to $0180 - $01FF. Zero page uses the same RAM, mapped to $0080 - $00FF; easy to do, just don't connect one of the address lines. This leaves $0000 - $007F for the TIA registers with easy access. Fast forward to the 7800, which has 4K of fast RAM mapped to $1800-$27FF. Built into the MARIA chip is an address decoder which (along with some external logic) has to handle 2600 mode addressing and 7800 modes (ROM & cart). For compatibility & sanity, the TIA registers are still mapped to $0000 - $001F, and the MARIA registers $0020 - $003F, leaving $0040-$00FF for RAM. For simplicity, this gets shadowed to $2040-$20FF, and the stack ($0140-$01FF) to $2140-$21FF (again, only one address line different).

Don't forget the stack page $0140 - $01FF is shadowed at $2140-$21FF and the stack grows bottom up (while ZP tends to be used top down).

For direct sprite, the address pointer in the display list entry points to the first byte of the last line of the sprite (the bottom left corner). (See HoleyDMA & Atari 7800 for basic info on direct sprites and vertical scrolling.) The width is the number of bytes in the sprite. For indirect sprites, the address pointer in the display list entry points to the first byte in the character/tile string and the width is the number bytes in the character/tile string. The address pointer formed by the CHARBASE register * 256 + the byte value from the character/tile string is then used the same way as the address pointer in the direct sprite case.

On the 7800 the screen is broken up into "zones" of 1-16 scanlines (typically 8 or 16), based on the 3 byte DLL header. The DLL header contains a 16 bit address pointer to the display list for the zone. The display list is made up of a sequence of 4 or 5 byte sprite headers ended by a 2 byte null header. Each direct sprite header contains a 16 bit address pointer to the graphics data drawn on the last scanline of the zone. (Indirect sprites, or tiles, are a little different.) Graphics data is laid out "upside down" with the last scanline on the lowest address and each scanline on a separate page. e.g. for a 2 byte x 16 line sprite $e000-$e001 bottom line $e100-$e101 2nd last line ... $ee00-$ee01 2nd line $ef00-$ef01 top line Horizontal motion on the 7800 is easy 'cause each sprite header contains a 1 byte horizontal position (though this means only 160 onscreen positions even in 320 modes). Vertical motion requires a little more work. Assume we are using 16 line sprites and zones. If the sprite is "on grid" then we have the following line 0-15 DLL -> sprite header -> $e000 Now say that the sprite moves down one scanline, then the sprite is overlaps two zones and we need the following line 0-15 DLL -> sprite header -> $e100 line 16-31 DLL -> sprite header -> $d100 Some of this seems counter-intuitive, but remember that the sprite header points to the bottom of the sprite. So the top scanline of the second zone will draw the graphics stored at $d100 + 15*256 = $e000 or the last scanline of the sprite. So the sprite has moved down one scanline. This is also where "Holey DMA" comes into play. In the above example the top scanline of the first zone will draw the graphics stored at $e100 + 15*256 = $f000. In the DLL there are two flags, one which treats odd 4K segment of ROM as full of zeros. So when that flag is set, graphics reads from $dxxx and $fxxx will be treated as zeros. Thus we can store code and non-graphics data in those segments. Now that we know how to handle vertical motion, the next challenge is building that silly display list. (See the mega sprite demo I posted to the Atari 7800 Programming mailing list.)

Mitch is correct. Compiling MESS (for Windows at least) isn't the easiest thing either 'cause it uses bunches of tools and libraries, which seem to change from version to version, from various places. There are also multiple "how to compile MESS for Windows" webpages out there of various vintages. (And, you guessed it, the older instructions are incorrect for the current version.) But once you get the compile working, it isn't too hard to make changes. (Although re-compiling does take some time.) Some logging statements are also commented out, so you want to edit the source (or even add your own logs). You should also know that the logs are no-where close to something like Z26.log (although they can be just as big :-) ), and IIRC only cover some MARIA stuff.

That's sets the 7800 flag / romsize used by the NTSC BIOS digital signature routine. Note: CC2 doesn't handle A78 files (yet), so you will need to move the SEG ROM to just before the ROMTOP ORG to create a bin file. (Which a78sign accepts too.)

Hmm, I see where you got the format from....

I agree with Thomas, any 2600 game idea has to take the limitations of the TIA into account. Although programmers have managed to do more with the 2600 than the designers dreamed, there are still things the 2600 cannot do. (Or would require a very complex cartridge with additional RAM, ROM and logic.) And as the old saying goes "10% inspiration, 90% perspiration".

From Programming the 7800

It's easy to embed this into your code too. SEG ROM HEADER ORG ROMTOP-128 DC.B 1 ; Header version DC.B "ATARI7800" DS 7,32 DC.B "Cart title" DS HEADER+49-.,0 DC.B $00,$00,256->ROMTOP,$00; data length DC.B $00,$00 ; cart type DC.B 1 ; controller 1 type DC.B 1 ; controller 2 type DC.B 0 ; NTSC / PAL ORG HEADER+100 ; DC.B "ACTUAL CART DATA STARTS HERE" ROMTOP ORG $x000 ; code & data here ORG $FF80 DS 120,0 ; 960 bit Rabin Digital Signature DC.W ROMTOP + $07FF NMI DC.W DLLNMI RESET DC.W START IRQ DC.W IRQRTI

Interesting. I'm going to have to look at the source code later. Have you joined the mailing list? Users can subscribe to your list by sending email to [email protected] with 'subscribe' in the Subject field I'm going to be posting a megasprite demo in the next couple of days.

I spent 6+ weeks in the San Jose area a while back, and wandered around Fry's once or twice. But even more interesting was "Weird Stuff" across the street. Lots of obsolete / used / broken computer & electronics.

I bought a bunch of parts from Mouser to build an S-Video A/V 4:1 switch; so I know that they sell the S-Video mini-DIN jacks. The only problem I ran into was my order was too small to ship to Canada, so I had them send it to a US cousin who forwarded it to me.

It's the Interupt Flag register. Bit 7 is the timer flag, which indicates whether the timer has expired. You can find the 6532 (aka RIOT) datasheets at www.6052.org

I have to first say that I haven't spent much time in arcades recently. The one at the local mall closed a year or two ago, and I buy my movies on DVD rather than renting a seat at the theater. But when I do stumble across an arcade I try to at least wander around and see whats new. And, frankly, there is very little which is new. A huge percentage of the games which I see are similar in concept to those I've seen in previous years. In my mind, the main reason that arcades have stagnated is (believe it or not) 3-D graphics. The problem with 3-D graphics is it is very difficult for the game to stray very far from reality. 2-D graphics could be used to create games which had no basis in reality, but 3-D graphics almost require it. There are also the economic chicken & egg / catch-22 issues. Since people aren't pumping quarters into arcade machines (like the 4 suits I remember putting probably $20 each into Gauntlet one lunch hour), arcade owners don't have $$ to risk on new machines, especially unique ones. This then means manufacturers only develop machines which retreat proven formulas. People stop playing arcade machines because they can play the same thing on their PC. Arcade owners raise prices on all machines, again driving customers away. There are still some games and venues which seem to pull in the players and quarters. The Golden Tee golf series does well at bars, and is probably helped by it's distributed leaderboard concept. Theaters and other entertainment venues usually have a few games for people to waste time while waiting. But I just can't see arcades being as big as they once were. Maybe a retro arcade with classic games would pull in people. But they have to pull out of the economic death spiral they are in now.

Total sales of Skeleton and Skeleton+ (Hozer, AA & Packrat VG) are over 100 at last count, though I'm sure Christmas sales will increase that number. (And that's not counting Activision Anthology PC/GBA/Mac either.) And it's kinda neat to think that I could be getting royalties from Skeleton+ for many years to come.

For some reason (probably having to do with fewer transistors required), the "sense" of the carry bit is reversed for ADC and SBC. So ADC with carry set adds one more, but SBC with carry clear subtracts one more. The following instructions affect the carry bit: ADC, SBC, CMP, CPX, CPY (compares set the flags just like SBC with carry set), ASL, LSR, ROL, and ROR. The 6502 doesn't have a NOT instruction (or NEG), use EOR #$FF instead.

The following things change between NTSC and PAL: 1. Number of lines on the screen: NTSC=192-208, PAL=228-240 There are several ways to handle this. Easiest is to code to NTSC screen size and just add blank lines to the top & bottom for PAL. Or you can make the playing area larger, or even try to rescale everything. 2. Refresh rate: NTSC=60 Hz, PAL=50Hz Depending on your game this can effect a lot of things. Period (counter to wait 1 second), velocity and acceleration (move 1 pixel per frame) etc. The easy way out is to ignore it and live with one version being faster/slower than the other. Otherwise you need to make the necessary adjustments and possibly move to fractional arithmetic. 3. Color: For this you simply need to make decisions; a. if it important to have a similar color & b. what color comes closest to what I have now? Just be aware that the PAL palette has fewer colors overall and the order of them is very different than the NTSC palette. There are, of course, colors which appear in one but not the other. 4. Music: There is a slight pitch difference between PAL & NTSC, but the change is relative so each version will sound just as out of tune as the other. 5. SECAM Same as PAL except for the colors & the B&W switch being hardwired to B&W. However, I don't know how big the SECAM market is. I haven't received any requests for a SECAM version of Skeleton+ yet.

RSYNC resets the TIA's internal horizontal position counter. Now, if I assume this resets the counter back 0, the same point that WSYNC releases, this would be before the sync pulse. So hitting RSYNC during horizontal blank would probably generate a double sync pulse which would probably throw the TV for a loop, probably causing it to skip down to the next line or half line. And even if the TV was able to sync properly, it also wouldn't change the object positions since the counters would still put it the same number of clocks after the end of the sync pulse.