EricBall

Thanks, that was the info I was looking for.

Unlike the TIA in the 2600, the 7800 MARIA handles the number of lines per frame. There are also differences between NTSC and PAL video beyond the 60Hz/50Hz frame rate.

Which TIA cycle does the 6507 write cycle "complete" on? The last third, I think, right?

FYI, the 6502C in the 7800 runs 50% faster than the 6507 in the 2600 (1/2 colorburst, 1.78MHz vs 1/3 colorburst, 1.19MHz), but it drops back to 1.19MHz when accessing the TIA (which the 7800 uses for sound & paddles/buttons and 2600 compatibility mode).

http://www.6502.org/tutorials/6502opcodes.htm Bonus question, how many cycles does the following require? ldy #1 lda $00FF,y

Are you sure? Unlike the TIA, there are no transistor level schematics available for the 6502. So any VHDL (the programming language for FPGAs) has to be based on functional documentation. And any transistor optimizations may be different becuase FPGAs are not simple NMOS devices.

I've seen a document somewhere on the 'net done by some C64 programmers that attempted to document the behaviour of all the undocumented instructions. They were largely successful, but in some cases undocumented instructions can cause multiple sources to drive the same bus, which can cause unpredictable results due to manufacturing differences. I agree with you there. But note I specified MacStella, not Stella or StellaX. The problem is with that emulator only. (Not to say that all emulators are able to emulate all undocumented instructions either.) As for VCS on a chip, it has a transistor budget too. And since it doesn't contain a transistor level copy of the 6507, each instruction (documented or not) has to be "programmed" individually. My observation about some games not working on some VCS is meant to indicate that even with "identical" hardware, micro differences can and do exist which may have a much larger impact. Goodness, what a discussion for what is supposed to be a beginner tutorial.

Sorry if I went off on a bit of a rant back there. I agree with Thomas for the most part. Undocumented opcodes like NOP ZP and LAX should be okay to use for the most part, but there are others with far less predictable results (and typically less usefullness) which should probably be avoided. But on the other hand, apparently MacStella doesn't handle undocumented opcodes. And who knows what the VCS on a chip will and will not do. And as for all 2600s being the same, there are still occasional reports of problems with various games on certain 2600s.

