gdement

Sort of. It still implies it was released by "Atari", claiming they made an official statement about it. Then he has a correction buried at the bottom where half the people won't see it. Why not just put the correction up top and remove the faulty information? And he still seems clueless that Super Pac-Man is not an original Atari game and Joust is the 2600 version. He won't know until somebody tells him because he doesn't understand what the hell he posted. It's amusing and lame how he says he "accidentally" skipped the part about source - atarimuseum.com. Regardless of whether he saw this footnote on the atarimuseum site, how could he "accidentally" forget that he copied the files from someone else? Giving credit should be a natural impulse unless he's just out for the attention.

It's not as simple as just turning it down. Atari was interested but they apparently didn't agree to terms. The premise of the deal would be that 1983 Nintendo couldn't handle North America themselves and needed help, which Warner could provide. Warner probably felt they were in a strong negotiating position so I doubt they offered much. It's not like they really needed the NES, as they had their own platform already in development. A long time ago I remember seeing a memo (online) that was supposedly from someone at Atari regarding this negotiation. I have no idea if it was authentic though, and I don't know where to find it anymore. Assuming it was legitimate, I remember it basically suggested they wanted to draw out negotiations with Nintendo until the 7800 was ready, so that they could do a better comparison. But negotiations didn't last long enough for that to happen. The 7800 developers claim Warner intended to secure rights to the NES but not actually release it, so Nintendo would be locked out of North America (*). Of course just because Warner told them this doesn't mean it's the whole truth. I expect they would have given the NES a serious look before locking it away. This could have been another snag in negotiations (Nintendo wanting guarantees it would be sold, Warner unwilling to commit). * = this is in the speech Allan linked above

If you haven't seen it already, please check the RIOT code in ProSystem 1.3e regarding the controllers. I believe the same changes were also put in the latest version of the Wii emulator, and that might also have a fix for a HSC issue so that's still probably the best place to look. 1.3e emulates the behavior of CTLSWA/SWCHA and CTLSWB/SWCHB much better than previous versions, so the controllers (even the console switches) are improved in that version. I did some experimenting with the console and there's some esoteric behavior involved that might not be obvious.

Overclocking a 7800? Interesting idea. Faster 6502's are certainly out there but I don't think any support the halt feature that the Atari depends on. I think the clock is controlled by the Maria, as it contains the logic to set clock rate based on what address is active. So overclocking the Maria should overclock everything. I'm skeptical that the Maria is any good for overclocking though. Might also screw up video sync. You'd probably have to somehow overclock the 6502 while leaving Maria alone. If you managed that, I think the big question would be how fast can the cartridge ROMs keep up with?

