Real Interlaced graphics on the A8 - getting closer

[atariksi]

Cool.

 

I've simplified the routine a bit and have 4 TVs here to test on. Trying to get common presets that work on all of them.

 

I'm going to make a version with a small number of presets... also do a bitmap picture instead of a boring text screen, might generate a bit more interest.

 

I tried "random" values at 54272 and did get a partial interlaced screen...

[peteym5]

Fascinating stuff, I have not gone into detail with this thread of how you get that. Would like to see the hardware modifications, what registers to modify, etc. I always thought Atari made it so the Antic chip could only do no Interlaced screens. I have played with APAC using 2 character sets and it did not slow down to the point to where Basic could drive things on the display.

[UNIXcoffee928]

Hi Rybags, great work! If you make up a self booting .ATR that prompts the user for machine type, & display (NTSC/PAL), then provides a "Worked? Yes/No prompt" after each setting is tried, you could then log the data to a text-based log file.

 

The log file just needs to id the program's version number, and have a delimited text setup, to reflect the user's responses for each field.

 

This way, you could then just collect log files from the testers, and you'll simultaneously eliminate the potential for error caused by multiple test program versions.

 

On your side, you can then run a short script to generate a report based on the submitted user log files, which would be text, and could be easily parsed, and used to populate a mini-database or table.

 

This would help to pinpoint where trouble areas are on each system, and would help you to to debug more rapidly.

 

I'm sure that you're already familiar with such testing concepts, but I thought that there would be no harm in mentioning it, since this program has grown in scope, audience, & practicality since it's initial idea stages, and a test like this could only help you to get a handle on how all of the options are effecting the various types of machines.

 

This type of testing may or may not be overkill, but it should only take about an hour, so it may be worthwhile to you. You could always re-use or re-release the testing/logging code & script tools later for other projects.

 

If its too much extra nonsense, then don't bother, obviously, but it may help you out, so I thought that I'd bring it up.

 

 

Thanks again for all the effort involved in this interlacing project, it's a cool idea!

[a8isa1]

INTV2B.zip

 

Can you try this one.

 

Works on my NTSC 800XL. offset=11 and field order=1 seems to be best.

 

BTW, your program crashes if running BASIC rev A (internal or external). Works OK with both rev B or C (both internal)

 

- Steve Sheppard

[a8isa1]

p.s. Your program completely confuses my scan converter (inexpensive TV/VGA converter)

 

 

- Steve Sheppard

Edited January 25, 2009 by a8isa1

[peteym5]

Would imagine this will confuse some VGA/HDTV converter devices, also doesn't work well on an emulator. Not totally sure what happens if its running on a NTSC or PAL. Have to test it on a real Atari here.

 

We can probably have it generate some nice fonts for like a work processor or increasing res for nice still pictures. Going beyond that would require some research on how much CPU usage this technique requires. Could probably double the res on PM graphics with 2 pmbases.

[Beetle]

The interlace mode confuses my "XL Laptop's" display, a 14" LCD TV (connected through Y/C) totally, as well.

It works on two 1084s i have.

[Rybags]

I'll try and get a standalone boot disk with a picture done in the next day... I was thinking maybe a 320x192 pic at the top of screen and a 40x24 half-height 8x8 character cells text window at the bottom of the screen.

 

CPU usage: all up it uses about 2-3 scanlines for 2 DLIs (in the latest iteration), and probably 3-12 or so scanlines in the VBI dependant on what Offset setting is in use.

 

That means little performance degradation, but means no simultaneous SIO and digitised music would need to be integrated into the VBlank if it was needed.

 

NTSC machines seem to just not have enough time to run the VBlank without some impact - I think the best fix will just be to disable the VBlank and run it as part of the second DLI, since the routine needs to have full control in the scanlines leading up to VSync.

Edited January 26, 2009 by Rybags

[supercat]

p.s. Your program completely confuses my scan converter (inexpensive TV/VGA converter)

 

Some decoders count the number of equalization pulses (even vs odd) to distinguish even and odd scan fields. The only way I see to make this thing work is going to be to look at a real signal and at what the A8 puts out to compare them.

[ijor]

Some decoders count the number of equalization pulses (even vs odd) to distinguish even and odd scan fields. The only way I see to make this thing work is going to be to look at a real signal and at what the A8 puts out to compare them.

 

I don't think any equalization pulses are being generated at all.

 

