Jump to content
Jagware
Starcat

High Res Graphics On The Jaguar

Recommended Posts

Starcat    0

Hi folks!

 

I know there are people on this board who did some experiments with high res graphics on the Jag. I did some experiments myself in the past with rather bad results except for horizontal res, so I have a few questions and maybe somebody who knows more about this can give me a snippet of code that helps me out.

 

There is a project I am working on which would really profit from high res graphics. I think only the mode close to 640 is useful to me, as most tv sets can't display anything higher than 720 pixels in width or so.

 

So here are my questions:

 

1) How "save" are these modes to use? Do they work on all Jags and all tv sets? (PAL / NTSC)

2) What exactly needs to be modified? Just the video setup or more parts of the code?

3) Is the source code available to those examples? I think I saw it before, but all I can find now, are binaries.

 

Thanks a lot.

 

Regards, Lars.

Share this post


Link to post
Share on other sites
Zerosquare    10
Hi folks!

 

I know there are people on this board who did some experiments with high res graphics on the Jag. I did some experiments myself in the past with rather bad results except for horizontal res, so I have a few questions and maybe somebody who knows more about this can give me a snippet of code that helps me out.

 

There is a project I am working on which would really profit from high res graphics. I think only the mode close to 640 is useful to me, as most tv sets can't display anything higher than 720 pixels in width or so.

 

 

So here are my questions:

 

1) How "save" are these modes to use? Do they work on all Jags and all tv sets? (PAL / NTSC)

As long as you keep the video timings compatible with TV standards, there should be no problem (beware with that -- you can easily fry some monitors with incorrects settings. I use a TV capture card for testing.)

 

I guess you already know how to do the horizontal part, but just in case : set the PWIDTH field to 1 in the VMODE register to get about 690 pixels in 50 Hz, or 700 pixels in 60 Hz. It will work on all Jags.

 

The vertical part is trickier. You need to enable interlacing to get 574 lines in 50 Hz, or 482 lines in 60 hz (note that the pixels won't be squares). I've written some not-yet-released code to initialize all video registers properly both for 50 Hz and 60 Hz (it's not present in the demos I released several months ago) and verified that the video signals are correct with a logic analyzer, but I put the project aside. What needs to be done is to check the compatibility with all Jag models, and figure out some OP-related things I haven't investigated yet.

 

2) What exactly needs to be modified? Just the video setup or more parts of the code?
No major modifications are needed in the code. Apart from the video registers initialization, you have to take into account that you now have 50 or 60 interlaced, alternating half-images per second. This affects the way you setup the object list, and there's a little trick without which you'll only get half of the VBL interrupts. Remember also that the picture will be more "flickery" - some kind of graphics are particularily affected (sharp edges, etc.).

 

3) Is the source code available to those examples? I think I saw it before, but all I can find now, are binaries.
I've not released mine yet, but I'm willing to share it with you. :) Symmetry of TNG can probably give you a hand also.

Share this post


Link to post
Share on other sites
Starcat    0

Hi!

 

As long as you keep the video timings compatible with TV standards, there should be no problem (beware with that -- you can easily fry some monitors with incorrects settings. I use a TV capture card for testing.)

 

I guess you already know how to do the horizontal part, but just in case : set the PWIDTH field to 1 in the VMODE register to get about 690 pixels in 50 Hz, or 700 pixels in 60 Hz. It will work on all Jags.

 

The vertical part is trickier. You need to enable interlacing to get 574 lines in 50 Hz, or 482 lines in 60 hz (note that the pixels won't be squares). I've written some not-yet-released code to initialize all video registers properly both for 50 Hz and 60 Hz (it's not present in the demos I released several months ago) and verified that the video signals are correct with a logic analyzer, but I put the project aside. What needs to be done is to check the compatibility with all Jag models, and figure out some OP-related things I haven't investigated yet.

 

No major modifications are needed in the code. Apart from the video registers initialization, you have to take into account that you now have 50 or 60 interlaced, alternating half-images per second. This affects the way you setup the object list, and there's a little trick without which you'll only get half of the VBL interrupts. Remember also that the picture will be more "flickery" - some kind of graphics are particularily affected (sharp edges, etc.).

 

I've not released mine yet, but I'm willing to share it with you. :) Symmetry of TNG can probably give you a hand also.

 

That would really be great! Could you send me something to try via PM? or via e-mail?

 

Regards, Lars.

Share this post


Link to post
Share on other sites

Well Starcat I could mail you my code (as it is) ...as long as I dont have to comment it any further =)

Ie no time to alter or comment it, but time to pack it & sent it to you would be ok...

then atleast you would get my AvP testpic of 640*480 to display and you could take it from there...

 