Posted something about this a couple days ago but it got lost in the server problems. A western style RPG better represents what would have naturally landed first on the 7800 if it were more competitive in the 80's. So I can see what the earlier poster was saying about that. It's like using Chevy parts to build up a Ford. But that's not important really. People should do whatever everyone is most fired up to work on. Linear Japanese story-oriented RPGs aren't my favorite thing. I'd prefer a more open western RPG like Ultima. Japanese artwork doesn't bother me as long as it isn't stupid. As long as the eyes don't turn into fireballs (because he's mad) or a character starts crying like an infant, then I don't mind if they just have green hair. I don't see that being an issue with any 8-bit machine. Japanese RPG's didn't *really* bug me until Lunar on the Sega CD.

In Choplifter, does 1 of the buttons still work (fire), but just the 2nd button doesn't work (rotate)? Or do none of them work? If 1 of the buttons still works, then it's probably wired for the Sega pinout and not 7800 pinout. When it says it works for Atari, they might only be talking about 1-button 2600-style compatibility. The 2-button wiring on the 7800 is different than for other systems, so only 1 button normally works with generic controllers. For Xevious, the fire+bomb behavior is controlled by the difficulty switches. Try fiddling with those.

I remember first seeing that controller in a 7800 ad in a later Sears catalog, or maybe some other major catalog. I noticed it and was amused because by that time I had a NES, and thought it was funny Atari had finally caught on to gamepads. So I'm confused to have read all over the internet that the gamepads were never released here (US), but maybe that catalog just used the wrong photo.

It's possible we could have had 3 companies each dominating a different market. Or more likely, I think it would work out like this: Nintendo strong in Japan and North America Atari strong in North America and Europe Sega strong in Europe and South America I hate to nitpick when obviously it's hard to speculate, but I can't help adding a couple other things: If the NES didn't have dominant market share, then the SNES probably would have arrived sooner than 1991. However, due to being developed and released sooner it might have some differences in graphics/sound/ram vs what we got. If the Jaguar were released in the same form as it really was in our world, then I think Atari would stumble at that point. From everything people say in those heated programming debates in this forum, it sounds like the hardware was badly bugged and very difficult for the programmers to utilize.

That was where I bought my first used NES game (Ultima: Exodus for $5), and also where I got a model 2 SegaCD ($40 I think) after my model 1 had broken again. I specifically asked for the top-load because my front-loader had been such a lemon. And sure enough the model 2 has been reliable ever since but it looks cheap and I miss the old one. That Funcoland store is also the only place I ever saw a Saturn unboxed and in use (new at the time). Some kid was playing SimCity on it. It was a fine store, wish they were still around instead of EBGameStop. Some time later I entered a backorder for Dark Wizard on the Funcoland web site. It never came in, and after maybe 6 months they canceled my order. That was frustrating at the time, but I scored a copy eventually.

I've never seen a good KayBee store either, just the messy little ones in malls. In the early 90's, after I had a Genesis, the KayBee store had a few old, faded and dented 2600 games and also 7800 Midnight Mutants. They wanted $5 for it but I thought it would be a waste of money. When they were closing last Christmas, for some reason they had dozens of Rocky 5 action figures of that Don King character in a white robe. I almost bought one just because I thought it was funny. The only thing I remember of the original "video game crash" was when I learned at a friend's house that Target was selling Atari games for $5 each. Then an ad came on the TV about it. So at the first opportunity I told my parents and they agreed to go buy some. I picked out Night Rider, and I think my older sister might have picked at least a couple other games. I'm sure I must have looked for Pele's Soccer but either couldn't find it or wasn't allowed to get both. Now I wonder if it was being sold as "Championship Soccer" and that's why I didn't find it. That sale is the only time I ever knew what an Atari game cost. I was too young to pay for anything and didn't really know what was a normal price.

For what it's worth, I'm now pretty confident that battery holders work fine on NES carts. The only problem is getting them to fit. I salvaged one from an old motherboard, but even using the smallest holder I could find I still had to sand it down. Once installed, I then saved something to the game, tossed it around and dropped and shook it, and didn't lose any data. I've used it over the last few weeks and no problems yet. Of the carts I've looked at so far, I noticed that they already have a capacitor on the battery, so that probably makes vibration a non-issue. One of my NES carts was 100uF and I think the other was 47uF.

That all might be true but if I remember correctly(as it was a while ago),I asked the developer of the unit if it could use the extra as Maria ram and I believe he told me it was to emulte ROM only. Perhaps he did not hookup the write line to the 7800. The Maria always just reads anyway, it never writes (like Mord was saying). But I suddenly remembered something and just checked the programming specs. I'm guessing this is what the developer would have been talking about: So holey DMA won't work in addresses below $8000 - and the XBoard RAM (and all carts that have RAM) sits below that. So if you need holey DMA then you can't put those graphics below $8000.

Hard for me since the NES is the first system I experienced that actually had good sound. So I have to pick something I saw on the NES before SMB. All I can think of is Popeye. I think I used to like the music in that game. Or I can go with 2600 Frogger. It's kind of like asking what was my favorite baby food.

If I remember correctly, the Xboard does not allow Maria access to the XBoard RAM as RAM but only ROM? That would be one feature I'd hope to see changed if Curt tries to maintain compatibility with XBoard. My guess is it would be possible to allow that RAM to act as both and still remain compatible....or do I completely misunderstand the purpose of the RAM in the XBoard? I'm not sure why it would have any such limitation. Maybe it's too slow for the Maria structures, but I doubt it. It's a modern surface mounted 128KB SRAM chip so I assume it's at least as fast as the 80's RAM in the console. Of course the RAM is bankswitched in a 16KB window, so the Maria wouldn't be able to see any more than that at once. I have an XBoard but haven't been able to experiment with it yet, as I can't seem to get it to work. I'll probably post a thread about that when I get things more organized.

That would be my laymen question, too. How does it improve pre-existing 7800 games? And obviously, how difficult to install? Will keep reading though. *If* the implementation is XBoard compatible, then it should improve sound on that game, and also on the Froggie demo.

The RAM/Pokey functions make it similar to what the XBoard does, so some compatibility with that would be useful. Will it interface at the same addresses as the XBoard, and provide some easy way to detect the ram size (16kb instead of 128kb)? Detecting ram size probably isn't a big deal though - you could just try storing different values in each XBoard bank and determine that the extra banks don't work. I know a lot of people might not care about the XBoard and consider it "dead", but it does exist, a couple homebrew games support it, and if these devices perform similar functions there's no need for them to have incompatible interfaces.

It's probably 2 separate logical rows of 8-bit chips (32Mx8) - only 8 chips would be active at the same time. I think the JEDEC standard is no more than 9 chips in a row unless it's registered memory. You may notice when the BIOS is booting it will detect 2 rows of memory for that one module. Some disreputable memory violates that by using 4-bit chips, but any major brand won't build DIMMs that way (again, unless it's a registered type).

