Chilly Willy

You have separate RGB, composite, and luma/chroma on the AV port. http://www.gamesx.com/avpinouts/jagav.htm

I originally used a Percom DD floppy. The Percom can control a second floppy drive, so I put a 3.5" drive in the Percom for the second drive. This was how I originally transferred stuff from Atari to PC - I'd copy it to 3.5" then read that on the PC (had to write my own PC dump program since the sector sizes were not what the PC BIOS expects). Now I use an SIO2SD, and can't be happier. Everything should use SD cards!

The graphics of Firestone look very familiar. Wait a second.... You noticed that too... for someone who made a huge stink over people "stealing" his precious IP, he seems to have no qualms about his own "borrowing" from other games.

It's a bug in the forum. Others have reported this as well. Thanks. I thought as much, but it's good to have confirmation. I wonder what will happen when someone eventually replies to it - it would be hilarious to have a thread with 1 or more replies, but 0 views.

Just got my BJL adapter in the mail! Looks nice... very well done. Now I just need a BJL cart/game.

I was able to view it just fine. Now as for understanding it.. still over my head! Very odd - it still says 0 views... it's the only thread I've seen like that. Maybe it's a bug in the board code related to the fact that I made the thread.

Uh - I posted this thread some time ago, yet it still says there's not been a single view of it. Can other people see this thread?

Is that really true? I always thought that expressions like "No tengo a nadie'" were erroneous, because of the double negatives. I don't know how much Spanish has to do with double negatives appearing in English, but he is right in that double negatives in Spanish are considered grammatically correct. I remember one of my high school Spanish teachers wishing English wasn't so anal about that. In Spanish they figure the more negatives you're throwing into a sentence, the more you are emphasizing the negativity. That's how we were taught it in my Spanish class. My teacher had just moved where we were from Mexico City, so you would think she'd know the difference. She was also always pointing out the differences between "common" Spanish and Castilian Spanish, which is what most US Spanish books cover.

Only in math or English. In Spanish, more negatives implies more emphasis. That's where the double-negative usage in the US arises from - the influence of Spanish from the large hispanic populations.

Yeah, I got an extra 32X and a bunch of 32X carts for next to nothing from VGLQ. They were awesome.

Something like this: http://krikzz.com/link-unit.html I've got two of those for the Genesis, but you could see where something similar could be done almost exactly the same way for the Jaguar.

No, but interested, but not at the prices I've seen lately. If I catch one on sale, I'll snap it up.

Been there, done that, uploaded the results Wow - very cool, man. I certainly wouldn't have had the patience to do that. I'd take the EASY way out and hack the emu... like I did.

Hence the winky. I was doing a little Futurama there. If someone stumbles across a file without a header (and they're all over the net), are they going to a) do a little research into why it doesn't work and correct the problem by adding a header or altering the emu, or will they b) whine and bitch and moan and tell their friends that VJ sucks because it can't load that one single file? Three guesses!

Building a Genesis/32X toolchain 1 - Go here and download the following: gcc-4.6.2.tar.bz2 Decompress it to wherever you keep your projects; you should end up with a folder called gcc-4.6.2. 2.1 - Go here and download mpfr-2.4.2.tar.bz2. 2.2 - Go here and download mpc-0.9.tar.gz. 2.3 - Go here and download gmp-5.0.4.tar.bz2. Decompress them all in the same folder. You should have three folders called mpfr-2.4.2, mpc-0.9, and gmp-5.0.4. Rename them to get rid of the version numbers, leaving you with mpfr, mpc, and gmp. Copy them into the gcc-4.6.2 folder. 3 - Go here and download binutils-2.22.tar.bz2. Decompress it in the same folder as the gcc folder so that you have two folders - gcc-4.6.2 and binutils-2.22. 4 - Go here and download newlib-1.20.0.tar.gz. Decompress it in the same folder as gcc and binutils, leaving you with the folders - gcc-4.6.2, binutils-2.22, and newlib-1.20.0. 5 - Get this archive and decompress it to the same place as the previous directories. You should have two more directories, bin and ldscripts, in addition to the file, makefile-sega. 6 - If you wish to leave the makefile with the default path of /opt/toolchains/sega, make sure you have permission to write to /opt or the toolchain will fail to install to the path. Since there's nothing critical in /opt, it's easiest just to do "sudo chmod 777 -R /opt" which allows anyone to do anything they want in /opt. 7 - Run "make -f makefile-sega" - depending on the speed of your computer, in an hour or two you should have two toolchains in /opt/toolchains/sega: m68k-elf and sh-elf. Copy the ldscripts and bin directories to /opt/toolchains/sega. You now have the latest gcc, binutils, and newlib for both the 68000 and the SH2. Both have compilers for C, C++, Objective-C, and Objective-C++. The bin directory has a few common tools one might use for compiling Z80 code for the MD. Copy whatever other tools you use into it, like sixpack or bin2c. Note: The size of the built toolchain can be reduced by stripping the debug symbols from the executables in the bin directories, and by deleting the libraries meant for CPUs other than the 68000 and SH2. For example, you don't need the libraries for the 68020 or 68040 or SH3 or SH4, etc. Here is an archive with example code - it includes Tic-Tac-Toe in both C and C++ for both the MD and the 32X. You should be able to compile them with the toolchain you just built. They should run on an emulator like Kega Fusion or Gens/GS, or on a real MD/32X with a flash cart. Here are a few archives of things I've built for the 32X using the toolchain. They should all build and run fine using this toolchain. 32xrick-20120212.7z Wolf32X-20120212.7z TremorTest-20120212.7z yeti3d-20120212.7z Here is an archive with three libraries. You will need them for the Tremor example. Build them BEFORE trying to build the Tremor test. Be sure to run "make install" to install the libraries into the toolchain so it can find them. Note: You don't need to set any environment variables for building as long as you use the default build path for the toolchain (/opt/toolchains/sega). All the examples and games have a binary image so people can check them out without needing to build them.

