How to setup GTIA modes with square pixels ?

[popmilo]

Could someone make a quick source code for setting up GTIA mode 9 with square pixels ?

 

Simple Graphics 10 mode is ok but I know you can "stretch" pixels vertically using display lists...

 

So how would I make 80x48 pixels screen in 9 colors ?

Or 96x48 ...

Or similar mode ?

 

Is there a "chunky" mode ? one byte one pixel ?

Edited June 2, 2009 by popmilo

[Rybags]

You need to use "VScrol register tricks".

 

Build your DList with the first DLI before the GTIA screen part, then Mode F VScrol DLI, Mode F DLI, repeating that an appropriate number of times to build the height of screen you need (ie each Mode F would be 4 pixels for square mode).

 

In the DLI, alternate between storing value $0D and $03 in the Antic VScrol register. $0C should be stored coincident with the start of "Vscrol" lines, $03 for the start of "normal" lines.

 

The timing is fairly critical, you should have 2 cycles between STA WSYNC and STA VSCROL.

 

So, the DLI source should look something like:

 

DLI
 PHA
 LDA SCROLVAL
 STA WSYNC
 NOP
 STA VSCROL
 EOR #$08 ; this toggles between 03 and 0D
 STA SCROLVAL
 PLA
 RTI

 

Additionally, you should have some VBI code that initializes "SCROLVAL" to the value of $0D.

 

There's no "chunky" 1 byte/pixel mode.

 

You can control the height of your pixels - the way it works is that Antic counts from what you store in VSCROL up to zero, so for "MODE F VSCROL" lines, that gives you D,E,F,0 for 4 lines, for the normal lines that siginify end of scrolling area it counts from zero up to VSCROL so you have 0, 1, 2, 3.

[popmilo]

Thanks for quick answer !

Have to wait to try it, until I come back home from work....

[MaPa]

Or just simply repeat every scanline four times in DLIST via LMS to the same memory area. It's slower than the previous method because it eats 40+ DMA cycles on repeating lines but certainly more simple to code.

Edited June 2, 2009 by MaPa

[NRV]

well, there is no chunky mode but you can always do (3d?) games assuming a resolution of 80x192 and writing the whole byte all the time

 

maybe a stupid question, but.. do graphics 4 mode (2 colors, 80x48) works with PRIOR values for GTIA?

(or any other mode that is not gr.8?)

 

NRV

 

(I suppose that the answer is "not really.. weird things happen", because if not the VSCROL trick is not that useful)

[Rybags]

Gr. 4 only has PF0 to mix with PM0 and PM1, so that's 8 combinations in total for a scanline, 11 if you include mixing PM2 with PM3, 12 if using "5th Player".

 