I don't know about the really old DRAM, but they definitely have powers of 2 on modern computer SDRAM. For example, you can get a 256MB module with: 8x 32MB chips 16x 16MB chips 32 (normally 36 for ECC) 8MB chips The last option is only JEDEC legal if it's buffered memory, so you don't normally see it with consumer RAM. I vaguely remember a college instructor explaining that powers of 4 are more convenient, but I don't remember what the reason was.

Given that the Maria can now run full time, in practical gameplay the RAM speed might not be any loss compared to the shared bus. But I don't know exactly how much slower the DRAM would be. Meanwhile you gain usable CPU cycles. Presumably you'd only upload graphics to the Maria at convenient times, like in between screens or levels. One issue with dedicated Maria RAM is they'd need to revise the "holey DMA" concept. The existing scheme would put major limitations on half the RAM. With shared memory you can just use it for something else instead of graphics. For whatever reason, SRAM only comes in multiples of 4: 2KB, 8KB, 32KB etc. That's also why Wint/Summer Games carts have a 32KB SRAM in them, even though only 16KB is addressable. I'd be curious about the quantity price of an 8KB SRAM vs a pair of 2KB in 1983/84. With shared memory, I think a larger DRAM would be good for the 6502's benefit with more complex games, but it wouldn't do the Maria any good. With shared access to the ROM, the Maria only needs RAM for display structures but not the graphics themselves. The slower memory would reduce the number of objects it could render, making detailed backgrounds more difficult.

I've heard lots of talk before about RGB on the Genesis, but what do people hook it up to? I've never seen a TV with RGB inputs. I know there's adapters for RGB -> Component, but they're expensive. Is that what people are doing? I suppose you could adapt it to a VGA monitor, but you can't use that for anything else, just your modded Genesis.

