Atari 7800 game development newbie questions

[Turbo Laser Lynx]

Hi guys, I've taken a real interest in the Atari 7800 lately because of "Knight Guy" and Rikki & Vikki (and also of the Atari 2600 the last couple of years). The Atari 7800 seems to be a really interesting and overlooked system so I have a couple of noob questions if somone could kindly help me out.

 

- Is there some sort of development cartridge for testing on a real Atari 7800?

- Does the Atari 2600 Harmony cart work on the Atari 7800 for testing Atari 2600 games / 2600 game development so that I could use an Atari 7800 as a "two in one" system, (main use would hypotethically be testing own game creations on real hardware).

- Are ntsc games completely unplayable on a PAL system? I noticed some interesting homebrew games like Time Salvo is only available on ntsc.

- I noticed/read that the graphics work in quite interesting ways on the Atari 7800 / Maria with zones and the display list etc. My first computer was a C128/C64 so I really like games/systems that utilize double wide "chubby pixels", like the Atari 8-bit computers, the Vic-20, the C64, the Amstrad CPC464 etc. and apparently the Atari 7800! That mode and quite simple graphics would automatically be close to my retro-feelings, but out of curiosity, are there some games or homebrew that utilizes the 12color sprites with mode 160B? It'd be really interesting to see that.

- I read that tiling characters is quite costly for Maria, so I started wondering what then would be a sensible approach to build up the screen, or what kind of sized bitmaps / "graphic blocks" would make sense and be somewhat performant for a simple game with background and a few sprites moving around? I read that the homebrew frogger at least changes background color once from water to road and that way probably has less tiling.

- Is anyone aware of some 7800basic examples where you can move a sprite or two around the screen without having the sprite disapearing and splitting in two on every vertical zone like in the 7800basic samples? Or could it be I'm using some old emulator that makes them tilt (I have "ProSystem")?

- Is anyone aware of some 7800basic example with a little bit of horisontal parallax scrolling? I thought I read somewhere here that the 7800 is quite good at that.

Thankful for any help!

Edited September 14, 2020 by Turbo Laser Lynx

[Trebor]

3 hours ago, Turbo Laser Lynx said:

