Jump to content

cubanismo

+AtariAge Subscriber
  • Posts

    1,268
  • Joined

  • Last visited

Everything posted by cubanismo

  1. Isn't that how many guys they had doing the programming for the entire game in many cases (E.g., Checkered Flag)? I'm not saying those games were all great, but rather pointing out that one programmer is indeed a lot for that era, especially given it was presumably "just" a port.
  2. Yeah, I tried many iterations of unplugging it and plugging it back in. Didn't have any luck there. Sometimes it even made it worse, throwing it completely out of sync again (Looked like the 90's scrambled porn channels, mixed up colors, wavy pattern, etc.). However, all is not lost. I switched to an official Atari SVHS cable, that worked fine (And of course looked extra crispy. Why don't I always use this cable? Because I have too many damn consoles, and not enough SVHS ports+switches in my current setup, that's why). Then I switched back to the composite cable I was using (A Reid circuits one I got off eBay that has been very reliable until now), and it too is working fine again. Go figure. Scary, but I'm good for now. I'll be back if it goes wonky again.
  3. I have a Jaguar that has been working fine for a few years now, but suddenly lost sync and went all warbly while watching a Cinepak disc, and now, after a power cycle, has a streaky picture, for lack of a better description. It's as if all the pixels bleed white to the right, such that everything has a white drop shadow. I've attached some pictures below. Anyone have any idea what could cause this? Ideas to help diagnose? I have a multimeter and oscilloscope if needed. I'm using a composite A/V cable.
  4. Agreed, and note my suggestion to unpin the more or less dead homebrew thread currently pinned at the same time.
  5. "I even heard there's no respawn points IRL."
  6. !!! =-O !!! I can't even quote the rest. This is just blasphemy. I hope you get drafted as a space marine and deployed to Deimos 😛
  7. I have no idea what you did, but the easiest way to get the Skunk working on Windows these days is to just use the signed installer packages I release: https://github.com/cubanismo/skunk_jcp/releases/latest You can thank those who purchased the collector's edition Skunkboards for funding the extortionately priced kernel driver signing keys, but they'll work on all Skunkboard revisions. If you already have some Zadig drivers installed, you may want to uninstall the device in device manager, unplug the Skunkboard, run the above installer, then plug the Skunkboard back in and power on the jag to complete the install process cleanly. I've not messed with SkunkGUI, but my understanding is it's just a wrapper around the command line JCP tool. Older versions of JCP should work fine with the drivers included in these packages, so I assume the GUI will work fine regardless of whether it uses the newer JCP tool or some older builtin/bundled one. If not, let me know.
  8. *Sets alarm for 11 years 364 days, and ~16 hours so I can post 'Put me on the list' before @Saturn
  9. It looks much better on CRT. Use a good filter over it on modern monitors for a good experience.
  10. I think significant modifications were made (E.g., it appears to have output MADMAC-syntax assembly rather than GNU format, as the "as" included is a symlink to mac), and I don't know exactly how it was configured.
  11. I was a little overly optimistic here. The gcc front-end "driver" and the "agpu" JRISC compiler backend (cc1) and preprocessor (cpp) work fine with the a.out loader, but the m68k backend stuff (cc1, cpp) do not. They want at least some minimal dynamic linking support unfortunately. Still, I'll get this integrated with my SDK shortly for the GPU C compiler support. Getting the m68k binaries to play nice would probably take considerably more work, so I don't have any plans to try to adapt that. It can still be run on old kernels in VMs and whatnot of course, so it's still nice to have around.
  12. Awesome. I'll get these integrated with my SDK. They are a.out binaries, but they run fine with the a.out userspace loader my SDK uses to load MADMAC and ALN. This will of course make it much easier for SDK users to experiment with the GCC-for-GPU compiler 😁 Perhaps of more practical application, since this gcc seems to support both 68k and GPU targets, users of my SDK should now be able to switch back and forth between building their projects entirely with Atari's original GCC, ALN, and MADMAC tool chain, or my newer 68k GCC 3.x build and RMAC/RLN, all on modern Linux kernels/distros thanks to the a.out loader wrappers, and all just by changing a few variables in their Makefiles if they're set up to use the usual $(CC) and similar variables in their rules. The Makefiles for all the sample code in the SDK can all be toggled at once, for example, just by editing jagdefs.mk. This will make it really easy to perform comparisons and characterize bugs or behavior differences between the tool chains!
  13. It was recently pointed out to me that this file has been in the public before. I'm trying to find someone who stashed away a copy of it. References to it still exist: https://www.yaronet.com/topics/72-54823-sdl-pour-jaguar-utilite-ou-pas Which points to the dead link http://the.protos.free.fr/jaguar/gcc263.tar.gz near the bottom of the page. No hits on internet archive wayback machine for that URL. Further up in that thread, you find a working link to the equivalent DOS build http://fadest.free.fr/gcc263pc.zip which does still work, and I believe is the same DOS build of the gcc-for-GPU compiler already included in my jaguar SDK package. http://jagware.org/jag_uploads/dev/cts_jagdev/index.html Which points to http://jagware.org/jag_uploads/dev/cts_jagdev/gcc263_tar.gz, which is also a broken link, and again no hits on the wayback machine. Anyone have this lying around and cares to share?
  14. I play a lot of WTR, and I've played a lot of Virtua racing. On hardware, Virtua Racing wins. On BigPEmu with uncapped blitter, WTR holds its own as far as gameplay, but subjectively the artwork is still probably better on Virtua Racing. It's why I wish Checkered Flag wasn't horrible, because IMHO, it actually looks better than Virtua Racing in static screenshots.
  15. It had the best home port of Virtua Racing for a long time too, one of my personal favorites from Sega, given the Saturn port was b0rk, for well documented reasons. I still never knew anyone who had one (or a Jaguar for that matter) when they were actually on the market though. People were either happy with their SNES, existing Genesis, or in one case Sega CD, and then just moved on to the "real" next gen stuff, or got girlfriends.
  16. Very cool! I'll test it out on some real input files later, and I'll definitely be reading through your blog! Converting mac (MADMAC) would be a lot more useful in the long run. ALN is a pretty simple program and is largely interchangeable with RLN these days, but MADMAC is still worth using, if only as a comparison tool to help find and characterize bugs and behavior differences between it and RMAC (modern replacement).
  17. I've also pushed a small update to point the SDK rmac and rln submodules at their gitlab mirrors since the official repos have been down for many days at this point.
  18. Agreed, thanks for all the work, it's much appreciated. Just bringing issues to your attention in case you guys weren't aware of them. For advanced users like myself, yes, I know how to edit scripts and do a little git heroics to drop in the Linux binaries when setting up the SDK environment, but for average users, the source repositories being down breaks things right at the initial "git clone" step of SDK setup, because rmac and rln are included as submodules that get recursively cloned if you're following the instructions in the README.md.
×
×
  • Create New...