Although Pitfall Harry has done an exceptional job explaining how SLEEP 2n+1 and NOP 0 work, I have to disagree with his statement that NOP 0 is merely undocumented through some kind of oversight. Let me explain. Back when the 6502 was designed (although I wasn't there, I do have a BASc in Computer Engineering), the team first came up with a list of instructions / capabilities they wanted their microprocessor to have. This wish list would have been whittled down (or beefed up) depending on the transistor "budget" they had to work with. But one of the important things that was done was to arrange the instructions into patterns so bits (or combinations of bits) in the opcode could be used to select registers, addressing mode and instruction type. This simplification reduced the number of transistors; a very good thing. But this also meant that the effect some of the undefined opcodes could be defined by inference. So opcode $04 is effectively NOP ZP, a two byte instruction requiring three cycles and not changing any registers, including the status register. There are more bizzare opcodes like $A7 (aka LAX ZP), which loads both the A and X registers simultaneously from zero page memory. And some simply crash the processor. However, because these instructions are not documented, the chip maker was under no obligation to ensure they worked, no matter how useful they were. This was particularly true for later revisions or enhancements. It was common for a chip maker, or cloners trying to add value, to add new instructions to later versions by using those "unused" opcodes. Personally, although NOP ZP does waste 3 cycles, there are other documented 2 byte instructions which accomplish the same thing (especially on the 2600), so I will use them instead.

I belive the Pitfall 2 chip was made like most of the other bankswitched games: with the control logic included as part of the masked ROM. So you can't re-use a Pitfall 2 chip, since there is no way to modify the ROM parts of the chip or reuse the control logic. However, there is no reason that you couldn't put the logic (documented in the patent) into a modern FPGA, and put that into a cartridge along with the code and graphics EPROMs. (See the Cuttle Cart for an example of what an FPGA can do & cost.) Patent #4,644,495 is an interesting read. However, some features almost require a disassembly of Pitfall 2 to understand how to use them. But my guess is, other than the sound oscillators, the features are only applicable to some games and would be useless in most cases. Supercharger games are an untapped market too.

Just for the heck of it, I put together the following tool. You feed it an a78 binary and it will create a PPM file. It assumes a 2 bit per pixel mode. Each page starts a new row, so each row is 1024 pixels wide. I used IrfanView to vertically flip the PPM and turn it into the attached GIF. Remember that the 7800 has 8 palettes. Source is included. a78sprite.zip

The 7800 is fairly easy to understand: everything is a sprite. The MARIA GPU has 25 colour registers (8 palettes of three 8 bit colors plus background) and 7 other registers (not including the TIA/RIOT registers shared with the 2600). (I'm going to use my own terms for this explanation for ease of understanding.) The MARIA processes a list of zone headers pointed to by two registers (pointer MSB & LSB). Each zone header contains a pointer to a list of sprite headers and the number of lines in the zone. There are two kinds of sprite headers: indirect (or tile) headers, and direct (or graphics) headers. Both sprite headers contain a pointer, a horizontal position, and a width. For direct sprites, the MARIA simply copies the number of bytes given pointed to by the header into the current line buffer. For indirect sprites, the bytes pointed to are tile numbers. From a program perspective, it boils down to a lot of data movement to build the list of sprite headers. I've included the source code for my demos in other posts for those who are interested.

To develop asymetrical playfields, I set up a simple spreadsheet, with each row representing one CPU cycle. I can then put cycle numbers in one column, PF changes in the second, and the instructions in another. My recommendation is to make sure the last CPU cycle of a PF update is either before or after the PF is active. Tighter timing may be possible, but would need to be tested on actual hardware.

And then there's this one I did:

The 6507 used in the 2600 doesn't have the NMI or IRQ pins, which trigger these interrupts on a normal 6502. The 6502C used in the 7800 does have these pins. The MARIA graphics processor can trigger an NMI interrupt (to allow the game a chace to change the MARIA registers mid-screen) and the IRQ pin is connected to the cartridge port (don't know if any games used it). But we're talking about the 2600. Although the 6507 doesn't have NMI or IRQ pins, it's good programming practice to have those vectors point somewhere, either the same as RESET or an RTI instruction. (And to include an SEI instruction in your initialization section.) That way if the 6507 flakes out it won't crash horribly. While we're on the topic, you should also reserve $FFF8 & $FFF9 in any 2K or 4K games to make them compatible with the Supercharger. Stick in a version code or your initials in ASCII. I'm still not 100% certain about what the correct timing of VSYNC / WSYNC is msyelf. And, unfortunately, I don't have a oscilliscope to check it out. Maybe I could brute force it with test programs on the SuperCharger. Re: VBLANK, see my replies over in Session 13 for more info, but basically there is no required relationship.

The Atari 7800 Software Guide is the place to start. Just be aware that each line of the sprites are stored on a separate page, with the bottom on the lowest page. Sprites will typically be stored on even 4K segments. Most 7800 games use 160A mode, with each byte being four four color pixels. Most of the other graphics modes are very strange and may be difficult to modify.

The bin can be obtained from http://www.atariage.com/software_page.html...areLabelID=2381 Just a note, toggling the undead locator on & off was in the original Skeleton too.

The best way to make your idea a reality is to code it yourself. Really, it isn't that hard, you will need the following: Atari 7800 Software Guide Atari 7800 ROM signature key generator (a78sign) DASM MESS time

The one disadvantage of a snipebot is you lose the element of control. Sometimes multiple auctions for similar/same items come due at the same time. (Why do wholesalers create 10 auctions for the same item all ending within 10 minutes of each other?) If I manually snipe, I can find out whether I won or not and then snipe the next one if I lost. If you think about it, bidding using a snipebot is the same as bidding during the auction. You are simply providing a maximum bid. eBay still determines the final price. The difference with a snipebot is your maximum bid is "hidden" which means the current price doesn't change. You also don't have an opportunity to change your maximum bid. But the rules are still the same. Your maximum bid should represent the most you are willing to pay for the item. Last night an auction I was watching was closing after midnight local time. So I placed my maximum bid and eBay informed me that the current price was now more than my maximum. Did I increase my bid? No, I had already bid my maximum. Did I curse and swear when I saw this morning that the price went no higher? No, I had already bid my maximum. I also knew that there were two more auctions for the same item ending in the next few days, and probably more after that. Even CtCW and CCs appear on eBay more than once a century. One-of-a-kind items (even Ghosts in Jars) simply don't exist on eBay. Those kind of things sell on Sotheby's.

Just to wrap this topic up. The general consensus on the Stella mailing list was it was okay (with most people) to use it also for 7800 programming topics, as long as this is indicated in the subject. (I recommend starting the subject with MARIA since the biglist search engine doesn't handle numerics.) The assumption is the volume will be low enough not to be a big problem. Plus it might encourage some of the existing 2600 homebrewers to give the 7800 a try. On a personal note, I'm going to put my 7800 programming on hold until I get my Lode Runner style game done. I just don't have enough time to do both and I don't want to let Leprechaun sit partially completed while I play with the 7800.

You might be able to physically put it in, but since the 2600 cartridge bus is only address & data lines, there wouldn't be anywhere for the audio to go unless the cart also had a small amplifier and a jack for external speakers/headphones. The 7800 cartridge bus has an audio in connection, which makes POKEY enhanced carts possible.

Whoops, missed the Vdd input and the CLK max. In that case you are correct. But, any memory-mapped sound generator with TTL level analog output should be okay.

Check out the 7800 schematics in the AtariAge archives. It looks like most of the signals are audio & video outputs with some input overrides. No data or address bus or other I/O lines.

Sure, stick a SID (6582) in a 7800 cart. I don't see any reason you couldn't.

Yes and no. It is a good idea to display black during the vertical blanking interval, but how you accomplish this depends on your kernel. It may be just as easy to clear the graphics registers or the color registers. Even if you use VBLANK to display black, you often need to clear the other registers so nothing is displayed at the top of the frame when you turn VBLANK off.