New Demo release - MemoPad 480i

[ivop]

I came accross this just now. Here somebody else retouched the Atari 8-Bit font to 8x16:

 

http://www.stevechamberlin.com/cpu/2009/01...fun-with-fonts/

[Kaz atarionline.pl]

Here's a kind of practical implementation demo of real interlaced mode on the Atari.

 

Rybags, your idea was spreaded by Pavros. He wrote an interesting article about mode E+ (extra color for background) and 300/i600 mode for PAL.

[Rybags]

Thanks, Kaz.

 

I only had a brief play with PMGs while playing with the Interlace mode. They don't work "normally" of course, because GTIA expects the HSync signal from ANTIC which alerts it that the next HALT sequence will be for the DMA fetch of the data.

 

But, not all is lost... you should be able to resume normal PMG DMA conditions by setting the Playfield Width bits to "11" (3).

 

By doing so, Antic should generate normal scanlines - of course they'll have the unmodifyable data going through to GTIA, to counter that you simply set PF0 and PF1 to colour 00 (as I do anyway).

 

The other problem is that you still need to do the VSync stuff - leaving the Playfield DMA enabled during VSync means that a proper VSync signal isn't generated.

 

That's easily countered too - just ensure that you set DMACTL back to 00 a couple of lines before VSync is due.

 

The timing is critical when you change DMACTL back to 00 because if it occurs during the display portion of a horizontal line, GTIA will receive a HSync command which can cause screen corruption if not done properly. The time to change DMACTL back to 00 is during HBlank - that way, the normal sequence of events shouldn't be disrupted.

 

 

I was planning to do a "Interlace (480i) - How to..." guide. Suppose I should get back to it.

 

All these other software modes around calling themselves "interlace" doesn't help either... just serves to confuse people as to what this and the other modes are actually doing with the hardware.

[Kaz atarionline.pl]

I was planning to do a "Interlace (480i) - How to..." guide. Suppose I should get back to it.

 

Great idea.

[Rybags]

Seems I was a little bit wrong in the last post - Antic doesn't appear to do PMG DMA in the offscreen area.

 

Outside the normal 240 scanline area, the GRAF Registers would need to be manually loaded.

[fibrewire]

has this interlace routine been considered for FJC gui?

[Rybags]

I think I suggested it early on, but:

 

- you then have doubled RAM requirements for fonts and the graphic screen.

 

- there's no provision yet for SIO to continue working. Standard speed could probably be catered for (with some occasional graphical glitching), high-speed SIO might be more of a problem.

The interlace routine needs to just burn away CPU cycles between when it gets control in VBlank Immediate and when VSync is generated by GTIA. On PAL machines this equates to a fair percentage of the frame (probably >10%). Of couse, other work can be done but the timing is critical.

In a GUI, it might be OK to use a Pokey Timer and return from the VBI, but the SIO issue will still exist.

[flashjazzcat]

Double vertical resolution isn't much use in the GUI unless it's accompanied by doubled horizontal resolution. All 400 lines would do - as Rybags points out - is eat more RAM and CPU time. Everything would take longer to draw, the icons would have to be 16x32 instead of 16x16 otherwise they'd have the wrong AR, etc, etc.

 

