Zerosquare

The subject comes up quite often here, and several topics have been created about it. This one has some good info. If you're not experienced with soldering tough, I'd suggest asking someone who is to fix your Jaguar, or at least finding another unit and giving/selling the dead one to somebody able to repair it. You can aggravate the damage with improprer soldering, and it's wasteful to throw away things that can be repaired .

A topic with links to all pictures and videos taken at the RGC 2006 has been created on the yAronet Atari Forums here. (It's in French, but it's all pictures anyways ). It should grow in the next few days as people upload their stuff.

Don't you think Tom & Jerry are already buggy enough at their normal clock rate ? Overclocking the Jag has already been evoked before, but one problem is that everything (video, audio, timers, RAM access times...) is tied to the same clock, so you'd have to patch existing software. Also, even if the Co-Jag uses the "same" chips, they're not necessarily manufactured using the same process, which has a major influence on the chip's maximum clock rate. If the stock Tom & Jerry could run at 52 MHz, I don't see why Atari wouldn't have done it (a 52 Mhz oscillator is not much more expensive than a 26 MHz one )

Same thing here.

Simple gameplay, but it looks well-executed, especially the design and graphics (well, not really surprising considering they've been drawn by Duranik ). The audio part will probably worth it also. Good job !

The best thing to do is an AV mod (sorry )

That's basically what I'm describing, only I believe the video card, and not the OS, is doing the overlaying.Yes, you're right. My sentence was confusing. What DirectDraw actually provides is a standard way to configure the hardware to do the hard work for you (the hardware-specific details are handled by your video card driver). Well, I'm not supercat , but in my experience it's implemented like this : instead of generating alternating odd and even fields, they generate odd (or even) fields only, at 60 Hz.

So true. This is why there should be a chapter about Murphy's law in electronics textbooks

I don't get how that would work. BTW, I'm an E.E., very interested in A/V stuff, and I wrote low-level (directly accessing the hardware) video capturing and displaying software for personal use. But I'm not saying you're wrong, I'm just trying to understand. The TV signal has completely different timings from the VGA signals, and they're not even phase locked to each other. I can't think of a purely analog way of displaying the TV signals in a "window" inside the VGA signal. (Which means, on second thought, that what I said about the ISA cards being fully analog is not true.) AFAIK, the fastest way of displaying a TV signal with a VGA card is by using the "overlay" hardware feature (it's implemented in DirectDraw, for example). What happens is that the VGA card checks each pixel in the frame buffer for a particular RGB value. If it matches, instead of using this value, it computes the value of the pixel using the data from another buffer (optionally doing on-the-fly scaling and colorspace conversion (e.g. YUV->RGV)) ; the computed value is only displayed, not written back to the frame buffer. Some DVD and video players software use this feature also ; in this case, if you try to do a screenshot with the Print Screen key, you get a solid color where the video should be (since that's what the frame buffer contains). Transferring video data into the "other" buffer can be done automatically via PCI bus mastering (it's even easier if the VGA part and video capture part are on the same card.) Right. I've heard that it's because it flickers less that the usual interlaced mode. Makes sense, since usually you're standing closer to the screen when playing video games (compared to watching TV), which makes flicker an issue. Not quite right. There are 262 1/2 scan lines in each field. But the sync signals are slightly different between the odd and the even field.

Are you sure ? The only true analog TV cards I known of are very old ISA-based ones, that required an external VGA pass-through cable (like the first 3Dfx 3D accelerator board) and/or the use of the VGA Feature Connector. PCI video capture cards, even 10-year old ones (like mine ), are digital. And they don't cause any noticeable lag with proper drivers and displaying software. Can one of the 2600 gurus here tell whether the generated video is interlaced ? Some video capture cards don't like non-interlaced signals ; I know it's an issue on mine with my Jaguar.

The day we leave the Jaguar scene, we'll take appropriate measures so that the knowledge is not lost. And anyways, if we released the details publicly, you'd blame us for helping people who whant to crack the protection. You can't have it both ways.

