Chilly Willy

The issue isn't FRAM versus SRAM, it's the WAY the FRAM is ACCESSED. Nintendo used a pretty silly method of accessing FRAM compared to SRAM (FRAM chips are designed to drop in to SRAM designs, so the way FRAM is accessed on the N64 is Nintendo's fault and not due to the FRAM itself). Even if he used real FRAM, he'd still have to add that crazy access interface to the firmware; if it has trouble with SRAM, it would have the SAME trouble with FRAM. The MAIN difference between FRAM and SRAM is the SRAM requires battery backed power while the FRAM doesn't. As mentioned above, FRAM generally comes in standard SRAM packages and pinouts to be a drop-in replacement without the need for batteries.

One, depending on the price. That may change to definitely one depending on how my finances go through the year.

Think of it as a 32X for the TG-16. The 32X added two more high-speed CPUs with local sdram, a dual framebuffer capable of 256 color paletted or 15 bit direct color modes, and PWM stereo audio. The System Card is just a ram card... think of it like the Saturn RAM cart (or Action Replay cart minus the cheat/region handling).

Very awesome game! My 65XE thanks you for the fun, and so do I.

Gateway computers held the patents. There is little doubt if there was anything they could monetize by licensing they would have. So that would seem to put to rest the idea that Commodore-Amiga was recognized as the creator of this tech. Except that Gateway was a prime distributor of PCI based systems. My guess now is they bought the Amiga IP to AVOID a lawsuit over patents covering PCI. Remember that unless the company is a NPE (Non Practicing Entity - cough - parasitic lawyers - cough), most patents are used DEFENSIVELY. That's only now in the last year starting to change as we se certain companies (Apple, MS) going after competitors using patents offensively.

Yeah, I don't know that anything was ever done with it. But for the time, it was perhaps the most awesome chipset around. Just think if Atari had come out with a 68000 + RMS instead of the ST chipset. Or if Tandy had made a 68000 + RMS instead of switching to 286 systems.

Once a flash cell goes bad, it's bad. There's no "reformatting" - it's dead, Jim. Always? I thought specific bits went "bad", and reformatting would label them that way so they would be skipped during use (just what I thought from reading about them, but I haven't read much about it since Compact Flash came out)... ...OK, I just read up on it... newer flash memory now has error correction codes and "wear leveling" built into the control circuitry of the flash device, so theoretically as cells go bad, they merely aren't used any more and the capacity of the memory device just shrinks (though I suppose the entire device would become useless if something in the control circuit went bad). Seems that one way to monitor the quality (and remaining life) of the flash memory is to see how small it has become since purchase... Also, transfer speed slows down as cells die since more memory management operations are required per usable byte. Wear-leveling is done at the filesystem or device level, not the flash level. For example, the controller in an SD card MIGHT do wear-leveling by redirecting the sector asked for based on wear statistics. More commonly, flash filesystems handle the wear-leveling; that's particularly true since the filesystem will have the most info on the data being written. It is never done at the flash level that I have seen. So unless KRIKzz put an MMU inside the ASIC, there's no wear-leveling for the flash on the cart, but the SD card you use MIGHT have it, or your PC used to write the SD card might.

The chips in question are the MC68486RMI (Raster Memory Interface) and the MC68487RMC (Raster Memory Controller). The datasheets for these are available through ChipDocs: http://www.chipdocs.com/pndecoder/datasheets/MOT/MC68486.html Of course, they charge $100 a year to access their collection. Back at the time this chipset came out, I xeroxed a nice copy of the info, but I've no idea where that is now. It looked like a really cool chipset.

Ah yes, the old 2600 version of Missile Command. That kept me busy for plenty of hours back as a kid. My biggest accomplishment as a kid was wrapping the score around on this game one Saturday.

However long it takes for the flash to develop a bad sector. Most flash is rated for at least 100,000 write cycles, and KRIKzz uses GOOD flash memory. You COULD get as many 1,000,000 writes, but I would probably doubt that much. Now remember that switching games rewrites the flash, so if you played a different game every day, it could go bad in 100,000 days, or 274 years. Please note that the ratings on flash are AVERAGES. It's POSSIBLE (but not likely) that you could get an error after 100 writes. Bad flash general gives errors after maybe 1,000 writes, so you at least have a few years of playing a different game every day. ...and then you just reformat and restore from backup... Once a flash cell goes bad, it's bad. There's no "reformatting" - it's dead, Jim.

