EricBall

I agree John, there is a lack of verified info for the 7800 out there. Maybe we can come up with a revised version of the 7800 Software Guide and fix some of the errors. Up to this point I've only played around with basic 160 mode, so I haven't had to deal with some of the quirks of the 320 modes yet. As for problems with MESS, I believe Dan Boris is the primary programmer, but I'm sure he would appreciate help instead of suggestions. A MARIA mailing list sounds like an idea, but I don't think I'm up to being the moderator. One benefit of a homebrew community is exactly that: sharing experience & knowledge.

Here are some links to 7800 programming resources: http://atarihq.com/danb/a7800.shtml Atari 7800 ROM signature key generator (a78sign) Atari 7800 Software Guide Source code for the NTSC BIOS, sprite demo & Robotron V7800 emulator http://www.whimsey.com/atari_docs Atari 7800 Development Kit Documents Atari 7800 Software Guide http://home.arcor.de/estolberg Atari 7800 ROM signature key generator (a78sign) http://www.atari7800.org Atari 7800 Development Kit Documents

One of the grand challenges with many DOS games was figuring out what CONFIG.SYS and AUTOEXEC.BAT entries were required to get enough free RAM while still loading all of the sound and other drivers. This became even more challenging with later versions of DOS used more RAM themselves. When I was archiving all of my floppies to CDR, I tried to play a couple of games and had to give up because I couldn't remember all of the tricks I used to use. And I thought to myself "This used to be part of the fun?"

I would love to see a homebrew community for the 7800. Now that I've done some playing around with the 7800, I think it has great potential. The MARIA GPU is fairly powerful, but relatively simple. And unlike the 2600, there is no need for tricky cycle counting. CPU and GPU time are still at a premium, so efficiency is more the rule. Consider the capabilities of the MARIA GPU: - palette of 25 colors out of 256 possible, most sprites use 3 colors (+transparent) but higher color sprite modes exist. - up to 30 sprites per line (but everything is a sprite, including background & bullets) - tile/character sprites (indirect addressing) - variable sprite width MESS provides decent (though not perfect) emulation; the crypto signature can now be added For those people with some programming experience, 6502 assembly is a declarative language like Basic or Pascal or C, just with much simpler operations. Try to find some online references and tutorials (http://www.6502.org is a good place to start) and start learning.

Who here is interested in programming the 7800? (And has the time & drive to actually create something.)

Just as an example, the maze in Skeleton+ is drawn using playfield graphics. In Pitfall, the playfield is used to draw the trees and the lakes (and probably more). Once you start programming, you will look at games in a whole new way and wonder "how did they do that?". And you may even be able to figure it out.

Heaven: The source is in the ZIP file. Not much in the way of comments though. Chad: Thanks, I had started to puzzle it out from the schematics. It's surprising the amount of random logic on the 7800.

Just my C$0.03 Although Andrew's code is an optimal way to clear all of zero page RAM & TIA registers, in my experience is it's not always necessary to clear all of the TIA registers & RAM. The code will often set the TIA registers to different values or set them at specific times. Variables (RAM) get initialized to non-zero values, or calculated as required.

Unfortunately, the timing list has "Indirect/2 byte 9 cycles" and "character map access 3 cycles". So the question was whether the indirect time included the character map access. Based on this demo and my cloud demo, I believe it does. Now, does anyone have documentation on how INPTCTRL works? I guess I could look at the MESS source or the wiring schematics.

A test program confirmed Eckhard's memory, only the graphics data is affected by holey DMA, not the character map. (This is effect is also shown in the V7800 and MESS emulators.)

Okay, I've reworked the demo so it uses less cycles to display the digits. The digits can also be turned off by setting the P1 difficulty switch to A. The one good thing about this is it has given me some hints about MARIA cycle counts. The following is a rough guide: 2 cycles / RAM byte, 3 cycles / ROM byte, approx 400 cycles available per line. Unfortunately, this means my clouds demo will remain a demo since there is no time left to display any other sprites. Sigh. colorgrid.zip

The three major differences between NTSC & PAL/SECAM are: 1. Frame rate (60fps vs 50fps). This impacts any calculations which are based on the number of frames, typically movement. 2. Number of lines per frame (262 vs 312), important since the game is responsible for triggering VSYNC. 3. Number of visible lines (192 vs 228), which can change all kinds of things like sprite sizes, size of the playing field, vertical motion rate, and more. Some homebrew programmers use the TV switch to change between NTSC and PAL, while others create NTSC & PAL specific versions. (SECAM is the same as PAL (50/312/228) except the TV switch is hardwired to B&W and there are only 8 colors.) PS The 2600 has 160 pixels of horizontal resolution.

As mentioned the N64 had a much smaller library than the PSX, though it tended to have a lower percentage of garbage (though it did have some major stinkers). As mentioned anything by Nintendo, or Rare, tended to be at least well done. Things from the cross-platform guys (especially stuff which started on the PSX or PC) often was less impressive.

Just picked up a PSX at a garage sale (C$20, including a dual-shock controller), and now I'm wondering what games I should be picking up. My tastes run to the exploration/adventure type games. FPS (and other ultra-violent games) are out to keep my wife happy. Kid friendly games as well for my under 3 year old son. (He loves Mario64, though I'm getting tired of playing it.) And how much should I expect to pay for a used PSX game (not copies)? Any other words of advice? Oh, any recommendations/cautions for memory cards?

