Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Chilly Willy

Members
 View Profile  See their activity

  • Content Count

    842

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Chilly Willy

  1. Posted · Edited by 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.

  6. Posted

    You need a Genesis flashcart, like the Everdrive. Works for 32X games too.

    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.

  7. Posted

    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.

    • Like 1

  8. Posted

    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. :D

  10. Posted

    I always thought Nintendo's decision to use such a slow (talking clock rate) processor in the SNES was rather silly. Slow-down in games aside, there was a numbers war going on from a marketing standpoint by then also.

    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.

  11. Posted

    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!

  12. Posted

    2. Amiga CD32

    I never 'got' the CD32. It just seemed wrong to me. To me it was more like a crippled amiga 1200.

    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.

    • Like 2

  14. Posted

    Nope, Vincent's page also has packages for Linux flavours too. And RHEL done by other people too, not just Vincent. So I think that script should function in most linux distros and Windows.

    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.

  15. Posted

    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).

    • Like 2

  16. Posted

    Thanks, but well, if you read my WoT (Wall of Text © sh3) above you'll noticed me saying I'm not exactly fond of C? Well, guess what I think about makefiles :D. What I did to build a cross-gcc was to simply take Vincent's build script, modify some paths, put the required files to the required places, ran it and presto! A cross gcc without all the useless cygwin environment gobbledygook! I was actually amazed it worked without my PC exploding into deep space! I won't push my luck further though, 0 makefiles created by me = enough to last a lifetime :).

    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. :D

     

    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!

  18. Posted

    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.
    • Like 1

  21. Posted

    Using my computer's parallel port to transfer files to the Jaguar through BJL has never really worked well. It often takes numerous attempts on small files and simply never works on large ones.

     

    As a small side project, I've been considering using the GPIO pins on my Raspberry Pi to talk to the 2nd controller port/BJL on the Jaguar so I can use updated hardware and a much more streamlined toolchain.

     

    Does anyone have any technical documentation on what, specifically, the BJL listens to on the 2nd controller port, for data?

    If you look at Matthias' web page, you'll find all the info. For example, on this web page, you find the cable schematic:

     

    bjl_wire.gif

     

    That and any controller port pin listing will give you the needed info.

  22. Posted

    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.

    • Like 2

  23. Posted

    I'd not rate Amiga piracy much worse than the likes of C64 or ST.

    Me neither.

     

     

    Amiga games were generally easier to copy though - the more sophisticated FDC onboard the Amiga made duplicating most schemes much easier, IIRC the Amiga can write out an arbitrary track of data where the ST's controller reserves certain byte values which will generate Sync pulses and overall makes it less flexible.

    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.

  24. Posted

    Martin Edmondson (Reflections) has said the reason they abandoned the Amiga was due to Piracy, as they were being told around 96%+ of their games doing the rounds on the Amiga were pirated versions.

    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.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...