Conceivable, this might be the problem with some of the TVs. Equalization pulses are supposed to be required for an interlaced video.

[atariksi]

The 'scope I've got doesn't work properly and even then I don't know if it would be any good for TV signals.

 

I've got 192 KHz sampling on the sound card, so that's all I can go by unless someone else can help out there.

That gives you 12 readings per scanline, so you get a bit of an idea what's going on.

 

There seems to be some leeway anyhow... the Plus/4 method of doing interlace actually makes each second frame shorter... sampling them and graphing alongside normal samples shows them skewing away by half a scanline each second frame.

 

You could compare with the Amiga interlace signal which always works consistently. I timed the cycles/frame and going from interlace to non-interlace does not affect the total cycles/frame much-- (< one microsecond on NTSC C1084S monitor).

 

OS timers weren't that accurate. I tested this again using higher resolution timers and there's about 31 microsecond increase in field time in interlaced mode vs. non-interlaced mode (on Amiga).

[Rybags]

 

A 320x384 bitmap.

 

Not entirely happy with this one, probably won't go further with it... doesn't really show the full resolution well.

Might add some small text to it which might express the increased vertical resolution better.

 

Or, might just try something multicoloured instead.

[Heaven/TQA]

as I haven't tested yet the stuff on real machine... is this flickerfree or is it interlacing like I know it by switching 2 frames every 25/30 frames?

 

Sorry for newbie question but you guys discuss too detailed... and too deeply.

[ZylonBane]

as I haven't tested yet the stuff on real machine... is this flickerfree or is it interlacing like I know it by switching 2 frames every 25/30 frames?

There's no such thing as flicker-free interlacing, no matter what kind of interlacing it is.

[potatohead]

It's two frames every 1/30 of a second.

 

Frame one is all the even vertical lines, frame 2 is all the odd lines, for a double total of vertical lines. Each frame is 1/60 second.

 

No horizontal flicker.

 

Rybags, how much DLI time exists with the method?

 

Wondering about a full on interlaced 640 x 400 bitmap...

 

Nice job, BTW.

[Rybags]

It's "proper" interlace at least so far as what you're seeing is concerned.

 

But, it's probably not "proper" so far as the signal being sent to the TV... still working on that.

 

Flicker - yes, but as stated by ZylonBane, it is a natural property of normal TVs.

It is noticable with thin horizontal lines, lone pixels, especially in high contrast situations.

 

For something like a multi-colour picture in graduated shades, it should be barely noticable.

 

 

DLI time... the DLI itself is next to nothing. Maybe 3 scanlines worth of CPU. The VBlank is another story though.

Probably more like 10 scanlines or so. It's timing critical too, part of the reason I haven't got a proper NTSC version yet.

 

I'll might need to dispense with the system VBlank code altogether - the problem is that if you delay it's execution, it stores the Display List pointer when the screen draw has already started... which can cause the screen to shift downwards.

 

A potential cure though... put a DLI up the top of screen, which could store the DList pointer at a specific time to bring things back into order.

Edited January 28, 2009 by Rybags

[+Stephen]

Rybags - I got it working on my NTSC 130XE. I am going through a VGA convertor to an LCD monitor. There is an occasional jump where the convertor seems to lose V-Sync for a frame, but other than that it works fine. Sorry the picture is a bit fuzzy. I will try to make time this weekend to test it on my 1084S as well as my CRT television.

 

 

Stephen Anderson

[Rybags]

I have a feeling that some scan-doublers might produce a hi-res picture anyway without tricks, as per some LCD monitors and capture cards.

 

Can you try the same settings you have there, and turn the Interlace option Off and see what you get?

[Heaven/TQA]

aehm... which advantage does your method have instead of simply switching between 2 display lists, one containing the odd and one the even lines via vbi?

[Rybags]

Check the pictures... this is doubling the vertical resolution.

 

And not by some "trick" where 2 images are overlayed and it tries on eyesight tricks.

 

It's actually fooling the TV into displaying each second frame one TV scanline downwards, not one "Atari scanline" which is in reality 2 TV scanlines.

 

Of course, you have to alternate character sets, or between 2 images each frame because you need odd/even scanline information to be different to get the extra detail.

[ZylonBane]

Of course, you have to alternate character sets, or between 2 images each frame because you need odd/even scanline information to be different to get the extra detail.

