SpritesMind.Net

I fixed some missing stuff (especially the status register of the VDP), and now, some commercial games work (with some display bugs).
So far, I have tried Golden Axe and Hard Drivin'.
I'll make some videos about it, this week-end probably.
Meanwhile, I'll be probably able to fix some display bugs.

Very cool stuff Torlus. I think I told you that already .

Anyways, I maybe converting this to Verilog once it gets released .

Here is a new video. Now, games I've tested so far work... but with some display issues.
http://www.youtube.com/watch?v=ilzKiW21T9Y

Looks like it's coming along rather well.

really awesome

and rick dangerous is the first working rom on this fpga \0/\0/

I released the source code and programming files.
See here : http://code.google.com/p/fpgagen/

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?

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.

Awesome news! I really need to get a DE1 or DE2 one of these days...

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.

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.

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.

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.

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...)

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...)

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.

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).