EricBall

Unfortunately there is no single correct answer. The 7800 (like the 2600, 5200, NES and probably others) generates the TV signal directly as a chroma/luma signal. Although there are equations to transform YUV to RGB, there are some constants which vary from console to console and TV to TV. At the height of one of the discussions about 2600 -> RGB (which is the same as the 7800, except the 7800 has an extra bit of luma resolution) Adam Wozniak put together a webpage where you can fiddle with some of the constants yourself. http://cuddlepuddle.org/~adam/video.cgi

I think you don't give Dan Boris and Eckhard Stolberg enough credit. Although it may not have been widely known, there was sufficient info available to create a homebrew back in 2000 (maybe earlier), prior to the signature key being discovered. (Which was never a factor for PAL 7800s either.)

In http://www.atariage.com/forums/viewtopic.php?t=44179 I did a fairly detailed comparison of the NES and 7800 (near the bottom of the first page). Needless to say, and NES to 7800 port will require a lot of changes to the graphics and sound due to the very different capabilities of the two consoles. In order to duplicate the color capabilities of NES tiles (each 2x2 block of tiles is 1 of 4 three color palettes), it will be necessary to use the 7800 160B graphics mode. Each tile will be 2 bytes = 4 pixels wide, and the NES has 32 tiles per line, so the screen will be only 128 (of 160) pixels wide. This may be a blessing in disguise since it will make it easier to scale the NES sprites which are twice the width. Although you could use all 160 pixels to show more tiles, this would leave no time for the GPU to display any sprites. Even with only 32 tiles per line there's only enough time to display 6 160A sprites per line (plus a border to mask the horizontal scrolling). The alternative would be to drop the background tiles to 160A, but that would only allow 4 colors for the whole background. The sprites can use either 160A or 160B graphics modes, although 160A is closer to the NES capabilities. Sound would have to be recreated by ear because the sound capabilities of the NES and the 7800 (even with a POKEY) are radically different. Game logic (outside of GPU and controller interfacing) should be largely portable (assuming you have commented SMB source code), depending on whether it has any other hardware dependencies and how much game logic processing it does per frame. Not only will the 7800 GPU halt the CPU during the active screen to retrieve sprite data, but it requires significant CPU time to create the GPU data structures. Good Luck!

See Christopher Tumber's very good note on this subject: http://www.freelists.org/archives/atari780...4/msg00068.html and the slightly shorter one I did: http://www.freelists.org/archives/atari780...4/msg00055.html One advantage of the 7800 is it uses the same 6502 CPU as many other consoles and computers. Therefore there are a lot of books (from absolute beginner to expert) on programming the 6502, some of them available online. The trick is to recognize when you are programming the CPU versus doing things which are specific to the console/computer.

Recognize that there is no way to enhance a 2600 game for the 7800. It's either a 2600 game or a 7800 game. Sure you can probably reuse the game logic, but anything display/kernel dependent will have to be recoded. I've also heard before people wishing for 7800 games. Well, let me tell you, wishing doesn't make things happen. If you want SMB for the 7800 I'd advise you to start working on it yourself because your desire doesn't translate into time & effort for anyone else. Don't know how to code? Start learning today and you will either be on your way to achieving what you wish or have a better understanding of what you are wishing for. [/u]

Note to all 7800 homebrewers, the width in the display list header is the number of bytes, not pixels. The bit -> pixel relationship depends on the current graphics mode (i.e. the Read Mode and Write Mode). For indirect mode the width is the number of characters/tiles. Horizontal position, however is given in 160H pixels, even in 320H modes. (320H modes are more like a doubleres 160H mode for other reasons.) CTRL EQU $3C; WO [CK DM1 DM0 CW BC KM RM1 RM0] ; CK: 0=color, 1=B&W ; DM: 10=DMA on, 11=DMA off ; CW: 0=single, 1=double wide char ; BC: 0=black border, 1=background ; KM: 0=transparent, 1=background ; RM: 00=160 1x=320

