Atari 7800 Programming: Help?

[Mord]

Okay. I'm not close to my computer right now so I'll check that later. Just to kill time, I was wondering about the Expansion Module. Seeing the Donkey Kong XM test for the add on baffled me with all of the colors and improved sound quality. I was wondering if that thing is out yet and if there is a way to write code for it on 7800basic.

 

It's not out yet no. You can keep an eye on progress in it's 7800XM thread that's pinned to the main 7800 forum. It's hit a bunch of snags over the years unfortunately. When it ends up released I'm sure 7800Basic will be updated to take advantage of it. In the meantime I recommend doing what I'm doing and tinker with what's currently available to get comfortable with the abilities and limitations of the system.

[DonavinTheSuperGamer]

 

It's not out yet no. You can keep an eye on progress in it's 7800XM thread that's pinned to the main 7800 forum. It's hit a bunch of snags over the years unfortunately. When it ends up released I'm sure 7800Basic will be updated to take advantage of it. In the meantime I recommend doing what I'm doing and tinker with what's currently available to get comfortable with the abilities and limitations of the system.

Thanks. And just one more thing; I was curious about color palettes. According to the 7800basic guide, there are 8 palettes with only 3 colors each. However, when I played Ken Siders' 'b*nQ', some sprites had more than just 3. (I counted a max of 4) Is it true that you can actually set more than 3 colors or am I just seeing things?

[+frankodragon]

It could be the transparent color used you see. Otherwise, 7800basic would give an error if more than three colors are used per image. There are also 320A and 320B settings but have restrictions according to this. I think b*nQ was made with assembly code.

[RevEng]

B*nq appears to use 160A/B. 160B mode graphics have 12 colors. Basically it uses the colors from 4 consecutive palette entries. I don't know if this is what you're seeing, or not.

 

You can use this in 7800basic, same as you would in assembly. Just bear in mind that 160B graphics take up a lot of ROM.

[DonavinTheSuperGamer]

B*nq appears to use 160A/B. 160B mode graphics have 12 colors. Basically it uses the colors from 4 consecutive palette entries. I don't know if this is what you're seeing, or not.

 

You can use this in 7800basic, same as you would in assembly. Just bear in mind that 160B graphics take up a lot of ROM.

12? That's a lot of colors. It also says 160B mode's 'characters' are only 2 pixels. I hope it's not talking about text and fonts.

[RevEng]

Yeah, it does. You could use double-wide characters for 4 pixel wide characters, if you were dead set on using 160B characters.

 

Bear in mind that you can display both 160A and 160B graphics at the same time. Generally it's better to stick with 160A characters, and use 160B graphics only where required. Having a whole screen of 160B characters will cause Maria to use a lot more time while the CPU is halted, leaving less CPU time for your game.

[DonavinTheSuperGamer]

Yeah, it does. You could use double-wide characters for 4 pixel wide characters, if you were dead set on using 160B characters.

 

Bear in mind that you can display both 160A and 160B graphics at the same time. Generally it's better to stick with 160A characters, and use 160B graphics only where required. Having a whole screen of 160B characters will cause Maria to use a lot more time while the CPU is halted, leaving less CPU time for your game.

Cool. I didn't know you could use both at the same time. I'll keep that in mind.

[DonavinTheSuperGamer]

Okay. So I just created this .png file here. I tried downloading GIMP but it would fail to install and the online version is very unstable and won't let me save. So, I used Game Maker to create this. The system failed to compile my game because the file "has too many colors," even though it only has three colors. I'm so confused.

Edited June 11, 2016 by DonavinTheSuperGamer

[Mord]

Okay. So I just created this .png file here. I tried downloading GIMP but it would fail to install and the online version is very unstable and won't let me save. So, I used Game Maker to create this. The system failed to compile my game because the file "has too many colors," even though it only has three colors. I'm so confused.

 

The problem is that while you only used 4 colors total (including background), the palette for the image itself was still set to 16-24 million colors. I've reduced it to 4 colors in the attached image. I think I figured out a better way to preserve palettes at least in paint shop pro with this, so let me know if the file works.

[DonavinTheSuperGamer]

.

Edited June 11, 2016 by DonavinTheSuperGamer

