Jump to content
Jagware
Zerosquare

Haute Résolution Sur Jaguar (et Mode Entrelacé)

Recommended Posts

Zerosquare    10

[Français]

Voilà une petite démo d'image en 688x576 ; pour le moment, ça ne fonctionne qu'en mode 50 Hz.

Le code est assez mauvais, je le rendrai dispo quand il sera nettoyé. :)

EDIT : certaines personnes ayant eu des problèmes avec le format COF, j'ai rajouté une version en .BIN (à charger à l'adresse $4000).

 

[English]

Here is a small demo of a 688x576 picture ; it only works in 50 Hz mode for the moment.

The code is rather bad, I'll release it once it is cleaned. :)

EDIT : some people have reported problems with the COF format, I've added a .BIN version (upload at address $4000).

HiResDem.zip

HiResDem_bin.zip

Share this post


Link to post
Share on other sites

Thanx for the email zerosquare..

 

..hmm my routine had the same kind of "flicker" in the text.. I guess it is because the text is so thin.

Guess interlace gfx needs to be made with some restrictions...to not flicker that much.

 

 

Some thoughts:

--Hmm i never tested my rout in 60Hz, but it also didnt work.. ?.. was a bit surpriced.. since the method has nothing to do with the framerate, so i kind of assumed it would work.. but did not..

So if someone wants to make a "European game ONLY" then here is a way to do it =)

It needs to be debugged in 60Hz to se if it is possible to do Highres on an US jaguar...

 

--It is said that the OP in interlace mode skipps every other line.... but that i never got to work, so i worked my way around it.. what about you?

 

--and then there is that "interlace vbl irq" thing... but that i guess you figured out ;) ... (i dont understand that eor you do but aparently it works =)

 

regards

/Sym

Share this post


Link to post
Share on other sites
Zerosquare    10
Thanx for the email zerosquare..

 

..hmm my routine had the same kind of "flicker" in the text.. I guess it is because the text is so thin.

Guess interlace gfx needs to be made with some restrictions...to not flicker that much.

You're right, it's not a problem with the code or the Jaguar, it's an inherent limitation of interlacing. Video cards with TV-outputs use a vertical "smoothing" filter to alleviate the problem, and computer-generated graphics for TV broadcasting are made with this in mind (images from video cameras are usually OK as-is, since they rarely contain sharp vertical edges).

 

Some thoughts:

--Hmm i never tested my rout in 60Hz, but it also didnt work.. ?.. was a bit surpriced.. since the method has nothing to do with the framerate, so i kind of assumed it would work.. but did not..

So if someone wants to make a "European game ONLY" then here is a way to do it =)

It needs to be debugged in 60Hz to se if it is possible to do Highres on an US jaguar...

There are 525 lines per frame in 60 Hz instead of 625 in 50 Hz, so a few values have to be modified. Not tested it yet, I need to locate a 60 Hz-ready TV set first :)

 

--It is said that the OP in interlace mode skipps every other line.... but that i never got to work, so i worked my way around it.. what about you?

Same thing. I guess that's either an error in the documentation, or a bug in the chip (Atari didn't seem to care much about interlacing, so maybe they had not tested it extensively).

 

--and then there is that "interlace vbl irq" thing... but that i guess you figured out ;) ... (i dont understand that eor you do but aparently it works =)

So you disassembled my code, uh ? :D

Sorry then for the horrible coding style (recycled Atari example + first 68k code for me).

The EOR is just a quick way to toggle between two different values :)

 

regards

/Sym

Thanks for the comments !

Share this post


Link to post
Share on other sites
GT Turbo    5
Cool so 640 x 480 with borders could become a new standard then :)

 

:yes:

 

High res game ? The new standard on Jag ? Hope you're right TXG / MNG, I hope too that will be used by a lot of people, that can give very nice picture :yes:

 

 

 

GT :poulpe:

Share this post


Link to post
Share on other sites

Well as long as the graphisist dows not create any single horisontal white line (odd frame white, even frame black) it should be ok... but usual graphis usually never contain that.

 

Hmm. perhapps my code wasnt as versetile as i thought.. though the trickery I do to setup the registers probably need to change for 60Hz.. thats true..

 

regarding "OP interlace bug":

there are a number of ways to make this:

--set dwidth to twice the size of the picture, but only display width pixels... then each vbl change the start position of the first pixel.

(the one i used)

 

--The 2nd a bit more "hacker style" woudl be to do a pre-processing of the picture separating the odd&even lines into two pictures "on top" of another..