VScrol tricks should work with chunky modes (for what it's worth)... so in theory you could have mega-tall pixels, or pixels that are trimmed to only 1 or 2 scanlines high, but the CPU penalty would probably equate to using a higher res mode anyway.

Edited June 3, 2009 by Rybags

[NRV]

Gr. 4 only has PF0 to mix with PM0 and PM1, so that's 8 combinations in total for a scanline, 11 if you include mixing PM2 with PM3, 12 if using "5th Player".

 

VScrol tricks should work with chunky modes (for what it's worth)... so in theory you could have mega-tall pixels, or pixels that are trimmed to only 1 or 2 scanlines high, but the CPU penalty would probably equate to using a higher res mode anyway.

 

ah, sorry, I was talking about setting GTIA 9, 10 or 11 over graphic mode 4.. in other words gr.4 with PRIOR = 64, 128 or 192

 

NRV

[Rybags]

Not much use either.

 

GTIA modes combine AN0-AN1 to make a 4 bit value, so they're only really useful with screen modes that produce 160 pixels across or better.

 

Actually, with Gr. 4, the AN0/1 pairs will always produce 0000 regardless of a pixel's value, so you'll just get a blank screen.

[Heaven/TQA]

re: mode9+ (80x60)

 

you should use the "repeat 4 times a scanline) before using the vscrol method... simply because it is good enough for beginning.

 

so... actually you would do this

 

.byte $4f,<vram,>vram

.byte $4f,<vram,>vram

.byte $4f,<vram,>vram

.byte $4f,<vram,>vram

.byte $4f,<(vram+40),>(vram+40)

.byte $4f,<(vram+40),>(vram+40)

.byte $4f,<(vram+40),>(vram+40)

.byte $4f,<(vram+40),>(vram+40)

...

.byte $41,<dlist,>dlist

[popmilo]

re: mode9+ (80x60)

you should use the "repeat 4 times a scanline) before using the vscrol method... simply because it is good enough for beginning.

I did this (source is in XASM format):

 

DLIST

:60 DTA 64+15,a($2300+40*#),64+15,a($2300+40*#),64+15,a($2300+40*#),64+15,a($2300+40*#)

DTA 65,$20,$00

 

And I got this:

 

 

I guess this is a maximum for pal screen... In atari800win it takes whole screen area.

Can anyone tell me how much cycles are there left for use each frame ?

How does it look like on real TV?

 

p.s.Im still without sio2pc cable so I can not test this on real machine...

But cable will come!

[Rybags]

Note if you go fullscreen to 240 lines you'll cop the "Scanline 240 bug" which will cause the screen to distort on a real machine.

 

Cycle usage will be somewhat high using the multiple LMS to repeat lines.

240 * 3 + 3 = 723 DList DMAs

240 * 40 = 9600 Bitmap DMAs

312*9 = 2808 Refresh DMAs

Total = 13131 DMA Cycles lost per frame from the available 35,568

 

Compare that to a normal Gr. 9

3+3+190+2*3 = 202 DList DMAs

192 * 40 = 7680 Bitmap DMAs

2802 Refresh

Total 10,690 DMA Cycles

 

Compare again to a 60 pixel high screen which uses VScrol tricks

3+59+3 = 65 DList DMAs

60*40 = 2400 Bitmap DMAs

2802 Refresh

Total 5,267 DMA Cycles.

 

Of course, you have to factor in the DList Interrupt that's needed to make the whole thing work. The DLI should be needed for every line except the first one - default VScrol value can be set in VBlank.

So, we could probably figure somewhere around 3,000 cycles on top of that for the DLI code.

[popmilo]

Note if you go fullscreen to 240 lines you'll cop the "Scanline 240 bug" which will cause the screen to distort on a real machine.

 

I don't really need 240 lines so that will be no problem...

80x50 is more than enough...

 

 

I would use only 50x4=200 lines so math using multiple LMSs would be like this:

200 * 3 + 3 = 603 DList DMAs

200 * 40 = 8000 Bitmap DMAs

312*9 = 2808 Refresh DMAs

Total = 11411 DMA Cycles lost per frame from the available 35,568 = 24157 left

 

Using VScrol tricks:

3+49+3 = 55 DList DMAs

50*40 = 2000 Bitmap DMAs

2802 Refresh

Total 4857 DMA Cycles = 30711 left

 

Of course, you have to factor in the DList Interrupt that's needed to make the whole thing work. The DLI should be needed for every line except the first one - default VScrol value can be set in VBlank.

So, we could probably figure somewhere around 3,000 cycles on top of that for the DLI code.

So 30711 - 3000 = 27711 left...

 

That is not such a big difference so I can focus on other part of code which is more important...

Of course I'll try to implement Vscroll tricks later...

Thanks a lot !

[Rybags]

Yep. The beauty of the thing is that you can max out using the multiple LMS method, then employ the other one and be gifted with a bunch of free cycles.

 

Although my estimate for DLIs is probably a bit conservative... you have to do a WSYNC, so it's probably closer to 90 cycles for each DLI.

[popmilo]

Yep. The beauty of the thing is that you can max out using the multiple LMS method, then employ the other one and be gifted with a bunch of free cycles.

 

Although my estimate for DLIs is probably a bit conservative... you have to do a WSYNC, so it's probably closer to 90 cycles for each DLI.

 

I guess this isn't enough :

 

DLI

PHA ;3

LDA SCROLVAL ;2

STA WSYNC ;4

NOP ;2

STA VSCROL ;4

EOR #$08 ; this toggles between 03 and 0D ;2

STA SCROLVAL ;4

PLA ;4

RTI ;6

--------------------------------------------------------

31 cycles

 

How would multiple DLI's look like ?

Did you mean every raster line ?

200 times ?

[Rybags]

That's prettywell what you need.

 

Note that your cycle count will be somewhat higher since the STA WSYNC should burn a few cycles. You could save a few cycles actually by tweaking it a bit.

PHA
SCROLVAL = * + 1
LDA #$D; self-modified code
EOR #8
STA SCROLVAL
STA WSYNC
NOP
STA VSCROL
PLA
RTI

 

You don't get many cycles before WSYNC - I think that should fit OK. Obviously with this example, you need to initialize the SCROLVAL byte to the "opposite" value to what it needs to be during VBlank.

 

You only need one such DLI for each group of 4 scanlines, so at most there'd be 59 of them.

[NRV]

Can you do this mode with IRQ's ? so to not waste cycles with WSYNC..

 

I have done the GTIA 9 + 11 mode with IRQ's in 15KHz and with AUDF1 = 0 (counting one scan line), but I don't know if you can sync the IRQ's to the specific point needed to change the VSCROL register (STA WSYNC, NOP, STA VSCROL)

 

NRV

[Rybags]

I don't think so... with any interrupt, unless your main program is in a controlled loop only executing short instructions, you have a variance of about 6 cycles where the Interrupt might actually get serviced by the 6502.

 

That would be quite fine for something like a colour change but with VSCROL register changes, there's only a small window of where you can perform it... in the short time a couple of cycles after WSync which leads up to Antic having to decide whether it needs to read another DList Instruction.

 

Additional to that, you'd probably waste a lot more cycles if using the default OS Timer vector since they get relatively low priority. You could use the Immediate vector or just swap out the OS altogether and use the Hardware IRQ Vector directly to your code.

 

As for whether you'd attain a stable system, I don't know. I kinda doubt it. Additional to that, you also lose the use of one or two Pokey voices.

 

 

ed - another downside is emulation. It's been discussed before - in Atari800Win+ at least, and probably with others, the Pokey Timer emulation isn't cycle exact, only scanline exact.

Edited June 16, 2009 by Rybags

[fox]

The VSCROL trick (a.k.a. "9++/10++ mode") should work on POKEY timer IRQ. You just need to setup the POKEY timer very precisely. Better use $FFFE because of ROM IRQ routine overhead. Whether your IRQ routine needs STA WSYNC probably depends on presence of rare 7-cycle instructions in the main thread because IIRC you have 6-cycle window to do the VSCROL store. In any case, you should gain some cycles compared to DLI, at the cost of an allocated POKEY channel and your time spent to make it work.

 

Cycle-exact POKEY interrupts have been on Atari800 emulator's TODO list since its creation.

 

Also: checkout source code of Numen for a simpler DLI routine which doesn't need a variable and runs every 8 scanlines instead of 4.

Edited October 14, 2009 by fox

[popmilo]

The VSCROL trick (a.k.a. "9++/10++ mode") should work on POKEY timer IRQ. You just need to setup the POKEY timer very precisely. Better use $FFFE because of ROM IRQ routine overhead. Whether your IRQ routine needs STA WSYNC probably depends on presence of rare 7-cycle instructions in the main thread because IIRC you have 6-cycle window to do the VSCROL store. In any case, you should gain some cycles compared to DLI, at the cost of an allocated POKEY channel and your time spent to make it work.

 

Cycle-exact POKEY interrupts have been on Atari800 emulator's TODO list since its creation.

 

Also: checkout source code of Numen for a simpler DLI routine which doesn't need a variable and runs every 8 scanlines instead of 4.

Thanks for info!

 

Currently I switched to 2x1 pixel ratio and display list looks like this:

 

DLIST	DTA	112,112,112
       DTA     64+13,a($8000)
:95 dta 13
DTA	65,$20,$00
DTA     $FF

No wasted time on LMSs and with GPRIOR set to $80 I have nice linear screen to test stuff with at 80x100 in 9 colors with small memory footprint.

[Rybags]

Using Antic Mode $D, you can't get all pixel combinations, unfortunately.

 

GTIA modes work by creating one pixel from data that otherwise would have been for 2 or 4 pixels by combining subsequent bitpairs of AN0-AN1 from Antic.

 

Multicolour bitmap modes never generate a "11" pair (equating to PF3), which will limit what colours you can generate to:

 

0000

0001

0010

0100

0101

0110

1000

1001

1010

 

The last 2 combinations in GTIA Paletted mode will use PF4 (COLBAK), so you'll get 8 colours instead of 9.

[fox]

I'd say last 3, so there are 7 colors.

[popmilo]

I did a test and I get 7 colors...

 

I found this on (great read btw):

http://www.virtualdub.org/blog/pivot/entry.php?id=243

 

"like ANTIC mode E, mode D also outputs BAK + PF0-PF2, and the result is that you can't get an encoding of 11 on AN0-AN1 and only 9 of the 16 colors are available. The only three modes that work are the ones that use the hires encoding, which are ANTIC modes 2, 3, and F. "

 

Uhhh.... 7 colors is enough for now... Speed is not so important right now... I just want to see how would it look like...

 

Thanks for info, I would probably be pretty puzzled with lack of those two colors

[Rybags]

Yep, 7 is right... early morning not good for working out stuff like that.

 

I'm not sure on the break-even point, but the VScrol trick on a single scanline mode is actually quicker if you want 4 scanline high pixels as opposed to repeating the same data using LMS... would probably be quicker for 3, probably lose a bit for 2.