That's mostly a non-issue, as 99% of BIN files use $4000 for both the load and start addresses. In fact, I don't think I've ever seen a BIN file with different addresses (programs that don't load at $4000 are usually supplied in a format that includes a header). Just preload the dialog box fields with $4000, include a disclaimer about how the user should check the addresses and BIN is an horrible format and all that, and be done with it. The users will just click OK, it'll work, and they'll be satisfied. In the rare case where it doesn't, you'll have the opportunity to tell them to RTFM That's why my little patch just loaded the rom to 0x4000 and set that as the run address. It's so simple and should take care of those 99% you mention. Problem solved once and for all! I don't think it'll ever get over Macho Grande.

Fallacy!!! Anyway, I run Gentoo amd64 and I didn't have to modify the link order. So even the ability to test a platforms build doesn't guarantee all flavors will work properly. You can't beat people willing to figure out why something isn't working properly and report it to you. I'm always thankful for a bug report but a bug report that comes with a fix is the taste. Hmm - sounds like different archs of gcc are less agressive about pruning unused code when linking. That's what that is with the link order - only those functions that are used are actually linked into the final object, but that relies on the linker being able to figure out what is dead code and what isn't. Just for a guess, I'd say the x86 branch (what I'm using) is better at that than the AMD64 branch (what you use). I ran into the dead-code issue with C++ on the MD - the linker was COMPLETELY incapable of telling what was dead code due to the special MD header for the rom, so it left EVERYTHING in. That made my 6KB example almost 500KB in size.

Good - that would have been the next thing to check. When reporting bugs, always check to see if they have a) already been reported, and even more importantly, b) already been fixed! That is true to some extent, but you have to remember that complete idiots will be using the program (any program, really) and the author really should take efforts (ESPECIALLY simple ones) to allow for a certain level of idiocy proofing on the program. Look for the most common failures and provide a simple workaround. That will make those idiots go from ranting about your lack of "user friendliness" to ranting about how great the program is to automatically deal withwhatever it is that is their current pet peave. I realize you can't please all the people all the time, but that doesn't mean you shouldn't bother pleasing anybody anytime.

Some of the time, the primary cartaker of a project is working with a different platform. He updates all the different platform makefiles, but cannot test them. So he relies on folks like me to build those other platforms and let him know when the makefiles need a little adjusting.

Even if the source for JagWolf was available, I wouldn't work from it. It would be better to use a better newer base, like Wolf4SDL, then put the work into improving the graphics.

If you go to the Virtual Jaguar homepage, you'll find the only version they have for linux is source. Well, that's not too bad - you only need to make one correction to get it to actually compile - In virtualjaguar.pro, change line 19 from LIBS += -lz -Lobj -ljaguarcore -lm68k to LIBS += -Lobj -ljaguarcore -lm68k -lz It's a dependency thing - libjaguarcore requires libz, so the -lz has to come AFTER it in the link order or it doesn't link. After you have that changed and it compiles, now you want to make one more change for an extra feature. Go to file.cpp line 184 where you find // We can assume we have JST_NONE at this point. :-P Add this code right after it and delete the "return false;" line. // CW - I'm going to assume this is a BJL file that loads/runs at 0x4000 WriteLog("FILE: Setting up homebrew (BJL)... Run address: %08X, length: %08X\n", 0x4000, jaguarROMSize); memcpy(jagMemSpace + 0x4000, buffer, jaguarROMSize); delete[] buffer; jaguarRunAddress = 0x4000; return true; And now it loads BJL files that are missing the header. Just give them a file extension of .bin or .bjl and they should load and run fine. The "Gorf 2000 (PD).jag" file is an example of this. To compile, you need gcc, g++, the SDL libs and developer files, and the qt4 libs and developer files. Just use the package manager to select and install them from the repo.

Yeah, but I'd rather just hang loose for a bit and see if I can get by without it. I don't want to fool around inside the Jag if I don't have to.

I know some folks don't care for Myst, but I was always a big fan. This looks really good!

I noticed that on the Jaguar version... it's like Doom on most other consoles of the time - the baddies always facing you. I would guess that means they based it on the Mac version of Wolf3D (forward facing baddies are a prime way of telling which W3D ports derive from the Mac branch - the Mac branch seems to be the main port base for Wolf3D much like the Jaguar branch of Doom is the base for most other console ports of Doom). I based the 32X version on the PSP version, which I also worked on, which was in turn based on Wolf4SDL v1.5. I was thinking to myself - I'm currently updating the 32X version of Wolf3D to the Wolf4SDL v1.7, which has lots of great stuff in it; it would also make a really good base for a Jagaur version. So it's on the Jaguar TODO list.

Did you order the adapter or the kit? Or both? Just the adapter. I'll either get something like Protector SE with built in BJL support, the cheap flash cart zerosquare designed (which also has built in BJL support), or I'll make my own flash cart with BJL support. In any case, I don't want to hack my Jaguar, and there are enough choices in the offing to avoid needing to do so.