What were the timing limitations for simple multiplexer-based logic in those days? Would it have been practical to interleave CPU accesses and display accesses on the cartridge bus without needing double-speed memory, if the code and display data were fetched from different memory arrays? For example, assume the CPU is running at 2MHz and there is a 12MHz clock. At step 0, drive phi0 to the CPU and start driving the CPU address to the chip. The data bus will hold the last byte of CPU data. At step 1, have the chip latch the address, and start outputting the LSB of the last requested byte of display data. At step 2, drive a new display address to the chip. At the end of this step, latch the data bus into the display controller. At step 3, hold the address. Have the chip start outputting the MSB of the last requested byte of display data. At step 4, hold the address. At the end of this step, latch the data bus into the display controller. At step 5, hold the address. Have the chip start outputting the requested CPU byte. The CPU memory will have a valid address by the end of step 1, and will have until the end of step 4 to supply data, so it would have at least a full half cycle (it would likely have the address sooner, and could likely supply the data later). The display memories (MSB/LSB) would have even longer to supply their data. If one were using off-the-shelf parts in the cartridge, one would have to use three separate ROM chips plus some glue logic. Integrating the three ROMs into one chip, however, shouldn't be a problem. OTOH, using a separate bus wouldn't be evil either. A "chevron-shaped" cartridge slot would have allowed 7800 cartridges to have many more pins while still having 2600 carts fit nicely. You know much more about hardware than I do. It sounds like carts described above might be significantly more expensive than a single standard ROM, but still it's more future-proof than being limited to a fixed amount of display RAM in the console. And I imagine a custom integrated chip might make it cheaper if they do enough volume.

I think activating 2 button mode and reading "C" on a Genesis pad should be safe. Based on the schematic I found online, it looks like pin 9 is held high through a pullup resistor, and shorts to pin 8 when C is pressed. I don't think that's dangerous, unless I'm wrong. However, button "B" could be dangerous in the wrong mode. It has the same problem as the 2600 controller, as it can short the +5v from Q8 to ground. I'm curious if it would be safe as long as the console only switches to 2-button mode for a short moment while reading "C", then switches back again. It would stay in 1-button mode except for maybe <10 CPU cycles per frame. It would be cool if future games could use this technique to read 2 buttons from an unmodified Genesis (maybe also SMS) pad.

I'd feel better about it if the homebrew developers in question (PacManPlus in this case) announce that they have an agreement and aren't getting ripped off. Otherwise I'm just trusting the word of 3rd parties.

I accidentally discovered something interesting happens if you try to read a Genesis controller in 2 button mode. I was using a 6-button pad, didn't try a 3-button. In the 2-button mode, the 2600 button always reads hi (inactive) as expected, but the other buttons also both stay high (which for those is the active state). Pressing "C" causes the left button to release (go low). In 1 button mode button "B" works normally as the 2600 button. So you could actually switch between the 2 modes each frame and support both "B" and "C" on an unmodded Genesis pad. I don't know if using the 2-button mode with that controller is safe though. When I tried this on my console no smoke came out, but I didn't do it very long.

Actually, if we're putting the Maria on a separate bus then giving it 16KB is more useful than I realized earlier. I was thinking in terms of the shared bus that it uses now, in which case a few KB of RAM is enough (for displaylist structures but not for the graphics themselves, which normally go in ROM, except for Gorf ). But I didn't properly think through the implications of a separate bus. If Maria is on a separate bus, then it needs access to graphics without interrupting the 6502. There's 2 solutions for that: A) Give Maria small SRAM and put dual buses on the cart slot, like the NES. This means 2 ROMs in every game, bigger cart PCB, and new cart shells. Games would cost more to manufacture. Compatibility with 2600 carts would be more awkward due to the size difference. B) Keep the carts the same, but have the 6502 upload graphics into the Maria's dedicated RAM. In this case, you'd want lots of DRAM. For solution B, if you do put DRAM refresh circuitry in the Maria, perhaps it could also refresh the 6502 RAM, allowing DRAM for that part as well. That site seems to just be talking about the standard members of the 6502 family, not the customized version like Atari used. But I just looked at the Commodore "6500 microprocessors" datasheet and it agrees with A,B,C being used as speed designations like shown at that site. Apparently, the name chosen for Atari's customized "6502C" conflicts with one of the standard part numbers. But I'm pretty sure Atari's 6502C is a 2MHz rated version, not 4MHz. Perhaps it was named before the 4MHz version existed?