148 replies to this topic

[Synthpopalooza]

There are two possibilities for this:

In bitmap mode you would need to have a custom display list set to Graphics 8, where an LMS instruction is used to repeat the preceding screen line (i.e. you LMS to the address of the preceding line).  This creates a 320x96 graphics 8 screen.

Next, you set DLI's so that the GTIA alternates between 9 and 11 every two scanlines.

Then you flip two screens, and also change the alternation of the DLI's so that 11 and 9 swap intervals.  This should get you a 80x96 screen in 256 colors, although it will flicker, tho not as bad as full-frame.

In character mode, you can use Antic 5 and flip character sets and GTIA between 9 and 11.  You only get 144 colors though because of the reduced color resolution under Antic 5, and it will flicker more.

[flashjazzcat]

NRV, on Tue Oct 25, 2011 10:49 AM, said:

Sounds like flicker hell...
If your gtia11 lines have the luma in 0 and some parts of your gtia9 lines use the luma in 15, you are going to have the "worst case" for flicker (alternating pixels of luma 0 and 15).. you could use luma 8 for gtia11, to average the flicker, but then I don't know how black will look.
I did this many years ago to do a "horizontal rainbow effect" and it didn't look that bad in some small parts of the screen.
Sure, in Altirra with frame blending is going to look like real 256 colors (but with the luma averaged between the two screens), but in a full screen of a real PAL TV...

Right on all counts. I did some experiments with it today and nearly threw up looking at it. The TFT monitor took some moments to recover after I'd pressed reset.

Synthpopalooza, on Tue Oct 25, 2011 11:19 AM, said:

There are two possibilities for this:

In bitmap mode you would need to have a custom display list set to Graphics 8, where an LMS instruction is used to repeat the preceding screen line (i.e. you LMS to the address of the preceding line).  This creates a 320x96 graphics 8 screen.

Next, you set DLI's so that the GTIA alternates between 9 and 11 every two scanlines.

Then you flip two screens, and also change the alternation of the DLI's so that 11 and 9 swap intervals.  This should get you a 80x96 screen in 256 colors, although it will flicker, tho not as bad as full-frame.

I tried all of the above apart from changing the alternation. I might experiment with that idea next. Thanks for the suggestion!

I'm also working on a time-machine in order to go back to 1978 and convince the Atari engineers to implement a colour attribute system and half colour-clock chroma changes.

Edited by flashjazzcat, Tue Oct 25, 2011 1:45 PM.

[NRV]

flashjazzcat, on Tue Oct 25, 2011 1:39 PM, said:

Right on all counts. I did some experiments with it today and nearly threw up looking at it. The TFT monitor took some moments to recover after I'd pressed reset.

hahaha can "almost" picture that..
(you can always add the option to render like that to your Gui project.. I mean, if you have any enemies in atariland)

flashjazzcat, on Tue Oct 25, 2011 1:39 PM, said:

I tried all of the above apart from changing the alternation. I might experiment with that idea next. Thanks for the suggestion!

The "alternate lines" seems to be a good idea, I would like to try it sometime. In your case, as you have a "tall" pixel of two scanlines you could alternate between one frame with the pixel with the first scanline in gtia9 and the second in gtia11, and the next frame with the same pixel in gtia11 and gtia9 order.
Hmmm that's going to look funny in PAL now that I think.. because of the pal artifacting, every time you have a zone of gtia11 followed by a zone of gtia9.

flashjazzcat, on Tue Oct 25, 2011 1:39 PM, said:

I'm also working on a time-machine in order to go back to 1978 and convince the Atari engineers to implement a colour attribute system and half colour-clock chroma changes.

while you are at it, can you include 8 players (everyone with a color register) instead of 4 players + 4 missiles? and gtia 10 with 16 color registers?

thanx..

[flashjazzcat]

NRV, on Tue Oct 25, 2011 2:07 PM, said:

The "alternate lines" seems to be a good idea, I would like to try it sometime. In your case, as you have a "tall" pixel of two scanlines you could alternate between one frame with the pixel with the first scanline in gtia9 and the second in gtia11, and the next frame with the same pixel in gtia11 and gtia9 order.
Hmmm that's going to look funny in PAL now that I think.. because of the pal artifacting, every time you have a zone of gtia11 followed by a zone of gtia9.