So 1st picture (say 640 width.. and also dwidth) only contains even lines... the secound picture (640*480*2 bytes away in memory) contains the odd lines...

 

THEN! ..you could actually utilise the other OP bug in your favour and you would only have to update the height variable in the OPL every other vbl! =)

 

Hence saving OPL update time!...

 

Thats the hacker way to do interlace :)

 

 

>So you disassembled my code, uh ?

*caugh* ..I have an alpine.. it comes as default ;)

 

But since Im the 1st to do interlace on the jaguar (as far as i know) I am the one that has to check where the code came from to see if there was a leak ;) ...but it checked out ok ;)

 

Eor=quick.. well i use the vbl counter and test the lowest bit.... "same same but different" =)

 

cheers!

 

 

 

--------------------------------

 

 

to TXG:

 

>Cool so 640 x 480 with borders could become a new standard then

 

Borders? ....Only if you whant to do a OldSchool ST tribute demo on the jaguar ;) ...otherwise No bordes requiered!...

I would say a picture 720*576 would absolutely fill the hole screen... and it would be magnificantly nice! =)

 

Just One problem... and i guess thats why atari never realy considered it...

 

720*576*2=829440 bytes!!!.. its like half the avaiable memory just for one screen!... (double buffer and you have 4K of gpu mem for your game.. Yeeehh! :)

 

For a demo this is Gold!... perhapps for a menu...anywhere wer you can sattle for 1screen .....but for a double buffer game? ....nahh...

 

 

but it is nice to know the jaguar can do what every other system can do.. interlace... now we just have to ues it in a production! =)

 

 

cheers!

/Sym

Share this post


Link to post
Share on other sites
GT Turbo    5
>So you disassembled my code, uh ?

*caugh* ..I have an alpine.. it comes as default ;)

 

/Sym

 

Lol !!!

 

 

 

:poulpe:

Share this post


Link to post
Share on other sites
Zerosquare    10
regarding "OP interlace bug":

there are a number of ways to make this:

--set dwidth to twice the size of the picture, but only display width pixels... then each vbl change the start position of the first pixel.

(the one i used)

 

--The 2nd a bit more "hacker style" woudl be to do a pre-processing of the picture separating the odd&even lines into two pictures "on top" of another..

So 1st picture (say 640 width.. and also dwidth) only contains even lines... the secound picture (640*480*2 bytes away in memory) contains the odd lines...

 

THEN! ..you could actually utilise the other OP bug in your favour and you would only have to update the height variable in the OPL every other vbl! =)

 

Hence saving OPL update time!...

 

Thats the hacker way to do interlace :)

Funny, I see we're thinking along the same lines ;)

I used the first trick in the demo, just as you did, but thought of the second one afterwards.

Share this post


Link to post
Share on other sites
GT Turbo    5

[english]

 

You know what ? Zerosquare come back faster and harder, yes because he has done a 1376x576 picture on a Jaguar !!

 

 

[french]

Zerosquare revient avec un : 1376x576 sur une Jag, on commence a se demander ou sont les playstations (Première du nom :) mais elles sont ou ? Mais elles sont ou ? Zero tu comptes t'arreter la ? Question en passant :flowers: )

 

zero_pic2.jpg

 

 

 

GT :poulpe:

Share this post


Link to post
Share on other sites
Zerosquare    10

[Français]

GT Turbo m'a pris de vitesse, voilà donc la démo de 1376x576, toujours en 50 Hz et à charger en $4000. Branchez votre télé en RGB si vous le pouvez ;)

(Désolé GT, je ne pense pas pouvoir aller plus loin, c'est la limite du hardware !)

 

[English]

GT Turbo has been faster than me, so here is the 1376x576 demo, still in 50 Hz and at address $4000. Connect your TV set using RGB if you can ;)

(Sorry GT, I don't think I can go further, this the hardware limit !)

HiResDm2.zip

Share this post


Link to post
Share on other sites
SebRmv    2

excellent!!!

 

la classe Zerosquare B)

 

Seb

Share this post


Link to post
Share on other sites
Zerosquare    10

[Français]

Voici des versions mises à jour qui gèrent correctement (si tout va bien ;) ) aussi bien le mode 50 Hz que le mode 60 Hz. (Comme la résolution est plus faible en 60 Hz, les bords de l'image sont un peu coupés...)

 

[English]

Here are updated versions which (hopefully ;) ) handle correctly 50 Hz mode as well as 60 Hz mode. (Since the resolution is lower in 60 Hz, I had to crop the image a bit around the borders...)

hdr1u.zip

hdr2u.zip

Share this post


Link to post
Share on other sites
Fredifredo    0

