Chilly Willy

The current file number and line number give *TOP* and 0, which combined with the weird fixup word leads me to think this is an extraneous fix up that somehow got onto the fixup list. EDIT: Putting a continue in place of the interror call caused a segment fault as the fixup list at that point is wonked. Putting a break at that point caused the assembly to finish with no apparent problems. Everything including the symbol table looks fine.

I saw that too. An extra print shows that the fixup that fails has a location of 010400f0 and a flag word of 3042. The location could be a word-swapped gpu immediate, but that fixup word is odd - it means FU_ISBRA|FU_SUB32|FU_EXPR|FU_WORD.

If you're familiar with it, you could run smac from gdb. That's what I did to find the last bug in it. If I can find some time, I'll try doing that on my system as well.

http://krikzz.com/forum/index.php?topic=1203.0 I think that has what you're looking for.

You probably compiled smac in 64-bit mode. Neither smac nor rmac are 64-bit clean. Compile them in 32-bit mode. If you add -m32 to the gnumakefile as a CC flag, it will compile as 32-bit. It should then work fine.

Yeah, although if you have the money, I recommend the Mega Everdrive. It's got a lot more going for it. It uses ram instead of flash to hold the games, so you don't have to worry about flash going bad. It uses an FPGA for the logic, so you can do more through changing the "OS" for the MED cart. For example, the current OS for the MED has all the normal flash cart features, like supporting all the different SMS mappers for playing SMS games on the Genesis, the ability to replace the CD BIOS, support of 8 and 10 MByte flat rom images like that Mortal Kombat hack, and SSF2. Not only that, he has a special mode meant for hacks and homebrew that allows you to use all 16 (or 32) MBytes of ram on the cart as Genesis ram, read/write the SD card, read/write the USB port, as well as a hardware multiplier and divider that can do a 32x32 multiply or 32/32 divide as fast as the 68000 can write the args and read the result. That recent Genesis game (Battlecity) that can be played across the internet is using that mode of the MED along with a PC app to handle the internet connection across the USB.

On the 32X, games like VF, Metal Head, and Darxide might have pushed the actual DRAWING of polys close to their limit, but nothing else at all. Even Sega's poly drawing code says right in the comments that it isn't optimized as much as it could be. First gen titles never hold a candle to what you see in later gen games. Many more optimizations remained, among them using the second SH2 a LOT more, optimizing the 3D math for the SH2, and figuring out the best balance between 68000 use vs RISC use (same issue as Jaguar games). Audio on the 32X was nowhere close to pushing it. All 32X games used a slightly modified Genesis driver, playing FM music and using interrupt-driven PWM to play four extra 8-bit PCM channels on the SH2. I think I've pretty much demolished the view of 32X audio with my demos on MOD, XM, Ogg-Vorbis, and MP3 audio on the 32X, using DMA to play buffers of audio decoded/mixed using the second SH2. I think if it had survived to a second gen of titles, we'd have seen at least MOD/XM/MIDI music used in 32X titles as opposed to the FM seen in the first. Had Doom not been pushed out for an xmas release, the music probably would have been more like the SNES Doom music, only better (not limited to 64KB of samples, and no heavy compression "muffled" sound). They would have also had time to test the later levels, so we'd have seen at least all the same levels as were used in Jaguar Doom. Saxman already made a converter that allows using processed forms of other wads like the Jaguar Doom wad in 32X Doom, so current 32X gamers can finally play all the different Doom levels the original lacked.

Without a 3D card, the slowest RECOMMENDED CPU for PC Tombraider was Pentium, but lots of folks ran it on their 486DX systems. I had both the PSX and PC versions, and liked the PSX better. Of course I didn't have a Pentium or 3D card at the time (mostly still using my Amiga 4000 at that time rather than PCs), so it was slightly painful on the PC. A Jaguar CD version would have needed more optimization than the PSX version, and perhaps fewer models or fewer polys per model, but still quite doable. By that time, however, you'd have probably been more likely to see a 3DO version than a JagCD version.

While the mock-ups do indicate it wasn't being worked on, the Jaguar COULD have run Tombraider. Not as good as the PSX, but good enough. Hell, the PC version ran on a slow 386 with plain VGA graphics - not very well, but it still ran.

Actually, for a 6502 derivative, the clock rate was fine. What holds back the SNES is the 8-bit data bus. That's the GOOD point on the Genesis - a fast 16-bit data bus really moves the data.

While flash roms should take 100,000 to 1,000,000 write cycles, remember that such figures are MTBF (mean time between failures). You could be one of the lucky few were it goes bad in 100 cycles! Aren't you the lucky one! If you don't plan to run the rom very often, run it from ram instead of flashing it to conserve write cycles. It PROBABLY won't be a problem, but better safe than sorry. Write to flash if you need to, or if you plan to run the rom a lot, but otherwise just load it BJL style!