I'll second that. The following is a rough guide: 2 cycles / RAM byte, 3 cycles / ROM byte, approx 400 cycles available per line. Note to all budding 7800 homebrewers - MESS isn't perfect, so I suspect those of us with CC2s will be doing a lot of beta testing.

With this surge in 7800 homebrewing (wow!), I'd like to encourage all 7800 homebrewers (and lurkers) to join the mailing list. One note - the mailing list doesn't archive attachments, although they do get sent out as part of the list.

I wouldn't be that harsh; it's simply different. And there are some 7800 games which put it's capabilities to good use, so obviously it isn't that bad. You can't compare the graphics capabilities of the 2600 with the 7800. A 2600 game is like a one-armed paper-hanger, trying to update the TIA registers ahead of the scanline. On the 2600 the CPU does all the work, while on the 7800 the CPU sets up the display lists and stands back. Sure, you can use a DLI to update a register or two during the frame, but for the most part the CPU isn't involved with the graphics. It's a different paradigm. It's like older FPS which had software 3-D renderers and modern ones which use OpenGL or D3D and pass off the rendering (in the form of lists) to the GPU.

Nope, completely different paradigm. The 7800 is based on sprites. Hmm, let's see if I can do a quick summary. Each frame the MARIA GPU loads it's internal display list list (DLL) pointer from the DPP register. The DLL is made up of a sequence of 3 byte headers which contain the number of lines in the zone (1-16), some flags, and a pointer to the display list for the zone. Each scanline, the GPU reads the display list, which is a sequence of 4 or 5 byte headers with a 2 byte terminator. Each header contains a pointer to either a sprite or a tile list along with an X position, a width (number of bytes/tiles), a palette (0-7) and some flags. Each byte in the tile list is used as the LSB of a sprite pointer with the MSB being a GPU register. The sprites are bitmapped graphics stored (in ROM) upside down with each line on a separate 256 byte page. The bit to pixel color relationship depends on the graphics mode and can be quite bizarre. The display lists and display list list are stored in RAM for access speed reasons. (RAM takes 2 cycles/byte to access, while ROM requires 3 cycles/byte.) The DLL is typically static, but the display lists are often completely recreated each frame (a CPU intensive process). The display lists also chew up a bunch of RAM. A 7800 game could create a bitmapped display by using RAM as one very big sprite, but it would need more than the 4K RAM in the 7800. (10K for a 160x240x4 color display)

Just my C$0.025 When the CK bit is set, MARIA doesn't generate a colorburst as part of the horizontal sync portion of each scanline. This results in TVs decoding the video as black & white. This was intended to allow the 7800 to produce high resolution (320x240) greyscale for displaying 40 column text. I've also used it for SpaceWar! 7800 to avoid artifacting. Color artifacting occurs when the luma (B&W) portion of a composite video signal is at or near the colorburst frequency (3.58Mhz). This is because the color portion of a composite signal is modulated at the colorburst frequency. Unfortunately, the NTSC 7800's high resolution modes (320 pixels per line) pixel clock is the same as the one used for colorburst; which means any color game which uses the high resolution mode has to deal with color artifacting. (Notably Tower Toppler, which uses it to its advantage.) It certainly is possible to turn the CK bit on and off on a per-line basis. Of course, there may be some modern hyper-intelligent TVs out there which might get wigged out by it.

As requested 7800man1.zip

As I mentioned above, I created a BASIC program to do exactly that. It doesn't do too bad a job on simple paragraphs, but lists, tables and diagrams need to be done manually. Look at the manual for Touchdown Football. The movement diagrams had to be completely redone to fit in 40 columns. The movement table for TMP Wrestling had to be split into two sections. Each manual presents unique problems. Also the creator of the HTML version may have tried to preserve the formatting of the manual with centering and indentation which can cause additional problems for the automated reformatted. Mitch - I'll send you what I've done so far. I was hoping to get all the 7800 manuals done as a complete set, but I haven't been able to spend the time.

