Better Graphics!?!?!?!

[TMR]

And 14K for a single picture is FINE, right now this is a demo type thing, maybe title screens!

 

Just for reference, FLI pictures are 16K and IFLI 32K.

 

As a suggestion, drop a couple of lines of the picture for a scroller and shove an RMT tune in there to make a demo or at least an intro of it; a still picture may be nice but a pic with a little work going on around it and maybe a few other parts all linked and entered into a competition like the oldschool compo at Asm '03 will get shedloads of attention...

[Heaven/TQA]

? When is assembly???

 

and how can you enter the wild compo when noone personal is there?

 

hve

[emkay]

And 14K for a single picture is FINE, right now this is a demo type thing, maybe title screens!

 

 

As a suggestion, drop a couple of lines of the picture for a scroller and shove an RMT tune in there to make a demo or at least an intro of it; a still picture may be nice ...

 

 

That's the way. But first there has to be a "routine" and creation-program to build pictures.

Later it will be no problem to change some code to add scrollers, music etc..

To use RMT with quadruple speed soundroutines, first the emulation has to be fixed. The same is in graphics. How is a picture to build on the PC in an emulation, if the emulation won't show anything....?

[TMR]

? When is assembly???

 

and how can you enter the wild compo when noone personal is there?

 

Assembly is 7th to 10th August this year and it's possible to get someone to take stuff along as a proxy (a few UK sceners i know are going, i think). We entered a VIC20 demo that didn't get past the preselection last year, which is a point - it'll probably need a few more bells and whistles than just a pic and scroller to get shown - it'll need to be a dentro.

 

There's a specific oldschool competition at Asm rather than go for the wild; the C64, VIC, GB, GBC, Spectrum or whatever all compete in the same category.

[TMR]

To use RMT with quadruple speed soundroutines, first the emulation has to be fixed. The same is in graphics. How is a picture to build on the PC in an emulation, if the emulation won't show anything....?

 

On the other hand, unless people build software that pushes what the emulator can and can't do the people behind the emu haven't a reason to upgrade it...?

 

RMT at single speed'll be enough for a decent tune, add a couple of pics if they can be crunched and a few effects and bingo...

[emkay]

To use RMT with quadruple speed soundroutines, first the emulation has to be fixed. The same is in graphics. How is a picture to build on the PC in an emulation, if the emulation won't show anything....?

 

On the other hand, unless people build software that pushes what the emulator can and can't do the people behind the emu haven't a reason to upgrade it...?

 

 

The biggest problem anyway is: How will a coder help creating tools that would be usable only on the original hardware, if he only has an emulator?

[ZylonBane]

I *think* I've seen ColorView stuff, it was quite flickery, can u point me to some good examples of this technique please -- maybe some ATR files

ColorView basically combines physical and temporal interlacing to achieve an unconstrained RGB display. It works by splitting a picture up into its red, green, and blue components. Then, on each scan line, it cycles displaying the red, then the green, then the blue components. So, it takes 3/60th second to show all the image data (temporal interlace).

 

Unfortunately, this causes the entire screen to flash red-green-blue-red-green-blue-etc. So ColorView adds physical interlacing-- the RGB progression is staggered down the screen so that, for example, line 1 will be showing its red data, line 2 will be showing its green data, and line 3 will be showing its blue data. This way, at any given moment you have all three primary colors visible at once and they blend together, just like the RGB phosphor triads on your TV, only at a larger scale.

 

The big downside to this technique is that the 3-stage interlace causes areas of solid color to appear to scroll down the screen. Thus, it's best suited to detailed photographic images. Though this technique is technically applicable to any of the Atari's graphic modes, the two most popular were CV9 (80x192x4096 colors) and CV15 ( 160x192x64 colors).

 

If I seem oddly knowledgeable about the subject, it's because I created the ColorView .RGB storage format and its compression/decompression routines.

 

