Tyrant

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

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.

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.

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 )

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.

So, hi to those who know me, hello to those who don't and yah boo sucks to the dicks who have to spoil it for everyone

Hiya, nice to see you joining up to this little oasis. I completely agree on your evaluation of it btw, it's a brilliant site, largely forgotten by the masses, and full of good stuff. Just a shame so much is in French, but that's mostly the old stuff.

Nah, use French, google translation is good enough for us

Google translation is *WEIRD*

Anyway, any chance you guys can call off the hounds?

I think you're referring to me, and as I said on AA I'm nobody's (nobodies?) hound.

Still, sorry for making a mess of your thread over there, I only wanted to post one brief comment but then got dragged into saying more by certain other people. I'll try not to let it happen again.

Since all original games had to use Atari's eeprom code, would it be possible to write a tool that scans a rom, finds the eeprom code (if it's always the same source it should compile to the same binary) and replaces it with a compatible one for the new chip?

Or just make the general commercial release use the 128b eeprom, and have the 2k one available for developers doing bulk releases.

Btw, this is not the primary reason for this cartridge

No of course not, I was just curious since it was explicitly mentioned.

Very awesome.

Just out of curiosity, what makes you think BS won't run on it?

You see, now this kind of thing is EXACTLY why Atari needed another 6 months of testing on the Jaguar. For the sake of A SINGLE DIODE! they made the C1-3 bits be all locked into the pause button (push pause and C1, C2 and C3 all go low too).

There should be a diode connecting pin 6 to the pause button, but someone forgot to include it (or decided it wasn't necessary) and it was never spotted in testing, because how many people hold pause when games start and do their TeamTap/Controller detection?

As you found out, assuming nobody is holding pause, the state of C1 should be that normally it's high, and the only time it is ever low is on socket 3 (player 4) of a TeamTap, which sets it low as an identifier. Seems a terrible waste of a bit to me, but it's not really significant I guess.

Btw, on the subject of the C2/C3 bits, everything Atari says about their use can safely be ignored. They should be used for controller-type identification. In other words, different combinations of C2/C3 indicate different controllers. The normal pad has them both high all the time (except when pause is pressed it seems), the Rotary was meant to have one high and one low, but nobody who made rotaries has ever implemented that (we leave them high like normal pads), and on top of that Tempest 2000 does not appear to support auto-detection of them using C2/C3 anyway. The ONLY advanced controller Atari ever made that actually (we assume) follows the spec is the VR head-mounted tracker, and there are precisely two of them, so it doesn't seem worth supporting them (especially since most of it is still undocumented).

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.

*I believe Starcats point-and-click will have support for bus (Atari) mice, when it comes out. Also there is the Balloons light gun demo, but guns read differently again.

On the subject of Rotary Controllers, the Atari spec is awkward and has never been implemented in full. It requires the knob-movement to be encoded on the left and right pins of socket 1 (i.e. player 2 on a TeamTap). No buttons are on socket 1, and a "pass-thru connector" should be used, which will respond to socket 0 codes and have an ordinary controller plugged in. This is ugly as all hell, and thankfully was never made that way. EVERY controller anyone ever made responds simply on socket 0 codes, and just has the left and right buttons replaced with the rotary encoder (usually losing up and down at the same time). The encoders produce a 2-bit grey code, which consists of a pair of square waves, 90' offset from each other. Each "step" of revolution changes an edge on one of the lines, enabling you to tell direction, and naturally the rate of change lets you know speed. In this they are identical to how Atari mice work (although I'm not sure how bus mice appear to the system, there might be a processor on the keyboard to help with them).

The best, and only reliable way to detect a Rotary is to watch for the situation where both left and right are simultaneously depressed. You can add that check to your standard controller-reading routines, and need not have an actual "detection" phase before launching the main menu. As people try to navigate the menu, or launch the game, they will rotate the knob, and you will see both buttons depressed at once (it happens 1/4 of the time), at which point you can adjust for a Rotary input. It helps to update the speed at which you poll the controller, to up the sample rate and avoid the situation where the user twists the knob more than 1 position in between the times you're reading it. Yak does it under interrupt from Jerry's PIT signal, and reads rotaries 8 times as often as normal pads. From what I can see of reading/searching through his source, he never once looks at socket 1 (player 2 on TT) and thus cannot be following the spec. He reads them just as we've been building them, which does beg the question of why Atari wrote the spec in the arse-backwards way they did.

Mouse detection is another anomaly, in that the only mouse adaptors people have hooked up are simple wire-crossing affairs which take no account of the 4 different common wires the Jaguar uses, and thus always output x1, x2, y1, y2, left and right, regardless of which row you're reading. They can be detected that way, or by the same method as Rotary detection, only you can check for up and down both being depressed at the same time as well as left and right, thus doubling your chances of detecting the controller quickly, before the aberrant signals cause unwanted button pushes.

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.