I've been working off and on reformatting the 7800 manuals to 40 columns. If anyone is interested, I have a QuickBASIC program which does a decent first pass. Done (so far): Super Huey, Super Skateboardin', Tanks Command, Title Match Pro Wrestling, Tomcat, Touchdown Football, Tower Toppler, Water Ski, Winter Games, Xenophobe, Xevious. (Yes, I'm working reverse alphabetical.)

For my balldemo each sprite requires 224 cycles, or two scanlines, to add to the display list. (Hmm, I just realized this means with 256 sprites onscreen the display lists are requiring multiple frames to update.) Plus the MARIA GPU will steal in total half a scanline of CPU time per (two byte 16 line) sprite to draw it onscreen. On the NES there are a finite number of sprites, but updating them requires little CPU time. The NES GPU has a separate bus from the CPU which allows the CPU to run constantly during active video. The 7800 GPU shares the CPU bus, so the CPU is disabled while the display list and sprites are being read. More available CPU time allows for better AI, improved responsiveness, and generally smoother gameplay.

I will disagree with this. 1. Although the 7800 can handle more sprites than the NES, the display-list requires more CPU and RAM to do so. 2. Graphics processing on the 7800 steals CPU cycles, making the CPU crunch even worse. 3. Scrolling tiled backgrounds on the NES are simple, accomplishing the same on the 7800 is not. 5. Although the 7800 has a 320 mode, it was seldom used because of artifact issues. It also still has 160 positioning accuracy. So most games are 160 mode, while NES is 256 (which has some advantages from a programming standpoint). 4. Have you even looked at what the 2A03 and POKEY are capable of? The 2A03 can do DMA digital samples, which trumps the POKEY's psuedo-random waveforms. This is not to say that the 7800 is not capable, nor that there aren't games where the 7800 version is better than the NES equivalent. But, other than a pure # of sprites, the 7800 isn't a clear winner over the NES from any standpoint. To say otherwise requires very narrow view.

The 7800 digital signature may have been used for quality control. However, if you contrast the N64 (quality) with the PSX (quantity), which do you think wins? Also consider that the N64 was more costly (both licensing & cartridge) for third party developers than the PSX. Variety is the spice of life. Yes, a glut of second (and third) rate games can damage the market, but a lack of titles (*cough* GameCube) is even worse.

The two buttons on the 7800 controller are probably wired differently than most other 9 pin controllers. On the Atari single button controllers, the fire button is between pins 6 and 8 (GND). The buttons on the 7800 are connected between pin 6 and 5 (left) or 9 (right) with 520 ohm resistors from pins 5 & 9 and pin 8. For non-handheld controllers, you may want to consider building a controller using arcade parts (www.happcontrols.com or www.therealbobroberts.com). That's the way I'm probably going to go at some point.

The NES sound generator is integrated into the 6502 CPU. (Part of the same IC, but no additional instructions.) It also puts the TIA and POKEY to shame. Specs from http://nesdev.parodius.com/2A03/ 5 sound channels, 2 pulse (square), 1 triangle, 1 white noise, 1 digital. Pulse channels have 4 duty cycle settings: 87.5%, 75%, 50%, and 25%. If you know how a pulse wave works, you will notice that the difference between 25% and 75% is indistinguishable to the human ear. Pulse and triangle channels have an 11-bit frequency control, and is capable of producing tones ranging from approximately A-1 to B-8. The triangle channel is one octave lower. Pulse and noise channels have 16 volume levels. Triangle and digital channels have no volume control. The triangle waveform is synthesized by modulating 16 volume steps, hence the lack of volume control and subtle metallic resonance-type sound noticable at low frequencies. Noise channel has 4-bit frequency control, and is capable of producing 16 frequencies. Noise channel has a special 'looped noise' setting that allows it to produce a metallic sound. Digital channel can use a DMA method to play a sample, the sample depth is only 1-bit but it retains good quality by using a technique called "delta modulation", in which only the changes in the waveform are recorded. Digital channel is capable of playing 7-bit samples through a method similar to a digital-to-analogue-converter, or DAC. Digital channel's DMA method allows access to only 16k of sample data, but by using external bankswitching hardware you can overcome this limitation. Pulse channels have a built-in frequency-sweep function, often used for sound effects. Pulse channels have a built-in primitive volume envelope function. All sound channels except digital have built-in time-length control. Compare this with the TIA & POKEY which had a 2 or 4 channels of selectable LFSR pseudo-random waveforms and 8 or 16 bit frequency control.

In http://www.atariage.com/forums/viewtopic.php?t=44179 I did a fairly detailed comparison of the NES and 7800 (near the bottom of the first page).

Dan, I think you misunderstood what Bruce was describing. What you are talking about is display lists with each list having a fixed start point in RAM with maximum length. e.g. 128 bytes per list = max 32 sprites per line which isn't bad considering MARIA can only display ~28 sprites (two bytes wide) per line. The alternative would be to somehow create each display list after the previous one then update the DLL with the start addresses. This would require ordering the sprite information so the the lists could be built in order; and don't forget that most sprites will be in two lists for vertical motion. What Bruce is talking about is to use fixed length lists, but segment the list into space for fixed position sprites and space for motion sprites so the full list doesn't have to be created every frame. Bruce then used character strings for the fixed position sprites, which allows the sprite graphics to change easily without having to update the display list. Conceptually, this is similar to the NES which has tiles (7800 character strings) and sprites.

http://www.freelists.org/cgi-bin/webpage?w...ge_id=atari7800 has links to all of the 7800 information I could find (though it hasn't been updated recently). I'd also recommend taking a look at my Balldemo sample code or even SpaceWar! 7800. And don't forget to subscribe to the Atari 7800 Programming mailing list.

Well, yes & no. Floating point numbers are just a different way of expressing a value. If n and m are a number of bits, then the range of different formats is. Unsigned 0 to (2^n)-1 twos complement -2^(n-1) to (2^(n-1))-1 signed fixed point -2^(n-1) to 2^(n-1))-1 + ((2^m)-1)/(2^m) unsigned floating point 0 to 2^((2^n)-1) * ((2^m)-1)/(2^m) Sorry if I've lost anyone there. Okay, the unsigned is easy to understand. 8 bits has the range 0 to 255. 8 bit twos complement is -128 to 127. Fixed point has two components, a integer portion and a fractional portion. So 16 bits (8 integer, 8 fractional) can represent the signed values -128 to 127+255/256. Floating point also has two components, a fractional portion and a mantissa (or exponent). So an 16 bit unsigned floating point number (8 fraction, 8 mantissa) has the range 0 to 2^255 * 255/256. As you can see, there is nothing implicit with floating point representation which requires additional bits. However, more mantissa bits increase the range of values which can be represented and more fractional bits increase the precision of the value. For example 1/3 would be have to be approximated as 85/256 with an 8 bit fraction. Note: no matter how many bits are used, all numbers can not be represented exactly. There will always be an error. Floating point is very useful when performing multiplication since the range of values is much, much larger than integer or fixed point with the same number of bits. However, floating point addition is much more difficult. Multiplication in general requires significantly more CPU processing to accomplish, so was typically avoided by time-sensitive applications (e.g. games) until the transistor budget was large enough to create dedicated high-speed hardware multiply, divide & floating point sub-processors.

First, great work Bruce! I know there have been requests for this in the past by people who couldn't use a78sign. Question - is the signature generated by your utility 100% the same as that generated by the original Atari utility & a78sign? Also, how does your utility determine how much of the bin to use for the signature (for future bankswitched carts)? Regarding the a78 header - I, for one, simply add the required info to the ASM to automatically generate the a78 header. And although the header & signature may not be required to execute the game via an emulator (or CC2), the signature will be required if/when physical cartridges are manufactured. The a78 header also provides an elegant method to provide meta information about the game to the emulator.