Chilly Willy

check into ICE or lz77 like you said. there are ported over versions of it on the jag that are much better (in my opinion) than bpeg or jagpeg Faster, maybe, but certainly not better compression. Lossless compressors can only do maybe 2:1 compression... 3:1 at the very best. Lossy graphics compression is typically 5:1 to 100:1, depending on how much loss in detail you can stand. Putting a game like this on cart will almost certainly require 10:1 or better compression.

Really awesome! You've captured that "Myst" feeling rather well.

If you've ever looked at the source for Doom for the Jaguar, you'll see they compressed much of the data in the wad file. The game has a heap in ram, and when data is needed from the wad file, it checks if it's compressed or not - if it is, enough ram is allocated from the heap to hold the decompressed data, then the data is decompressed from the wad file into the ram. Compressed chunks are indicated by ORing 0x80 with the first character of the name of the chunk in the wad directory. I'm sure many other games do the same. Decompressing data on the fly into ram has LONG been a trick for keeping roms smaller (and thus cheaper) while still giving a large game. Older consoles with weaker CPUs use simple compression with fast decompression times like lz77. The GPU in the Jaguar makes it possible to use heavier compression - Atari made their own version of JPEG call JagPEG... jpeg is extremely slow to decompress on older cpus like the 68000, but the GPU can handle it. There's a version called BPEG that's available for homebrew as part of the public Jaguar devkit.

Okay! Double-posting because the forum won't let me edit the post... The post on setting up the toolchain in Windows was here, and says

Someone was able to use my guide with mingw. They posted about that over at SonicRetro... which I can't connect to right now. I imagine cygwin would work as well. The main thing to remember is to use the mingw/cygwin shell/terminal instead of the Windows command shell. The Windows shell can't handle the difference in path delimiters.

The ED is not meant to play anything more than 5MB, and that only for SSF2. Pier Solar also uses extra hardware in the cart to keep "backups" from being usable, so don't ever think a backup will run on a flash cart, even if it could hold 8MB. So even when the MegaEverdrive comes out, it STILL won't run your backup of PS.

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.