I'd forgotten about the (in this case unwanted) PAL effect, but I'm testing this on a VBXE 1200XL at the moment, so I haven't encountered the colour blending issue. What really worries me is the whistling sound the TFT monitor makes when I'm running this thing, and the fact the normal screen still shudders for a few seconds after I press Reset. I'm sure it's not my eyes!

Actually, if the lumas are kept muted, it's not as bad, but I haven't got the alternation correct yet. I wasted quite a lot of time earlier trying to use the vscroll trick to get double-height mode lines, without success. At the moment, LMS instructions do the same job. The DLs are just a bit more of a palaver to set up (mainly because they're so long).

Quote

while you are at it, can you include 8 players (everyone with a color register) instead of 4 players + 4 missiles? and gtia 10 with 16 color registers?

How's about a mode 7 with bitplanes so we get 160x96 in sixteen colours too!

Actually this interlace may not look too bad at all, but high lumas are going to be a no-no, unless the base hue of the mode 11 lines is raised (I suppose this will give an even more pastelly effect).

Managed to get something going on the LCD using the contents of the OS ROM as screen data, which isn't ideal:



The bright lumas are MUCH worse on a CRT - it looks really brutal on my SC1435. I haven't tried normal s-video output yet. But I'd like to see what a photo looks like - I just need two 4KB bitmaps in the requisite format, hint, hint!

Edited by flashjazzcat, Tue Oct 25, 2011 3:00 PM.

[Synthpopalooza]

I think a normal APAC mode picture will work for this.  The format for APAC pics is:

40 bytes of mode 11
40 bytes of mode 9

Repeat the above two items 95 more times.

so 40 bytes to screen 1, the next 40 bytes to screen 2, then the next 40 also to screen 2, the next 40 on screen 1, etc.  This is to account for the 2nd line interlace.

I'll have to look and see if I have any APAC pics.

I just remembered another method that was used on Jeff Potter's APACVIEW:  Set up normal APAC mode but then flip one of the skip scan line instructions in your display list every vblank, changing it from 8 to 7 blank lines.  This will shift the display up and down by a scanline every VBLANK and create tall pixels.

Just thought of something else:  You could use this method or my Antic 5 method also, in HIP mode, to create double line hip pictures.  The idea this time is you do Mode 9 + mode 10 every 2 scanlines, or flip those modes and character sets when using Antic 5.

Edited by Synthpopalooza, Tue Oct 25, 2011 5:56 PM.

[flashjazzcat]

The problem with APAC is that not only does it not work on NTSC machines, but VBXE's RGB output won't display it. Nevertheless, it seems the obvious choice for flicker-free full colour video frames.

If it weren't for the appalling flicker, the blended full-frame interlace with double-height pixels looks nice and "solid". No such thing as a free lunch, I suppose.

[Rybags]

It works with VBXE if you're using an RGB to S-Video convertor.

Problem is though - VBXE has a known bug where in GTIA colour mode, colour 0 takes it's luma from COLBAK instead of always staying at 0.
That's not a problem if using luma = 0 but in some cases APAC looks better with luma = 2.

Re - moving entire display up/down 1 scanline in APAC.  I've done that for a long time, it's a mixed bag of results, generally works better in pics where the average luma is higher.

[flashjazzcat]

Thanks Rybags - I wasn't aware of the COLBAK bug. Maybe Candle has fixed that in the upcoming core release? I asked him about emulating PAL blending too, but apparently there's no room left in the FPGA for a line buffer.

Clearly all these solutions are a bit of a mixed bag. Talking of VBXE - there we have all the graphical capability we need to display video frames, but no means to pull the information off the HDD fast enough (certainly not at 64KB per frame). DMA controller required...

That's one good argument for persevering with the legacy modes.

[Rybags]

Yeah, the fix for COLBAK is probably simple but apparently there's no room left.

One workaround, somewhat of a pain, would be to use all the PMGs to override and give black, but they're often wanted elsewhere.
Although on the other hand, it's VBXE, so an overlay with a single black scanline repeated 240 times could be used with GTIA having priority, only COLBAK should get overridden.

Same reason for the linebuffer... if it could be done then we'd probably also have a fully-functional VGA version on 14 MHz master clock.

[flashjazzcat]

An optional core with PAL blending, COLBAK fix, etc, would be useful even without the extended FX capabilities. Anyway - I guess we'll see what Candle comes up with.

[1NG]

flashjazzcat, on Wed Oct 26, 2011 5:35 AM, said:

An optional core with PAL blending, COLBAK fix, etc, would be useful even without the extended FX capabilities. Anyway - I guess we'll see what Candle comes up with.

I take one!

[flashjazzcat]

1NG, on Wed Oct 26, 2011 11:48 AM, said:

I take one!

I hope Sebastian is watching.

[Synthpopalooza]

1NG, on Mon Oct 24, 2011 4:05 PM, said:

I coded something in between in the last minutes with a little less flicker: mou_itlc.xex
switches mode every character line (which is every 8 screen lines). This ensures less pumping of the screen, because there is always the nearly the same amount of light and dark areas on the screen. Enough for today ...

Finally checked it out today.  You should also change COLBK (712) every character line.  It should be mid grey in mode 11 and 0 in Antic 4.  This mixes the colors better.

[Synthpopalooza]

Hey again ...

Just to let you know I am about to try some more picture rendering experiments.  With some developments from G2F and Atari Interlace Studio (two very excellent programs) I believe I am ready to try rendering some pictures using the Super PCIN and Super 10+ modes.

Super PCIN is one of the most interesting and complex modes to display in that you have to switch Antic 4 with Graphics 10 every VBLANK ... which gives you about 34 colors at Antic 4 resolution (less than Super CIN), but because no color palette chages are done, it should be possible to reduce the flicker with this mode.  The key is to render a Graphics 10 bitmap, convert it to fonts, then render a G2F with the same picture in Antic 4, and be sure to choose the 4 most prominent colors from the Gr. 10 bitmap to use in the Antic 4 render.  The flicker can also be reduced further by using a chekerboard dither pattern in areas of the picture where the characters use PF0-PF3 in both instances.

Super 10+ should also be interesting.  It's Graphics 10 in text mode (ANTIC 2), but with 8 palette changes every VBLANK (705-711).  Combining this with a bankswitch on the 130XE should display a whole picture at Graphics 10 resolution but with 80 colors onscreen at once.  The render will be accomplished by using Atari Interlace Studio to render Graphics 10 bitmaps from a picture, but selecting different base colors for each render, for 705-711.

I also have an idea for a picture format .IFP and a viewer which will display these sorts of pictures.  Should be fun ...

More to follow ...

[Stephen]

Sounds interesting.  I look forward to following your progress.

[Synthpopalooza]

ok, first test is to try to do this C64 pic:



I rendered this in Graphics 10:



And this in Gr. 12



making sure values for PF0-PF3 and the background are the same in both images.

This is a preliminary PCIN pic:



It looks ugly now because of 3 things:

1.  Top 4 rows have been cut off (???)
2.  The PF3's cause conflicts in the gr.10 font, I will need to fix this
3.  There is a GR 10 pixel shift (like in HIP), the GR. 12 pixels will need to be shifted one color clock right to compensate.

More tomorrow

[Synthpopalooza]

Some progress:



I changed some color registers to make the picture look better, and now the PF3 inverse conflicts have been fixed.

Still to do:

Shift the Graphics 12 pixels to the right by one color clock so that the display lines up properly.

Dither the areas of the picture where PF0-PF2 (or PF3 in the inverse chars) mix with each other.  This will reduce the flicker even more.

[Synthpopalooza]

More progress:



Now the pixels have been lined up.  There are some artifacts on the left side, that can't be fixed.

Next, fix the colors some more, then do some dithering ... next post will have an .ATR

[Synthpopalooza]

Did another PCIN pic, this one looks better.

Original, from the Atari ST Space Ace:



The converted PCIN pic:



All but the last 4 char lines will display, but this picture will look excellent when dithered.  This would be a terrific mode to do Space Ace in, the colors are great and the flicker will be minimal.

The bottom 4 lines of the pic are in this:

6

One way around the limitation of 20 char lines may be to use 130XE 128k and bank switching, switch all 6 font sets at once.

Time for bed

Edited by Synthpopalooza, Wed May 2, 2012 11:16 PM.

[Synthpopalooza]

I have finally gotten .ATR's for both pictures.

Both pictures have been dithered and are viewable with these files.

On spacepin.atr run D:SPACEPIN.TUR and D:SPACEPI2.TUR
On stoneage.atr run D:STONEAGE.TUR

These disks contain screen maps plus ICE font files which can be loaded into ICECIN.TUR which is available in this thread:
http://www.atariage....uc#entry2403791

I would be curious to see what results are gotten on real hardware with these.  On emulators, these are best viewed with Altirra v 2.0 or later with frame blending on.

Here is another PCIN picture:

Original ATARI ST pic:



PCIN picture:



No dithering has been done yet, and there are inverse conflicts to fix about 2/3 down the picture, specifically the white areas, including Ace's clothing.

So the basic steps to doing PCIN pictures:

Get a good looking Graphics 12 font picture using G2F
Use Atari Interlace Studio to do a Graphics 10 bitmap, making sure PF0-PF3 and background are identical to the Graphics 12 picture

Dithering should be done on areas of the picture where PF0-PF2 (or PF3 on inverse chars) are blended together to reduce flicker.
Also set the Graphics 10 display list for horizontal scroll and HSCROL to 13 to fix the pixel shifting problem in this mode.

Currently I can only display 20 lines of character ... this could be increased with font optimization or a utility like 1NG's GraphicsTileMaster.

Attached Files

•  pcin-pictures.zip   89.14K   55 downloads

Edited by Synthpopalooza, Sat May 5, 2012 10:16 PM.

[Synthpopalooza]

There is now an .ATR for the most recent space ace pic:



The inverse conflicts are fixed, and the picture has been dithered ... in particular, the mid-level shade sky part on the left where PF0 and PF1 blend together.

Here is the ATR ... run D:SPRUN.TUR

I would be most interested if others could report what results this brings on a real Atari.

 sprun.atr   90.02K   59 downloads

[AtariNerd]

Looking great. I think many are still trying to wrap their heads around how these interrupt driven modes work  and how to work them into programs that might use those for other purposes- I know I am, but I'm not a coder, so.... Give people a chance to play around with the tools and they may find their way to acceptance. Kudos to you, for exploring  things others haven't, so much,  and doing the needed experiments  to gather the insight on how the Atari functions in this regard. Knowledge is power, as they say..and the more you know.

[Sikor]

Great work, Synthpopalooza. Bigest problem in SA is make full animation, but I think, that it is possible.

[Synthpopalooza]

The thing is, it doesn't have to be a 25 fps animation like on the arcade game ... The Atari ST version gets away with less, from what I can see.  Plus, there are some scenes which are mostly static, where the only elements which change are the characters and the lasers and whatnot that get fired ... so maybe some kind of optimization engine could save a lot of KB.  And again, store everything you can in extra memory and do bankswitching as necessary.

Or, maybe do the PCIN mode in lo res.  I haven't experimented with it yet, but it is possible to render PCIN in Antic 5 (I call this PCIN IRG).  On the Graphics 10 side of the display you will still get all 9 colors, but they are paletted in a similar fashion as the playfield colors in Antic 4/5 ... this means, You get 7 of the 9 Gr. 10 colors per char. cell, but you can't have P2 (705) and PF2(710) in the same character cell as P3 (706) and PF3 (711) ... the latter two color registers replace P2 and PF2 when using inverse characters.  The tricky thing will be resolving PF2/P2 and PF3/P3 conflicts in the screen where the colors overlap and cause problems ... again, more experimentation.

I'm not sure how it would look, but if necessary it could also save some KB.

Edited by Synthpopalooza, Mon May 7, 2012 3:03 PM.

[Sikor]

I think, that about 12FPS will be o.k. for this game on little ataris.