Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Zerosquare

  1. Yeah, I was gonna recommend that, but compatibility is indeed a problem.
  2. I see you're using lead-free solder. Leaded solder is easier to work with, and melts at a lower temperature. (But don't mix lead-free and leaded solder, or you'll end up with a weird alloy that's not good). Also, what kind of tip do you use for drag soldering?
  3. All official cartridge games which allow saving scores or progress (Tempest 2000, Rayman, etc.) do use that chip. Same thing for homebrew games, with a few exceptions. Why?
  4. What's the point of asking for feedback if you've already made it?
  5. The Jaguar won't turn on at all without a game inserted, and the no-load voltage of the official power supply is known to be significantly higher than 9V. Nothing to worry about
  6. The interlace code generates proper 480i signals. Apart from it (and the homebrews that use it), I'm not aware of any software that uses anything else than 240p. I also did manage to get VGA-compatible 480p (at 31 kHz) out of the Jaguar a few years ago. But it needed a bit of extra electronics, because I couldn't figure out any way to disable the equalization/serration pulses completely from software, and the VGA monitor I used for testing wouldn't display anything if there were any extra pulse. Also, it required software changes and twice as much bus bandwidth as regular 240p, so it was more like a proof-of-concept than anything else.
  7. Yes, those are called equalization and serration pulses, and they are a feature of standard TV signals ; standard VGA signals don't have them. If your monitor doesn't support those, you indeed need a more complex circuit to suppress them. It looks like the LM1881 sync extractor could fit the bill: https://www.ti.com/lit/ds/symlink/lm1881.pdf
  8. ADPCM isn't samplerate-sensitive (and even if it was, the ~0.2% difference in samplerate would be too small to matter, anyways).
  9. If you're using the JagCD's audio clock (SMODE bit 0 = 0), it's exactly 22050 Hz. If you're using the Jaguar's audio clock (SMODE bit 0 = 1), the closest rate is about 21869 Hz (with SCLK=18): 26590906 / (2 * 16 * 2 * (18+1)) Hz for NTSC consoles, and 26593900 / (2 * 16 * 2 * (18+1)) Hz for PAL ones.
  10. mulaw (µ-Law, actually) isn't an ADPCM variant; it is a simple non-linear LUT-based coding scheme. I can't find the discussion right now (it was a long time ago!), but I think Orion's ADPCM code was based on the one described in this document: http://ww1.microchip.com/downloads/en/AppNotes/00643c.pdf
  11. I agree with @Stephen Moss If you want to check whether replacing REG1 will fix sound, unsolder REG1, then connect pin 1 to VCC (not pin 1 of the ADC chip, as it isn't connected to VCC). I wouldn't recommend using it as a permanent "fix" either. While it won't damage your console, the signal/noise ration of the audio output will be worse than normal.
  12. Rotary basics The way the rotary works is pretty simple: it replaces the left and right directions of the D-pad. Instead of encoding the left/right movement directly like a normal pad, it has four different states: left direction on, both directions on, right direction on, and both directions off. Each time you rotate the rotary by one step, it goes from one state to either the next one or the previous one, depending on the rotation direction: (clockwise and counter-clockwise may be swapped on this diagram, I'd have to double-check) Another thing that's different from the standard pad is the poll rate: to avoid missing states, the rotary must be read more frequently; once per VBL is not enough. I read the rotary 2000 times per second in my code, but that's because the same code can also handle a mouse; for the rotary itself, you don't need such a high frequency. I don't have a lower bound, but maybe @LinkoVitch can tell us what frequency he's using in U235 SE (I believe it's lower). Supporting the rotary in practice You need one temporary variable (JoyState) and two permanent ones (PrevJoyState, RotationCounter). RotationCounter is signed and should be initialized to zero. Periodically: 1) Select joypad row 0 (Write $817E to JOYSTICK). 2) Read from JOYSTICK and store the result in JoyState. 3) Mask out everything except the Left and Right bits. 4) Compare JoyState to PrevJoyState: • If they are identical, the rotary didn't move: there's nothing to do. • If JoyState is one state beyond PrevJoyState, the rotary moved one step in the forward direction: add 1 to RotationCounter. • If JoyState is one state behind PrevJoyState, the rotary moved one step in the backwards direction: subtract 1 from RotationCounter. • If none of those conditions are true, then you missed at least one step (this shouldn't happen if the frequency is high enough). Don't do anything. 5) Copy JoyState to PrevJoyState. Once per frame: 1) To avoid race conditions, pause the periodic reading (e.g. if you're using a timer interrupt, disable it). 2) Copy RotationCounter to a temporary variable, then set it to zero. 3) Use the usual code to read the states of buttons from the pad. Don't forget to mask out the left and right directions. 4) Restart the periodic reading. Recommended: • Allow the player to customize the sensitivity of the rotary, to account for different number of steps/rotation and personal preference. You can do that by using fixed-point arithmetic and multiplying RotationCounter by a constant (bigger constant -> more sensitivity). • Auto-detect the rotary by detecting the "left + right directions" condition (it will happen naturally as soon as the player rotates the rotary a bit). To make sure it's not a glitch, only enable rotary mode if the condition persists for a few frames. Optimizations • You can skip step 1 of the rotary reading if you leave joypad row 0 selected all the time. (Write $817E to JOYSTICK after step 3 of the "once per frame" code.) • Step 4 can be done efficiently with a few binary operations (see "Code" below). • You don't actually need to read the rotary at a precise frequency ; as long as the delay between two consecutive reads is always shorter than the limit, it will work fine. • Instead of using a timer interrupt, you can use the DSP audio interrupt ; this avoids the risk of a rotary read delaying the audio processing and introducing audio glitches: 1) when you get a DSP audio interrupt, process the audio first. 2) increment a counter. If the counter is below (audio_samplerate / rotary_read_frequency), return from the interrupt. 3) reset the counter to zero. 4) set a flag to signal that your main DSP code should read the rotary. You can also try reading the rotary directly from the interrupt, but it may not be fast enough, depending on the audio samplerate you're using. 5) return from the interrupt. Note that you can't disable the audio interrupt to pause the rotary reading code, as this would cause audio glitches. Use a global disable variable instead. • If you can, use the DSP to read the buttons as well as the rotary. It is faster than the 68000, so there is less risk of missing rotary steps. Code Unfortunately, the code I use was developed to handle a mouse, and rotary support was hacked later. This means the code is needlessly complicated if you only need the rotary, and harder to integrate into something else. Also, I lost my Jaguar's video cable, so I can't test the refactored code until I find it In the meantime, here's some untested but should-be-working DSP code for the periodic part (this assumes row 0 is already selected): movei #JOYSTICK, Tmp loadw (Tmp), JoyState move PrevJoyState, Tmp shrq #1, PrevJoyState shlq #1, Tmp xor JoyState, PrevJoyState xor JoyState, Tmp shlq #(31 - 10), PrevJoyState shlq #(31 - 11), Tmp shrq #31, PrevJoyState shrq #31, Tmp sub PrevJoyState, RotationCounter add Tmp, RotationCounter move JoyState, PrevJoyState Don't hesitate to ask if you have questions or if something doesn't make sense
  13. All rotaries don't have the same number of steps per revolution. But in practice it doesn't matter, because you don't actually need 1:1 mapping: since you're not looking at the rotary when playing, the position of the knob isn't important. If you're not convinced, try playing Tempest 2000 with a rotary In fact, it's best to let the player adjust the sensitivity (angle per step) of the controls.
  14. Can you tell us more? It would be sad not to have rotary support in a game that's so suited to it.
  15. No. The only thing we got from them was a very terse press release saying basically: - developers can release Jaguar software without Hasbro's approval (great - they had been doing that for several years already anyways) - they shouldn't use the Atari trademark (well, duh) - Hasbro has zero interest in the Jaguar (duh again) Nothing else. The BS guys made a big deal out of this, but in practice it didn't make any difference.
  16. TL;DR version: want to do good? Don't waste your money on Battlesphere and all the BS that's associated with it. Buy a game from your favorite homebrew developer instead, and donate the rest to a charity of your chosing.
  17. Dunno if it can be any use to you, but here's a (very old) project I made: https://www.jagware.org/index.php?/topic/632-mindebug-the-basis-for-a-jaguar-debugger/ It uses an older protocol than the one I described in the other topic. It's slow, but it seemed to be reliable.
  18. I don't have any demo of the coprocessor part, but there's this old video showing running various homebrews, displaying high-resolution pictures (unfortunately, the video compression spoils the result), and video streaming: http://zerosquare.free.fr/demo_jagcf.avi
  19. I believe CJ has implemented ADPCM audio decompression in his Bad Apple demo ; it could be useful to store more music in the cart. It is also possible to create bank-switching cartridges to go beyond the 6 MB barrier ; since the original game is CD-based, it doesn't need fast access to ROM, and so the cartridge's data bus could be reduced to 8 bits to lower costs.
  20. I'd need to extract the communication code from the rest and clean it up a bit, but here's how it works: On the PC (or microcontroller, etc.) side, set the parallel port (D0~D7) to output mode, all outputs low (data=0x00). Then: - To send a "0" bit, toggle D6 ; to send a "1" bit, toggle D7. - Wait until BUSY toggles. - Repeat for the next bit to send, etc. On the Jaguar side, set the joypad port to output mode, all outputs low (JOYSTICK=$8000). Then: - Wait until either bit 14 ("0" bit received) or bit 15 ("1" bit received) toggles. - Toggle the state of bit 7 of JOYSTICK. - Repeat for the next bit to receive, etc. That's all there is to it. Note the complete lack of timings in the definition of the protocol, and . This means that timeouts and race conditions can never occur: both sides are always in lockstep, and if one side is slower, the other will simply wait for it to be ready. In fact, the communication will automatically run at the fastest speed that's possible Also, since there's only a single signal changing state at the same time, propagation delays are irrelevant: even if different pins have different delays, it will not cause problems. Crosstalk between signals can also be detected and rejected: if more than one signal appears to have toggled, read the inputs again until it is no longer the case. Once that works, you can speed things up by sending two bits at the same time: toggle D4 for 00, D5 for 01, D6 for 10, and D7 for 11. On the Jaguar side, simply XOR the current and previous state of the inputs, shift the result 12 bit right, and use it as an index into a look-up table to get the value of the bits (or an "invalid" value if more than one signal toggled). Basically, the Skunkboard happened. After it was released and widely adopted by the community, interest for BJL pretty much waned, and so did the purpose of the Catnip: using the Skunkboard's USB connection was faster and most reliable. The Skunkboard also provided a way to play cartridge games, which was one of the major features of the JagCF. Even if both projects had different goals, there was significant overlap between the two (and even more overlap with SainT's SD cart). The Catnip itself has been completed: I still use it with my Jaguar, and it can also be used to program Jagtopus carts. There's just little point in releasing it now.
  21. BJL is definitely finicky about propagation delays ; I remember tweaking the timings to get things to work reliably. And even with dedicated hardware and precise timings, large transfers still fail from time to time. One thing you can do to improve reliability is to first upload and run a small and more resilient custom loader using BJL, then use that custom loader to actually transfer the data. That's what I use to program the Jagtopus cartridge, and it works very reliably. Let me know if you're interested.
  • Create New...