For hardware talk only (please avoid ROM dumper stuff)
I will suggest that any and all enhancements should be gated behind an "enable" register, lest you break any existing software. Case in point - the Commodore 128. As with the SMS/Genesis relationship, the C128 contains a C64 in hardware, but also has some enhancements in C128 mode. However, some of the enhancements were also available in C64 mode (2MHz 8502 speed, most notably). 99% of software isn't affected by this, but there are a few things that were sloppily coded and when setting up the VIC-II, would write past the last register. On a C64, these extra writes did nothing, but on a C128, they tripped the 2MHz flag, which fouls the screen display (since the 8502 and VIC-II access memory on opposite phases of the clock, 2MHz mode prevents the VIC-II from being able to fetch graphics data, instead receiving the value currently on the bus). In C128 mode, the BASIC command to switch into 2MHz mode ("FAST") would also disable the VIC-II screen, generating purely border color instead. We don't want this happening with this implementation of the Genesis architecture, so if using the features requires setting a specific flag explicitly, you have much less chance of it affecting any existing hardware (commercial, homebrew, hacky pirate originals, etc). The problem there is "merely" finding a location for this flag that we can be reasonably sure won't be tripped inadvertently. Maybe you could overload $A14000, and require the programmer to write something like "MD++" or something like that to enable the new features?
- Very interested
- Posts: 2388
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
Some sort of enable feature would be good to have. Perhaps like what Everdrive cart does, i.e to enable features Everdrive allows you need to have "SEGA EVERDRIVE" in the header.
While that would be safer, I doubt it's really needed for something like the Genesis. All the software, other than homebrew, is already done. Homebrew would be more likely to take advantage of extra features if they were easier to use.Jorge Nuno wrote:Instead of using just one magic address for extra-features enabling, you could use a method like flash memories use: they need a series of commands to be provided in the correct order for erasure operations.
Any chance of someone cloning the VDP to make a pin for pin drop in replacement with enhanced features. Ex: Separate Color RAM for Sprites and Scroll Planes, or even 3 sets of 64 Color RAM entries with one for each of Sprites, Scroll A, and Scroll B. It would be amazing to see that assuming you could clone the VDP's operation otherwise so it would just be a pure enhancement but still backwards compatible.
It's easy. That and overclocking the Z80 would be two of the better enhanced features, and aren't that hard to do in the FPGA. Much harder than on a real MD.eighty5cacao wrote:Is it technically possible to have overclocking of the 68000 as one of the enhanced features?
(I'm guessing that the answer is no, given technical limitations of how clock signals can be derived within the FPGA, but I'm not the expert...)
As to the previous question about a drop in VDP replacement, you'd probably have to make a module unless you could locate an FPGA that has the exact same physical dimensions AND has all the programmable IOs and power pins in just the right places (not very likely).