A 180K double-density disk is off by three sectors of 128 bytes because the first three sectors are ALWAYS 128 bytes, even in double-density. This is because the disk boot process loads three sectors assumed to be 128 bytes each. Double-density disks store the data as 256 bytes sectors, but the control board only returns half the sector data for the first three sectors.

The mask can be stored in a table and accessed by ANDing off all but the last two bits of the x coord to use as an index into the mask table. 0 -> $3F 1 -> $CF 2 -> $F3 3 -> $FC

However long it takes for the flash to develop a bad sector. Most flash is rated for at least 100,000 write cycles, and KRIKzz uses GOOD flash memory. You COULD get as many 1,000,000 writes, but I would probably doubt that much. Now remember that switching games rewrites the flash, so if you played a different game every day, it could go bad in 100,000 days, or 274 years. Please note that the ratings on flash are AVERAGES. It's POSSIBLE (but not likely) that you could get an error after 100 writes. Bad flash general gives errors after maybe 1,000 writes, so you at least have a few years of playing a different game every day.

No problem. Most of that is from SpritesMind. If you really want technical info on the Genesis/CD/32X, you probably want to check there. Especially low-level info on the YM2612.

I'm waiting on Amiga mouse support so I can try it on my 65XE with the Boing! mouse.

The entire memory map for the 68000 is 16 MBytes. On the Genesis, that 16 MBytes is divided like this: 0x000000 - 0x3FFFFF = CART if a cart is inserted, if no cart, this is CD space 0x400000 - 0x7FFFFF = CD space is a cart is insert, otherwise it is cart space (a cart that doesn't assert the /CART line is considered a BRAM cart) 0x800000 - 0x9FFFFF = 32X space - if you have a 32X and it is enabled, this will have the cart rom, frame buffer, and frame overwrite regions 0xA00000 - 0xDFFFFF = IO space 0xE00000 - 0xFFFFFF = Work RAM space - only 64KB, but mirrored through whole 2MB If you do not have a CD or 32X, you CAN use the space for those if the cart does its own decoding and asserts the /DTACK for areas outside the CART space. So you CAN have carts that go to 8 or even 10 MBytes, but only without the CD or 32X. With the CD and/or 32X, 4 MBytes is the max without bank selection. SEGA did define one mapper for the Genesis (which is also supported by the 32X): A cart can have up to 32 MBytes of rom split into 512 KByte segments. There are eight 512 KByte pages in the cart space; page 0 will ALWAYS point to the first segment of the rom; pages 1 to 7 can be set to point to any of the 64 different segments of rom. 0xA130F1 controls the save ram 0xA130F3 sets the segment for page 1 (0 to 63) 0xA130F5 sets the segment for page 2 (0 to 63) 0xA130F7 sets the segment for page 3 (0 to 63) 0xA130F9 sets the segment for page 4 (0 to 63) 0xA130FB sets the segment for page 5 (0 to 63) 0xA130FD sets the segment for page 6 (0 to 63) 0xA130FF sets the segment for page 7 (0 to 63) The only game to use the official SEGA mapper is Super Street Fighter 2, so most people call it the SSF2 mapper. SEGA had two different developer carts that implemented the SEGA mapper for developers wishing to make games larger than 4 MBytes. Note that the SH2 processors on the 32X cannot access the page registers on the cart; it must command the 68000 to do it for it. The 32X BIOS for the 68000 has two functions built into it besides the exception jump table - one functions sets one mapper register, and the other sets all the mapper registers. So it's clear SEGA meant to have 32X games that were larger than 4 MBytes, but it died before that happened.

NOTHING will do everything for you... except BEX, and that's BASIC, not asm. You're better off just starting from the examples and demos than wishing for a "does everything" assembler/compiler. I made a thread on how to build a toolchain for the MD/32X: http://www.sega-16.com/forum/showthread.php?16552 http://gendev.spritesmind.net/forum/viewtopic.php?t=889 It has example code that takes care of the header and a bunch of over stuff. You'll find lots of demo and example code at SEGA-16 and SpritesMind, so I suggest making an account at both. If you want just a plain assembler, you'll need to look into the examples and demos yourself. As for the assembler, try AS: http://john.ccac.rwth-aachen.de:8000/as/

That is nonsense you'd have to live in a very small world to believe. There were numerous examples of autoconfiguring expansion systems before and after the Amiga. The Amiga was far from the most prominent pioneer in EE circles. The only thing that was especially notable about the Amiga slots was their appearnce in a relatively low-priced system accessible to consumers. They owed a certain heritage to things that came before , like S-100. Any time a project has a chance to do something from scratch without backward compatiblity concerns, there is always the question, how would you implement X if you were using today's tech. The Amiga Bus slots were a perfect example of that. Transistor budgets were a bit higher, RAM a bit available, etc. You clearly aren't familiar with the S-100, Zorro (I or II), or PCI specs. (cough - ripped off Zorro II - cough) The PCI folks were just lucky CBM was out of business by then and that whomever held the Amiga IP didn't deem it worth a lawsuit for violating the patents on the Zorro technology. If it would have happened today (as litigious as companies are over patents), PCI would still be tied up in court.

NuBus required the driver be embedded in a rom on the board. The OS could override the built in driver with an updated one, but most just used the driver on the card. Amiga cards usually had the driver on the card as well. AutoConfig was more flexible about allocating space for the card - NuBus hardcodes the address of the card based on the slot the card was plugged into; also, the size of the space for the card was fixed, which is why NuBus had a limit on the number of cards you could use. Two different size spaces were reserved for the card: a 1MB space in the 24-bit addressing range, and a 256MB space (IIRC) in the 32-bit addressing range. The card control registers and rom (for info and possible driver) had to be in the 1MB space. The 32-bit space was mainly used by video cards for more vram for larger resolutions. While you COULD have a NuBus ram card that added a bunch of ram to 32-bit space, MacOS never supported it - it was mainly only used by that old Mac UNIX.

I just tested it (since it's been a while ) and the GG starts Zany Golf with no codes. Of the five early unlicensed games by Electronic Arts and Accolade (Budokan, Ishido, Onslaught, Populous, and Zany Golf), I think the only one that won't even work with a GG on a TMSS system is Budokan. All the others work fine, with no codes necessary, since the GG takes care of pushing TMSS into the right register. There is a Euro version of Budokan that should work on TMSS systems. Someone on Sega-16 also claimed that their American copy worked fine with their TMSS system, so maybe there's a domestic ROM variant that works. BTW there are also a ton of unlicensed games that benefit from the Game Genie. A few of them need much more radical intervention though, since they intentionally trash the TMSS register! There were some very useful posts on the topic by Chilly Willy and Eke-Eke over on Sega-16. Yeah, that was a really crazy thing... I looked at a game for someone to make some PAR codes (not GG) to get it to run, and it turned out the game walked on the TMSS register (probably due to missing copy protection hardware). The code to get it to work was to just change the value stored to the TMSS register to the proper value. Anywho, flash carts usually also run games that don't work on TMSS models because they've already set the TMSS register as part of the menu startup. You'd only run into a problem if you ran the image as the only thing on an MD-Pro flash cart since it would be just like a real cart at that point. If you put the menu on the MD-Pro, then it's like the other flash carts.

It was for titling and overlays for info not related to the video. Think opening/ending credits or that damn weather alert. Super HiRes (ECS at least) was NOT for CGI video for the actual program. Neither was AGA Super HiRes. The Toaster was probably the first used for that. As to overscan, the Amiga had fully programmable start and stop positions for both horizontal and vertical. Vertically, you were limited by where the vblank started and stopped, while you were limited horizontally by where the mandatory DMA stopped and the hblank started. You could have severe overscan on the Amiga that pretty much covered 100% of the active display.

In case anyone was curious, PCI was "inspired" by (cough - stolen from - cough) AutoConfig. You can't look at the two from a hardware standpoint without coming to that conclusion.

Those games work on Model 1s without TMSS. TMSS requires the word "SEGA" at offset 256 in the rom along with special startup code that stores that value into a special register. I'm sure there are GG codes that handle that.

Chilly, could you elaborate on this a bit? Since i got my sdrive in april, ive found a large number of games that seemingly dont work, and im wondering if this could be the issue? could renaming some of these ATR's to XFD do the trick? Actually, sorry, I was confused there... it's the SIO2SD that requires the specific extensions. I had it confused with the SDrive. Sorry about that.

Whoopsie! Nice catch - yes, I meant 4 colors for ECS Super HiRes NTSC or PAL. Sorry about that. The reason I said 16 is kinda interesting - on the ECS chips, the video out couldn't really handle Super HiRes straight, so they required you to set the palette in a really odd manner; you set all 16 playfield colors using the four desired colors via a particular method. ECS Denise would process the 4 color data at 16 color speeds and output the 16 colors in a way that created the four colors desired. I'm probably not explaining it right, but it was a very odd situation. Anywho, I left it up to graphics.library to set the colors correctly. You only had to worry if you took over the system and poked the color palette directly.