Zerosquare
-
Content count
2,138 -
Joined
-
Last visited
-
Days Won
5
Posts posted by Zerosquare
-
-
Bon anniversaire à celle qu'on ne voit jamais
-
[Français]
Un petit "le saviez-vous ?" à propos de Tempest 2000 : on a fait des tests hier avec SCPCD, et l'option "Interlace" n'utilise pas le mode entrelacé
Ça semble seulement faire trembler l'image horizontalement...[English]
A little bit of trivia about Tempest 2000 : I did some testing yesterday with SCPCD, and it appears that the "Interlace" option does not use interlaced mode
It only seems to make the picture shiver horizontally... -
[Français]Par contre, ça serait bien que vous pensiez aux utilisateurs de Linux pour le soft de transfert...Ne t'inquiète pas, c'est prévu, le code sera en C "propre" et pourra être compilé au minimum pour Windows et Linux.
[English]
Don't worry, this has been foreseen, the code will be "clean" C and will be compilable at least for Windows and Linux.
-
[Français]
Le boulot se poursuit, on s'est fait une petite réunion hier avec SCPCD pour finaliser certaines choses, on vous en dit plus très bientôt.
(P.S. pour FrediFredo : je crois qu'on va avoir besoin de tes compétences
)[English]
Work is going on, I had a little meeting with SCPCD yesterday to finalize some stuff, you'll get news very soon.
(P.S. for FrediFredo : I think we'll need your abilities
) -
Young children are said to have a very "flexible" mind, maybe the Jag hardware would make sense to herthe following days Im babysitting my sisters daughter
10months.. I will diskuss the solution with her ;P
-
[Français]
Désolé d'avoir été un peu long à la détente
En réponse à ta question, X = 0 (pour les sprites) correspond au bord gauche de la zone gérée par l'OP (à l'inverse de ce qui se passe pour les Y, donc).
Voilà un bout de code d'exemple pour le mode non entrelacé (SCPCD ou GT devraient pouvoir te fournir d'autres trucs du même genre).
[English]
Sorry for the delay
To answer your question, X = 0 (for sprites) is the left edge of the area drawn by the OP (i.e. it's different from what happens for the Y values).
Here's a bit of example code for non-interlaced mode (SCPCD or GT should be able to provide you with more stuff of the same kind).
.include "jaguar.inc" .bss a_hdb: .ds.w 1 a_hde: .ds.w 1 a_vdb: .ds.w 1 a_vde: .ds.w 1 .text ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Procedure: InitVideo (same as in vidinit.s) ; Build values for hdb, hde, vdb, and vde and store them. ; Original code by Atari, slight modifications and comments ; by Zerosquare / Jagware InitVideo: movem.l d0-d6,-(sp) move.w CONFIG,d0 ; Also is joystick register andi.w #VIDTYPE,d0 ; 0 = PAL, 1 = NTSC beq palvals move.w #NTSC_HMID,d2 move.w #NTSC_WIDTH,d0 move.w #NTSC_VMID,d6 move.w #NTSC_HEIGHT,d4 bra calc_vals palvals: move.w #PAL_HMID,d2 move.w #PAL_WIDTH,d0 move.w #PAL_VMID,d6 move.w #PAL_HEIGHT,d4 calc_vals: ; You can modify d0 and d4 here to set the area drawn ; by the OP (by default it fills the whole screen). It will ; be centered on the screen. ; Warning : the horizontal values are in video clock cycles, ; so don't forget to multiply the number of pixels by ; PWIDTH + 1 ; Check also that the VDB and VDE values used for the first ; two stop objects in your object list are those calculated ; here move.w d0,d1 asr #1,d1 ; Width/2 sub.w d1,d2 ; Mid - Width/2 add.w #4,d2 ; (Mid - Width/2)+4 sub.w #1,d1 ; Width/2 - 1 ori.w #$400,d1 ; (Width/2 - 1)|$400 move.w d1,a_hde move.w d1,HDE move.w d2,a_hdb move.w d2,HDB1 move.w d2,HDB2 move.w d6,d5 sub.w d4,d5 move.w d5,a_vdb add.w d4,d6 move.w d6,a_vde move.w a_vdb,VDB move.w a_vde,VDE movem.l (sp)+,d0-d6 rts
-
Really nice
Advice : press 0 before playing with the values, the default step is so small you may think nothing is happening
-
[Français]; ICI ON N'AFFICHE QU'UN POINT; ; DEBROUILLEZ VOUS POUR LE FAIRE; ; HERE YOU ONLY NEED TO DISPLAY ONE POINT; ; DO IT YOURSELF;
Au premier coup d'oeil ça m'a fait peur ! C'est en lisant le code que j'ai compris ce que tu voulais dire
[English]
This worried me at first sight ! I understood what you meant later by reading the code
-
[Français]
Désolé, j'ai pas le courage de le refaire en français... Profitez-en pour travailler votre anglais
[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 ?
)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
). 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 
This is by no means complete yet...
-
Well...PS: by the way, what about the documentation of the video registers ?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
), I got a bit tired with it (no to mention some persons started to wonder aloud about the progress of the Catnip project ), 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. -
Just to make sure : I was aware of that ; it was a snide comment because of my dislike for software bloat, I don't doubt the usefulness of your program or your coding abilitiesYes, that's the price to pay when statically linking all the libraries you need...
And I'm convinced coders can use whatever software they're comfortable with as long as the job gets done
I've replied here, in order not to hijack your topic.PS: by the way, what about the documentation of the video registers ? -
That will be very useful ! Thanks !
(I won't say anything about the binary being more than 1 Mb in size...
I know it's not your fault ) -
itouJoyeux Anniversaire Tempi et Xerus !
-
Happy birthday !
-
Thanks TXG/MNX !
I've finally made a choice about the new name (Catnip Cable* ; see this topic on AtariAge), and I'm about to resume work on this project. I'll keep you updated
*Pour les non-anglophones : « catnip » signifie « herbe à chats »
-
I agree.hummmmm ... for me , I would to see "jag" on the name to show what is it and for what is it.
I'm not the only one, let's not forget SCPCD, GT Turbo and youand I would to see a note from or for the conceptor ( the one who make it : Zerosquare ) , so my opinion is that the name should be neutral on that.
-
[Français]
On recherche une nouvelle idée de nom pour notre câble de communication USB (voir ici pour plus d'infos).
Il s'appelle pour l'instant le "JagWire", mais certaines personnes pensent qu'il y a risque de confusion à cause de l'ancien site web d'Atari du même nom, et du site de cobracon.
Si vous avez un nom sympa à proposer, postez ici !
(Note pour ceux qui ne sont pas inscrits comme membres sur ce site : le même sujet a aussi été posté sur AtariAge et Yaronet.)
[English]
We're looking for a new name for our USB communication cable (click here for more info).
It's currently known as the "JagWire", but some people feel it will create confusion because of the former Atari website with the same name, and cobracon's site.
So if you've got a cool name to suggest, go ahead and post it here !
(Note for those who are not registered members on this site : the same topic has also been posted on AtariAge and Yaronet).
-
Lovely
-
[Français]
Pour ceux qui se poseraient la question, je n'ai pas lâché l'affaire, la doc va sortir
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
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
-
Nice oldschool stuff, Orion_
When running it on my Jag, the top half of the first (or last) ball is not drawn (see the attached picture) ; is it a bug ?
EDIT : In PT 0.95, all balls are displayed properly.
-
Ben pour tout dire j'ai une petite baisse de motivation en ce moment
Et faut que je prenne le temps de faire ça bien, une boulette en élec c'est moins facilement rattrappable qu'un soft (où il suffit de diffuser une mise à jour). Sans parler de tous les à-côtés (le problème du boîtier, de la fabrication, etc.) qui sont loin d'être ma tasse de thé... Donc je préfère attendre d'être bien concentré pour avancer
(Oui, je sais que certains sont impatients. J'y pense, j'y pense.)P.S. : Merci pour les infos (comme d'hab !), Fredifredo.
P.P.S. : Pour le changement de nom, j'ai rien contre. On repêche les anciennes suggestions ? Ou quelqu'un a une idée neuve ?
-
[Français]
Je sais qu'on avait parlé de moi pour cette routine, mais vue la "qualité" de mon code 68000, je pense que ça serait mieux que je fasse une doc sur les aspects vidéos de la Jaguar (modes "hautes résolutions" inclus, bien sûr), et que quelqu'un d'autre s'occupe de la réalisation
Ça vous va ?
[English]
I know some people had thought about me doing this routine, but considering the "quality" of my 68000 code, I think it would be better for me to create documentation on the Jaguar's video features ("high-resolution" modes included, of course), and have somebody else apply it
Do you agree ?
-
-
[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...)
Le UART bug ...
in Development
Posted · Report reply