Atari 8-bit to 7800 porting questions

[peteym5]

There are a few Atari 8-bit games I have laying around that I could be ported to the 7800. They used Antic 4, multicolor character set modes. 7800 has something similar. Just have to look at a good example of how to set this up. 7800 has a different sprite system than the 8-bit player/missile graphics. Allows 8 sprites of different sizes on a single like, won't need a multiplexor.

 

I see there are samples made for another assembler, but I use MADS. I would have to port that stuff to MADS so it makes better sense to me.

 

I understand the sound is 2 voice and always is a concern for us. Adding a Pokey chip or having the program detect that add on module are also options. We try to keep the prices of the cartridges down.

 

 

[Rybags]

Everything visible from Maria on 7800 is like a sprite. Or better description might be playfield elements that are independantly fine positioned with priority decided by the order they appear in the DLs.

 

Concerns of course though are finite amount of DMA as well as only 4K Ram, plus lots of objects can mean lots of time creating DLs.

 

The sound from TIA is an obvious weakness.

Also notable that there is no collision detection at all - it has to be performed by the software.

[EricBall]

At one point I did a quick comparison of the 5200 & 7800 graphics processing: https://sites.google.com/site/atari7800wiki/atari-5200

 

I'd recommend you first learn & program the 7800 so you have a better understanding of its capabilities and weaknesses.

 

And while having the source code will make porting much of the game logic easier, I think you will find the graphics are so dissimilar that anything dealing with graphic objects will need a major rewrite for efficiency.

[tep392]

Allows 8 sprites of different sizes on a single like, won't need a multiplexor.

 

You will want to take a look at the tech documents here.

 

http://www.atarimuseum.com/ahs_archives/archives/archives-techdocs-7800.htm

 

There isn't a specified limit on number of sprites per line, but there is a limit on Maria cycles, I think 454, per scanline. The number of cycles per sprite depends on it's width and color depth. There is also a character map mode good for doing backgrounds.

 

Here are some examples, if I understand Maria cycles correctly.

 

160 pixel wide char map, 2bit color. 130 cycles total. 10 for DL header plus 120 for data (40 bytes x 3 cycles/byte)

 

8 pixel wide sprite, 2bit color. 14 cycles total. 8 for DL header plus 6 for data. each additional byte of data adds 3 cycles so an 12 pixel wide 2bit/pixel sprite would be 17 cycles.

[tdididit]

MADS 7800 macro file got some bug. here is working version

*********************************************************
* MARIA MACROS FOR EASIER GRAPHICS CONSTRUCTION *
*********************************************************
*
*
*this macro constructs a 4 byte header for display lists
*
.macro header ; address palette width hpos
.byte [:1 & $FF] ; .byte \address & $ff
.byte [(:2 * $20) | ($1F & (:3 ^ $FF))] ; .byte (\palette*$20) | ($1f & -\width)
.byte [:1 >> 8] ; .byte \address >> 8
.byte :4 ; .byte \hpos
.endm
;
;this macro constructs a 5 byte header for display lists
;
.macro xheader ; address,palette,width,hpos,wm,ind

.byte [:1 & $FF] ; .byte \address & $ff
.byte [(:5 * $80) | $40 | (:6 * $20)] ; .byte ((\wm*$80) | $40 | (\ind*$20))
.byte [:1 >> 8] ; .byte \address >> 8
.byte [(:2 * $20) | ($1F & (:3 ^ $FF))] ; .byte ((\palette*$20) | ($1F & -\width))
.byte :4 ; .byte \hpos
.endm

[peteym5]

Thankyou, I find some of what posted here useful. What I need specifically is setting up a character(or tile) mapped screen. Similar to A8s Antic mode 2 or 4. 40x24 character screens, for the background. I know the player/missile thing will be totally out the window because the 7800 Maria does much better with the sprites and multiplexing them is much easier.

 

I also read this thread http://atariage.com/forums/topic/162032-basic-q-about-character-maps/to get me started.

 

