Jump to content
Jagware

ggn

Members
 View Profile  See their activity

  • Content count

    172

  • Joined

  • Last visited

Posts posted by ggn

  5. Posted · Report reply

    This documentation is wrong. Encoders don't have 3 different states, they have 4 different states, They behave like a Gray code counter, incrementing for one direction of rotation, and decrementing for the other (explanation on Wikipedia)

     

    It's also explained in the Jaguar developer docs, in the section about controllers. According to this, the sequences are :

     

    Clockwise rotation is : none, right, left AND right, left.

    Anticlockwise rotation is : none, left, left AND right, right.

     

    Personally, my code is similar to this :

     

    {
    unsigned long dataJoypad;
    unsigned long ph0, ph1, ph0_old, ph1_old; // ph0_old and ph1_old must be initialized, and preserved between calls to the routine

    dataJoypad = joypads->j1;    // we only manage jagpad 1 for this demonstration routine

    ph0 = !(dataJoypad & JOYPAD_LEFT);
    ph1 = !(dataJoypad & JOYPAD_RIGHT);

    if (ph0 ^ ph0_old ^ ph1 ^  ph1_old)
    {
        if (ph0 ^ ph1_old)
        {
             // do whatever you need to move anticlockwise
        }
        else
        {
              // do whatever you need to move clockwise
        }
    }
  
    ph0_old = ph0; 
    ph1_old = ph1;
}

     

    (I've not tested it on the Jaguar, it's possible both directions are swapped)

     

    Okay, it took some time to verify this (actually I waited till I have a rotary on my hands!), but there's a small problem with the above code. Unless I'm really reading it wrong of course (some C specifics elude me).

     

    Anyway, I transcribed the above code to GFA Basic on the Falcon for testing some time back and while it worked 100% for one of the two movements (anticlockwise IIRC), on the other one the code was alternating between clockwise and anticlockwise every two ticks (I think - not that it matters too much :)). I traced the problem to the way ph0 and ph1 are calculated; i.e. reading the jagpad, masking for specific bits and NOTting the result. What I did was to convert this to give me $ff for one state and $00 for the other state for both ph0 and ph1. After this it worked perfectly :).

  14. Posted · Report reply

    I have just added a similar routine (counter wise) within the DSP and using the JPIT timers, it gets exactly the figures I am expecting. Am I just trying to interrupt the 68K too much? It feels wrong that this should be the case given there were a variety of sample playback routines on the ST which could manage more than 20kHz playback (I think 32kHz was the top I saw) and that was a ~9MHz 68K

     

    Just to make it worse, recently there has been released a 50khz soundtracker for a plain 8mhz st :)

     

    Anyway, maybe a method of checking would be to output the value to BG and see the color changes?

  15. Posted · Report reply

    Wow, someone actually found it useful? Thanks :)

     

    Tyrant: As it stands, the symbol table is copied verbatim across formats. I pondered a bit about including such a feature, but decided against it.

    Firstly, it'd require that I had a better look at the COFF format, which for the time being I don't have the time to.

    Secondly, I feel that the programmer is responsible for everything he/she releases. It's much easier and safer to have a switch in the makefile (or build script) that turns debugging symbols on and off than me stampeding into the file removing stuff :).

    Thirdly, I don't like making utils that have every feature including the kitchen sink. As it is, it's just some simple code to do simple format conversions. If I started adding stuff I didn't thought of before I starting coding, it'd potentially make the program kludgy and buggy.

     

    Thanks for the feedback though! If such a tool is required by people I might sit down and code it, but as it is I can't justify including it in JiFFI :)

  22. Posted · Report reply

    Hello,

     

    Me and a few friends are thinking about initiating a project to make a batch of mice for the ST, Amiga and Jaguar.

     

    But instead of making an adapter and selling it, we thought we'd simplify things a bit: What we are planning to do is to buy a batch of PS/2 optical mice, removing the PS/2 cord, inserting the adapter logic inside the mouse, and installing a standard 9-pin cord. In our opinion, this makes for a neater solution than having 2-3 adapters in order to get to the computer's port.

     

    The mice we're thinking of using are Logitech optical PS/2 like these:

     

    logitech_ps2mouse.jpg

     

    (the actual model is subject to change, it will depend on the actual quantity we will want to buy and also the source).

     

    The design we're going to use is this, but with the difference of using a better firmware, which gives smoother movement. If you're aware of this design, you'll know that there is a way to have a selector switch for ST/Amiga, but we decided that in order to keep things as simple as possible, we'll hardwire either one or the other. Also, since an ST mouse can be wired to be used for the Jaguar, we can also make mice with a 15 D-SUB end, ready to be plugged in.

     

    What we'd like from people would be initially to see if there's interest in this. We'd like you to just express your interest and how many devices you would like. This is because we cannot estimate the price (it will depend on a few factors). But we would like to gauge interest in this.

     

    After a couple of weeks, we'll count the number of devices people would be willing to buy and announce the price (we hope to keep it low, we're not in it for the money).

     

    So that's what this is all about. Any people interested? Please reply below stating how many devices you would like and of what type (ST/Amiga/Jaguar). Also, feel free to ask questions, we'll be more than happy to reply!

  23. Posted · Report reply

    You see, now this kind of thing is EXACTLY why Atari needed another 6 months of testing on the Jaguar.

     

    More like 6 YEARS really, but let's not split hairs here ;)

     

    Incidentally, on the subject of controllers: There are precisely three Jaguar games* which support non-standard controllers. One is the aforementioned Missile Command VR, supporting the head-tracker. The next is Tempest 2000, supporting Rotary Controllers, but not following the spec on them. The last is BattleSphere Gold, which supports Analog Joysticks, but only on early models of the Jaguar which still have the ADC chips onboard. Atari wrote a nice spec for how to interface them digitally, but it's not been implemented in BSG, which just reads variable voltages off two pins directly. They presumably don't check for C2/C3 either. I believe STe's and Falcons have the ADC chips for Analog Joysticks too.

     

    Yes, the ADC chips do exist on STE/Falcon.

     

    One question though: Does BSG support the same rotary controllers as those you build or are they different? I'd assume that the wiring and mode of operation is totally different.

     

    If you don't have the dev docs, I'd be happy to upload them for you, they're an invaluable tool, although not exactly the most complete or intuitive docs to read.

     

    No worries, the Falcon is my primary target anyway :D

     

     

    P.S. Mods, there is another thread on the rotary in this forum. Maybe we should merge both threads into a bigger one that talks about all kinds of inputs on the Jaguar?

     

  24. Posted · Report reply

    I also posted this on the D-Bug forum a few minutes back, but I thought I'd mention it here, since I don't think there'll be anything different for the Jaguar :). Original text follows in verbatim.

     

     

    Recently I've been messing around with Jagpad input and while I sorted it out easily, I wanted to add support for the teamtap as well. Not wanting to reinvent the wheel, I asked around for some advice on the matter. Zerosquare of CVSD pointed me to two solutions for this.

     

    One was to use heuristics (i.e. make the user press a jagpad button and see if the button press is shadowed on other pads on the same port - if yes, the user most certainly doesn't have one installed), and the other was in fact a method by Matthias Domin, which reads a seemingly unused bit on the jagpad matrix on jagpad #4. Matthias claimed that if this bit (C1 on the jaguar docs) is inactive (at least on Falcon, jagpad bits are all set to 1 when the user doesn't press any button on the pad), then there's a teamtap installed.

     

    That was just what I needed! So I quickly wrote a test program in GFA Basic and sent it to SH3 (I forgot to mention that I don't own a teamtap ;)). And that didn't work 100%. It turns out that this bit can change if there's no teamtap installed and the user presses the pause button. Fortunately we noticed that only bit C1 changes when you insert the teamtap in the port. So Matthias' claim was partly correct. The check that works 100% is:

     

    • if (bit c1 in jagpad #4)=set and (bit c2 in jagpad #4)=set then the user is using a single jagpad without teamtap and pressing pause
    • if (bit c1 in jagpad #4)=unset and (bit c2 in jagpad #4)=set then we have a teamtap! (the trick here is that when a teamtap is installed, then if jagpad #1 pause is set, you don't have any shadowing to the other pads)
    • if (bit c1 in jagpad #4)=unset and (bit c2 in jagpad #4)=unset then we have a normal jagpad, pause is not pressed

     

    (note: "unset" means that the bit is in it's natural state and "set" means it's changed. As I mentioned, on the Falcon it's 1 for unset and 0 for set :))

    (note #2: there's a 4th combination of bits, but I don't think it's possible to achieve this with a normal teamtap, so it's left out)

     

    I hope I didn't screw anything up - after all, I tested at blind (sh3 was my eyes :)). If you find any inaccuracies, please mention them to me so I'll fix the text :)

     

     

    Addendum: The shitty GFA program I used to test all of the above. It's not anything brainblasting, but at least it works (it's for port #1 btw) and it displays all ports' pad bits in the same screen.

     

    DO
  PRINT AT(0,1)
  PRINT "teamtap port a"
  SDPOKE &HFFFF9202,&HFFFE
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFFD
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFFB
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF7
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  '
  PRINT "teamtap port b"
  SDPOKE &HFFFF9202,&HFFF0
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF1
  PRINT BIN$(x1%,16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF2
  PRINT BIN$(x2%,16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF3
  PRINT BIN$(x3%,16)'BIN$(DPEEK(&HFFFF9202),16)
  '
  PRINT "teamtap port c"
  SDPOKE &HFFFF9202,&HFFF4
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF5
  PRINT BIN$(x1%,16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF6
  PRINT BIN$(x2%,16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFF8
  PRINT BIN$(x3%,16)'BIN$(DPEEK(&HFFFF9202),16)
  '
  PRINT "teamtap port d"
  SDPOKE &HFFFF9202,&HFFF9
  PRINT BIN$(DPEEK(&HFFFF9200),16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFFA
  x1%=DPEEK(&HFFFF9200)
  PRINT BIN$(x1%,16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFFC
  x2%=DPEEK(&HFFFF9200)
  PRINT BIN$(x2%,16)'BIN$(DPEEK(&HFFFF9202),16)
  SDPOKE &HFFFF9202,&HFFFF
  x3%=DPEEK(&HFFFF9200)
  PRINT BIN$(x3%,16)'BIN$(DPEEK(&HFFFF9202),16)
  '
  PRINT
  PRINT "C1=";BTST(x1%,0);", C2=";BTST(x2%,0);", C3=";BTST(x3%,0)
  PRINT "So..."'
  IF BTST(x1%,0)=1 AND BTST(x2%,0)=0
    PRINT "you have a teamtap installed!"
  ELSE
    PRINT "you DO NOT have a teamtap installed!"
  ENDIF
LOOP UNTIL INKEY$<>""

×