Tyrant

Some auto-detection is better than none. And with the magic pulses coming once every 4 steps, the odds are that you'll be able to detect the right controllers while people are still on the menu, and thus only need them to go into the options in order to calibrate the sensitivity. Thus do you add polish to your game.

Look at the Duranik website. It seems Matthias is working on a Jaguar version of the Atari Falcon Arkanoid like game called: Impulse I didn't play the Falcon version yet, but it looks great. I suppose, in addition to the rotary controller support, Matthias will add Atari/Amiga mouse support and maybe Atari paddle support for ADC equipped Jaguars? I wonder if it would be possible to add USB mouse support if you have a SkunkBoard, since Atari/Amiga mice are difficult to find. Technically it is possible, but I wonder how difficult it is to read USB mice via the SkunkBoard's USB ports. Robert Robert is right, "Impulse X" is an eXtended version of Duranik's Falcon game called "Impulse". Because of the many features i have added to the Jaguar-version (like controller-support, built-in level-editor), we decided to add the X to the game-name. Rotary-Controller support will include VCS driving controller, digital ST or Amiga mice and modified Jagpads (now in two flavors ). My experiences with the accuracy of the analog VCS paddles weren't the best, so there is no support for them built in, sorry. Impulse X will be released on CD as this allows to access the MemoryTrack. Kind regards Matthias Sounds great, I can't wait. Btw, you do know that what the techref says about rotary controllers is utter bollocks, right? The grey code is there, but just on the left and right button lines, and the controller-type bits are the not modified from a standard pad. However, you can auto-detect both rotaries and bus mice because they will push both left and right (rotary) and up and down (mouse) simultaneously 1/4 of the time.

Hey man, long time etc. What's ImpulseX?

Nice sales pitch I am watching it, wanting to see how high it goes -Disjaukfia Thanks, I thought it'd be worth a try.

Not with the officially released version of Breakout 2000, but the source for this game was released, so it is possible to add support of rotary controllers to it. Kind regards Matthias Darn, that is another game that I think would honestly benefit from a rotary controller . . . I'm too lazy to try to add it to a custom version of Breakout myself . . . the controls with the D-Pad aren't bad, their quite good actually, just thought a rotary would be nice. -Disjaukifa You're right, a rotary for that would be ideal, but as Matthias said, the source is out there, and looks to be complete, so it shouldn't be too hard for someone to patch a new version that does support Rotaries in the future, so you can look at this auction as an investment for the future: one day it will work on games other than T2k, when they get patched or written.

Just a reminder, there are only 48 hours remaining on this auction currently.

I made up a few to sell at JFUK. Three of them didn't sell so I'm putting them on eBay currently. If there's enough demand for them, I'll consider ordering extra parts and putting together another batch. I've only got nine more mint controllers to mod though, so there will definitely be no more than that, but given that the encoders I used are getting harder to source in the uk I may not make any further ones if demand is low. We'll see. It also depends of course on how busy I am with uni this year.

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.

The stuff publicly available is from mid 1995 or so. I've clearly got too much time on my hands, as I just went through and checked all the docs for their dates: 00 index 11 nov 1994 copyright 1994 atari corp 01 getting started 5 june 1995 copyright 1995 atari corp 02 tech overview 10 april 1995 copyright 1995 atari corp 03 soft ref 7 june 1995 copyright 1992-95 atari corp "version 2.4" 04 tech ref 26 april 1995 copyright 1995 atari corp 05 hardware bugs 26 april 1995 copyright 1994 atari corp 06 cd-rom 16 may 1995 copyright 1995 atari corp 07 modem 26 april 1995 copyright 1995 atari corp 08 workshop series 8 nov 1994 copyright 1994 atari corp 09 samples 16 may 1995 copyright 1005 atari corp 10 libraries 26 april 1995 copyright 1995 atari corp 11 qsound 25 april 1995 copyright 1995 qsound labs 12 cinepak 16 june 1995 copyright 1995 radius inc and atari corp 13 tools 5 june 1995 copyright 1995 atari corp 14 apendices 26 april 1995 copyright 1994 atari corp 15 madmac 8 nov 1994 copyright 1994 atari corp 16 linker 5 june 1995 copyright 1995 atari corp 17 debugger 93/11/15 no copyright notice