An interlace which gave us an effective 640x200 would be twice as useful in a GUI, since it would do away with horizontal scrolling in text documents (we're using the same 72dpi that the Mac used, so an A4 page is 512 pixels wide). Of course, VBXE provides us with 640x200, but it's also a 4bpp mode... but the GUI needs to run on a stock machine.

 

Re: CPU cycles - the mouse driver already eats them (via DLIs), but with the balance just right, I feel. A long VBI process, however, might just tip the balance.

[fibrewire]

What if there was a helper chip in the cart like the SuperFX for the SNES? Too bad you can't VBXE in a cart...

[bugbiter]

I'm impressed! Could anyone explain the secret how you get the atari to shift the tv display 1/2 a scanline?

[tebe]

source code example ? how create interlace with this method

 

or this is TOP SECRET

[Rybags]

I'll have a dig around, been a while since I created anything with it.

 

Not sure if there's any one source documenting the method. What it comes down to is some cycle-precise stuff over 3 scanlines or so, and the before/after part of looking after the display.

 

And, no, don't want to keep it secret. Would be so good if 480i support came to programs like RastaConverter and G2F, that would help make it more widespread to say nothing of helping to put C64 into it's (2nd) place.

Edited May 17, 2016 by Rybags

[tebe]

I do not want to reinvent the wheel

[Bryan]

Rybags, your idea was spreaded by Pavros. He wrote an interesting article about mode E+ (extra color for background) and 300/i600 mode for PAL.

I tried to read up on mode E+ and couldn't find the article. Anyone got a working link or more info?

[tebe]

https://github.com/epi/ivbconv/blob/master/ivb2.asx

[Rybags]

Ah... I don't know how that ended up there. But yeah, the important stuff is in there.

 

The magic mostly happens between just after label "not_ntsc" and "vblankend".

I wrote this I think before Altirra existed or at least had decent debugging. I did the cycle counting by hand and have never verified the required cycle-exact timing to be correct but the results on analog TV seem to suggest I got it right.

 

I'll still see if I can dig up Memopad 480i source. That was the first meaningful program I did with 480i aside probably from the test stuff and static pics.

 

I guess while I'm in there, may as well see if I can find the source for Stellar Shuttle. Although it's a bit of a mess, I think I did that as added on code and a series of patches with source that was generated by a big list command from Atari800Win+ so it's a bit messy.

[Kaz atarionline.pl]

Bryan, old links are archived for now. When new AtariOnline.pl layout will be changed, all old links will back.

[Bryan]

Bryan, old links are archived for now. When new AtariOnline.pl layout will be changed, all old links will back.

Okay, thanks. Does anyone remember what mode E+ was?

[Rybags]

Memt617a.zip

 

I think this is the latest version of the source code. I developed it using AtAsm but it should be short work to convert to MADs.

 

There's a seperate resource that has 2 chunks of bitmap data used for the logo at the top (even/odd scanlines in seperate blocks). I've got the original bitmap as 8-bit BMP but can't seem to find whatever it was I used to build the final executable.

But it's not vital to get it working so I'll upload it later if I can find it, or alternatively just build some raw data files which can be included with INCBIN.

[tebe]

thx Rybags

 

in attachment mads version

Memt617a_mads.zip

[Rybags]

I just realised, in addition to the logo the resource for the character sets is missing.

 

I have BMPs of everything, I can't remember how I got them to bare binaries... pretty sure I would have used a Basic program to generate them.

The important stuff is in the source though, you could easily enough just get the needed resources by extracting from the earlier executable file.

[+Stephen]

I just realised, in addition to the logo the resource for the character sets is missing.

 

I have BMPs of everything, I can't remember how I got them to bare binaries... pretty sure I would have used a Basic program to generate them.

The important stuff is in the source though, you could easily enough just get the needed resources by extracting from the earlier executable file.

WUDSN should be able to go from your BMPs to whatever format you want the font data in.

[Rybags]

I'll have to look at the program but fairly sure it doesn't do any processing on the font data.

 

The fonts themselves alternate between fields, one displays scanlines 0, 2, 4 etc. and the other displays scanlines 1, 3, 5 etc.

Not sure if there's many tools around that will deal with that requirement. Plus the way I have them in the BMP isn't suited to easy extraction either.

Pretty sure I just did a Basic program that did a linear read of the BMP and placed into memory the way it was needed, then just save the data out as resource files.

[+Nezgar]

A little late to this party, but just came across this had HAD to try it on my real hardware. (320XE) The prospect of this is amazing, would have been fantastic to have 48 line text screens in the BBS days!!

 

I had a cheap LCD monitor connected via RF, and simultaneously a Commodore 1702 monitor. The commodore monitor unfortunately refused to do the interlacing no matter whether it was connected via Composite video or Separate Luma/Chroma. Both fields draw on top of each other, making the small text essentially unreadable.

 

However, the cheap LCD monitor would pick up on the interlace signal, and did successfully display the full 480i, and the smallest text was extremely legible. Problem I had was 50% of the time, it would pick up the wrong field order, so it took a few resets of the progam / power cycles of the monitor to get it to decode the field order properly.

 

Bellow are snaps of what the same text looks like on the C1702 (failing to interlace) and the same video on the LCD. The third is an example of how incorrect field order affects Stellar Shuttle... Again, I could correct this manually with a but of fiddling with resets / power cycling the LCD etc.

 

EDIT: Apparently I missed the bit in the original post about use of function keys to toggle interlacing on/off, field order etc. This might have been a little easier to tweak things.

Edited April 4, 2017 by Nezgar

[woj]

Necrobump! I got severely interested in this for reasons I do not want to disclose yet, I also got the sources for the MemoPad 480i and the VBXE 480i demo, I roughly do understand the method (even though my understanding of CRT displays and depths of Atari graphics are rather superficial). 

 

Before I dive into my own small project (which I do not think I will be able to complete within 5 years), the up-front question that I need to have answered, probably by @Rybags himself  -

 

Both programs work with normal field width of Antic, would the waiting dmactl on/off timings be the same if one goes narrow field, or will it all need to be recalculated from scratch?

 

Further on, I did search with little luck, is there any more documentation / resources on the technique other than this thread and the other one and the associated ASM sources?