I didn't list system specs for the Catnip because it makes very little difference ; I've tested it both on a 233 MHz machine and on a 2.1 GHz machine. The reason why Alpine and BJL speeds vary wildly beetween machines is that they're basically parallel port hacks, which are especially problematic on today's operating systems. In contrast, the Catnip is based on a standard USB chip. As for the rest, please reread my posts. Except if you're a developer, you probably won't use the Catnip to upload programs to the JagCF. I can't give you transfer rates on the PC side since it depends on which Compact Flash writer you use (and also on the card, forgot to mention that - all CF cards are not created equal, speed-wise). And obviously, the speed on the JagCF side has no relation to your computer's specs. The JagCF will have a feature designed to lock the inserted Compact Flash on request.

If you wanted me to reply to that, I can't. I don't have an Alpine.

I did. Earlier in this topic, via GT Turbo : It's a link to one of my posts on Jagware. I'll even paste it there : (The time quoted for Native is using the standard BJL mode, not the fast JagCF mode). And directly :

http://www.earthstation1.com/ThemeSongs/Un...d_Mysteries.wav http://justclaws.atari.org/sounds/t2000-1.mod (Use Winamp or another .MOD player) Sounds somewhat similar to me, but not that much.

Beefdrop is a hack.For or for not, using cartridges games on JagCF ? dont emulate F-18 Hornet ROM Four recents topics in which you've been particularly vocal about your opinions. Four topics that ended up locked. Yes, please give it a rest, I'm getting tired of seeing you accuse the entire AA community of being pirates and all that jazz. Yes, we have ROMs for the older Atari systems here on AtariAge. These systems are 20+ years old and most companies have turned a blind eye to the distribution of these binaries. When asked by copyright holders we have removed ROMs from AtariAge. No, we don't have Jaguar binaries as it's a newer system, there are many vendors still selling new copies of Jaguar games, and the Jaguar community is a fair bit more sensitive about this sort of thing (you being a prime example here). ..Al If you want to shout your point of view over and over again, there's JSII. Next time you do it here, I'm reporting it to the mods.

You already managed to get the other topic closed. There's no need to go on with this, you've voiced your opinion loudly enough. This is not JagCF related, open a new topic if you want to discuss it. And personally, I've never seen anyone transfer Native in 5 seconds with BJL.

Anyways, uploading programs through USB will be essentially used by developers. The "normal" way of using the JagCF will be to copy the software you want to run on a Compact Flash using a PC (or your favorite machine) ; the speed is the one of your card reader. The JagCF's own transfer rate is not 100% known since the hardware is not final, but it'll be at least several megabytes/second, so speed isn't a real issue.

http://www.danrock.com/ But as it's just a generic op amp, it'd probably be cheaper to find a modern equivalent. You may even manage to get a free sample from the manufacturer.

Hmmmm... I'd have to disagree with you here

You could check the output signals of the chip with an oscilloscope, but you'd need to be familiar with the expected ones first. Anyways, I don't think you have a 'scope, do you ? If you have access to another, non-modded NES, you can add a DIP socket on the cartridge where you removed the chip, plug it in, and checks that the cartridge still works. IIRC, the lockout chip in the cartdridges and in the NES are identical, with only one pin wired differently to setup which is which ; so you could also desolder another chip, hook up both together, and check that the RESET signal they generate is inactive (which should be the case if the communication between the chips is OK).

JagChris and T2KFREEKER, please stop this, I don't want to see this thread locked. If you want to fight each other, PMs are available.

Thanks for voicing your opinion, Songbird.

*sigh* I have said this before... Since your game has not been released yet, all you have to do is to include detection code to be sure that it won't run on the CF. For existing games, we're looking at a solution to "block" the ones whose developers don't want to see on the CF.

They're Atari Falcon pads. They are compatible with the Jaguar, but not really rare AFAIK. Besides, the D-pad is said to be worse than the regular controller's one.