Bon bah maintenant Zerosquare il manque plus que la routine qui va bien pour faire du slideshow avec la CF :)

( par exemple les photos de l'AC ... :D )

 

[english]

 

too tired too translate...lol..

Now Zerosquare you must make a routine to do a slideshow with the CF

example with some AC pictures. :D

Share this post


Link to post
Share on other sites
TXG/MNX    0

What's next? AVI hi-res playing on the JAG? Would be cool to play DVD quality, with the CF we can put an AVI from several hunderd Mb's on it ;-)

Share this post


Link to post
Share on other sites
Zerosquare    10

[Français]

Pour ceux qui se poseraient la question, je n'ai pas lâché l'affaire, la doc va sortir :whistling:

Les démos étaient vraiment de la bidouille, et comme je veux que ce soit bien fait, je suis en train de confirmer le comportement de tous les registres vidéos à l'oscillo, vu que la doc Atari est loin d'être sans ambiguités...

En attendant, vous pouvez me contacter si vous avez besoin d'infos potentiellement incorrectes sur les modes vidéos :)

 

[English]

For those who might be wondering, I've not given up, the doc is going to be released :whistling:

The demos were really a hack job, and as I'd like to do things properly, I am currently confirming the behaviour of all the video registers with an oscilloscope, as the Atari documentation is far from unambiguous...

In the meanwhile, you can contact me if you need possibly incorrect info on video modes :)

Share this post


Link to post
Share on other sites
SebRmv    2

:yes: on n'a jamais douté de toi 0^2 :D

 

Seb

Share this post


Link to post
Share on other sites
GT Turbo    5
[Français]

En attendant, vous pouvez me contacter si vous avez besoin d'infos potentiellement incorrectes sur les modes vidéos :)

 

Non pour ma part, les infos potentiellement incorrectes j'ai les docs d'atari ca devrait me suffire, mais c'est super sympa de ta part :blink:

 

[English]

you can contact me if you need possibly incorrect info on video modes :)

 

Lol !! You know what i've got Atari docs, that's enough in this kind of case !!

 

 

GT :poulpe:

Share this post


Link to post
Share on other sites
stabylo    0

[Français]

Pour ceux qui se poseraient la question, je n'ai pas lâché l'affaire, la doc va sortir :whistling:

WikiPendium, destiné à toutes les connaissances Atari qui n'ont jamais été documentées, me semble un endroit bien adapté pour y mettre cette doc que tu composes. Bien sûr, je ne t'empècherai pas de farie un PDF de ton côté :P

 

[English]

For those who might be wondering, I've not given up, the doc is going to be released :whistling:

WikiPendium, which was set up to recieve all undocumented knowledge about Atari, sounds like the right place where to put this doc. Of course, I won't blame you if you also release it as PDF :P

Share this post


Link to post
Share on other sites
Zerosquare    10
PS: by the way, what about the documentation of the video registers :P ?
Well... :blush:

My goal was to make an accurate doc, so after fiddling with the registers to get the demos to work, I attempted to understand exactly how the hardware behaved. After many many tests and more-or-less strange results (Atari hardware-style :P ), I got a bit tired with it (no to mention some persons started to wonder aloud about the progress of the Catnip project :whistling: ), so I put the video thing on the side. I'm not comfortable publicly releasing things I don't fully understand, but as I said before, you can contact me if you need the info I've gathered so far for a project.

Share this post


Link to post
Share on other sites
Zerosquare    10

[Français]

Désolé, j'ai pas le courage de le refaire en français... Profitez-en pour travailler votre anglais :P

 

[English]

SebRmv asked me in a PM about how to setup the video registers for a given resolution, and I think some info could be helpful to several people, so I've deciced to post it here.

 

Note that I'll give no registers values and no code here. For "usual" video modes, SCPCD and others have much more experience than me, so they should be able to help those interested in the matter. For "hi-res" modes such as 1376x576, I've not solved all of the peculiarities yet, and I prefer to offer explanations about things I really understand.

 

An important thing to keep in mind, I think, is that there are far fewer actual resolutions usable on the Jaguar than on a typical PC graphic. This is because a TV set is very limited in its capabilities compared to a computer monitor (fixed refresh rates), and Atari did not bother to implement a flexible video clock generator in the Jaguar (though the chipset would have been able to use it).

 

 

Let's start.

 

 

Vertical resolution

 