In Andrew's sample kernel he uses ORG $F000 to set the start of the code. He then uses ORG $FFFA to set the start of the 3 interrupt vectors. Each vector is 2 bytes, for a total of 6 bytes. $FFFA + 6 = $10000. $10000 - $F000 = $1000 = 4096 = 4K. Now that I have that clarified I can answer your question. If you recall, the 6507 used in the 2600 only has 13 address lines. Thus from the 6507's perspective $F000 is the same as $1000 because the 13 least significant bits are the same. And when DASM generates the code (with the -f3 option) it starts the binary file at the first ORG. So DASM only generates a 4K file. It really comes down to (for 4K games at least) style. Though if you want to use a 6502 emulator (instead of a 2600 emulator) you will need to put the interrupt vectors down at $FFFA (instead of $1FFA) so the emulator can find them, since the 6502 emulator will track all 16 bits of the address. Clear as mud, right?

Since general division & multiplication take so many cycles (often with a wide variation between cases) 2600 programmers try to avoid them if at all possible. Where one of the operands is a constant a dedicated routine can often be created (such as the div/mod 15 routine sometimes used for sprite positioning) or a table used. But even then, it is a good idea to try and figure out a way to do without. BCD (binary coded decimal, where each byte stores 2 decimal digits, 00-99) sometimes is used for scores, etc where the display is in decimal. But often it's easier to use one byte (or even a two byte pointer) per decimal digit (so you don't have to try and extract each nibble).

Sounds like I'm asking to much of Maria The first line of text is 16 indirect sprites with double wide characters and 5 direct sprites each 8 bytes wide. It sounds like Maria runs out of cycles before all of the indirect sprites are displayed. The color and number updates are handled by an NMI routine. Again, since Maria is using all of the cycles trying to display everything there's no time left for the CPU to do the updates before the start of the next line. I just need to come up with a different (less time consuming) way to display the first 0-F. Just one of the pitfalls of developing with an emulator. However, it should be possible to use this to clarify the cycle times given in the 7800 documentation. Oh, and if someone is going to do a screen capture, I can create a version which doesn't display the digits.

Snapshot from MESS (not a screen cap, using the built in capture function.) I don't have a 7800 (yet). It would be interesting if someone could make a video capture to assist in color correcting the emulators.

This is just a quick demo which displays all 256 colors the 7800 is capable of. Source code is included for those interested. And it should autodetect PAL/NTSC and adjust. (Did any released games do this, or does sole credit belong to Eckhard?) colorgrid.zip

Regarding the design document, I agree with other posters that what you have described will not fit into 4K. (Skeleton+ PAL just fits in 4K, though a 1.8K of that is data tables.) My recommendation would be to start to develop a complete game around the DRIVING MODE. As mentioned previously, the 2600 has no built in text mode. See Dark Mage for what is possible, although you may be able to simply create 48 pixel text sprites for menus etc. 2600 has a 1-D GPU (the TIA) - no bitmapped display. Thus the MAP SCREEN and PLOT COURSE will be difficult to accomplish. The GOON/BOSS/PURSUIT modes all seem very challenging. I would also recommend creating a version which does not require any special controllers (or have it selectable via the difficulty switches). Consider also people tend to hold the joystick with both hands, so when using the touchpad they will not be able to use the joystick.

Start with the Links for Programmers topic over on the Programming forum. One major advantage of the programming for the 2600 is the wealth of documentation, examples, and community. (fixed link)

Rather than heap on the negative comments, let me see if I can come up with some positive suggestions. 1. First, take the previous messages to heart. Programming the 2600 is not an easy task, the retro market is very small (100 units could be considered a platinum album), etc. 2. Next, start by setting reasonable short term objectives. Create a working development environment, program a simple demo and gradually work up to the pieces required for your game. 3. Try to dedicate some time to your project on a regular basis. (This is my biggest problem, very little spare time.) 4. Don't be afraid to put KR2600 on hold and work on something else. Many of us have more than one project on the go at once. Given time and effort you will be able to create a 2600 game. It may not match the vision you have now, but some of that will be a result of the limitations of the 2600. (76 cycles per line to start with.)

Question for the PAL folks - does the 7800 have the same PAL palette as the 2600, or is it closer to NTSC? In my demo the ground plane should be blue, two shades of green, and a tan. And I am working on a revised version with NTSC/PAL autodetect too.

I've looked at the various A/V mods, and I've asked myself why people are doing it that way. Here's my logic: The TIA has 4 digital luma outputs, a digital colour phas output, and 2 analog audio outputs. An A/V mod needs to convert the 4 digital luma outputs to a single analog output (simple resistor ladder network, nothing fancy), then amplify the outputs. I stumbled across the Fairchild Semiconductor ML6415. This (and it's cousins) is a simple video filter which appears to be exactly what the doctor ordered. This single chip takes in luma and chroma, and outputs luma, chroma & composite signals ready for a 75ohm cable. (I haven't found an equivalent IC for the audio side yet, but a standard op-amp or a Maxim MAX44100 headphone amp might work.) It might also be necessary to adjust the TIA chroma output with a resistor ladder to give it the swing the ML6415 wants. But this looks like it has the potential to give the best A/V output.

Unfortunately, Gauntlet isn't a JAMMA board (although an adapter can be made, though 4 joysticks isn't standard JAMMA either). And since part of my logic for Gauntlet is 4 player cooperative play, the cabinet has to be large enough for 4 people to stand in front of it.