Kids, just say No to bilinear filtering

Monday, 11th December 2006

ristar_1.gif

The old layout of the emulator was a bit of a mess.

The Z80 emulator needed to sit inside a class of your design that inherited from IHardwareController (and so exposed methods to handle hardware devices) and another that inherited from IMemoryDevice that exposed methods that could be used to read and write to memory.

As you might imagine, this got a little messy what with the various nested classes needing to pass references to eachother around. The new design is much more straightforwards - you build a class that inherits from Z80A (which is the basic Z80 emulator) and override the four functions for reading from/writing to memory addresses/hardware ports.

ristar_2.gif

Further to that, the Master System emulator itself has been shunted out to its own class library, meaning that the code isn't mixed up with interface code. This way I can easily have two different front-ends - an MDI Windows GUI for example, like the one I've posted screenshots of before, with debugging tools and so on, and an XNA interface that runs full-screen, taking input from a connected joypad.

alex_kidd.gif

For the moment I have the blurry and slow solution which is just to dump the output Bitmap onto a form. You can probably guess as much from the pathetic framerates reported on the above screenshots.

alien_syndrome.gif

Overall compatibility is still increasing slowly. Some programs that used to work now don't, of course. It goes both ways.

The VDP emulation has been significantly rewritten. A lot of the main scanline rasteriser is still the same as it was, though, but slight fixes have been made there (including picking the correct backdrop colour - an x & 0xF + y versus (x & 0xF) + y bug - and sorting out the second column) but I still have a lot of interrupt-related bugs to iron out.

tails_adventure.gif garfield.gif superman.gif greendog.gif dragon_crystal.gif

Just as a test, I cobbled together an 'alternative' interface that uses that console code I posted here a while back.

pinball.gif vfa.gif faceball.gif

It's a sad thing that the above runs at a decent framerate, whereas the graphical versions run at half the rate of they should. At least, that is running in Debug mode within the IDE...

sonic.gif james_pond.gif

Checking the Release build would always be a better plan. That's still lousy performance in my book, though.


Having written the above, I decided to look at the official Game Gear documents once again, and reread the section on ROM banking. I had not realised that for 1MBit cartridges, area 0 and area 1 ($0000..$3FFF and $4000..$7FFF respectively) were fixed, and only area 2 ($8000..$BFFF) could be changed.

Fixing areas 0 and 1 fixed a number of the smaller games:

zillion.gif fantasy_zone_3.gif ghost_house.gif alex_kidd_mir_1.gif alex_kidd_mir_2.gif fantasy_zone_1_1.gif fantasy_zone_1_2.gif wonder_boy.gif
monaco_gp.gif aerial_assault.gif pengo.gif woody_pop.gif

It turns out that if I resize the window so the display is at 1:1 pixel scaling, I get ~73FPS on my machine and - most importantly - only 3% CPU usage. If I make the window even twice as large as it was, it drops to about 30FPS and 100% CPU usage. DirectX beckons...

FirstPreviousNextLast RSSSearchBrowse by dateIndexTags