(warning of unclear code though!.... made in a hast years ago).

 

 

Will check if i can figure out your email and youll get it...

 

cheers

/Sym

Share this post


Link to post
Share on other sites
SebRmv    2
Why not release some sample code overhere... would be interesting for more people...

 

:yes: I think so

Share this post


Link to post
Share on other sites

hehe ...works if you are not ashamed of it ;P

myone beeing a total experimental test routine not well written in any way but just to get the code running... (2yars old routine for that mater).

 

Sorry for this next "patriotic" line but recent external events has awoken this "childish" behaviour in me:

---It would also be nice if it was only downloadable by registered Jagware members...---

I do wanna promote & help fellow hardworking!/hardcoding! JagWare coders!...

The rest i dont realy care for much atm... (sorry).... it will pass.. but untill it does.... Jagware is the way to go!... So you who get this keep it to yourself...

 

I could start by sending my sheit-code to you to (seb & txg :) ...600Kb of mail heading your way.. (txg i hope i still have your mail..if not PM me).

 

If you want a better "public" example we will have to turn to Zerosquare & do some begging ;P

 

 

 

cheers

/Sym

Share this post


Link to post
Share on other sites
TXG/MNX    0
If you want a better "public" example we will have to turn to Zerosquare & do some begging ;P

 

hihi ok we will do that aswell thx for your time and effort to send your code B)

 

 

I hope zerosquare will release some code and maybe a how-to real soon when he has sorted his files...

Share this post


Link to post
Share on other sites
Zerosquare    10

OK, since Tyr of the Arcana asked me about it, I think it's better for me to release the info I have rather than wait until it is finished (which may never happen, since I seem to be involved in too many projects :P)

 

First, some basic facts about interlacing (with a few simplifications to make it easier to understand) :

 

- a standard TV picture is interlaced. That means that the lines are not refreshed in sequence (0, 1, 2, 3...), but alternatively : first the even ones (0, 2, 4...), then the odd ones (1, 3, 5...), then the even ones again, etc. A set of lines, either odd or even, is called a field. A complete picture, made from two consecutive fields, is called a frame. Consequently there are 50 (60 in NTSC) fields displayed per second, but only 25 (30 in NTSC) frames.

 

- the Jaguar, like almost every console before it, outputs non-interlaced video by default, since it's easier to generate and generates less flicker for sharp graphics. It means that instead of alternating between and even lines, it only outputs fields containing even (or odd) lines. In this case, each frame is made of a single field. So you get twice as many frames per second (50 or 60), at the expense of half the vertical resolution (since you only use every other line).

 

- unfortunately, there's no definitive agreement on how the lines should be numbered ; depending on the book/website, the convention used isn't always the same. In particular, the lines you call "even" may be called "odd" (and vice-versa) by someone else. To avoid confusion, instead of using those terms, I'll call the field which contains the first (from top to bottom) line of the picture top field, and the other bottom field.

 

Now, the code. This stuff is old, and I'd need to delve into it again to understand exactly how it works. I'll try to post an example program when I have time.

 

First you need to enable interlacing by rewriting some video registers (the ones the Atari documentation tells you not to touch :lol:) :

    move.w      CONFIG, d0
    andi.w      #16, d0
    bne.s       Init60HzI
                                     
    Init50HzI:
    move.w        #0, HC   
    move.w        #1, VC    
    move.w      #624, VP    
    move.w      #614, VEB  
    move.w      #619, VS    
    move.w        #4, VEE  
    move.w       #40, VBE  
    move.w      #614, VBB  
    move.w      #850, HP   
    move.w      #1749, HS   
    move.w      #787, HEQ   
    move.w      #600, HVS  
    move.w      #1709, HBB
    move.w      #153, HBE   
    bra.s       Suite

    Init60HzI:
    move.w        #0, HC   
    move.w        #1, VC   
    move.w      #524, VP  
    move.w      #512, VEB   
    move.w      #518, VS   
    move.w        #5, VEE   
    move.w       #30, VBE  
    move.w      #512, VBB  
    move.w      #844, HP    
    move.w      #1743, HS   
    move.w      #780, HEQ   
    move.w      #595, HVS   
    move.w      #1697, HBB  
    move.w      #118, HBE   

    Suite:
    stop        #$2700

This code should really be rewritten to accept different resolutions, but it should be enough to start testing.

 

From now on, you can test whether the current field is the top one or the bottom one by testing bit 11 of the VC register :

- if it's clear : top field

- if it's set : bottom field

 

If you use the 68K VBL interrupt, you also need to dynamically alter the value of the VI register, otherwise the interrupt won't trigger :

