Tyrant
-
Content Count
1,608 -
Joined
-
Last visited
-
Days Won
4
Posts posted by Tyrant
-
-
Hello Tyrant, hello Robert!
What's ImpulseX?
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.
-
Hello!
I think i posted about this on the Underground-Mailinglist (I bought 2 of the modified ProControllers and added the missing diodes).
Thanksfully this topic reminded about this circumstance, so i was able to add today support for this kind of controllers in ImpulseX to avoid strange behaviour of the program.
Kind regards
Matthias
Hey man, long time etc.
What's ImpulseX?
-
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.
Nice sales pitch
I am watching it, wanting to see how high it goes -Disjaukfia
Thanks, I thought it'd be worth a try.
-
Hello!
does anyone know if this controller will work with Breakout 2000?
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.
-
Hey Tyrant, are you not going to be pursing this thread about another patch of rotary controllers, I know in your other thread that you are selling the rest of the rotary controllers you have on ebay!
-Disjaukifa
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.
-
Mine say July 11, 1994 on most of the pages.
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
-
If I am going to be the only that is going to use this, then I'm not going to bother, however if ya'll would like a copy please let me know, it will take a while. I am going to do it in sections and release it in sections as it is with the downloaded developer Documents.
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.
-
I still have my original Jaguar printed documentation, with my developer number watermarked over every page.
Having electronic searchable docs come in handy when doing development.--Selgus
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.
-
Forgot one thing...
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.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.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.
-
Shit.... I'm truly sorry guys. On my display though, I can stretch or squish the browser to fit however I want it. Do it all the time out of necessity. So, stretching the browser out, I don't see the annoying line breaks at all. Course, I run my display natively at 1344x840, so maybe those with lower resolutions and smaller monitors are the ones seeing the annoying line break thing. I'm trying my damndest to break myself of the habit though - I swear :-) Thanks for making this old man feel like a computer newbie ovalbugmann! lol
-edit- had to insert an extra 'n'... like Manfred Mann, to your user name.
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.
-
I believe the docs are wrong on the 2KB page size. The page size is dependent on the RAM chips used.
You can imagine the RAM memory as a grid of memory cells. To select a memory cell in a normal DRAM chip is a two step process. First you select the row and then the column. In fast page DRAM, you only have to select the row once when you access multiple columns in the same row. Thats why access in the same page (row) is faster.
Now, the Jaguar has 2MByte of ram in four 16-bits wide chips. So each chip has 512KByte (16-bits wide) thus 512*1024/2=262144 16-bit cells. The square root of 262144 = 512 thus there are 512 rows with 512 columns each selecting a 16 bit cell. Thus each page is 512 * 2 byte (16 bits) = 1024 bytes or 1KB per chip. Since there are 4 chips in parallel to give 64-bit wide access, the page size is 4*1KB = 4 KByte
Robert
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.
-
RAM-to-RAM blitting is an interesting case, as you'll indeed waste lots of time because of the constant pages misses. But I believe using the GPU/DSP RAM as an intermediate buffer should solve that problem.
For other things though, like running code or displaying graphics using the OP, I think ROM is really slower than RAM.
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.
-
And anyways, it's best to copy everything you can into RAM anyways since ROM is much slower in all cases
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.
-
No I do not have the documentation, can you post links to where this documentation is???
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.
-
No I do not have the documentation, can you post links to where this documentation is???
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.
-
Is there a good book or site that anyone knows about that good for assembly???
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.
-
The developers long ago abandoned everything about the Jaguar. They aren't making a cent off of any Jag sale today.
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.
-
4
-
-
I was going to mention it at JFUK but I forgot, anyway there was a STOS program (just BASIC code) written by Tony Greenwood I think that would read out text on the ST, I assume that is they type of thing you are looking for. I have never tried STspeeach is it I do not know if it is better or worse but it might give you some ideas if you can find a copy, try asking some of the STOS people on Atari Forum if they have a copy or know where you can download it.
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.
-
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.
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.
-
but who is modding controllers with a detent pot? Yeah, not normal - or good. I hope NOBODY is producing rotary mods using that silly method.
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.
To me, "free spinning" means 360˚ rotation. This "detent" or stepped attenuating potentiometer business is a
whole other chapter...
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.
-
I just ordered one from TrickyDick and forgot to ask if it's free spinning! I would assume so.
Why would you want one that is not?? Like the arcade, you should be able to spin that bad
boy 'round and 'round if you please. I know that these are not weighted, but models that
prevent total free spin ala the 2600 paddles would feel all wrong on this game.
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).
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Rotary Controllers
in Atari Jaguar
Posted
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.