This one is easy to explain: it was an attempt to get around a US patent. Silly as it sounds, there was a valid patent on using XOR to invert the pixels on the screen. Every computer maker who sold a computer in the US had to get a license, and they ALL did rather than fight it. Even Amiga had a license on it. However, when Commodore had their meltdown, they didn't pay the license fee. This was right as the AGA machines came out. The patent holder got a restraining order against sales of the Amiga, so Commodore's biggest market was closed with xmas looming. So they tried a back door around the patent. Video game consoles did NOT license the patent... mainly because (at the time) no console had a BIOS rom that did anything more than show a logo and play a tune. There was no reason to license the patent - it was up to any games that used XOR on the screen to license the patent on their own. Unfortunately for the CD32, the patent holder knew the CD32 still had the Amiga kickstart rom inside, which violated the XOR patent. So they got a restraining order on the CD32 as well. And that was it for Commodore.

I ran AWeb on my Amiga until color Mac emulation was nice and stable, then I ran Netscape in the emulator.

It has PACKAGES for (like) Ubuntu. That's different from building it yourself. That makes is very easy to USE, not to build. It also has mint specific packages, not generic packages. My makefile makes a generic m68k-elf build, not a mint build.

The code/data is in the 68000 code/data right where it is in the source. All org does is tell the assembler to change the addresses computed for that code once it's moved to the right place. So the gpu code may end up at say 0x18000 on the 68000 side, but all the labels and branches inside that block point to the gpu local ram, and once the 68000/blitter moves that chunk of code from 0x18000 to the gpu local ram, it will work properly. It won't work if you try to run it where it is in the system ram... unless you left off the org command so that it assembles to run right there in system ram (which then means following rules needed to run in system ram instead of in local ram).

Yeah, that's good for Windows folks. My makefile makes things easier on *nix folks. My makefiles are pretty straightforward. Makefiles can get REALLY hairy on complex projects. I've seen some that would take a PHD in CS to understand. Basic can be a fun language - it was probably the first language many of us from the 8 and 16 bit eras learned. It's pretty easy to learn, but still quite capable... and no makefiles!

This is my makefile for building gcc for the m68k in *nix. It build gcc 4.8.3, binutils 2.24, and newlib 2.1.0. It builds c, c++, objc, obj-c++, libc, and libstdc++ for the 68000. It's basically the same way I build gcc for the Sega Genesis.

The assembler DOESN'T handle it at all. All the code indeed assembles with the same gpu ram address and will overwrite each other. The main program (on the 68000) handles loading each bit of gpu code as needed. Look at this in tri68k.c: TRIrender(Object *obj, Camera *cam, Lightmodel *lmodel) { Triangle *tri; int tricount; Polygon *pgon, *altpgon; unsigned andclips, orclips, curclip; int camx, camy, camz; int i; Texmap *tmap; unsigned color, basei; /* load up GPU code we will need */ GPUload(gpufixdivcode); See how the function loads the gpu code it will use shortly? You'll find other GPUload() calls elsewhere in the code as needed. When it needs to run the code, it uses the GPUexec() function to start the gpu running.

We call that the Stomach Flu here in the states. I went through that a month or so back. It's no fun at all. Try to enjoy Xmas as best you can!

And don't forget this as concerns the basic Jaguar devkit files: http://www.atariage.com/Jaguar/archives/HasbroRights.html

If you look at Matthias' web page, you'll find all the info. For example, on this web page, you find the cable schematic: That and any controller port pin listing will give you the needed info.

Yes, that would definitely be easier for many folks. That's pretty much how Genesis projects are handled as well - you have a bunch of BMPs and WAVs and a "resource" file that tells the tools how to convert them into sprites for the SDK and sounds for the sound driver.

Me neither. SOME games were easy to copy. Many were nearly impossible without extra hardware BECAUSE of the better FDC in Paula. For example, Psygnosis commonly used one single huge sector per track, and wrote the track at a slower speed to make the track longer than Paula could write. This was impossible to copy without extra hardware. They also used custom sync marks that many copier programs didn't recognize, meaning they wouldn't even READ the disk much less copy it. And they also timed the sync from the index mark so that even if you could somehow write the track, if it wasn't aligned to the index mark correctly, it would fail. Then some other games also added extra copy protection to the last couple tracks that were impossible for Paula to write, period. Copy protection on Amiga games got really sophisticated very quickly.

I take piracy claims with a grain of salt. There was a LOT less piracy on the Amiga than the PC, but you never heard of devs leaving the PC because of "piracy". If you want N0 piracy, you stick with arcade machines. I think the PSX had more piracy than the Amiga, but I don't recall anyone claiming to leave the PSX because of piracy. Several distributors claimed to have left the Dreamcast due to piracy, but that's also rather suspect. Most people in the know at the time were certain they just used that as an excuse, but the real reason is people were fed up with Sega's shit. They burned most of their goodwill when they pushed the Saturn out six months early, then failed to port huge games to other regions, and finally killed the Saturn off early, leaving everyone out to dry until the DC was finally ready.

Yeah, us Amiga devs hated him and Mehdi Ali with a passion for what they did to our beloved platform.