Anyway, I was poking around the umich archives for RGB pics and only found one. But I also found a program which I'd almost forgotten about-- GED. It's a drawing program that does just what some of you are talking about now... restuffs ALL the color registers on each scan line and allows moving/redefining the sprites on each line too.

[emkay]

GED. It's a drawing program that does just what some of you are talking about now... restuffs ALL the color registers on each scan line and allows moving/redefining the sprites on each line too.

 

This is very near to MCS(++) but truely not as complex.

GED uses ANTIC mode e and the 9 colors are build due the fifth Player color. So you left the possibility of

 

-using the "9th" color on the full screen in a 4x8 raster

-the ability to use one player color twice in a scanline by position the Missile separate from the Player...

 

This is a must if you seriously want the most flexible picture creation on the XL/XE.

[Jetboot Jack]

I'd like to go beyond vDLI ertical color changes Zylon, and change color registers during the horizontal line draw, it can be done, I've seen several GTIA/Antic E vertical splits and I played with the technique for sprite multiplexing many years ago, and got some reasonable results. But I need technical help to pull this off, so any help would be appreciated...

 

Changing colors horizontally is really the last step (combined with Antic 4/E and PMG) for a really good stable display kernal (rather than DLI) to allow upto 16 colors perscan line and every scan line different too...

 

The idea of using flickering to generate colors is aesthetically displeasing I think, and all the demo's I've seen using it (TIP/HIP etc etc) are either too blocky or too flickery...

 

sTeVE

 

P.S. Zylon, I can't seem to access the GED stuff, can you mail me it (preferably not in arc format)...

[Bryan]

I'd like to go beyond vDLI ertical color changes Zylon, and change color registers during the horizontal line draw, it can be done, I've seen several GTIA/Antic E vertical splits and I played with the technique for sprite multiplexing many years ago, and got some reasonable results. But I need technical help to pull this off, so any help would be appreciated...

 

Here's my best guess:

Let's see....the best way to load colors from a table on the fly...

 

LDA ZP,X is 3 cycles, then you'd need to increment X, which is 2. Total=5

On the other hand, PLA is 4 so that's the way I'd go...

 

Set a DLI for the 1st line. Then load A,Y,X with the 1st 3 values. Then WSYNC to the end of the current line.

 

Set your starting color regs and player positions (as many as you can do), and throw in some NOPs for positioning into the visible raster.

STA in a color reg

STX in a color reg

STY in a color reg

PLA

STA in a color reg

PLA

STA in a color reg... etc...

 

Either WSYNC after a while, or this could be timed through an entire section of the screen.

 

-Bry

[emkay]

@bryede

 

By using of the Stack, you need time to fill the Stack before the next visible Scanline... How much would be possible?

 

I would use the following in cause of the most colors at a fair memory usage:

 

At first a wsync...

 

In the border loading a,x,y by using a fixed y value to re-set a selected color the fastest way.

The first then is a simple sta $ followed by a STA $,x inc x ...

 

The first STA can compensate a bit the ANTIC DMA at the beginning of a Scanline.

With the STA $,x you are able to re-use color rows for saving memory too..

[Bryan]

@bryede

 

By using of the Stack, you need time to fill the Stack before the next visible Scanline... How much would be possible?

 

Um, the stack is 256 bytes long. If you made 8 PLA's per line, that gives you 32 lines. It could certainly be used in places (you would leave a few bytes unused if NMI's are needed). Also, you could mix PLA's with other loads. Perhaps use the PLA's at the left edge where you have fewer available cycles (due to RAM refresh), then switch to LDA's.

In the border loading a,x,y by using a fixed y value to re-set a selected color the fastest way.  

The first then is a simple sta $ followed by a STA $,x inc x ...  

Okay, where do you do your loads? You'd have to LDA $,X, INC X, STA $COLxx, LDA $,X...

 

-Bry

[emkay]

Bryede wrote:

 

>Um, the stack is 256 bytes long. If you made 8 PLA's per line, that gives you 32 lines.

 

So you would try to fill the stack before the main color-changing routine.

 