We don't have much of a choice here. Since we must be compatible with TV sets, we have to follow the timing requirements for PAL and NTSC, and both specify a fixed number of lines per frame, specifically 625 in 50-Hz mode and 525 in 60-Hz mode. This number covers the total length of the frame, including the blanking period where the electron beam is shut off. Consequently, only up to 576 lines can actually contain picture data in 50-Hz mode, and up to 480 or 486 lines in 60-Hz mode (depending on who you ask). Actually, the very first and very last line in the frame are partially blanked, but this is generally ignored to make the calculations easier.

 

Now, you've probably heard about interlacing. It means that the frame is split into two half-frames, called fields. One is composed of the even lines, the other one of the odd lines ; let's call them A and B. Normal TV signals are interlaced, and the refresh pattern goes like this : A B A B A B... Since each field lasts during 1/50th or 1/60th of a second, note that the full frame is only refreshed 25 or 30 times per second.

 

But by default, the Jag uses a (slightly) non-standard non-interlaced mode, which has the following refresh pattern : A A A A A A... You can see that only half of the available lines are displayed, but they are refreshed twice as often compared to the standard interlaced mode.

 

So to recap, you have only two possible vertical resolutions : 576 or 480/486 lines interlaced, and 384 or 240/243 lines non-interlaced. Yet, you don't have to put graphics in all of those lines ; you can use a border in the top and bottom lines, or leave them blank. (Some of them will get cropped anyway because TV sets and monitors are set to overscan a bit, thus you should not place important graphics near the edge of the screen.) On the Jag, the VDB and VDE registers control which lines are filled by the Object Processor ; the other ones simply display the border color. The values of those registers do NOT affect the vertical resolution. In other words, they control the number and the position of "active" pixels vertically, not their size.

 

Beware that the VDB and VDE value are expressed in half-lines, and the first visible line is not zero. This is also the case for Y values used in OP lists (they are NOT relative to VDB : if you want to display a sprite on the first line handled by the OP, you have to use the value of VDB, not zero).

 

 

Horizontal resolution

 

Now this is a bit more interesting. Like all game consoles (except the most recent ones), the Jaguar outputs analog video, and you'll not find anything about horizontal resolution in any serious document about analog video. This is simply because there is no sampling in the horizontal direction ; the signals produced by, for example, an analog video camera, are continuous during the scan of a line. (That doesn't mean that the equivalent digital resolution would be infinite.) So the "length" of the lines are not defined in terms of pixels, but time : 64 µs in 50-Hz mode, 63.5555... µs in 60-Hz mode. Just as for the vertical stuff, we have to account for the blanking period ; this leaves 52 µs in 50-Hz mode for the video part, and 52.6555... µs in 60-Hz mode.

 

Now what about the Jaguar ? The video chipset need values exprimed in pixels... According to the docs, the video master clock is 26.593900 MHz for PAL units, and 26.590906 MHz for NTSC units. This gives us about 1382 pixels per line 50-Hz mode, and about 1400 pixels in 60-Hz mode. To make things a little more flexible, you can divide this master clock by an integer between 1 and 8 using the PWIDTH field of the VMODE register (it is only applied to the OP, by the way ; the other video registers don't need to be modified no matter the value of PWIDTH). Dividing the clock frequency by N makes each pixel last N times longer ; as the horizontal timing is fixed, the pixels get N times larger and consequently the vertical resolution line is also divided by N. If you do the math, you'll notice that unfortunately no configuration results in square pixels...

 

The HDB1, HDB2 and HDE registers play a similar role to their vertical counterparts, allowing you to specify which pixels are "active". Their value do NOT influence the horizontal resolution.

 

You may be wondering why there are two different registers for the beginning of the display. Usually the OP runs once per line, and HDB1 and HDB2 both have the same value. However, since the lines buffer are 1440 bytes long, they can handle only up to 720 pixels in CRY or RGB16 mode, or 480 pixels in RGB24 mode. If there are more active pixels than that, the OP has to run twice successively to draw an entire line. The HDB2 register is used in this case to specify on which pixel the OP should reset its processing, just as if it was the beginning of a new line. So, basically, "wide" screens look like screens with twice as many lines from the OP point of view. (By the way, the OP lists X values's ARE relative to HDB1 and HDB2... Isn't it fun ? :D )

 

 

Other registers

 

The VP, VBB, VBE, VS, VEB, VEE, HP, HBB, HBE, HS, HVS and HEQ registers define the video signal timings. If they've been properly set, you don't need to change them, no matter which resolution you use (except when you're fiddling to get interlacing to work right, but this is for later :D ). Be aware that you CAN generate completely weird signals, which MAY damage your TV/monitor, by writing to these registers ; this is why the Atari docs tell you explicitly not to even think about it :whistling:

 

 

This is by no means complete yet...

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×