Jump to content

Chilly Willy

Members
  • Posts

    973
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Chilly Willy

  1. That was my concern as well, but if you don't have any of those games and don't plan on getting them, the A600 would be better to keep. Granted, I kept my A500.
  2. Almost EIGHT years ago! Your perseverance on this project is incredible. Respect! Much respect! Not only did he persevere, but the game turned out to be incredibly awesome! Quite often, after so many years devs will sometimes do anything just to get done. Kudos for not doing that.
  3. Yes, I was going to mention that everyone has their own ideas about what is "fast". My Amiga mice come from the early 90s. Maybe they're getting slow in their old age. Yes, definitely. I'm awed at how responsive the gui is... windows snap into place when moved, menus blink in and out of being, menu items hilite sharply as you move the mouse.... I've seen worse GUI response from 2GHz PCs. I understand this GUI doesn't have as much it's doing underneath as compared to Windows or linux, but it's all perception to the user - the interface FEELS fast, so it IS fast.
  4. Thinking about the mouse movement issue a while, it probably has to do with the counts per inch. If I remember correctly, the original Amiga ball mice were 200 cpi, while the Boing! mouse was supposed to be 300 or 400... I forget exactly. The new Boing Ball mice sold for the Amiga all advertise 1000 cpi, so it's no wonder you have to move them slowly to work right.
  5. I'll try the demo on my Boing mouse and see how it responds... Okay, tried it on my 65XE... works like a charm! Moving the mouse "normally" is smooth and fluid. I have to move the mouse REALLY fast before it has a problem. I noticed that I can move the mouse faster to the right without trouble than to the left. Maybe a difference in how the code processes the mouse. I noticed that the zoom gadget only goes to full-screen, not back. I suppose that's coming, along with close gadget handling. But, I like what I see so far. Excellent work! EDIT #2: Attract mode isn't canceled by moving the mouse or clicking the mouse buttons, but only by pressing a key. You might want to fix that.
  6. Wow - a LOT of that is really outdated. The NeoFlash part is really outdated, and an Everdrive section needs to be added.
  7. 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.
  8. One, depending on the price. That may change to definitely one depending on how my finances go through the year.
  9. 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).
  10. Very awesome game! My 65XE thanks you for the fun, and so do I.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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
  19. 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.
  20. 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.
  21. I'm waiting on Amiga mouse support so I can try it on my 65XE with the Boing! mouse.
  22. 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.
  23. 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/
  24. 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.
  25. 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.
×
×
  • Create New...