>Okay, where do you do your loads? You'd have to LDA $,X, INC X, STA $COLxx, LDA $,X...

 

So the standard color-line will be a kind longer.

 

 

I think, the biggest problem is to compensate the timing of that kernal(?)

 

Example:

 

It is necessary to use a 3 cycle command. By removing a 5 cycle command you have to put a 2 cycle command to compensate the timing. If not doing so, the complete kernal has to be rewritten any time you will change a command by a command with different cycle usage.

For pictures only, you can forget this by now.

[Bryan]

So you would try to fill the stack before the main color-changing routine.

 

Yup...

 

I think, the biggest problem is to compensate the timing of that kernal(?)

 

Example:

 

It is necessary to use a 3 cycle command. By removing a 5 cycle command you have to put a 2 cycle command to compensate the timing. If not doing so, the complete kernal has to be rewritten any time you will change a command by a command with different cycle usage.

For pictures only, you can forget this by now.

 

I didn't say it was the easiest way! Just the most cycle efficient (haven't looked into what you could do with illegals, tho. Probably not much more).

 

-Bry

[emkay]

bryede

 

Maybe you PLA trick is usefull for every 1st scanline of a charmode-line.

 

What about a definition of some ways to create hor. color changings. So an artist who needs more colors can chose by the better way of creating colors for his Picture.

[Bryan]

bryede

 

Maybe you PLA trick is usefull for every 1st scanline of a charmode-line.

 

What about a definition of some ways to create hor. color changings. So an artist who needs more colors can chose by the better way of creating colors for his Picture.

 

It won't be any good for that, because charmodes use ALL available cycles during the 1st line. The changes would only occur in the borders.

 

-Bry

[Heaven/TQA]

is approximation a way to get nearer to the solution?

 

so... writing a 1 big DLI routine starting with WSYNC 1st scanline and going down the screen...

 

the 1st model is a simpler one like 4/5 antic e/charmode "foreground" gfx with the ability (via $d01a and/or PM) for background changing every 4th pixel/cel? so like on vic20/c64... kind of "simulated" color ram...

 

so the painting program or converter could write colors directly via VBL into the desired positions in the DLI kernel?

 

if this works... try to make it more complex via horizontal multiplexing?

 

 

hve

[emkay]

 

It won't be any good for that, because charmodes use ALL available cycles during the 1st line. The changes would only occur in the borders.

 

 

Heck! Is that a delirium why I see colors changing?

[emkay]

Heaven wrote:

 

>so... writing a 1 big DLI routine starting with WSYNC 1st scanline and going down the screen...

 

The WSYNC has to be written in the "pre" scanline. So the first color could be changed multiple in a scanline.

 

>the 1st model is a simpler one like 4/5 antic e/charmode "foreground" gfx with the ability (via $d01a and/or PM) for background changing every 4th pixel/cel? so like on vic20/c64... kind of "simulated" color ram...

 

That's it. But the changes will not be so "fine". To "bridge" the wider programmed color-lines you have the 5th color of the charmode and the PM overlay.

 

>if this works... try to make it more complex via horizontal multiplexing?

 

There is no "if" . It works very well.

By using a fullscreen DLI/kernal, you can multiplex your whole ATARI

[Shawn Jefferson]

It should be possible to write a PC program that either converts existing pictures, or lets you draw new ones, and dump a raw data file that can be read by the atari, initial color regs, pm locations and size, and also outputs a custom DLI to move the players and missiles to where they are needed, and/or change the color regs as well on every scan line.

 

A little more work would/should let you output a more complex DLI that also multiplexes the players/missiles horizontally, and/or changes color regs horizontally as well.

 

Do you think it is possible to write a convertor, or would the pictures have to be specially drawn with the constraints in mind?

 

Unless I am misunderstanding you would have the following constraints (without multiplexing):

 

9 colors per scan line, 5 from the playfield colors and 4 from the players and missiles. You would further be constrained in that you could only use a players color in two "areas" of the screen (depending on where you place the player and missile and the size setting.)

 