[DonavinTheSuperGamer]

 

The problem is that while you only used 4 colors total (including background), the palette for the image itself was still set to 16-24 million colors. I've reduced it to 4 colors in the attached image. I think I figured out a better way to preserve palettes at least in paint shop pro with this, so let me know if the file works.

The program successfully compiled! However, the emulator will still do absolutely nothing. I used the incgraphic command to insert the file. Then, I put in alphachars to represent symbols 0 to Z. I put some alphadata and set plotchars to write it out, but it won't do anything. I have a feeling I'm doing something wrong.

Edited June 11, 2016 by DonavinTheSuperGamer

[RevEng]

It would be easier to say what's wrong if you posted the source files.

[Mord]

Have you specified your characterset? Just a guess of course as I think I had that happen to me once. As rev says, we can give more concrete answers if we see the source.

[MobiusAqua]

I agree with RevEng and Mord, but I also just had a thought: did you set your palettes? Like...

P0C1=$0E
P0C2=$45
P0C3=$8A

...for example? Just curious.

[+frankodragon]

Did you also remember to put a restorescreen and drawscreen commands in your code too? Restorescreen is important otherwise it'll make the screen glitch. Drawscreen makes sure all of the graphics are ready to display.

[DonavinTheSuperGamer]

Okay. Here is the code I wrote:

PROGRAM_CONFIGURATION
	set romsize 48k
	set zoneheight 8
	set screenheight 224
	set pokeysupport on
	set debug color
	displaymode 160A
SETTINGS
	P0C1 = $d2
	P0C2 = $d8
	P0C3 = $3b
MAIN
	incgraphic tileset_char.png 160A 0 2 1 0
	characterset tileset_char.png
	alphachars '0123456789'
	alphadata mytext tileset_char.png
	'4562'
	'8093'
end
	plotchars tileset_char.png 0 0 8

[Mord]

Here's a modified version of your code that'll do what you want it to do.

 

The reason your code wasn't doing anything was likely because it was failing to compile.

 

Main things that needed to be changed/added:

1. set doublewide on needed to be added. Also be sure to add that before you set your displaymode or it won't take effect.

2. Several places where you used "tileset_char.png" were incorrect. (take note of how they should look below. )

3. alphadata commands should be a single line. plotchar will only plot a single line regardless.

4. You need 4 parameters for plotchars. palette, X-coordinate, Y-line, and # of characters to plot. When you omit the last one, it'll read in an incorrect value and you'll get ... different results.

5. An infinite loop was needed at the end to keep the program from running off into unused rom/data/misc code. In your case it was running off into unused data which was likely filled with $FF's. The infinite loop stops that.

 

Normally in the infinite loop, that's where you'd have your main loop for things done every frame. You'd usually need a clearscreen/restorescreen and displayscreen to help organize things. Where this program is simply putting a bit of text on the screen, they're not really needed here.

PROGRAM_CONFIGURATION
	set romsize 48k
	set zoneheight 8
	set screenheight 224
	set pokeysupport on
	set debug color
    set doublewide on	
	displaymode 160A

	
SETTINGS
	P0C1 = $d2
	P0C2 = $d8
	P0C3 = $3b
MAIN
	incgraphic tileset_char.png 160A 0 2 1 0
	characterset tileset_char
	alphachars '0123456789'
	
	alphadata mytext tileset_char
	'4562'
end
	
	alphadata mytext2 tileset_char
	'8093'
end

	plotchars mytext  0 0 7 4
	plotchars mytext2 0 0 8 4 

mainloop
  
  ; This loop helps ensure the code won't continue to run off into undefined
  ; sections of your rom - or into data. Without it, you'll get errors.
  
  goto mainloop
	

[DonavinTheSuperGamer]

 

Here's a modified version of your code that'll do what you want it to do.

 

The reason your code wasn't doing anything was likely because it was failing to compile.

 

Main things that needed to be changed/added:

1. set doublewide on needed to be added. Also be sure to add that before you set your displaymode or it won't take effect.

2. Several places where you used "tileset_char.png" were incorrect. (take note of how they should look below. )

3. alphadata commands should be a single line. plotchar will only plot a single line regardless.

