Jump to content
Jagware

Zerosquare

Administrators
 View Profile  See their activity

  • Content count

    2,138

  • Joined

  • Last visited

  • Days Won

    5

Posts posted by Zerosquare

  1. Posted · Report reply

    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.

  2. Posted · Report reply

    I've just started playing with the GPU, so apologies if this is well-known.

     

    If you read the doc carefully, you'll see that MOVEQ writes the destination register in cycle 2, unlike most instructions for which this happens in cycle 3. This is cool, because code like this doesn't cause a pipeline stall, even though we use r1 just after writing it :

    moveq        #1, r1
or         r1, r0

    But this can be a trap too ! Remember this bug ?

    13 Scoreboard failure on successive writes

    Note - This bug applies to both Tom & Jerry.

    Level 0 software

    Description If two instructions write to the same register with no read references to it in between, and the

    second of the two completes before the first, then the register can be left holding the result of

    the first, which is now what the programmer would expect. This is because there is no scoreboard

    protection against an instruction writing to a register that is currently flagged as invalid.

    It was never envisaged that this situation would actually occur, but some programmers have

    managed to contrive circumstances under which it can occur, particularly when debug code is

    inserted, e.g.

    load (r3),r2; get data value
moveq 3,r2; over-write with bebug value

    This combination can have the appearance of the MOVEQ instruction not being executed, as

    the load data is written into r2 after the quick immediate data.

    Work-around Put an instruction dependent on the data between the two, e.g. an or r2,r2 between the

    two instructions above.

    At the first glance this seems to only affect long-latency instructions such as LOAD... but because of the behaviour of MOVEQ, the following code doesn't work reliably either !

     

    xor         r1, r1
moveq       #1, r1

    So beware when you use MOVEQ...

  13. Posted · Report reply

    [English]

    Since several persons requested more detailed info, here are the Catnip Cable features :

    • A replacement for the BJL parallel cable

      The BJL protocol is handled internally, so the tranfers are reliable no matter the computer the Catnip Cable is connected to. The speed is currently about 50 kilobytes per second. This feature is completely independent of the JagCF, so it can be used by those who don't have it, or who wish to develop or use standard BJL homebrews.

    • A high-speed serial port

      The Catnip cable can act as high-speed (up to 3 Mbaud), TTL-level serial port. It can be connected to the JagCF for real-time communication between a Jaguar and a computer, or used for your own applications.

    • A JagCF updater

      Several major upgrades are planned for the JagCF ; the Catnip Cable will be necessary to enjoy the full potential of the card.

    • An open system

      The Catnip Cable is a USB 1.1 device compatible with Windows (98 to XP) and Linux x86 (other platforms are being considered, but we can't promise anything). The software will be provided in source and compiled form, and the information needed to develop your own applications will be available.

    • More...

      The firmware can be updated easily through USB, so future functionalities can be added without having to send the cable back to us. (Of course, firmware and software updates will be free.)

    [Français]

    Comme plusieurs personnes ont demandé des informations plus détaillées, voici les caractéristiques du Catnip Cable :

    • Un remplacement du câble BJL parallèle

      Le protocole BJL est géré en interne, donc les transferts sont fiables quel que soit l'ordinateur sur lequel le Catnip Cable est connecté. La vitesse est actuellement d'environ 50 kilo-octets par seconde. Cette fonctionnalité est entièrement indépendante de la JagCF, elle peut donc être utilisée par ceux qui ne la possèdent pas, ou qui veulent développer ou utiliser des homebrew BJL standards.

    • Un port série à haute vitesse

      Le Catnip Cable peut se comporter comme un port série à haute vitesse (3 Mbauds) à niveaux TTL. Il peut être connecté à la JagCF pour une communication en temps réel entre une Jaguar et un ordinateur, ou utilisé pour vos propres applications.

    • Un moyen de mettre à jour la JagCF

      Plusieurs améliorations majeures sont prévues pour la JagCF ; le Catnip Cable sera nécessaire pour profiter au maximum du potentiel de la carte.

    • Un système ouvert

      Le Catnip Cable est un périphérique USB 1.1 compatible avec Windows (de 98 à XP) et Linux x86 (d'autres plateformes sont à l'étude, mais nous ne pouvons rien promettre). Les logiciels seront fournis sous forme source et compilée, et les informations nécessaires pour développer vos propres applications seront disponibles.

    • Plus...

      Le firmware peut être mis à jour facilement par USB, par conséquent des fonctionnalités futures pourront être ajoutées sans devoir nous renvoyer le câble. (Bien entendu, les mises à jour du firmware et des logiciels seront gratuites.)

  16. Posted · Report reply

    [English]

    (If you do not know what this is about, read this topic.)

     

    At this point of the Catnip Cable development, we'd like to know how many people would be interested in buying one. Although this is not a preorder, note that the results will affect the project's future. Consequently, please vote only if you're reasonably sure of your choice.

     

    The price should be very approximately around 30 € (that's US $39). We cannot give a more precise estimate at the time, as the production costs are not fully known yet (they depend on the manufacturer we'll choose, on the number of clients, etc.)

     

    The poll has been posted on AtariAge, Jagware, and Yaronet, therefore you can vote if you're a member of one of these sites (if you are a member of several, please vote only on one of these).

     

     

    [Français]

    (Si vous ne savez pas de quoi il s'agit, lisez ce topic.)

     

    À cette étape du développement du Catnip Cable, nous aimerions connaître le nombre de personnes souhaitant en acheter un. Bien qu'il ne s'agisse pas d'une précommande, les résultats influenceront la suite du projet. Par conséquent, merci de ne voter que si vous êtes raisonnablement sûr(e) de votre choix.

     

    Le prix devrait être très approximativement aux alentours de 30 € (ce qui fait 39 $ US). Nous ne pouvons pas donner d'estimation plus précise pour le moment, car les coûts de production ne sont pas encore entièrement connus (ils dépendent du fabricant que l'on choisira, du nombre de clients, etc.).

     

    Le sondage a été posté sur AtariAge, Jagware, et Yaronet, vous pouvez donc voter si vous êtes membre de l'un de ces sites (si vous êtes membre de plusieurs, merci de ne voter que sur l'un d'entre eux).

  21. Posted · Report reply

    I read it there, are you planning to make an API that can be used inside Visual Basic aswell ?

    Yes, I know I am a lame coder but I am more creative in basic then in C

    I had not thought about it, but it should be easy to make a DLL out of the API, and use it in Visual Basic.

  24. Posted · Report reply

    One month after any news for your fans ? :)
    What has been done :
    • Final hardware revision (hopefully :) )
    • Bootloader (for upgrades through USB)
    • Beta firmware (supports 8-bit transfers, and BJL commands such as switching to download mode -- so far, upload success rate is 100%)
    • Beta multi-platform API in C (allows any program to use the Catnip features)
    What is not done yet :
    • "Real" programs (using the API) to update the firmware and upload code (currently, it is made using a messy test program)
    • Testing under Linux
    • Choices related to the plastic box, connectors and cables (I'm working on it, but finding cheap and usable solutions is not easy !)
    • Second prototype using the final boards
    • Organization for collecting payments, sending the products, etc.
    I know you've been waiting, and I'm sorry for the delay, but please be patient :blush:

     

    First, I'm not always as motivated as I'd like :(

     

    Also, about 95% of the code has been rewritten since the demo at the *tari Connexion 2006, and many changes (both visible and internal) have been made to make the Catnip evolutive and reliable.

     

    Besides, some people we need to contact (e.g. suppliers) are in vacation right now...

×