Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Zerosquare

  1. 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.
  2. 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
  3. 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.
  4. 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.
  5. 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.
  6. I've been using a switched-mode power supply on my Jaguar for years and never had any problem. 200 mV of ripple seems reasonable, considering the Jaguar include its own regulated power supply. Really cheap and nasty power supplies may still cause issues, but the one mentioned above doesn't seem to be in this category : it's not cheap, and don't believe a major distributor like Digikey would sell junk. So it's most probably fine.
  7. The BJL ROM isn't very composite-friendly in the first place: it uses bright red and blue, which are fuzzy on composite, and the "waiting for upload" banner is especially hard to read. I assume @42bs developed it using a RGB monitor or TV.
  8. I don't recommend doing that. If you could get away with using a single 1.2 A power supply for both, Atari definitely would have, knowing how they liked to save money.
  9. @42bs: can you tell us what are the differences between the 1999 loader and the 2005 one? @cubanismo mentioned the new "-d" option; is there anything else?
  10. 😛 I finally dug out the oscilloscope and measured the signals. Hsync is a 3V high, 0V low signal (so it's valid TTL indeed) : Composite sync is a 5V high, 0V low signal: So... it should work fine with the 78HCT86. I don't know why your monitor doesn't like it, and I don't have a similar one so I can't test it here. Sorry. Regarding the "CGA" converters, I don't know why they're advertised like that. CGA was a digital RGB video standard which supported only 16 colors ; those converters are mostly used with analog RGB sources. There were some non-CGA analog monitors with the same connector (Atari and Commodore computers, among others, used them in the 1980s), so maybe that's the source of the confusion.
  11. You've been playing Supercross 3D again, haven't you?
  12. A cheaper way is to use a single 2.5 A (or more) power supply and add an Y splitter, like this:
  13. You don't like playing Pac Man?
  14. It's Cinepak we're talking about. Don't get your hopes up too much
  15. @cubanismo: you're right, I never noticed that the HSync signal is only 3V peak-to-peak, not TTL-level like the VSYNC/CSYNC one. Atari's fondness for weird hardware quirks strikes again... In theory it could be a problem, in practice I'm not sure. I'd have to do a simulation and/or get out the oscilloscope to find out for sure. I'll try to do that later. The 100 nF capacitor is not included in the package, and should indeed be in parallel with the power supply, physically close to the integrated circuit.
  16. The one I have is this: Behind Jaggi Lines v1.06.0.bin The date is January 24, 1999. It includes the games. I'm surprised by the 2005 version mention on Matthias Domin's page. I don't recall ever seeing it, and to my knowledge @42bs didn't seem to be still active on the Jag scene back then.
  17. These are the area of the board where signals are located. Top middle for most of the signals, bottom left for the audio ground one. Top side -- the location of the colored dots match where you need to solder the wires.
  18. Hear that, CJ? "Downfall" is not a clear enough name. And the gameplay is way too complex to be remembered.
  19. You can extract the MP3 files from the ISO using 7-zip: https://www.7-zip.org/ And convert those MP3 files into WAV files using Audacity: http://www.stenographsolutions.com/solution/index.php?View=entry&EntryID=130 (keep the project rate at 44,100 Hz to maintain quality)
  20. They're 320 kbps MP3 files, so the difference in quality should be insignificant. You can easily convert them back to uncompressed audio if you like
  21. Speaking of low expectations, remind us: what have you ever released on the Jag?
  22. Yes, the hardware supports Z buffering and Gouraud shading... as long as you painfully feed it one scanline at a time. Because it can't even draw a single triangle by itself. You don't get any geometry support, either. And HLL is not an option because there is no standard 3D API. So, you want to play a Jaguar 3D game in 1920x1080? Disassemble the code, understand how its 3D engine works, trap the calls and forward them to the emulator's 3D functions (which you'll have to write, obviously). Then do it all again for the next game. And so on. Piece of cake, really.
  23. I don't think a sync extractor would be useful here, since the sync signals are already available on the video connector. You could try extracting the missing VSYNC signal using 74HCT86 XOR gates: There's some power available from pin 11A on the video connector, but it's unregulated 9 V, so you'll also need a 5 V regulator to power the chip.
  • Create New...