Mail Archive - Plus/4 World



	Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum	Login

Previous | Next

From: TLC (all posts)
Date: 1998-05-29
Subject: Re: NTSC on PAL...

Hi!

[Your routine]

Yes, I see the point. Your routine waits for $ff1d being equal with 02.
When it reaches, it make the counter jump forward by 2. And it waits for the end of the frame.

Since you wait for $ff in the end of the loop, the check for
$02 in $ff1d will actually catch the value $0102 (since you don't examine $ff1c). So where you do this jump is actually the vertical retrace part, not the beginning of the main screen.

What it should be, I don't really know - but it seems like you jump over a checkpoint of the TED and that's why it keeps on generating horizontal blanks twice for each scanline.

It's interesting to know, however, it is a similar thing like the VIC-II-
like bordereffects. I haven't known this, I bet nobody knew it (except TCFS). ...I guess it's place is a complete TED doc ( I mean, something like Christian Bauer's VIC-II article).

> Still, setting NTSC MODE on PAL plus/4s speeds up crunchers, fractal
> creators and other routines w/ many calculations to be done enormously.

I meant, __regular __NTSC __Plus/4 with the __appropriate 14.31818Mhz crystal.

Obviously, a PAL Plus/4 with it's 17.773Mhz crystal will run a lot faster when setting it's TED to NTSC mode. But it also won't generate regular NTSC videosig for you at all.

> It's also possibble to switch only parts of the "screen" to NTSC MODE and
> leave like one charline for controlling output data or something like
> that. Btw, I read in an ATARI ST DEMO that, the NO (upper and lower)
> BORDER FX was done by switching to NTSC MODE... Has anybody tried this on
> plus/4? I think it could work like the switching between 24/25 lines
> display to achieve a NO BORDER FX. (It was the only ATARI DEMO I ever saw,
> done in 1987 by TEX!)

Hmmm, I have something better. This is an idea, I never realised it but I invented it just back in '92. Maybe, Larry even wrote such a routine but he also never released it in a demo.

In these small Commodore computers, all clock signals are derived from the same base. That means, at least, in Plus/4 all signals are derived from the 17.773 or the 14.31818 crystal. Seems like even more is true - most of the signals are in relation with the clock divisor part's output too. ...It means, that not just the processor clock, but the timers, the sound generators and the video timing is affected also by the actual setting of the PAL/NTSC switch in the TED.

What I'm trying to explain, that not even the processor clock, but also,
the dot clock will be faster when you set the PAL Plus/4 to NTSC mode.
What should that mean? The faster the dot clock, the smaller the pixels are on the screen. ...We have some thinner pixels? ...Boy, that means: we raised the horizontal resolution of the screen!!!

Since the clock divisor is 10 in PAL and 8 in NTSC, that means, each
4 original pixels will now make 5 pixels, or in other words: our trick resulted in a better horizontal resolution by 5/4. So in overall, we have 400 pixels in width instead of 320. Combining this with real Interlace, the Plus/4 is able to do real 400x400 (or more, with overscan)!
And, all this was done by software only!

Well, realising it is some more hard than it hears at first. Since the synchs go mad when you set the NTSC TED mode, your program has to equalize the line length by writing to $ff1e in certain positions.
This is just the smaller problem. The harder thing is, the TED was originally organized to fetch only 40 bytes per line. That means, even if you made some extra pixels, the TED doesn't want to fetch screen memory for the new area. The bitmask fetch can be overridden (I tried it), but the color memory and character pointer fetches (I mean, 'bad lines') are much harder to convince. I never managed to do it. ...Hmmm, since it has something to do with the way as sideborders can be removed, first I'd ask if Crown has some better results with his 40+2 chars wide screen.

Speaking of the colors, I believe it should run without problems.
The reason, the color subcarreer is still derived from the 17Mhz crystal.
So it should still match the standard. ...Or, if I'm wrong: not at all,
but it should be checked. My monitor didn't mess the colors when I tried this equalizing thing.

Hmmm, also, I won't be a happy emulator-writer if I read such postings about these tricks :-). I guess emulating a TED will need a lot of different methods than actually, a VIC-II emulation utilizes. It's because, you are free to play with the lowest level things in the TED, affecting even the synchrons and all such things.

Well, happy coding :-)

Levente