With multiplexing you could have more than 9 colors per scanline, but only in restricted areas of the scanline (9 colors per half of the scan line or third depending on how many changes you can make.)

 

Am I misunderstanding anything here?

 

Would/could you use the "mixing" of players with playfield colors to obtain additional colors?

 

Theoretically it should be possible to use the full MCS mode in a game if you have some sort of dynamic DLI that can adjust the horizontal position of players on the fly? Would it even be remotely possible to multiplex color regs and player/missiles horizontal on the fly in a game, or are we relegated to static displays using this technique?

[emkay]

Shawn Jefferson

 

 

Such a "kernal" or fullscreen DLI can truely multiplex all that is visual.

You can "poke" from the outside into registers to create colorcycling, PM movement....

 

 

A converting program has to check first, on which Scanline the colors are to create and to check how much colors are possible to create "on the fly".

Then the Overlay by PMg had to be figured out. After that the program has to check if a font inversion would help to create proper colorusage .

At last the "normal" registers have to be drawn.

 

The best quality you will gain by draw pictures special for this color mode. And I would really like to do so

[Bryan]

 

It won't be any good for that, because charmodes use ALL available cycles during the 1st line. The changes would only occur in the borders.

 

 

Heck! Is that a delirium why I see colors changing?

 

On the 160 pixel playfield, there are 80 CPU cycles (1 cpu cycle is 2 pixels). Antic takes 40 of them to read the 40 character codes (which are cached for the next 7 lines), and the other 40 to read the 1st line of character graphic data. There are no cycles remaining. Even RAM refresh is suspended on line 0.

 

Believe me.. I've tested this.

 

.ORG $0600-6
;Binary header

.db	$FF, $FF, $00, $06, ((end-1)&$FF), (((end-1)>>8)&$FF)


;$0600

lda #$00;We're never coming back!!

sta $D40E;Stop NMI's (NMIEN)

sta $D20E;Stop IRQ's (IRQEN)

ldx #$78

ldy #$38



loop

sta $D40A;WSYNC to end of line

sty $D018;RED red at right border

nop

nop

nop

nop

nop

nop

nop

nop

nop

nop;Wait for left border

stx $D018;BLUE

sta $D018;BLACK

stx $D018;BLUE

jmp loop	

end


;Make it run

.db	$E0, $02, $E1, $02, $00, $06 

 

The output can be seen in the picture (xlpic1). We never get a chance to go from RED to BLUE on the 1st line until the very end (after the last data byte is read by Antic). The next line is blue because we missed the WSYNC deadline for line 0. If you want to change colors in the middle of every scanline, you must use mode E instead of 4.

 

The other picture simply changes between 2 colors to show what cycles color changes can take effect (once again... notice that there are no changes on the 1st line of each row).

-Bry

[emkay]

@bryede

 

Would you change please the DLI for left WSYNC outside/before the "LOOP" and put commands directly(the fastest way) to change black, white, black, white ... for the first line. how much commands are possible until the colorchange will happen on the next Scanline.

[Bryan]

I don't have to. Look at the top picture. Do you see that there are scan lines where black or orange go all way across a scan line? Those are line 0's. That program does nothing but STA COLPF, STX COLPF in a loop and that's the screen it generated. Every 8th line has no changes on the line (by the way, these are normal Antic 2 text screens, same DMA rate as 4).

 

If you want to prove it can be done, it's up to you. Post some code. I'm in the middle of writing a Mode 4 program, and I ran into this a long time ago.

 

-Bry

[Heaven/TQA]

seems be be independence day... so people should have time to code or to barbeque...

 

at least i see some screenshots... this helps to understand how it works....

and these are a good starting point...

 

emkay: have you tried out GED?

 

bryde:

 

can you post the binary as well??? so i can check it in atari800win how accurate it is (emkay, i know amidarius is not 100% perfect running on emus)

 

the screenshots look like a 2600 kernel...

 

hve