Dean Odley

So after tracing the d-pad back to the 244 I can confirm that right connects to pin 6 and left to pin 8. It turns out that the pin-out of the rotary is non-standard as was suggested might be the case. If you are looking at the rotary with the shaft pointing upwards, and the legs to the front, common is on the right hand side. I've never seen this layout before but maybe it's not unusual in some brands from afar. Once the rotary was wired up correctly everything works great. Thanks again to @Zerosquare for the steer.

@Zerosquare thanks for the info. My controller is a G-series but does not look like that inside. What I assumed was ground is actually pin 4 on the joystick port. I think this is correct but the diagram I followed may not have been correct. So, if we agree common goes to pin 4, do A and B go to pins 6 & 8 on the 244?

I finally got around to adding a rotary encoder to one of my jag controllers. I followed the wiring diagrams I found on line, where one side of the rotary is wired to d-pad left, and the other to d-pad right with ground to the centre pin. I did not include the switch as the encoder is mounted on the back, out of the way. My problem is that the response is janky. The rotary jumps back-and-forth when turning in either direction, sort of like left, left, left, right, left, right, left etc. The funny thing is that I have tried three different rotary encoders (of differing types) in two different controllers all with similar results. The game selected doesn't seem to matter - the behavior is the same no matter what. In Rebooteroids, i have played with the trim but it doesn't stop the basic underlying issue. The encoders are bog-standard ones I had lying around, detented with 24 stops, but are not the recommended Bourns type. I have to admit I'm stumped and was wondering if anyone has any ideas?

@Zerosquare thanks for that. I belled out my cable and it is the same as yours with one difference, 9B <-> 19 & 21. For some reason my TV detects the signal as CVBS and not RGB. It works OK with my other SCART cable.

Yes that seems to be what's happening. Do you know if there's a schematic for this cable online anywhere?

Just some info for anyone interested - I got an official ATARI scart cable from BEST and the screen flickers like crazy on my setup. It does not appear to have the 220uF capacitor and 680R resistor required for C-SYNC so it may be wired to a different spec. I haven't had a chance to look at it too closely but possibly if you have an OSSC it may not be an issue.

This is true - the games were optimised for the displays of the time. Therefore a CRT is much more "forgiving" of S-Video or composite signals. In my opinion both of those signals usually look awful on modern displays, which really only suit HDMI or a component (RGB, YpPbPr) signal.

Some people say that RGB is superior as it's the closest thing to what actually makes up the TV picture, i.e. red, green and blue dots. Component on the other hand uses a luma (Y) signal and two other lines U & V to "encode" the colour information. Luma on it's own is a black-and-white signal. Some consoles have native RGB, like the PS2, XBox etc. The N64 needs a mod to output it, but it is much easier on the early NTSC models. Unfortunately, for the Jaguar, it's not possible to output RGB over component cables without some sort of active converter, that's why you'll never see a component cable that plugs straight into the Jag. From there your choices would be RGB to HDMI or RGB to component, although the former would be more common.

Yes I think RGB is the best you will get from a Jaguar. Component and RGB SCART both carry the signal as individual "components" - for the former it's YUV and the latter it's RGB. SCART was a French invention and was widely used in Europe, but was not adopted in the US where component became the de-facto standard for analog video. In practice they are similar in quality but one important distinction is that SCART signals are typically interlaced whereas component normally uses progressive scan. SCART also carries audio in the connector as well as CVBS (composite) - the RGB part is optional. When RGB is used the composite line is repurposed for sync, and called C-SYNC.

Contact info is at the bottom of this page: https://www.best-electronics-ca.com/text.htm

I'm lucky in that I have an old 48" LCD with a single SCART input that produces a fantastic picture. No OSSC or scalers, just a simple RGB SCART switch to go between the Saturn and Jaguar.

I'm curious as to what most people do with their SCART output here? convert to HDMI via OSSC/Framemeister/Retrotink etc.? native SCART input on CRT or HDTV (not an option for US fans)? convert to RGB component?

AvP never crashed on me, only Doom, but as I recall AvP's attract mode is not actual game-play so I don't think the jag is getting too stressed with it. I think if you were going to have trouble with Doom you would know about it within those 30 minutes ... so you may be OK