P.s. Sorry for the wall of text, I like to be complete where I can be.

P.p.s. Feel free to copy/pasta this elsewhere if it is useful to people.

The 74HC245 fits the bill.

Mr Zerosquare sir, I think I love you! Thanks! This will make things so much simpler.

Actually scrub that, its pinout is still annoying. Does anyone know of a driver with all it's input (a pins) on one side, and all its outputs (y pins) on the other?

Thank you.

Next question: Would an HC365 or 367 work in place of the LS244? It looks to be similar enough to me and has a nicer arrangement of input and output pins, but I'm still a noob when it comes to electronics.

I'm trying to understand exactly what goes on inside the Jaguar's controller. My knowledge of electronics is practically zero, and I'm running into a few head-scratchy moments.

From a logical perspective, things are fairly simple, except for the use of negative logic throughout. There are 4 outputs from the Jaguar, which connect to the buttons (via diodes to prevent cross connections) in a 4x6 matrix, which then flow to the 6 inputs on the Jaguar. The Jaguar enables each of the 4 pins in turn, reads the 6 pins and caches the result in the right row and moves onto the next of the 4 pins. Simple, relatively anyway.

But when we drop down a level and look at the electronics, things get more than a little confusing for me. The 4 outputs from the Jaguar (which are enabled by driving them low) are connected to the inputs of an LS244 / HC244 type octal 3-state line driver. Only 6 of it's 8 lines are used, and the output enable pins are wired always on, which as I understand it, means that the driver will either drive the lines high or drive them low. What is confusing me is the arrangement of the diodes and pull up resistors on the input side of the LS244. My best guess is that the pull up resistor keeps the line high unless the Jag is driving the line low and the corresponding button is pressed, but I'm not entirely sure I understand how.

Also I think there's an error on Steven Moss' diagram: pins 14 and 6 seem to be the wrong way round.

JAGPAD__Schematic_Design_.pdf

Just a reminder that there are now only 48 hours remaining for this auction.

Just to let everyone know, I've just put up a new Rotary Controller on eBay.

You can find it here (in gbp) or here (in usd).

I have two more built and ready to sell after this one. I tried to list all three at once, but it seems eBay thinks that's too confusing for noobs and have disabled it unless you're selling at a fixed price. Go figure.

Hmm... can someone explain what the expected output of this circuit is?

I'm guessing it doesn't use the official atari way to read analog inputs (a bank switched advanced controller type returning the output of an adc digitally), right?

My electronics skills are... limited at best, but it looks like it's just producing a variable frequency squarewave on the up and down buttons, right? essentially a PWM signal that relies on the Jag to decode? Wouldn't that mean you'd have to poll the controller ports incredibly frequently, and with a regularity that would be tricky to achieve? or am I barking up the wrong tree entirely?

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.

 

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

Having fired up teamtap.bin and hooking up one of my rotaries, I can confirm that the directions are in fact reversed.

When rotating clockwise the pattern is:

none, left, both, right

and anticlockwise is:

none, right, both, left

I seem to remember that this was so the first level of tempest made more sense. If you want the claw to travel clockwise around the level, twist clockwise.

-- Tyr (aka Tyrant)

Hiya, I've been out of the scene for a loong time now, but have got my alpine out again and am looking to get back into Jag coding. However, I'm curious as to what has happened with the various emulators since I dropped out of the loop. Have any of them become stable enough to use to test code on. I have a friend who is interested in working on some projects together, but doesn't have bjl, or a cdrom, or prot:se, so we were considering setting him up with an emulator.

Has anyone here tried something like this? The emulation doesn't need to be perfect, since I could test regularly on my alpine, but are any of the emu's good enough to even attempt to write software on?

Thanx everyone.

Hi Tyr, I hope you find here a place for your "not so" distant game plans

Ah, the only games I have planned require me to get a lot better with the riscs, and write a new 3D engine, so that'll take a while, but I'm sure I'll have other stuff to release in before then

Welcome Tyrant ! (nice avatar btw )

Thanx, its a montage of my other icons from other places and times. I hope you all recognise the cry colourspace in the middle of the animation

Well, since this seems to be the thread for saying hello in, I guess I should say:

Hello Jagware! :waves:

Many of you (the non-french crowd anyway) already know me as Tyrant. I've been around for many years, although not very active the last year or so. I made rotary controllers and was the first to use the currently popular design of having the encoder replace the d-pad in a normal jag-pad.

I've used the Jag to teach myself assembly, and now feel fairly confidant (if a little slow) in 68k, and am just now making my first faltering footsteps onto the risc chips. I've not released anything yet (except an extremely hacked in patch to balloons), but I've a few demo effects in progress and distant plans for a number of games.

Well, that about does it for an introduction I think. So, hi to everyone I know, and hi to everyone I don't know yet.