Well, I just printed out the key bits of the scanned pdf's (softref, appendices, etc) and keep them in a binder, I actually find them easier to refer to on paper than as a pdf, but I suppose a machine readable version would be of benefit for many people. It would also form a nice base for an updated set of documentation, including the things the community has discovered post-Atari, so I say go for it. What format were you thinking of? You would want it to be fairly accessible, but also be able to manage large documents and support nice formatting (and diagrams)... micros~1 word would be one choice, but LaTeX would be my suggestion for a document that size.

You do?! What are the dates on the bottom? If you have newer versions of anything from the scanned pdf's I think I can speak for everyone when I say we would all be in your debt if you could scan and release them.

It looks like you're absolutely right. I always used v8 as I thought it was the most recent version, but comparing it with the one scanned by Starcat, it's obvious that it's not. For other documents, I used a different set of files as they were cleaner (can't remember who did the scanning), but it appears they're older than Starcat's version. Now I have to read the whole documentation again to see if there are "new" things in it . Many thanks, Tyrant ! You're welcome, glad I could be of some help. See, I very rarely get round to actually writing any code, but I do spend a lot of time reading docs and planning code.

Pfft! It doesn't bother me in the slighest, but I guess people on a really low resolution would get a line and a half for each of your lines and that is annoying.

Hmm... interesting. I really don't know enough about how ram access works to know if you're right or not, but either way, it's still a fairly small window, given that ALN will pack all the text segments together and all the BSS after it, the odds are that code and data will very rarely, if ever, be on the same page.

Yes, that all makes sense. Someone should really compile a new version of all the docs, and include a section on page misses and how to avoid them. After all, if ram to ram blitting (at 64 bits per blitter tick) was slower than alpine to ram blitting (capped to the 32 bits of the cart space), then it follows that a page miss is more than twice as slow as a page match. When executing code out of main ram (risc code or 68k code), the odds are that any data loaded or moved will be a long way away from the code, thus causing two page misses on every load and every store, and up to three page misses on 68k instructions. In fact the only 68k instructions that won't cause two page misses are ones that only operate on register operands or immediate data. That's a lot of cycles wasted waiting for the memory controller. You could probably get double the performance from the 68k simply by running your code from either cart space or the cache in tom or jerry... assuming the 68k can cope with their "all memory is 32 bit" behaviour.

Symmetry of TNG made an interesting test program a few years back, in which he blitted a bitmap several dozen times from cartspace into ram, and then blitted the same image the same number of times from ram to ram. He was using an alpine, and found that actually, the cartspace ram on the alpine was slightly faster than the main systems ram, most likely due to avoiding page misses in main ram. I'm not sure how this compares to cartspace roms, but I would assume its similar. Remember, Jaguar ram is divided into pages of 2 kilobytes, if you make successive accesses within that same page, the memory controller can respond much quicker than accesses at more distant locations. However, cartridge space is evidently not paged in the same way, and can be accessed without changing the current page of main ram that is active. edit: Also, going back to the v8 vs scanned manual issue: the scanned pdf's state that the page size is 2kbytes, whereas v8 (iirc) simply mention page misses once or twice but never elaborate on the issue or the page size in the jaguar console.

In response to another thread over in the main Jaguar forum, I've uploaded the Atari developer docs. I figured if I post them here as well then the link should remain archived for some time. If the files are ever removed from rapidshare, just pm me and I'll put them back up. http://rapidshare.de/files/48454707/MANUAL.zip.html Included are both the scanned pdf's, and the 'v8' techref, which was released in 2001, but I am convinced it was in fact taken from an earlier (and thus outdated) revision dated somewhere in '93. I hope these are helpful to someone.

