basic Q about character maps..

[ceti331]

curious how backgrounds worked on the 7800,

<r.e. indirect mode ..>

>>"The Character Map is composed by W entries, where W is the

specified width and each entry is one byte long. Each entry is a

Low address byte of a character, and the High address byte is

specified by the Character Base register (see CHARBASE under

REGISTERS). This means that each character on a scan line must

have the same high address byte (sit on the same 256 byte page)."

 

Does this really mean each zone of background in a 7800 screen can only feature 32 4x8pixel characters & 1 palette?

does seem the 7800 screenshots i've seen have very simplistic background graphics

what tricks were used? did people run length encode sections of backdrop around sprites as background chunks or what?

Edited April 24, 2010 by ceti331

[+GroovyBee]

Each zone can contain more than one Display List (DL) header. You use as many as you need to make up your game's display. You can also use programmer tricks like changing CHARBASE on a Display List Interrupt (DLI) to swap character bases or to change the colours in the palette. If you have CWIDTH set in the CTRL register 2 bytes of graphics data will be fetched for every character.

[ceti331]

Each zone can contain more than one Display List (DL) header. You use as many as you need to make up your game's display. You can also use programmer tricks like changing CHARBASE on a Display List Interrupt (DLI) to swap character bases or to change the colours in the palette. If you have CWIDTH set in the CTRL register 2 bytes of graphics data will be fetched for every character.

 

After posting that i wondered if the character defs had a pitch of 256 like the sprite defs.. or is each Indirect CharMap DL-Header only able to reference 256 total bytes of character map definitions

 

any examples of games with complex backgrounds (e.g. what would an r-type or armalyte port look like on the machine..) or examples of homebrew on this.

[+GroovyBee]

After posting that i wondered if the character defs had a pitch of 256 like the sprite defs.. or is each Indirect CharMap DL-Header only able to reference 256 total bytes of character map definitions

 

Yep! Its much easier in hardware terms just increment the MSB of the address. When you use indirect mode the only difference in how the graphics are accessed is that CHARBASE provides the MSB of the address and the data in the buffer provides the LSB.

 

any examples of games with complex backgrounds (e.g. what would an r-type or armalyte port look like on the machine..) or examples of homebrew on this.

 

Sirius is a side scrolling shmup. It was never released back in the day but is a fully working prototype. Check out my WIP Apple Snaffle for a 4 way scrolling game using indirect character mode.

[ceti331]

After posting that i wondered if the character defs had a pitch of 256 like the sprite defs.. or is each Indirect CharMap DL-Header only able to reference 256 total bytes of character map definitions

 

Yep! Its much easier in hardware terms just increment the MSB of the address. When you use indirect mode the only difference in how the graphics are accessed is that CHARBASE provides the MSB of the address and the data in the buffer provides the LSB.

 

any examples of games with complex backgrounds (e.g. what would an r-type or armalyte port look like on the machine..) or examples of homebrew on this.

 

Sirius is a side scrolling shmup. It was never released back in the day but is a fully working prototype. Check out my WIP Apple Snaffle for a 4 way scrolling game using indirect character mode.

 

googled that... very armalyt-esque indeed, and appears to be port of C64 graphics by the looks of the colors? i gather the 7800 would have been able to color each sprite properly

[+GroovyBee]

googled that...

 

Screenshots and emulator binaries are available in the 7800 section of the site too :-

 

http://www.atariage.com/software_search.html?SystemID=7800

 

very armalyt-esque indeed, and appears to be port of C64 graphics by the looks of the colors? i gather the 7800 would have been able to color each sprite properly

 

There are 8 tricolour palettes available in 160A (2BPP) mode. Each palette consists of 3 colours and a common background colour (25 colours in total). Which means you can have 8 sprites on screen with completely different colours from each other without resorting to any programmer tricks. Everything on the 7800 is a sprite. It doesn't have any video RAM.

[ZylonBane]

It doesn't have any video RAM.

You should probably rephrase this statement in a way sufficiently specific to not be false.

[+GroovyBee]

It doesn't have any video RAM.

You should probably rephrase this statement in a way sufficiently specific to not be false.

 

I'm not talking about MARIA's Line RAM. If you say video RAM to any low level programmer it will be understood to mean a full screen linear mapped frame buffer.

[ZylonBane]

I've slung my share of assembly code in decades past, and when I hear "video RAM", I think of any RAM that's touched by the video display hardware, be it frame buffers, sprites, fonts, display lists, textures, vectors, etc. So what you really meant was that the 7800 doesn't have a hardware-native fullscreen framebuffer mode. And even then, it can be configured to fake it so well there's no practical difference.

[ceti331]

I've slung my share of assembly code in decades past, and when I hear "video RAM", I think of any RAM that's touched by the video display hardware,

 

i see your point

 

in defence of GroovyBee, his description sumarises the salient difference between the atari 7800 and the average programmers picture of an 8bit computer

 

I always think of a Frame Buffer first, especially a special type of dram chip with a second sequential output port designed for video scanout. but thats a very old definition now.