Jump to content

Chilly Willy

Members
  • Content Count

    842
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Chilly Willy

  1. Games that change values in the rom normally require a master code that kills the checksum check. Most Genesis carts do a checksum to start (since it was part of Sega's sample init code) and show a red screen when the checksum fails. GG codes that change values from the rom make it fail the checksum. Also, a game might use the same ram location for different things at different times. For example, a location may be part of a decode buffer before for the intro animation, and then become the number of lives during the game itself. In those cases, you use the switch to keep the cheat off while the game starts, then while the game is running, you turn on the cheat.
  2. There's a big difference between porting ST games and Genesis games - let's just look at one area: graphics. The ST uses plain 16 color bitmap graphics; the toughest thing about it is that it's in bitplane format rather than chunky format. You can use DMA to change the color palette on every line, if you so desire, but that's not a big deal. There are no sprites to worry about. Now let's look at the Genny - you have two planes of 16 color tiled graphics, with the ability to choose between four sets of color registers with every tile. You have fairly complicated scrolling and priority modes, as well as up to 80 sprites you have to mix into the whole mess. You can change a number of things on the fly - not the entire palette, but a number of color registers, among other things. At least the tile data is in chunky format, but it is otherwise a big pain in the ass. Even emulators on PCs with near infinite speed have fun getting the graphics right.
  3. The more you examine the Amiga chipset, the more obvious it becomes the lineage it shares with the Atari. Even the way they updated Denise for Extra-Half-Brite mode brings to mind the update from CTIA to GTIA. It's too bad they didn't have something like the A500 to start with; they probably would have done better given how well the 500 did three years late to the party.
  4. Really? There are 32 color registers (in OCS/ECS). The first 16 are exclusive to the playfield, and cover one layer of 16 colors, or two layers of 8 colors each. The last 16 color registers are used by the sprites, or by a single layer playfield of five or six bitplanes. So only the second 16 colors are POSSIBLY shared. When sprites are in four color mode, pairs of sprites share four colors, the first actually being transparent. So color regs 16, 20, 24, and 28 are not shared in four color mode, but exclusive to the playfield. If you put a sprite pair into attached mode, they show 16 colors - all the upper color registers... except the first which is again transparent. So color 16 is always exclusive to the playfield regardless of the sprite mode. 20, 24, and 28 may or may not be exclusive. The idea was that most games would use two playfields of 8 colors each, leaving all the upper color registers for the sprites. Single playfields of 32 or 64 colors have to share most of the upper color registers.
  5. An aside about being "lumbered" with a 32X devkit: the devkit hardware was crap. The docs are so full of things devs need to work around it's not surprising that many devs thought twice about working on it. Seriously, one interrupt bug in the IO chip was so bad they used the free-run timer to periodically "bump" the interrupt system. Nearly all these bugs were fixed in the consumer units, which is actually fairly easy to develop on. I do all kinds of stuff on the consumer unit that devs were warned against. Makes me wonder if SEGA had planned to update the devkits at some point, or if developers would have switched to developing on consumer units rather than dev units.
  6. Yes, but they would have been much too expensive. At best, you could have seen an EC020. Now that would have been nice compared to the 000.
  7. You might try checking the Tech Aid forum over at Sega-16. That's probably better than asking on an Atari board.
  8. Those games do come close to what you could do GRAPHICALLY. Not the very best, but you get a good idea of what you can do on the 32X. As far as sound goes, they didn't even scratch the surface. Same for making better use of the extra SH2. So while you can claim there's not a lot left to show for graphics, and that is arguable, nothing else was remotely pushed on the platform. My demos have done a decent job of showing closer to what the audio could do, as well as a little of what another sh2 allows; interrupt processed DMA'd sample buffers, using the slave sh2 for sound processing (ogg/mp3/g722.1/xm/mod), but there's still more to be done there as well. Again, look at the GBA games for a better idea of what you could have seen on the 32X if it had lasted more than six months. Launch games rarely show you what a platform is REALLY capable of, and that's ALL you got on the 32X. True - where the 32X got VF and VRD, the Jag got Fight for Life and Checkered Flag. Not a very good comparison that we KNOW should have been better. In that respect, the 32X got a lot more love (relatively speaking) than the Jag. Which is a shame since despite all flaws, it's a pretty awesome console. It's funny that the 32X was considered such a flop when it actually propped up Sega's profits for the quarters it was sold. There's been a lot of financial records for the periods covering the MD through the DC posted on boards, and had Sega not put out the 32X, it's arguable they'd have gone bankrupt trying to push out the Saturn. The 32X was not sold for a loss at the beginning, sold a metric shit-tonne of consoles that first xmas, and had several games that EVERYONE bought. So what if there were only 30-some games total for the 32X? I bought just as many 32X games as I did PS1 games within six months of purchase.
  9. Well, it DOES have a lot of untapped potential... just not anywhere near the PS1 or Saturn. The 32X has a lot of untapped potential. Doesn't mean it can take on the Saturn. To get some idea about how games COULD have gone on the 32X, the GBA is roughly the same power (32X has more processing power with its dual SH2s, but otherwise very nearly identical in all other areas). So just look at the game they came out with on the GBA. The Jaguar is easily more powerful than the 32X or GBA, so we know that anything that came out on the GBA could have easily been done for the Jaguar as well. Think about some of the last few racers for the GBA, then look at Checker Flag or Club Drive...
  10. I never got this - have these people never used controllers on other consoles? There are FAR more controllers far worse than the Jag controller. It realistically doesn't even make a list of the top ten worst controllers if you consider all of them, maybe even a top twenty list. The controller is one of the things I like about my Jaguar. I just wish I had a Pro controller, too.
  11. No problem. When I locate the stuff, I'll scan the blueprints and post them and the BIOS disassembly.
  12. My VERY FIRST commercial program ever was for the A8. Didn't get much for it, but I was a college student at the time and didn't care so much as I wrote it in my spare time. After that, I moved into the Amiga for most of my early work. But nothing ever quite matches the feeling you get on your first sale. I discovered artifacting independently... and thought my Atari was bad. I took it to a dealer and showed him via a BASIC snippet what was wrong, and we tried it on several more Ataris with the same result, thus realizing that was actually not a bug, but how it was supposed to work. I never heard the term until after I was already on the Amiga. I called it Color Aliasing since that's what a TV repairman would call such a thing.
  13. Uh, is BJL support only part of newer skunks? My SillyVenture Skunkboard works great with lo_inp, and the manual for the V2 Skunkboard says it does as well. Or am I crazy and using something else and mistaken? Sorry, but getting old does things to your brain. EDIT: Yes, it was a brainfart. I use jcp with my skunk. Sorry about the confusion. Jcp should compile and run fine in OSX. Jcp is part of the skunkboard archive that was posted when it was discontinued.
  14. I had a Small-C compiler for the Atari called Deep Blue C. These days, it's just easier/faster to use a cross-compiler like CC65.
  15. If you run in OSX more than Windows, try compiling and using lo_inp instead. That works great in any version of *nix. If you really want to use Windows, you could try installing cygwin and then compiling lo_inp under cygwin. That should also work.
  16. TECHNICALLY you can, but in both cases, you're using the memory in a way it wasn't meant for and will slow the game. Both companies told devs not to do so, and that doing so will result in a refusal to license the game. Funny enough, Nintendo had the same stance on N64 cart rom - while technically, you can run code in the N64 cart, Nintendo would refuse to license a game that did so. You were supposed to use the DMA to copy code/data to RDRAM and run it there, not run it from the cart. Again, probably for the same reason - the cart is slow compared to system ram, and latencies were bad enough on the N64 without throwing in cart bus issues.
  17. I'll have to dig out the listing and schematics, but from memory, the Percom has the code in the BIOS to respond to the "?" SIO command. That was how most drives of the period switched to high speed mode. If the SIO command timed/errored out, DOS knew to not change the serial rate, but if the command succeeded, the return value was the new serial rate value to use. It was assumed that the drive switched to the higher speed after responding to the SIO command. The Percom had the command, but no way to change the serial clock to the serial chip used to communicate with the Atari. My goal was to add another clock at the proper rate and a switch to select between them. The Percom used the 6809, which was my first real exposure to that processor. I wrote my own 6809 disassembler for the Atari to generate the code from the BIOS. IIRC, I pulled the rom from the Percom PCB and put it in an Atari cart to dump it to my brother's 1050 so I could disassemble it. I had one of our 400's with a switch wired to the /CART line so we could put in a cart, disable the cart to boot into DOS, then enable the cart and dump to a file. Worked great for dumping those carts that were flagged as diagnostic to keep DOS from loading.
  18. Ah, yes. I see that. And that's very true. It's even more true on the CD32X - the CD gives you 600+ MB of storage, but the 32X is reduced to just the basic 256KB of SDRAM since the cart is gone. At least the Jag had 2MB. Yes, they COULD have put more ram in with the CD, but I guess they thought 1) it would be too expensive, and 2) the 2MB in the Jaguar was plenty for the time (not thinking ahead).
  19. Uh, no I wasn't. The ram carts for the Saturn are most definitely NOT like the ram expansion for the N64. They're fairly slow, even compared to the low ram bank of ram in the Saturn, 16 bit, and Sega EXPLICITLY states not to put any code into the ram cart - it's DATA ONLY. In which case, other than being able to load the ram with data from the CD, it's exactly like the Jaguar cart in that you can't run code from the Jaguar cart either. Actually, the Jaguar cart is faster as they used a 32 bit bus rather than the 16 bit bus for the Saturn ram cart. Granted, being able to load the ram cart from CD gives it a major advantage in terms of cost - making a rom cart for the Jag big enough to hold all the data you could load from CD would cost a LOT... like those old NeoGeo carts. The point was, if a company was willing to spend the money on a big enough cart, the Jaguar could be at least as good for those big 2D fighters as the PS1 or Saturn, and better in some ways (especially compared to the PS1 were there was no ram cart available). This isn't about CPU speed or GPU power - the games in question ran on lower power processors, and the Jaguar had more than enough graphically speed to handle these 2D games in question. There's no doubt the Jaguar wasn't close to the PS1 or Saturn on 3D. I think even the 3DO was faster for 3D. The argument for 3D is that some games could have been done on the Jaguar and still been playable. Many wouldn't. We just never saw any on the Jaguar because it was dead by the time those games were being worked on. And yes, the Jaguar CD added little beyond a larger storage device, and CD quality audio. It doesn't add any memory, but it doesn't take all that much ram from the Jaguar. At worst, you lose maybe a dozen or two KB for the JagCD BIOS and code needed to read a Jaguar CD.
  20. I had a Percom DD disk drive. It was awesome. I RE'd the BIOS in it, and they support the speed change command in the BIOS! Unfortunately, they didn't support it in the hardware. I got the schematics from Percom, and started looking into a mod to allow higher speeds, but right at that time, I finally moved up to the Amiga (500) and it got pushed to the side.
  21. Those large 2D fighters would have worked fine on the Jag... if they made them as larger bank switched carts like the NeoGeo. They could have made huge bank switched carts for the Jaguar easily... and more expensive, of course. That was the primary issue with 2D fighters on the PS1 and Saturn - not enough ram for holding all the tiles. Some Saturn fighters off-loaded the extra tiles to a rom cart. Those would have done well on the Jaguar on a large cart. It's one area a cart has the edge over CDs.
  22. Especially given the already high price, they could have afforded to add an extra few bucks for a better screen.
  23. Yep! I played Necromancer off cassette tape on my A400 and loved every minute of it!
  24. Audacity automatically dithers when converting audio to a form with fewer bits, but 8-bit is as low as it goes. To do four bits, you'd need to roll your own code, but that's really easy. Dithering is easy, too. Say you have 8-bit audio samples for the input. Dither needs to be +/- 0.5, plus or minus half a bit. Apply that before you convert, so half a bit for 4-bit samples is +/- 8 for 8-bit samples. If RANDOM is a random number between 0 and 1, you want DITHER_NOISE = 8 * (RANDOM - 0.5). For a rectangular power distribution function, the sample you use is merely (sample - DITHER_NOISE) >> 4. If you want the better triangular power distribution function, the sample is (sample + DITHER_NOISE - PREVIOUS_DITHER) >> 4, then set PREVIOUS_DITHER = DITHER_NOISE.
  25. PAR was just a GG with a different name and interface. That Nakitek Saver just saves what it can and ignores the rest. If you read reviews on it, the sound isn't saved - as I said, that's not something you can save from the cart slot. So it's kinda similar to the MegaED save states, only not as good. Probably about as good as you'll find for the SNES, though.
×
×
  • Create New...