Hmm... Actually I'm afraid I've no idea. I got my copy almost a decade ago. Starcat was hosting them back then, but took them down due to bandwidth costs. I tell ya what, I'll stick them up on rapidshit for you, they're only 75 meg or so, so it shouldn't take too long. Hey Tyrant, I really appreciate that, thats awesome!!! Post the link once their up please -Disjaukifa Here you go. I've included both the scanned copies from '95, and the "v8" version from '93 released in 2001. I'm convinced that the v8 version is earlier, and thus outdated by the scanned copies, but you're welcome to draw your own conclusions. http://rapidshare.de/files/48454707/MANUAL.zip.html Hope they're helpful to you.

Hmm... Actually I'm afraid I've no idea. I got my copy almost a decade ago. Starcat was hosting them back then, but took them down due to bandwidth costs. I tell ya what, I'll stick them up on rapidshit for you, they're only 75 meg or so, so it shouldn't take too long.

Depends if you're looking at 68k assembly or the Jag's custom risc chips. 68k is slow as shit, but has such a wonderfully complete instruction set and range of addressing modes that it's not all that far removed from basic. I learnt 68k asm from a very thin book which must have been really cheap to produce since 90% of it is just a reproduction of the instruction set descriptions. The risc chips are a little more awkward, very limited addressing modes, far fewer instructions, and the instructions generally do less (no dbxx for example). But if you already know another kind of assembly, the move to learning the riscs shouldn't be *THAT* hard just based on the atari docs. You do have a set of the atari documentation, right? There's a discussion on JSII right now between myself, Steve Moss and Gorf, in which we're trying to work out which is the most recent version. I think I've proved that the scanned multi-part pdf's are the most current version, and that techref v8, which was released to the community in 2001 as "the last version" was infact a much earlier revision.

You mean the commercial developers active during the console's heyday? There are active homebrew developers for the console. No developer is making money from Jaguar games, nor will they, ever again. Sure, you might make a small profit over the cost of materials, maybe even the time taken to assemble each cart... but NOBODY is going to make a profit when you factor in the cost of the developer-hours it takes to code a game on this beast. That single fact alone is what makes the whole "OMG PIRATES! OH NOES!" bullshit so meaningless and frankly retarded.

Interesting... in STOS basic you say? That's either very impressive or simply a wrapper that calls stspeech.tos I'll have a hunt for it, although now I've found a disassembly of stspeech I'll probably just go from that, since the sound of its voice is so well known and loved.

Thanks for clarifying Tyrant. Sounds as though, even with the slight detent, that the encoder still operates smoothly and does not loose or skip values during the indent/detent. Stepped attenuation with no grey between is typical in a potentiometer scenario and that's what I was thinking originally. My bad! And yes, I took it that the term "free spinning" mirrored how the driving controls behaved. Never crossed my mind that someone would use a rotary knob with a slight detent to it. Interesting! I'm sure they're fine then as 1 million happy customers can't be wrong :-) lol *grins* hardly a million, but yeah I think the general consensus is that they work just fine. I've never seen a stepped pot, but they sound like they could have their uses, in specific scenarios. The way Jag Rotaries work is the same as the 2600 driving controllers, but more sensitive. Basically a two bit binary grey-code; a pair of squarewaves with one preceding the other by a quarter cycle. There are thus four steps per cycle, and on the encoders I use, 9 cycles (which is 36 steps) per revolution. For comparison I believe the 2600 driving controller used four cycles per revolution, but I could be wrong on that.

Uh... I am, and so is (or was) Jonathan Ascough. Well, it's not a pot since the signal is a 2 bit grey code, but the encoders both I and he used have a slight detent to them, and I've never heard a complaint about it from people who've actually tried one. 360˚ rotation as opposed to what? one that would only go 270˚ and stop? That wouldn't, couldn't work with the way Tempest operates. All the encoders, no matter who they're made by, can be rotated infinitely in either direction. I know the 2600 had both driving and paddle controllers, but that isn't the case for the Jaguar, since there are no games that would benefit from that kind of input.

The distinction between "free spinning" and "detented" isn't really so significant. On all of the rotaries based on ordinary controllers, the knob is only about an inch across, and won't spin once you let go of it. For that you would need a much larger flywheel-like knob. The only difference is that the detented ones have a slight... detent, is really the only term for it, on each step of the signal it sends. This makes it easier to navigate the menus, and also to play the bonus levels, which behave rather... strangely (read: they're buggy as hell).