Many of my games made use of "Procedural Screen Drawing" that uses a series of instructions to draw the screens vs storing or compressing the screens on the cartridge ROM. Instructions are straight forward, like Horizontal Line (LHZ), Screen Position, and Length. Have different instructions for Vertical, Diagonal, and Blocks. About 4 or 5 bytes per instruction. Less than 100 bytes can set up a screen. If I can port this over, I have 5 games that can come over to the 7800.

 

The programming for the Player/Missile multiplexer take the X,Y, Color, and sprite number for each sprite going on the screen. The multiplexer is executed at the beginning of each Vertical Blank Interupt (VBI). That multiplexer routine can just be swapped out with something that puts 7800 sprites at the same X,Y positions since both use values 0 to 255. Would not be too hard to adjust the A8s player/missile offset.

[Trebor]

Perhaps the Atari 7800 Development Wiki may be of assistance, under the MARIA Documents section. There is the Overview of MARIA from the updated 7800 Software Guide as well.

[EricBall]

The 7800 GPU uses several data structures to generate graphics. The screen is first broken into zones which are 1-16 lines high. The graphics for each zone are generated based on a display list (which is very different from the A8 display list). The display list contains a series of entries which describe either a sprite or a series of characters (i.e. tiles).

 

So, to generate your 40x24 character screen (NTSC) you need the following (assuming a static background):

1. 8x8 4 color character graphics, stored in 7800 order

2. A 960 byte character map in raster order (character is the LSB of the character graphics)

3. 24 display lists, each containing two 5 byte entries pointing to the left & right halves of the character map, followed by a 2 byte list terminator

4. 28 display list list entries - 4 for the vertical overscan (13 lines each), 24 for each of the 8 line high zones

The graphics can be in ROM, the rest needs to be in RAM (either copied from ROM or generated programatically).

The real difficulty comes with the sprites. You first need to determine which zone(s) to add the display list entry to. Then you add the entry to the end of the display list(s), adjusting the MSB of the sprite graphics for any vertical offset.

[RevEng]

Good advice so far. I know you're interested in getting characters up on the screen, but it's probably easier to start with a simple sprite example. Dan Borris has one. Once you've figured out the details of putting sprites on the screen, drawing characters/tiles is only a bit more complicated - you create Display List entries that refer to character/tile RAM, instead of Display List entries that refer to sprites. Because the Display List code can be a bit fiddly, it's better to start as simple as possible.

 

I ported the A8 version of Serpentine to the 7800, so I spent a bit of time contemplating this very topic. Here are a few things to keep in mind when looking at an A8->7800 port...

 

PM graphics can be as tall as the screen height, but are only 8-bits wide. Maria's sprites have opposite strengths - they can be up to 32 bytes wide wide (that's bytes, not pixels) but they're limited in height to a single zone. (you wind up drawing multiple sprites, more or less, if you need a taller sprite on-screen)

 

Atari 8-bit PM graphics are relatively cheap for the 6502, with the worst cycle expense being vertical movement. On the 7800 the cost is a bit higher, due to the DL memory structures you need to create and maintain for Maria. In my case I was able to tune Serpentine to run faster to compensate for cycles lost to creating DL structures. If your game is already running full speed you may not have this luxury.

 

PM graphics can overlay on top of any graphics mode on the A8. On the 7800, you can't overlay graphics with dissimilar (read) modes within the same horizontal zone. In the Serpentine port this meant changing the score text at the top to match the mode used in the maze, since the frog can jump out of the maze into the score area. I could have hidden the frog, but having him hopping around the score area is part of Serpentine's charm.

 

Maria's 320A mode is pretty much the same as Antic mode 2, including artifacting effects. 160A mode is the closest to Antic mode 4, though you can't get a 4th color by using characters greater than 127.

 

The other thing worth mentioning is that RAM is fairly tight on the 7800, compared to any A8 config. For Serpentine I needed to resort to on-cart RAM.