You could also use this technique to simply get rid of the blank scanlines, producing more solid-looking graphics. The Bally Astrocade's display chip did this.

 

On the other hand, this would make the graphics look even more low-res than they already are, so I doubt anyone would want to do that.

[Fröhn]

Check the pictures... this is doubling the vertical resolution.

 

And not by some "trick" where 2 images are overlayed and it tries on eyesight tricks.

Interlace is a trick too. To really have 525 rasterlines @ 60 Hz you'd need... 525 rasterlines @ 60 Hz and not 525 rasterlines @ 30 Hz

[ijor]

Rybags,

 

Could you post, or PM, the source of the assembler routine?

The merit is already all yours no matter if somebody else happens to find the exact best values

 

I was meaning to do some tests on NTSC, but we could be much more helpful if we could "play" with the routine. At least we could verify easier if the DLI is too late or not. And I'm too lazy to dissasemble it

[Rybags]

A lot of the work I've done since the initial working one has just been modifying it within the debugger...

 

but I'll get something together to send over to you.

 

Like I've said before - NTSC might be a bit more effort. PAL gives you an absolute ton of time to run the OS VBlank before the routine takes control, then sits there waiting for another eternity.

 

NTSC doesn't quite have the same luxury - it seems that the OS VBlank has the machine at the same time I need it.

 

Solution I think is to just do away with the OS VBlank altogether. The only real loss is the keyboard debounce/repeat sequence.

It's not too much effort to just recode the stuffing of the shadow registers we need to keep updated.

[Rybags]

GTIA has its own horizontal counter. The counter is reset when a transition to Hblank code is received. But GTIA also resets the counter on its own on 227 value (this means that GTIA can keep horizontal timing without ANTIC). Horizontal SYNC is derived indirectly from this counter, not directly from any AN code.

 

GTIA has composite sync only, no separated HSYNC and VSYNC. Both internal SYNC signals are combined just befored driving the CSYNC pin. Note that composite SYNC is possibly quite relevant to the issue.

 

I think this horizontal counter is the key to it all... my routine works by changing Antic's DMACTL width settings (0,1,2, or 3) in the leadup to VSync.

Could it be that somehow, by engaging the 240-scanline bug that Antic itself can become confused in that screen region outside the normal 240 lines we can control. I've found that the most stable screen setting is to have Antic in Widescreen mode when the bug is engaged.

 

Is composite sync a simple logic level switch, or an variable voltage?

Also - how does GTIA know to display "Black" (ie not background, but Black) outside the normal 240 scanlines we have control over? Is Antic outputting the VSync code on AN0-AN2 for the duration? Or is something else happening?

 

I've enclosed the latest version of the Basic+Asm program. Sorry about the lack of source code at this time.

 

INTV3.zip

 

But, I can easily explain what happens, and what needs to be done.

 

Firstly, 2 copies of the OS character set are used, at $8000 and $8400. The DLI switches between these once per frame. The "F" Field swap option merely changes the swap order.

 

I've made a new version of the DLI. It resides around $3FF0-$4031. It executes twice. First instance is near the top of screen, to put Antic into Normal DMA mode.

Second instance is to engage the 240-line bug.

You can cause the bug by turning DMA off during the last line of a hires mode. Doesn't need to be on scanline 240. Just so long as there's no more graphics modes for the remainder of the screen, this method will work.

This is only required to be done every second frame. By doing so every frame is kinda pointless, since all it would do is move the entire screen down by a scanline all the time.

 

Next - the VBI ($40F0-$415F)

The OS VBlank is sort of misnamed - it occurs well before VSync on PAL, and several lines beforehand on NTSC.

Anyhow. First thing is it stores an initial DMACTL value from $600.

Next thing, it waits for VCount to hit a predetermined setting (as per the onscreen value in the program).

After that, it stores from the table starting at $601, into DMACTL 3 times per scanline.

Note that we now have an "Offset" setting... this affects the starting index into the table, and also how long the routine runs.

 

Other important stuff...

. It's a good idea to set PF1 and PF2 values to $00 outside of the normal display area. Engaging the line-240 bug causes PF0's colour to be displayed (as if we were in Graphics 8 with an area filled with pixels).

 

. In such case you dispense with the OS VBI as I suggested... don't disable it, just JMP $E462 from your Immediate routine.

It will become necessary to do some shadow register stores manually. Important ones are DMACTL, the shadow DList pointer ($230,231) and the colour registers.