- for top field : VI must have bit 0 cleared (even value)

- for bottom field : VI must have bit 0 set (odd value)

 

Remember that when the VBL interrupt triggers, the next field hasn't begun yet. So you have to set VI correctly for the next field, not the current one.

Which means that at the start of your VBL interrupt, you should set VI to an even value if bit 11 of VC is set, set it to a odd value otherwise.

 

I'll try to add additional information when I find time, and probably a test program. Anyways, feel free to ask questions in the meantime !

Share this post


Link to post
Share on other sites
Tyrant    0

I finally have a chance to try this out now, but I have a few more questions.

 

First you need to enable interlacing by rewriting some video registers (the ones the Atari documentation tells you not to touch :lol:)

Hmm... do you remember how you came up with those values? I only ask because they're very very different from the defaults (as specified on techref page 1).

Also is just setting those values sufficient to enable interlacing? I would have expected to find some kind of "interlace enable" flag somewhere, but can't see one in the docs.

 

This code should really be rewritten to accept different resolutions, but it should be enough to start testing.

Do you mean horizontal resolutions? What would need to be changed? I'm thinking of a pixel divisor of 2 (for 665 overscanned pixels horizontally) specifically. Surely vertical resolution is determined by the PAL and NTSC standards?

 

If you could help me get a better understanding of what those values do and how they inter-relate (and how you came up with them), it would be really helpful.

 

Share this post


Link to post
Share on other sites
Zerosquare    10
Hmm... do you remember how you came up with those values? I only ask because they're very very different from the defaults (as specified on techref page 1).

Also is just setting those values sufficient to enable interlacing? I would have expected to find some kind of "interlace enable" flag somewhere, but can't see one in the docs.

There's no real flag : if the total number of half-lines per video field is even (not the value of the VP register ; remember that the number of half-lines is VP plus one), the display is non-interlaced ; if it is odd, the display is interlaced.

 

However, changing VP alone is not sufficient to generate a correct interlaced screen in all cases. The values used by the boot ROM to initialize the video are slightly wrong (I recall that the number of sync pulses was not correct, and there may have been other inaccuracies) ; I suspect whoever wrote the code didn't understand the documentation fully, which is believable since it's not very clear... Additionally, there are two different versions of the boot ROM, plus the BJL ROM, and some values are different depending on the version.

 

All of this doesn't matter much for non-interlaced screens (the picture will just be offset slightly), but it is critical for interlaced screens, otherwise odd and even lines may be swapped with each other.

 

Oh, and the relationship between bit #11 from VC and whether the current field is "top" or "bottom" is indirect ; it just toggles on each field, on its own. So you can't switch from non-interlaced to interlaced whenever you want, otherwise you have a 50% chance of getting it wrong. This is why the code writes to VC and HC first, so that the video counters start from a known value.

 

So I decided to compute the correct values for the video registers using the official TV timings, the documentation, and (lots of) testing.

 

Do you mean horizontal resolutions? What would need to be changed? I'm thinking of a pixel divisor of 2 (for 665 overscanned pixels horizontally) specifically. Surely vertical resolution is determined by the PAL and NTSC standards?
I was thinking horizontal resolution ; although it's not directly related to interlacing, a single routine which would take care of everything would be good :)

 

There's also the special case of using a dividor of 1 : you have to init both VDB1 and VDB2 with different values.

Share this post


Link to post
Share on other sites
Tyrant    0

Ok, I've got interlaced video up and running (confirmed by turning off the eor on VI and I only get half the interrupts)... but the OP isn't doing what it's meant to be doing.

 

The docs say (Softref p16, object definitions) that the height field should be decremented by 1 per line for non interlaced, and 2 per line for interlaced modes... I'm getting it decremented by 1 per line when interlacing. This means it's drawing the whole bitmap each field, instead of every other line, with the result that it's twice as tall as it should be.

 

Any idea why this is, what's causing it, and how to fix it?

 

Thanks for all the help.

 

Edit: Hmm... I *think* the problem is occurring because I'm using the normal InitVideo code from Atari. In workshop #1 (mou.cof) it says that that routine will work for any non-interlaced resolution. I've tried both doubling and halving the values of height and hmid, but both are leaving me with a blank screen. Leaving them alone gives me an interlaced picture which outputs at non-interlaced resolution.

Share this post


Link to post
Share on other sites
Zerosquare    10
The docs say (Softref p16, object definitions) that the height field should be decremented by 1 per line for non interlaced, and 2 per line for interlaced modes... I'm getting it decremented by 1 per line when interlacing. This means it's drawing the whole bitmap each field, instead of every other line, with the result that it's twice as tall as it should be.

 

