Some 7800Basic questions

[SlidellMan]

Hello everyone,

 I was wondering how does one program palettes for 160B mode, and how many variables can you assign without running into problems?

[+SmittyB]

160B mode graphics use either the first or last 4 palettes so you assign your colours to p0c1 through to p3c3 or from p4c1 to p7c3 and then when you draw your 160B graphic you specify either palette 0 or palette 4 to choose which colours you're using.

 

As for variables you have 100 in var0-var99, 26 in a-z, and 1535 bytes in a large chunk from $2200 to $27FF.

[SlidellMan]

Hey, thanks a bunch. Now, back to work on Lady Zenithian: The Time Jump.

[Jinks]

Sounds very provocative. 

[+mksmith]

Just one thing to be careful with 160B - takes up a lot more space in than 160A.  Also very large images may need to be split into smaller widths when using the plot sprite and banner features.

[SlidellMan]

Thanks, I'll try to keep that in mind.

[+SmittyB]

10 hours ago, mksmith said:

Just one thing to be careful with 160B - takes up a lot more space in than 160A.

To be specific it's exactly twice as much. 160A mode is 2bpp (bits per pixel) so each pair of bits represent the values 0 to 3 for each pixel, and you get 4 pixels per byte.

160B mode is 4bpp so you get the values 0 to 15 for each pixel but it only defines 2 pixels per byte. You don't get 16 colours though because 4 of those values represent transparency.

 

The reason you need to keep it in mind is because the way the 7800 works to draw something it counts the number of bytes and not pixels and for some things there's a 32 byte width to what can be drawn in one go. The 7800 can also only read so many bytes per frame so it's easier to hit that limit.

 

On the other hand if you compare it to the technique of stacking sprites to get more colorful object's as was the only option on other consoles it's a much more efficient method, stacking 2 sprites would take the same space to store but would still only give you 6 colours (plus transparency) and not the 12 you get with 160B.

[+mksmith]

@SmittyB thanks for the additional info ?

[SlidellMan]

By the way, I wonder if 7800 Basic has XM support?

[RevEng]

Maybe some - existing games should enable the XM pokey or HSC if your game is compiled for them - but seeing as I don't actually have an XM, and also seeing as the XM programming spec hasn't been officially released, I can't really guarantee it. I took my best shot.

 

Other features will be added, if I get a hold of one.

[SlidellMan]

Maybe I could try sprite stacking as a palette swap method. Of course, I have to figure out programming jump height, wall clinging, etc.

[SlidellMan]

Sorry for dredging this up, but when it comes to programming sound effects, which frequency corresponds to which note?

[RevEng]

Assuming you're talking TIA, check out Eckhard's SOUND FREQUENCY AND WAVEFORM GUIDE.

[SlidellMan]

I just started to layer sprites for a vertical shooter/shmup, and will that still work in regards to the same sprite with different palettes? Can the same be done with background tiles? I've attached said graphics in question.

[+SmittyB]

While it would technically work it would not be practical to layer the background tiles as you'd quickly hit the limits of how much MARIA can draw per zone/frame.

 

It would also technically work with sprites, but depending on how you're using the extra colours you may be better off using 160B as 160B gives you 6 extra colours and reduced overheads compared to layering 2 sprites.

[SlidellMan]

Thanks for the clarification, Smitty. For this shmup, I want to keep the color count to a minimum and keep the ROM size around 144kb. (That is subject to change, however.) By the way, ever since the mid-'00s, I always wanted to make my own shmup, but could never figure out how to have the screen to auto-scroll.

Edit: I just wrote scroll_speed and scroll_direction variables, but am still stumped on how to get the auto scrolling. Is anyone here experienced in vertical shmups?

Edited May 31, 2020 by SlidellMan