Zerosquare

Je n'ai pas testé, mais d'après le schéma c'est la résistance R19 qui détermine le mode d'encodage des couleurs. Elle est reliée à la patte 19 du MC13077. C'est le même principe que pour le switch 50/60 Hz, sauf que c'est le contraire : résistance présente en mode NTSC, absente en mode PAL. Tu devrais donc pouvoir obtenir un switch PAL 50 Hz/NTSC 60 Hz en enlevant cette résistance si elle est présente, et en reliant la patte 19 au côté non utilisé de l'interrupteur. EDIT : ce n'est pas suffisant pour obtenir du NTSC standard, car la fréquence du quartz utilisé pour la sous-porteuse couleur doit aussi être changée (Y1 sur le schéma ; 14,31818 MHz pour le mode NTSC, ils omettent de mentionner la valeur différente pour le mode PAL). En laissant le quartz d'origine des Jaguar européennes (17.734475 MHz), on devrait obtenir du "NTSC 4.43" si je ne me plante pas. Reste à savoir si ta carte le supporte ou pas...

[Français] Certains le savent déjà, mais pour les autres : je développe actuellement un bootloader pour le Catnip Cable. Pour faire simple, cela va permettre de mettre à jour le firmware (pour corriger des bugs éventuels ou ajouter de nouvelles fonctionnalités) sans devoir nous renvoyer le câble. Le "problème", c'est que j'ai dû changer d'assembleur, et que le code doit être compact et nickel... ça me demande un peu de temps, ne perdez pas espoir . On continue à mettre au point d'autres aspects du projet en parallèle. [English] Some of you already know this, but for the others : I am currently developing a bootloader for the Catnip Cable. To put it simply, it will allow upgrading of the firmware (to fix possible bugs or to add new functionalities) without having to send the cable back to us. The "problem" is that I had to use another assembler, and that the code must be compact and flawless... I need a bit of time for that, so please don't lose hope . We continue to work on other parts of the project in parallel.

I'm not so sure about that with the side-effects and loopholes of the DMCA law in the United States. Several small companies got sued by their bigger competitors.

Not a stupid idea, but certain people would get very angry with us, and it might even be illegal. Besides, I think we have the abilities to figure it out ourselves without having to copy someone else's code.

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] 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 her

[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] 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... 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 abilities 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.

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 )

itou

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. I'm not the only one, let's not forget SCPCD, GT Turbo and you , 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 ?