Jump to content

Zerosquare

Members
  • Content Count

    3,119
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by Zerosquare

  1. This is not a bug -- this behavior is documented: Workaround: always use explicit parentheses.
  2. I wonder if there would be a need for a tool which would copy files to a SD card while making sure they're not fragmented. (The "lazy" way would be generating a fresh FAT32 file system image and writing it to the card.)
  3. Zerosquare

    Jim Power

    I've never played the original game, but it looks like there's also something wrong with the parallax scrolling. Objects on a slowly-scrolling plane shouldn't appear in front of objects in a faster-scrolling plane.
  4. Are you sure the monitor is actually set up for RGB mode, not YPbPr mode? Also check that your cables are connected properly.
  5. I'm not a fan of DRM, but this situation is a pretty rare occurrence. And I think most homebrew developers would send you a "replacement" download for free if you showed them some proof your JagGD got stolen or damaged.
  6. ...while Reboot is working on SoulStar.
  7. I don't think so. This has not happened on other consoles.
  8. That doesn't look like a Jaguar...
  9. The boot ROM is 8-bit wide with 10 cycles access time. The Skunboard Flash memory is 16-bit wide with 5 cycles access time. The settings in MEMCON1 affect both, so if you want to read the boot ROM, you need to change the value of this register (from code running in RAM, of course, otherwise it'll crash) and restore it after you're done. Keep in mind that accessing the boot ROM will make your game incompatible with the BJL ROM.
  10. It's an old classic, but rereading it is always fun and shows how dysfunctional Atari was back then. There were also interesting stories from the developers side: https://atariage.com/forums/topic/221243-minter-txk-t2k-and-stuff/?do=findComment&comment=3090113
  11. I'll have to check the actual source code -- that thing is more than a decade old at that point... But this is pretty strange. If the BJL uploader works fine on the same machine, I don't see any obvious reason why the dumping code wouldn't.
  12. You don't need fancy cable. I made several BJL cables by reusing 15-pin extension cables - the cheap kind with a single piece of aluminum foil over individual thin wires, not the quality VGA ones with several mini-coaxial cables inside - and it works fine. Check that: - you don't have a cold solder joint somewhere - the cable isn't too long ; I don't recommend anything longer than 2 meters (~6 feet). If in doubt, try a shorter cable. - you don't have anything else running which could screw up the timings (BJL is quite picky with that). - you use proper 3.3 V ↔ 5 V voltage translators (i.e. a dedicated chip, not a resistor/diode based hack). Good luck (even if I don't understand why you bother with BJL while you have tons of Skunkboards )
  13. You can also open the jcp_installer-02.06.00.exe file using 7-Zip, and extract the jcp.exe file manually.
  14. #1 is possibly a VJ bug, but margins and picture centering varies from TV to TV (especially on CRT ones), so relying on it is not a good idea anyways. #2 is a consequence of VJ not emulating stuff down to the cycle-level (which would make it even more complex, and slower). So if you want your game to run well in emulation, don't rely on "implicit" timing such as how fast the CPU/GPU/DSP are. Use explicit timing sources such as the VBL and timer interrupts instead, and don't depend on perfect timing accuracy. Even on real hardware, this advice is usually good, too. #3 sounds like an actual bug or limitation in VJ. Try reporting it to @Shamus.
  15. Be careful with that. It involves writing to the EEPROM, which causes it to wear down a little bit, and can also cause data corruption if the Jaguar is turned off right at this moment (unlikely) or if EEPROM contacts on the cartridge slot are a bit dirty (more likely). If you only run the autodetection code when explicitly saving/restoring the EEPROM contents, it's probably fine. But it's not something I'd recommend doing every time you run JCP, or at startup in your game code. (I thought about providing EEPROM size autodetection code for the Jagtopus board, but decided against it for that reason.)
  16. Resistors are 0805 size. The ferrite beads are 1206 size. The original part number is Murata BLM31A02, but it appears not to be manufactured anymore. You can use a Fair-Rite 2512067007Y3 instead.
  17. Look under your mouse, there may be a switch to choose between Atari ST mode and Amiga mode: To clean it : https://www.wikihow.com/Clean-a-Mouse-Ball
  18. That. And don't rely on CPU speed for timing ; even on real hardware, it's fragile. Count the VBLs or use a hardware timer instead.
  19. The warning is expected in that case, it's documented in the lines just above your snippet: ; NOTE!!!: This code can run in DRAM only because it contains no JUMP's or ; JR's. It will generate a warning with current versions of MADMAC ; because it doesn't '.ORG'.
  20. Check that you have not forgotten to put a .org statement before your GPU code.
  21. For red, the parts to check are resistor R29 and ferrite L15. If you can, also check that your TV/monitor/converter works correctly with another RGB source.
×
×
  • Create New...