4 replies to this topic

[Heaven/TQA]

Hi!

as some of you may know i started my 1st 2 homebrew projects for the A7800. coming from atari 8bit it is really sometimes strange to code for a7800 as it has no "natural" atari evolution (2600 (player/missle) - 5200 - 800xl - 130 xe).

i am stucked in displaying our "TAQUART" logo. how long is a 160 pixel scanline in RAM (not in the linebuffer?) because this implifires how to store the gfx data in a7800.

at the moment i made it like on playstation1.

the screen is seperated like this:

160
-------------+-------
128 + 32
r1: dl1 dl2
r2: dl3 dl4

where each region is 16 pixel y-direction
and dl1 is 128 pixel in x region (32 bytes max of length) and dl2 is the left 32 pixels.

what makes me wonder is do i have to store
the grafics for each DL separate? or
can i make the dls tell how to read the grafics data (like a blitter on atari ST)?


maybe someof you can help

ps i have "INCed" in VBL the hi-byte of the DLs and the "rubish" grafic scrolled vertical fine through the DLs. is this possible? this would mean that the lines are stored in 256 bytes per scanline?

[Eckhard Stolberg]

In a display list entry you can specify the starting address for the graphics data and the number of bytes to load. The DMA will increase the low byte of the address by one for each byte that is has to load. Also it will increase the high byte of the address by one for each line that the display list covers. So the grahics for the second line in a region has to start 256 bytes after the first byte of the graphics for the first line. Therfore you will need a 4KB block of graphics data for a 16 line region.

If your lines need less than 256 bytes, than you can store the graphics for several 16 line regions in the same 4KB block. If you need more than 256 bytes per line, then you need to split up the graphics data into several 4KB blocks, and have several display list enries in the display list for that region point to the appropriate starting address for the graphics data.

I hope this answers your question.


Ciao, Eckhard Stolberg

[Heaven/TQA]

ah... so my eyes havent fooled me (more than 17 years practice in 8bit demo coding... enough skill to see "correct" scrolling chaotic bitmap... ;=))

what makes me again wonder is...have i missed this inc lobyte inc hibyte and the 16x256 size in the docs somewhere??? i guess not...

again another question: does this rule fit for sprites, too? so i have to store the 16 bytes of a sprite to x+y*256?

now i try to convert the taquart logo.

re: grafics converter...i have done my own in (!) turbobasic on my lovely atari800win emulator (and run the atari as fast as your pc can)... let u know if it worked...

[Eckhard Stolberg]

If you read the first paragaph about the Display List List in the 7800 software guide, it says that OFFSET gets added to the highbyte of the graphics data address in the display list entries, and that OFFSET gets decremented in each scanline of the region. So I think I made a little mistake. I think the graphics must be stored upside-down, because OFFSET decrements.

And there is no difference between sprites and background on the 7800. It's all the same type of object. Therefore the same same limitation apply, which means that you have to store each line of the sprite in steps of 256 bytes as well.

BTW, I tried your demo on my PAL 7800 and it looks pretty much like the screenshot on your site, except that there are a lot of lines with garbled graphics under the logo.

But writing converter tools for programming on one PC based emulator on another PC based emulator is just as wrong as it gets, especially when you are trying to replace converter tools that are running on a third PC based emulator.


Ciao, Eckhard Stolberg

[Heaven/TQA]

but it was the fastes way doing it workable.

otherwise i had to install visual studio just to make a quick look how to convert a logo...and atari8bit has the antic mode 4 which is similar to the atari7800...

i dont want to spend 2 hours just learning how to get the io-routines work in visual c and how the controlling grafics-output on pc and the correct writing of data in atari format...i spent in past 1 day just to get an idea how "hello.c" works in visual c with the project files...

that's why i decided to go for turbo basic... ;=)
and for that you need an emulator...but atari800win 2.8+ has the direct to pc bridge implemented so... rock'n roll...why not? ;=)

as demo coder i love now the idea of 16x256 chunks...256 byte long scanlines makes calculations really easy in 6502...

expect on this weekend my 1st screenshot of the ingame grafics... i will render it on cinema 4xl or reflections and than import it back to 7800...

papa, hve