Zerosquare

There's been a topic about this before here. Let's say that opinions about Tempest X3 are mixed

I agree with Selgus, but the amount of work needed (typing and proofreading - which is very important for a technical document) would be positively huge. I'd have suggested using OCR software, but I doubt it would work considering the quality of the scans. And TechRef v8, which covers a lot of useful things, is already text-searchable. I'd advise saving your time and motivation for something more useful

The same files are available on Starcat's website. On dial-up, however... you can cook and eat a nice dinner before it's finished downloading

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. Now I have to read the whole documentation again to see if there are "new" things in it . Many thanks, Tyrant !

True, and it's something I never really thought about. Oh well, one more reason not to use the 68K I'd have to check (I did some testing on this some time ago), but I think you're right, at last for the GPU : I don't think 16-bit accesses work properly, so the 68K would not run. Anyways, if you're going to be limited to 4K or 8K of code, you might as well make that RISC code There's definitely a pitfall there. SCPCD tried it for the JagCF, and he found there's an intermittent bug in some cases ; I think it involves the blitter, and possibly an arbitration problem when several processors try to access the bus at the same time. You'd have to ask him for details. You're aware that child labour is illegal, right ? (j/k, but I would be very interested to know how you could get such cheap prices ) I agree with you ; if I were designing something for mass production, I'd definitely choose a 3.3 V Flash too, as they're cheaper and easier to get hold off. For low-volume, it's less clear cut. I'd be a bit wary of using the Flash chip for save states - think of what would happen if there's a bug in the code ! Call me paranoid, but I'd wire it as read-only and add a cheap, dedicated EEPROM chip

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.

I agree with kskunk on almost everything he said on the hardware aspect, except one thing : you can still find 5V-compatible Flash chips, and they're not overly expensive. A 2 megabytes Flash chip costs a bit less than 10 euros on Farnell (and that's considering only what they have in stock right now, there are some cheaper ones that are currently out of stock). Additionally, IIRC, the exisiting homebrew cartridges use a 32-bit data bus like the original cartridges. which requires two 16-bit memory chips, or four 8-bit ones. You don't have to do it that way : you could reduce the data-width to 16 or even 8 bits, and use a single bigger, cheaper and easier-to-find chip. Of course ROM accesses are going to be slower, but that could be partially compensated by reducing the number of wait cycles. And anyways, it's best to copy everything you can into RAM anyways since ROM is much slower in all cases, so I don't think it would be a real problem for new games if taken into account.

I agree 100%

Yup. Mac never had integrated parallel ports. USB parallel port adapters don't work for BJL, even on a PC. USB PCMCIA card do, but you'd have to find a Mac with such a slot, and between the lack of drivers and virtualization, I seriously doubt it would even work. So using BJL is pretty much impossible. Your best option would be to buy a second-hand Skunkboard, or to wait until the release of the JagCF. (or you could also find an old "junk" PC )

...whose name you can not reveal, of course. As usual.

Something has been bothering me for a long time, and I'd like to make it clear. Everyone keeps talking about "Jaguar developers this" and "Jaguar developers that". There is NO SUCH THING. Despite what some may want you to believe, there is no common opinion shared by every developer, and there is no elected leader which could claim to represent the interests of everyone. Additionally, the fact that some developers prefer no to get involved in the debates doesn't mean they agree with what is said on their behalf. Please remember that posters only represent their own opinion, not the one of Jaguar developers as a whole, regardless of what they may claim. Consequently, if you're disappointed or angry about what they say, discuss it with them ; don't lump everyone together.

Screenshots :

Sorry, I did not read your previous post correctly. You're right. I must have been half-asleep that day... Here's the corrected schematic :

Hehe Yes, it's probably possible to reverse-engineer the communications protocol - it's only simple data like button states after all, so I doubt it's very complicated. I have the needed equipment to reverse-engineer that, but neither a controller nor a Nuon, and they're pretty rare. It would be interesting to know if the communication is bidirectional or not. In the later case, it should be possible to test the controller without needing a Nuon. That's pretty much what I had in mind as well. I prefer to do it with extension cords (they seem to exist, according to Nuon-Dome) ; that way you don't even have to to mess with the original controller. I've been thinking about doing the same thing to add rotary or mouse support to games that only support the standard control scheme. One thing that may not be esay is getting the length of pulses right, so that they're never missed or counted twice. On the Jaguar, you could probably use the row select lines as a means of synchronisation (assuming the game reads the joypad ports once per frame), but most microcontrollers are too slow to keep up - I used a CPLD on my PS1 pad-to-Jaguar adapter for this.

The 74LS03 is four NAND gates with open-collectors outputs, i.e. : output state is 0 -> output is pulled to 0 volt output state is 1 -> output is high-impedance Check the schematic again with that in mind

Regarding building a rotary controller for the Nuon : apparently an analog controller exists, and Tempest 3000 supports it. But I don't know if you're supposed to rotate the analog stick or if it's just the standard left/right control scheme. It seems that both the hardware and Tempest 3000 support a real rotary controller too, but details are missing. Additionally, I was wrong : the Nuon controllers are not USB-based.

Because it is intended for optical encoders, and using just a switch won't work in this case. Mechanical encoders outputs are either open or connected the common pin, just like real push-buttons, so they can be connected directly. Optical encoders outputs are either 0 volts or 5 volts ; they require additional logic to be compatible with the wiring scheme used in the Jag controllers.

The Jaguar power supply specs are : 9 V DC, 1.2 A, center negative. The Sega Genesis/Megadrive 1 (this is important - the Genesis/Megadrive 2 has the opposite polarity, which will fry your Jag !) is reported to be compatible. In any case, double-check what's written on the power supply before plugging it in.

http://www.atariage.com/forums/topic/94279-optical-rotary-controller-project-completed/page__st__25__p__1811573entry1811573 I vaguely recall that the Nuon controllers are supposed to be standard USB controllers, only with a different connector. Doesn't solve the other problems, though.

The red screen means that the cartridge authentication check failed. With an official cartridge or a properly made homebrew one, it almost aways means dirty contacts or bad connections. The Atari logo and the spinning cube appear after the authentication check succeeds. After they disappear, the 68000 starts running code from the cartridge, usually at address $802000.

Looks good !

Future Assassin is right, there are some tunes which are not present in the game. However, those who have the Tempset 2000 soundtrack CD which came with the JagCD know them already, as they are included on this CD. Using the track names from the soundtrack CD, and AFAIK : Tunes used in the game Glide Control (Tune1.mod) 2000 Dub (Tune3.mod) Mind's Eye (Tune4.mod) Constructive Demolition (Tune5.mod) Digital Terror (Tune7.mod) Ultra Yak (Tune12.mod) Title screen music (Tune13.mod) [This one isn't present on the soundtrack CD] Unused tunes Thermal Resolution (Tune2.mod) Tracking Depth (Tune6.mod) Future Tense (Tune8.mod) Ease Yourself (Tune9.mod) T2K (Tune10.mod) Hyper Prism (Tune11.mod)

Once again, great thanks Curt !

Exactly. Isopropyl alcohol is widely used as a contact cleaner in electronics. It isn't corrosive, and evaporates quickly anyways.

Great ! I'm glad that Virtual Jaguar is still being worked on, and I hope one day it'll reach perfection. By the way, do you have any idea where the bottlenecks are in the code ? VJ is pretty accurate, but it seems to consume a lot of CPU time, which makes it barely usable on slower machines. Is there any part of the code which could benefit from optimization by hand ?