Any idea why this is, what's causing it, and how to fix it?

Yes. The doc is wrong ; in practice, the OP doesn't seem to care whether the display mode is interlaced or not, it always decrement the HEIGHT field by one per line.

 

One solution is to split your bitmaps into two different ones : one with the odd lines only, one with the even lines only. In your VBL interrupt routine, update the DATA field of your bitmap object with the address of the correct half-bitmap, according to the field which will be drawn next.

 

Another possibility is to keep the bitmap data as it is, but double the value of the DWIDTH field. This will cause the OP to skip every other line when drawing. In your VBL interrupt routine, update the DATA field with either your bitmap's address (to show lines #0, #2, etc.) or your bitmap's address + one line (to show lines #1, #3, etc.), according to the field which will be drawn next.

 

In both cases, remember that you're only drawing half the number of lines per field, so the HEIGHT field value should be divided by two, compared to a non-interlaced screen.

Share this post


Link to post
Share on other sites
Tyrant    0

That's rather annoying. Ah well, yet another bug to add to the endless list.

 

Your second work around (doubling DWIDTH, halving HEIGHT) sounds most sensible, especially since I'm going to be generating some of the graphics at runtime and can't really split them into two. Once I have the OP generating code written, and the ISR, I shouldn't have to even remember that I'm doing it.

 

Thanks so much for your help. As I was explaining to someone earlier today, there really are only two people in the world who can help me with this, yourself and symmetry, and he disappeared from the scene several years ago.

Share this post


Link to post
Share on other sites
Tyrant    0

Thanks for all the help, everything seems to be working just fine. However, my TV being a bit funny about aligning pictures sometimes (things tend to fall off the left hand edge a bit), I'm wondering if I can get some help testing this on various different systems.

 

It doesn't really do anything much yet, just sets up 640x480 interlaced video.

I'd like to check that it works on:

  • PAL and NTSC Jaguars
  • PAL and NTSC TV's
  • modern and old TV's
  • and how well aligned the image is on all of the above.

Anyone who feels like testing this, your help would be very much appreciated.

 

Source is included, feel free to do what you like with it (it's 95% code by Atari and Zerosquare anyway, my changes are minor).

 

Thanks.

highrestest.zip

Share this post


Link to post
Share on other sites
Matmook    1
Thanks for all the help, everything seems to be working just fine. However, my TV being a bit funny about aligning pictures sometimes (things tend to fall off the left hand edge a bit), I'm wondering if I can get some help testing this on various different systems.

 

It doesn't really do anything much yet, just sets up 640x480 interlaced video.

I'd like to check that it works on:

  • PAL and NTSC Jaguars
  • PAL and NTSC TV's
  • modern and old TV's
  • and how well aligned the image is on all of the above.

Anyone who feels like testing this, your help would be very much appreciated.

 

Source is included, feel free to do what you like with it (it's 95% code by Atari and Zerosquare anyway, my changes are minor).

 

Thanks.

 

Yop !!

 

Tested with a PAL JAG with 50 and 60Hz on a old TV !

Picture seems good. I just don't see the left part of the picture (but it's the same wit all my jaguar games so ... and this TV doesn't allow horizontal tuning ...).

Share this post


Link to post
Share on other sites
Tyrant    0
Picture seems good. I just don't see the left part of the picture (but it's the same wit all my jaguar games so ... and this TV doesn't allow horizontal tuning ...).

That's what I get with my TV, on this and most (all?) other jaguar games. That's really why I asked people to test this for me, because I don't trust my TV.

 

If I can ask one more thing, could you see the whole image (apart from a bit off the left), The white diagonal lines go to the edge of the image, could you see all of them on all sides? Also was the TV PAL or NTSC natively?

Share this post


Link to post
Share on other sites
Matmook    1
That's what I get with my TV, on this and most (all?) other jaguar games. That's really why I asked people to test this for me, because I don't trust my TV.

 

If I can ask one more thing, could you see the whole image (apart from a bit off the left), The white diagonal lines go to the edge of the image, could you see all of them on all sides? Also was the TV PAL or NTSC natively?

 

You are right to not trust your TV, mine has the same "trouble" ... I must find an Atari SC1435 :)

 

I don't see the left part of the picture (All the part with vertical and diagonal lines) and my TV is a very old one so it's a PAL version (but it accept PAL50 and PAL60 mode).

Share this post


Link to post
Share on other sites
Tursi    0

Just to add to this, I tried with my NTSC Jag and a MadCatz LCD display - image is rock-solid and seems properly centered - I can see both edges and only lose a tiny bit off the top. It looks fantastic. I think I might steal this code. ;)

 

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.


×