I have the cool-novelties cable (linked on eBay above) but be advised that although the cable sheath is doubled screened, the conductors inside are not individually screened. It's obvious when you pick it up as the cable is quite thin when compared with a fully-screened cable. This situation can lead to hum. In my case there is a noticeable audio hum on bright/white screens but during most games when the screen is darker it's hardly noticeable, but it is ALWAYS there at some level. Of course YMMV but if you want to avoid any hum whatsoever then maybe look at a cable that has individually screened conductors but it will most likely be more expensive than one that doesn't have that.

Good news. What about AvP?

OK, thanks @Zerosquare

Fair point. No everything seems fine. I was thinking of using my older Win98 computer which has an actual RS-232 serial port, not USB. The diagnostics may not reveal much, but at this stage I'm just curious to see the output. From your diagram, it looks like I can just connect the Tx, Rx and GND pins directly to the 232 port. Something like the attached image, except Jag2 is the PC. Is that correct?

Answering my own question here but it looks like the save game only includes the level number, ammo and health. Loading a save from the middle of level 2 puts me back at the start of the level with the same health and ammo I entered the level with. I confirmed this in an emulator. Seems a bit strange and only slightly more useful than the level warp cheat.

@Zerosquare Thanks. I assumed incorrectly that the normal ROM and headless ROM were loaded into different memory locations. For some reason, Doom doesn't crash when the header is absent, and so I can live with that now that the GD makes it so easy. It does not appear to be a common problem but perhaps the info in this thread will help someone in the future who comes up against the same issue .

Thanks @Zerosquare and @Mitch. I've run the diag cart successfully and there were no obvious errors. Everything went according to the printed instructions. I've also run the interactive cybermorph demo without issue. So do you think that means the hardware is OK? Is it a comprehensive test? Is there an easy way to wire up a serial port to the smaller edge connector to see the additional output or do you always need the catbox/jaglink interface, and then a RJ11 to 232 cable?

From my (limited) experience so far, the red screen usually means a problem with the electrical connection between the cart and the machine. So you're looking at the cart edge connector, the cart slot and the physical connection between the two. The standard advice seems to be clean, clean and clean again. When I got my jaguar, only one of five supplied carts loaded correctly. Vigorous cleaning and the credit card trick brought everything back to life.

I've seen an issue with Wolf 3D save games with the Gamedrive. I start a new game and move forward a few rooms and then save my progress into any of the save game slots. Then I restart the game with the "*" and "#" keys. Now if I select any of the save games in the menu it just starts at the very beginning of the game every time. I deleted the e2p file on the SD card and tried the whole procedure again but got the same behaviour. I also cleared the "cartridge" memory from the menu screen with "*, option + #" but the problem remains. Any ideas?

Hi - as the title suggests, is there an available utility that can test the memory of the Jaguar, in a similar fashion to Memtest86+ as found in the PC world, moving inversions, walk test etc.?

Good one . One of the first things I did was to reset the savedata on the cart. It made no difference. I can live with loading Doom as a headerless ROM but I would also like to know how come this isn't happening to more people.

Update: OK so I got delivery of the Gamedrive today and the first thing I tried was to load a Doom ROM from the SD card. I checked it had the correct CRC = 5e2cdbc0 and let it rip in demo mode. After about 3 minutes it crashed in exactly the same way as the cart before. Now here is the interesting part - I have two ROM collections and I noticed that the second Doom ROM was a different size than the first, it was smaller - so basically a.bin with no header. When i loaded this second ROM from the Gamedrive menu as a "Headerless ROM" the demo loop ran without crashing for three hours. After this I removed the header from the first ROM and did a binary compare - the ROMs were now identical. To prove a point, I ran the first ROM (which crashed earlier) as a headerless ROM, and I could not get that one to crash subsequently. So, I can see three possibilities: 1) there is something odd in the Doom code which causes the crash in its default memory location that doesn't happen when the code is loaded into $802000, where the GD loads headerless ROMs. 2) I have faulty RAM and the alternate location where the headerless ROM is loaded does not involve the faulty chip(s). If the RAM is faulty, Doom is the only game that exposes it. Tempest, AvP, Wolf 3D and everything else runs fine as a standard ROM. 3) something else... I'd be interested in any opinions from developers who understand the hardware and ROM addressing that might shed some light on this. I understand the header in encrypted but it would be a neat exercise to load the Doom ROM into several different memory location to see what happens.