4. You need 4 parameters for plotchars. palette, X-coordinate, Y-line, and # of characters to plot. When you omit the last one, it'll read in an incorrect value and you'll get ... different results.

5. An infinite loop was needed at the end to keep the program from running off into unused rom/data/misc code. In your case it was running off into unused data which was likely filled with $FF's. The infinite loop stops that.

 

Normally in the infinite loop, that's where you'd have your main loop for things done every frame. You'd usually need a clearscreen/restorescreen and displayscreen to help organize things. Where this program is simply putting a bit of text on the screen, they're not really needed here.

PROGRAM_CONFIGURATION
	set romsize 48k
	set zoneheight 8
	set screenheight 224
	set pokeysupport on
	set debug color
    set doublewide on	
	displaymode 160A

	
SETTINGS
	P0C1 = $d2
	P0C2 = $d8
	P0C3 = $3b
MAIN
	incgraphic tileset_char.png 160A 0 2 1 0
	characterset tileset_char
	alphachars '0123456789'
	
	alphadata mytext tileset_char
	'4562'
end
	
	alphadata mytext2 tileset_char
	'8093'
end

	plotchars mytext  0 0 7 4
	plotchars mytext2 0 0 8 4 

mainloop
  
  ; This loop helps ensure the code won't continue to run off into undefined
  ; sections of your rom - or into data. Without it, you'll get errors.
  
  goto mainloop
	

Wow! It works! I can even change the colors of the text. Thanks!

 

Just a couple of questions... Is there a way to display characters regular sized instead of double the width? How do I change the color of the background? And what was that Paint Shop Pro you were talking about earlier?

[Mord]

Wow! It works! I can even change the colors of the text. Thanks!

 

Just a couple of questions... Is there a way to display characters regular sized instead of double the width? How do I change the color of the background? And what was that Paint Shop Pro you were talking about earlier?

 

Changing the background color is done with another variable: BACKGRND. Works the same way as the palette registers.

 

Paintshop Pro is a graphics program. The copy I have is actually quite old - I bought it back in 2005 I think. Not sure how well the more recent versions of it work as it's been taken over by Corel.

 

The size of the text you have there is as small as you're going to get them in 160 modes. The double-wide parameter doesn't refer to making the pixels larger, but instead tells MARIA to grab two bytes of information whenever it grabs a byte from the character map (where you have your font stored). It grabs the byte you're asking for, and the byte immediately after - which happens to have the second half of your character/digit.

 

The only way to avoid using double-wide in 160A will be to make it so that your characters all fit in a 4x8 sprite. (4 pixels wide, 8 tall.) That way it can grab all four pixels of data with one byte - in 160A modes.

[+frankodragon]

One thing I've learned is that an image can be reused again and again. However, different variables must be used in order for the images to display. For example, if I want to put two enemies on one screen, but from the same sprite, I have to give them different variables. (i.e. enemy_a_x,enemy_a_y; enemy_b_x,enemy_b_y). If I just use one x and y variables for all the enemies, then it will not work.

[DonavinTheSuperGamer]

Wow. It's been a while since I've been on the forums. I was out celebrating the end of school! So, thanks guys for the help. I finally got THIS to show up on Prosystem Emulator. I specifically set 'BACKGRND = $00', but it's a different color every time I run it. The background changes to red, green, and even purple. I don't get it. Could I be doing something wrong or could it be the emulator itself?

[+frankodragon]

It's probably best if you displayed your code so others can find out the solution.

[Mord]

Wow. It's been a while since I've been on the forums. I was out celebrating the end of school! So, thanks guys for the help. I finally got THIS to show up on Prosystem Emulator. I specifically set 'BACKGRND = $00', but it's a different color every time I run it. The background changes to red, green, and even purple. I don't get it. Could I be doing something wrong or could it be the emulator itself?

 

While Prosystem has some issues with emulating the 7800, it's not likely the case here. The kinds of issues you might have with Prosystem involve 320B mode sprites not looking perfect (has some complications which I've learned to work around) or the emulator being a little too generous with how much time MARIA has to display graphics.

 

If the background is changing color like that, there's probably something else setting the background color. Seeing the code is the easiest way to know for sure.