- Is there some sort of development cartridge for testing on a real Atari 7800? (If I'd happen to manage to start developing something small for it).

None currently distributed on a mass level.  Concerto and Dragonfly are on their way.

 

3 hours ago, Turbo Laser Lynx said:

- Does the Atari 2600 Harmony cart work on the Atari 7800 for testing Atari 2600 games / 2600 game development so that I could use an Atari 7800 as a "two in one" system both for games and testing. (If I'd happen to manage to start developing something small for the 2600).

Yes, the 2600 Harmony carts (Both original and Encore) work on the 7800.

 

3 hours ago, Turbo Laser Lynx said:

- Are ntsc games completely unplayable on a PAL system? I noticed some interesting homebrew games like Time Salvo is only available on ntsc.

Most retail 7800 NTSC games have a 7800 PAL counterpart.  The majority of modern 7800 homebrews auto swap for region, T:ME Salvo is among the auto-switching kind.

 

3 hours ago, Turbo Laser Lynx said:

...are there some games or homebrew that utilizes the 12color sprites with mode 160B?  It'd be really interesting to see that.

I know of one being developed privately that uses a 12 color sprite.  Hopefully, sooner than later, it will see a public release.

 

3 hours ago, Turbo Laser Lynx said:

I read that tiling characters is quite costly for Maria, so I started wondering what then would be a sensible approach to build up the screen, or what kind of sized bitmaps / "graphic blocks" would make sense and be somewhat performant for a simple game with background and a few sprites moving around? 

I'll leave this one for the programming experts.  At the very least though, I would recommend reading up on MARIA, the remainder of the Software Guide, and other guides available from the 7800 8BitDev site.

 

3 hours ago, Turbo Laser Lynx said:

- Is anyone aware of some 7800basic examples where you can move a sprite or two around the screen without having the sprite disapearing and splitting in two on every vertical zone like in the 7800basic samples? Or could it be I'm using some old emulator that makes them tilt (I have "ProSystem")?

Do not use ProSystem.  It is antiquated and inaccurate with many items related to system timings.  It may lead to very inaccurate hardware results during your game development.  Use BupSystem instead for an interface similar to ProSystem, but much closer to accurate hardware emulation.  A7800 has a built in debugger, contains very close to accurate hardware emulation, and is recommended.  JS7800 is a Java based online emulator that comes recommended too.

 

3 hours ago, Turbo Laser Lynx said:

- Is anyone aware of some 7800basic example with a little bit of parallax scrolling? I thought I read somewhere here that the 7800 is quite good at that.

Here's a recent vertical scrolling demo under 7800basic, in which the same principles can be applied scrolling horizontally.

[+Pat Brady]

4 hours ago, Turbo Laser Lynx said:

- I read that tiling characters is quite costly for Maria, so I started wondering what then would be a sensible approach to build up the screen, or what kind of sized bitmaps / "graphic blocks" would make sense and be somewhat performant for a simple game with background and a few sprites moving around? I read that the homebrew frogger at least changes background color once from water to road and that way probably has less tiling.

 

How to optimize performance really depends on what you’re doing.

 

My recommendation for learning is to start very small, understand 160A with Direct mode first, and don’t worry about performance at all until you get something simple working. I read the Software Guide until most of it made sense before I started coding — but I did not understand the DMA Timing appendix until much later.

[+SmittyB]

At this point it seems it would be better if ProSystem quietly disappeared from the internet because it's just not up to the standards of other emulators and from what I've heard includes a number of bodge fixes to get even the original retail releases working properly. JS7800 is based on it but doesn't have a lot of the same problems fortunately.

A7800 and BupSystem are as good as hardware for almost everything so you can't go wrong developing with those.

 

 

As for the graphics, most early systems' graphical prowess was in how they could draw tilemaps and / or bitmaps to the screen with fancier systems capable of shifting the tilemaps in pixel increments, flipping tiles around, or having different palettes in different locations, but the sprite capabilities were always relatively lacking.

 

The NES and Master System both have a fixed amount of memory to manage 64 8*8 or 8*16 sprites but can only draw 8 on a given line, while the C64 has 8 24*21 sprites (12*21 in multicolor mode similar to 160A on the 7800), but the 7800 goes completely the other way by dropping the tilemap and making everything that gets drawn a sprite (sprite isn't the best term but it's what most people think of them as) so it can draw sprites up to 248*16 (124*16 in 160A mode and that's if my maths is right).

 

Of course this allows for huge graphics on screen that other systems can't do without plenty of trickery, but the downsides, of which there are many, include that while the objects can be placed anywhere horizontally they must be aligned vertically to a zone so scrolling vertically requires a lot of fiddling about and horizontally requires moving every object instead of just updating a shift register, and as each object is drawn with a single palette you need to have multiple objects if you want more than 4 colours in your pseudo-tilemap built from 'indirect mode' objects.

 

As each object to be drawn requires the system to read a header to understand what it needs to do, and 'indirect mode' objects require extra processing to read the tilemap, one of the ways to optimise things is to ditch the mindset of tiles, make use of the 7800's strengths, and just have bits of your levels just be single large chunks of graphics.

 

 

With all that said, 7800BASIC takes care of a lot of the details so you don't need to worry about them until you get into more advanced stuff and you shouldn't focus on optimisation while you're learning the ropes as @bizarrostormy suggests.

[Trebor]

2 hours ago, SmittyB said:

At this point it seems it would be better if ProSystem quietly disappeared from the internet because it's just not up to the standards of other emulators and from what I've heard includes a number of bodge fixes to get even the original retail releases working properly. JS7800 is based on it but doesn't have a lot of the same problems fortunately.

A7800 and BupSystem are as good as hardware for almost everything so you can't go wrong developing with those.

?

I'll say it before and I'll say it again...ProSystem being utilized for Atari 7800 emulation, is akin to using Nesticle for NES emulation.  Both were great in their heyday, but we have come a long way in emulation since then for both platforms.  A7800 has a built-in debugger and very close to hardware accurate emulation, making it an excellent choice for development.

 

There used to be an argument for interface and ease of use between ProSystem and A7800.  BupSystem has made that point moot and includes close to hardware accurate emulation as well.  JS7800 has brought convenience and accessibility, regardless of OS, to the forefront.  Extra bonus with the global high score saving as well as customization of inputs and palettes.  It is nearly as accurate as A7800 and BupSystem, much better than ProSystem.

[Turbo Laser Lynx]

Thanks so much everyone for your help! Very kind of you! This really gives me an Atari 7800 kick start.

 

17 hours ago, Trebor said:

None currently distributed on a mass level.  Concerto and Dragonfly are on their way.

Keeping my fingers crossed for these! I like using original carts/tapes/diskettes on old systems but for development.

 

Quote

Yes, the 2600 Harmony carts (Both original and Encore) work on the 7800.

 

Most retail 7800 NTSC games have a 7800 PAL counterpart.  The majority of modern 7800 homebrews auto swap for region, T:ME Salvo is among the auto-switching kind.

Nice!
 

Quote

I know of one being developed privately that uses a 12 color sprite.  Hopefully, sooner than later, it will see a public release.

I'm slightly surprised if no games use it ? I read somewhere on this forum that stacking sprites for more colors would be more demanding for Maria (which also confuses me a bit, since Maria seems to be quite a sprite pusher, at least in 8-bit terms), so I guess there must be some other hurdles too.

 

Quote

Do not use ProSystem.  It is antiquated and inaccurate with many items related to system timings.

Yup, thanks! I found the other emulators and have them now.
 

14 hours ago, bizarrostormy said:

How to optimize performance really depends on what you’re doing.

 

My recommendation for learning is to start very small, understand 160A with Direct mode first, and don’t worry about performance at all until you get something simple working. I read the Software Guide until most of it made sense before I started coding — but I did not understand the DMA Timing appendix until much later.

Exactly, yeah I had my sights on 160A anyways, I love that double wide pixel look. ^^
 

12 hours ago, SmittyB said:

 

As for the graphics, most early systems' graphical prowess was in how they could draw tilemaps and / or bitmaps to the screen with fancier systems capable of shifting the tilemaps in pixel increments, flipping tiles around, or having different palettes in different locations, but the sprite capabilities were always relatively lacking.

 

The NES and Master System both have a fixed amount of memory to manage 64 8*8 or 8*16 sprites but can only draw 8 on a given line, while the C64 has 8 24*21 sprites (12*21 in multicolor mode similar to 160A on the 7800), but the 7800 goes completely the other way by dropping the tilemap and making everything that gets drawn a sprite (sprite isn't the best term but it's what most people think of them as) so it can draw sprites up to 248*16 (124*16 in 160A mode and that's if my maths is right).

 

Of course this allows for huge graphics on screen that other systems can't do without plenty of trickery, but the downsides, of which there are many, include that while the objects can be placed anywhere horizontally they must be aligned vertically to a zone so scrolling vertically requires a lot of fiddling about and horizontally requires moving every object instead of just updating a shift register, and as each object is drawn with a single palette you need to have multiple objects if you want more than 4 colours in your pseudo-tilemap built from 'indirect mode' objects.

 

As each object to be drawn requires the system to read a header to understand what it needs to do, and 'indirect mode' objects require extra processing to read the tilemap, one of the ways to optimise things is to ditch the mindset of tiles, make use of the 7800's strengths, and just have bits of your levels just be single large chunks of graphics.

 

With all that said, 7800BASIC takes care of a lot of the details so you don't need to worry about them until you get into more advanced stuff and you shouldn't focus on optimisation while you're learning the ropes as @bizarrostormy suggests.

These systems that take a completely different approach both fascinates me and annoys me a little bit at the same time (mostly I love them). I've done a few small (tiny) Atari Lynx games, and many of these things like that everything is a sprite and reading a header (well "sprite control blocks" on the Lynx) sounds familiar, there you can also link the sprites together and draw them all in one command (sounds like some sort of display list, thankfully no zones though), also you can skip reading the palette, using the "same as before". It's quite interesting coming up with ways how a game should/could work without tilemapping.

I read up a bit about the Atari 8-bit computers and the Amiga lately, and it seems to me they have similarities too. I'm only 1/4 technical and 3/4 artsy fartsy, so I usually don't have the patience to understand these old beasts super deeply, but it's super interesting understanding at least the basics and the graphic modes to understand what you're dealing with. Anyway I'm really glad 7800basic takes care of the details, because I'm not looking to "push the limits" really, mostly I'm looking to have fun, and hopefully create some fun small game in the process.
 

Quote

but the downsides, of which there are many

Made me giggle a lot haha.

*Btw. I had just put some retro gear into circulation so I went and bought an Atari 7800 last night! Woohoo! ?
 

Edited September 15, 2020 by Turbo Laser Lynx

[fultonbot]

On 9/14/2020 at 4:27 AM, Turbo Laser Lynx said:

 are there some games or homebrew that utilizes the 12color sprites with mode 160B? It'd be really interesting to see that.

I have some 12-color sprites working in an action game.  Some of them are cover 2 zones (16x32) and they appear to work fine.
The big issues with the 12-color sprites are that they take up more ROM, and they are seemingly difficult to get the colors indexes working.
When you display them, all the colors are mixed-up and 12-colors takes much more time to match indexes than 4 colors.   I have system now, and it just takes time to swap the colors until you get them right.  Here is what they look like in the Atari Dev Studio editor:

 

Here is what they look-line in engine:

 

I'm not any kind of sprite artist, so I hope this gets the idea across.   

 

Edited September 18, 2020 by fultonbot
Update

[TailChao]

With regard to switching modes within a scanline (in this case 160A <-> 160B), you also have to switch back. If whatever you're designing has an arbitrary screen layout which could easily have too many objects per line - it might be a good idea to try layered draws instead. This reduces the amount of "safety mode sets" you'll need sprinkled around the rest of your Display List.

 

But I'm not 100% sure of what you're working on or what 7800basic does under the hood, so you might be able to ignore all that entirely!

 

On 9/14/2020 at 2:30 PM, SmittyB said:

At this point it seems it would be better if ProSystem quietly disappeared from the internet because it's just not up to the standards of other emulators and from what I've heard includes a number of bodge fixes to get even the original retail releases working properly. JS7800 is based on it but doesn't have a lot of the same problems fortunately.

That would be nice - but ProSystem has been in use for so long that nudging current or new users towards anything else will require pulling several (possibly all) teeth. Until A7800 is the first result on a Google search for "Atari 7800 Emulator" and / or listed in the Wikipedia article we're pretty much stuck with it.

[Turbo Laser Lynx]

On 9/18/2020 at 5:17 PM, fultonbot said:

I have some 12-color sprites working in an action game.  Some of them are cover 2 zones (16x32) and they appear to work fine.
The big issues with the 12-color sprites are that they take up more ROM, and they are seemingly difficult to get the colors indexes working.
When you display them, all the colors are mixed-up and 12-colors takes much more time to match indexes than 4 colors.   I have system now, and it just takes time to swap the colors until you get them right.  Here is what they look like in the Atari Dev Studio editor:

 

Here is what they look-line in engine:

 

I'm not any kind of sprite artist, so I hope this gets the idea across.  
 

I think they look really nice!  Hahaa, I'm used to fiddle with the color indexes on the Lynx with 16 colors! I'm sure there's a better way, but I've usually ended up setting them manually.
 

On 9/19/2020 at 7:29 PM, TailChao said:

it might be a good idea to try layered draws instead.

 

You'd think it'd be possible to have a few layered and/or stacked sprites on screen.? At least from reading superficially about the Atari 7800 and Maria!

Edited September 24, 2020 by Turbo Laser Lynx

[Turbo Laser Lynx]

If someone remembers from the top of their head, could you kindly help me with a controller question. Is the American version of the controller usually used as a joystick in games with up for jump, or if not, which button is usually used for jump in games, A or B? Or do games have both up for jump and a jump button? ?

Edited September 29, 2020 by Turbo Laser Lynx

[+SmittyB]

I've yet to meet anyone who likes up to jump. You should go with whatever feels best for your game but for platformers most people are used to what was established in Super Mario Bros with the right fire button being jump and the left fire button being run / action / whatever.

I suppose you could have up to jump for a selectable 1 button mode if you want, but in my opinion you shouldn't base a 7800 game around the expectation that players will only have 1 button controllers.

[Turbo Laser Lynx]

4 hours ago, SmittyB said:

I've yet to meet anyone who likes up to jump.

You have now met one! My first computer was the C128 (i.e. C64) so for example Giana Sisters made a huge impression on me. Atari got it mixed up with the 7800 controllers, they should've sent those joysticks to Europe  Joysticks were probably popular a while longer here, but obviously that changed in the late 80s and especially in the early 90s with consoles becoming more and more pop here too (instead of home computers).

I wouldn't wanna have up for jump if a lot of 7800 users use mainly joypads or if the convention is not to have up for jump (even though us controller looks like a joystick).

[Turbo Laser Lynx]

 

Does anyone know approximately how long the Atari 7800 stays in the different temperatures? I mean which temperature is likely to be the most common one? Of course it would depend on the length on the play session, but it would still be good to know when choosing palette, in a format like: cold-10min, warm 1h, hot 1h+. I would guess that people don't usually do super long play sessions, so it'd be interresting to know how long it runs warm before moving over to hot. What do you guys think?

  

On 8/30/2020 at 9:29 PM, vhzc said:

The 7800 palettes are kinda tricky so maybe you should test it in different color "temperatures".

 

[Trebor]

On 9/30/2020 at 2:15 AM, Turbo Laser Lynx said:

Does anyone know approximately how long the Atari 7800 stays in the different temperatures? I mean which temperature is likely to be the most common one? Of course it would depend on the length on the play session, but it would still be good to know when choosing palette, in a format like: cold-10min, warm 1h, hot 1h+. I would guess that people don't usually do super long play sessions, so it'd be interresting to know how long it runs warm before moving over to hot. What do you guys think?

Although it can vary, here's a general overall view:

 

COLD = ~24.7 degrees (Experienced when system just powered on from a few seconds to upwards of within ~1 minute).

COOL = ~25.7 degrees (AKA 'Factory Settings', where Hues $1x and $Fx match - experienced within ~5 minutes).

WARM = ~26.7 degrees (AKA 'Ideal' 256 unique colors - experienced within ~10-15 minutes).

HOT = ~27.7 degrees (Many consoles ultimately wind up here - within ~20 minutes).

 

 

On the console motherboard, there is a tunable resistor (AKA internal color dial on system's motherboard), which has a span of ~15 degrees when tuned all the way left and achieves as high as ~45 degrees when turned right, before losing all color. 

The tunable resistor excludes Hue $1x. Its appearance is highly influenced by the tint/hue setting of the device it is broadcast from, and is not impacted by system warm up either.  It is the hue begin or start point of the palette. 

 

How the tunable resistor is set will strongly determine the begin and end results of the degrees of separation between hue values.

The majority of 7800 consoles appear to have been adjusted within 1-2 minutes of power up to achieve the "COOL" or 'Factory Setting' of ~25.7 degrees (This setting is where hues $1x and & $Fx will match exactly). 

From there, each major system temperature difference is denoted as a full degree delta on average.   The degrees of separation between hues gradually climb though, and anyone can take a "hot" system and turn that resistor for a slightly to drastically different outcome, as eluded to earlier.

The warm up factor is something that really doesn't have to be weighed too much if keeping some guidelines in mind:

CAUTION: $1x = Likely to lean greenish instead of a golden range on modern displays.  A $2x compromise can be tried instead.
CAUTION: $5x = May straddle between pink or purple at times.  For better consistency: Use $4x for pinks.  Use $6x for purples.
CAUTION: $8x = May straddle between purple or blue at times.  For better consistency: Use $6x for purples.  Use $9x for blues. 

AVOID: $Ex = Colors can vary considerably from a range of greens to a range of browns.
AVOID: $Fx - Can start very green; ultimately becomes brown/auburn as system warms up.

Simplified Suggestions:



 Visual of typical COOL to HOT transitioning:



NOTE:  All examples are NTSC, for conversion purposes:

NTSC $1x <--> PAL $2x
NTSC $2x <--> PAL $3x
NTSC $3x <--> PAL $4x
NTSC $4x <--> PAL $5x
NTSC $5x <--> PAL $6x
NTSC $6x <--> PAL $7x
NTSC $7x <--> PAL $8x
NTSC $8x <--> PAL $9x
NTSC $9x <--> PAL $Ax
NTSC $Ax <--> PAL $Bx
NTSC $Bx <--> PAL $Cx
NTSC $Cx <--> PAL $Dx
NTSC $Dx <--> PAL $Ex
NTSC $Ex <--> PAL $Fx

NTSC $Fx no real equivalent to PAL.  Nearest PAL $2x.
PAL $1x no real equivalent to NTSC.  Nearest NTSC $Dx.

[Turbo Laser Lynx]

Thank you so much for this @Trebor it's gold! ? I wasn't expecting such a detailed and comprehensive answer, haha! This is extremely helpful as it highlights the most problematic colors. Unfortunately the "time zones" are all long enough to be taken into account, but it seems it doesn't have to be to much of a headache after all.
 

On 10/1/2020 at 3:53 AM, Trebor said:

The warm up factor is something that really doesn't have to be weighed too much if keeping some guidelines in mind