March 11, 2010
MAMEdev Main Page
MAME 0.137
Believe it or not, the first official MAME release of 2010 is finally available, so head on over to the Latest Release page and grab yourself a copy!
Believe it or not, the first official MAME release of 2010 is finally available, so head on over to the Latest Release page and grab yourself a copy!



Posted by Tom (noreply@blogger.com) at March 10, 2010 05:59 PM
Read the instructions here. Get the endings.zip utility here (updated!).
For 0.136u4 you do NOT need the separate PowerPC patch that was formerly here.
MAME 0.136u4 is now available on the MAME Updates page. Next release will be 0.137.
Incremental progress on Namco System 23 and friends continues. Got Rapid River to drop into attract mode, with these 2D graphics (and music and sound f/x): In other news, I found the coin input on Time Crisis 2 and was able to start a game, although without the 3D there’s not much there.




Currently looking (again) at the Multi Amenity Cassette System, a Japanese Arcade System developed by I’Max in 1995. First off, I’ve removed the existing hacks in the driver and implemented BIOS support and basic BIOS/cart ROM bankswitch.
First effect of this is improved logic in Kisekae Mahjong, that boots, runs some attract mode and it’s playable until it resets in the middle of the gameplay (still investigating on it):




Posted by Tom (noreply@blogger.com) at February 16, 2010 05:36 PM
Team Europe and the Dumping Union proudly presents … Uncle Poo, an obscure 1983 game from the even more obscure Diatec, possibly a bootleg/hack of something else obscure that we don’t know jack about it either. Me and Haze worked on the driver for this, it currently works apart from sound and a bunch of minor bits. I also don’t know why the title screen colors looks so awkward, but I don’t see anything weird from the ROM-to-videoram transfer so I don’t know if it’s the correct behaviour or not…
As you can see, game is a maze game with scrolling (from left to right), on which you have to collect money/diamonds in order to advance to the next level. Your main attack is a … er, a fart (yeah, not joking here, check last snap), it’s used for breaking objects and kill enemies. There is also another button, the character puts blades on his feet and moves faster, but it costs a lot of “power points” (also used by the farting).
I think it’s not a bad game per-se, it’s at least original in game design (for a 1983 game, obviously). If it rings a bell to anybody about what it could truly be let us know, thanks.
supponendo che la memory map del hd63484 (grazie a dox e alle sue note nel driver sigmab52) sia: 00000-3ffff = RAM
40000-7ffff = ROM
80000-bffff = unused
c0000-fffff = unused
tramite accesso alla videoram si vedono queste schermate:
Posted by Knarfian (noreply@blogger.com) at February 07, 2010 03:43 AM
Here's another game running on astrocorp.c hardware (see also part 1). It's called Skill Drop Georgia:
Apart from having double the resolution, it uses the hardware in a slightly different way than Show Hand, revealing several features of the sprite chip that were either unemulated or incorrectly implemented. Namely wrap around, negative coordinates, end of sprite list and the need for a frame buffer.
Thanks to Smitdogg, Brian Troha and The Dumping Union
With the redumped ROMs from Japump / Dumping Union, and a few tweaks the the driver Versus Net Soccer is looking a lot better.
There are still some 1 frame sprite glitches (like the other GX Type 4 games), and a problem with the background layer not wrapping properly (see the crowd, Rushing Heroes suffers from the same issue), bad sound (the sound rom is still bad), and the only the left screen working properly, but it’s basically fully playable for the first time, as can be seen below.























R.Belmont recently made a post about upcoming changes in MAME 0.136u1. The 0.136u1 update of MAME will be a major update for several reasons, not only will it be the first ever version to be compiled as C++ code (although the vast majority of the project is still written in C) it will also be the first version where the cross-platform SDLMame becomes an official target alongside the standard windows compile.
That’s not the only unification that’s going on at the moment however. As followers of this site may have noticed, I’ve always prefered the MAME style ’software lists’ over the open-ended approach taken by MESS with regards to loading software hence the creation of side-projects such as HazeMD and TinyCDI which serve to document both the hardware AND the software released on a platform. Changes are underway in MESS right not to bring that concept to MESS alongside the existing open-ended loading (for homebrew etc.)
This will bring MESS much closer inline with MAME’s level of documentation and policies, properly documenting what software was available for each system. The MAME / MESS database format provides a more comprehensive way to document cartridges than the existing databases which are available, and will allow proper cart dumps, with proper rom naming to be supported just as easily as in MESS. It will also inherit the parent/clone relationship system from MAME, and have fields for Manufacturer, and Year information, just as can be found in MAME.
Hopefully with changes like this MESS can become the ultimate database for Console informaiton, much as MAME has become for Arcade systems. The current databases are limited, and despite their intentions are unable to properly document some details about the cartdiges (such as the actual ROM labels, # of roms, sizes etc.) so assuming MESS can get some traction in this area it is more than capable of becoming a far better reference than those already out there. This is something I’ve wanted to see for a long time because while the existing console ROM formats are great if you just want to play games in any given emulator they fail to actual document things the way MAME does. As the games become older starts to become more of a priority, and isn’t something you can rely on the various rereleases on modern platforms because those are simply about playing the games, so it’s important for other people to document it. There are other advantages to the MESS / MAME database too, for example, the development team make no claims of ownership over the database, once exported from the executable you’re free (and even encouraged) to use / import the information for use in your own emulator, so that things can be consistently and correctly supported.
This should also lead to it being possible to create sites like The fantastic MAWS from the MESS database, and also easier set-name based bugtracking and regression testing as is used on Mametesters. It’s a large undertaking, but as long as people can get behind the idea, and support it then it could be of great benefit to everybody who cares about the history of Computer / Console software, and the emulation of these systems.
This could well be the start of a unified database system for Computers / Consoles, and the first step in the Console emulation scene growing up to be something that’s more than just about ‘playing the games’. Here’s hoping.
una volta decrittati la maggior parte degli opcode ecco il primo risultato (un grazie a kale per la routine di tracciamento e per il consiglio sugli interrupt)

Small site update. I just implemented Permalinks. Posts can now be individually linked, their URLs don't change over year boundaries, and they're more search-engines friendly. You can get the permanent links from the titles of the posts or from the menu on the right.
It’s been a while since I’ve emulated a game with the new system 573 protection, so it took me a little longer to get back into it.
Unlike the digital DDR games this is playable.

There are a few more in the pipeline, but they’ll have to wait a little while. This had problems booting, because of some known issues with the playstation emulation.
I need to verify the changes are correct, but it should help with some other games that I’ve had problems with in the past.

It’s Fisherman’s Bait 2 - A Bass Challenge, but in a different language.
Its been a while since I did any major updates to the peplus driver, but recently I decided to tackle a hardware add-on for the machine.


Posted by Stolistic (noreply@blogger.com) at January 09, 2009 12:50 AM
All controls that inherit from ListControl (BulletedList, CheckBoxList, DropDownList, ListBox and RadioButtonList) have some annoying behavior in common:
You can only bind the control to a single property using the DataTextField property. For example, if you have a Customer class with properties Id, Name, Surname, etc and you want to show the full name of a customer in any of the ListControls, you have several options:
The truth is that I don’t like any of those options, all of them are hacks.
For nested properties you have the similar problems. You can bind to Id or Name, but you can’t bind to Address.City or Address.Zip.
Today I faced this problem again and I decided to investigate a more innovative solution. The problem itself is in the controls that inherit from ListControl that are very strict in the binding options. So I took a look of how the controls perform the binding to see if I could do anything to overcome those limitations. At first sight I thought I was loosing my time but after a deeper study I found that it was amazingly easy to fix those problems in a very sleek way.
The data binding of the controls is performed in the PerformDataBinding method. The code at ListControl.PerformDataBinding uses DataBinder.GetPropertyValue to retrieve the value to show in the control if you set the DataTextField property. However, DataBinder.GetPropertyValue doesn’t handle nested properties. DataBinder.Eval is a better choice because it does handle nested properties. So using it we solve one problem. The other problem can be solved easily as well. As we have two properties that control how the Text of each ListItem will be extracted and shown from the data source, with a bit more of effort we can handle the new functionality. I have come up with a very intuitive solution:
The code that performs the data binding is:
As we need to call this data binding code instead of the one from ListControl I needed to subclass all controls that inherit from ListControl in order to fix them. So now I have BulletedListEx, CheckBoxListEx, DropDownListEx, ListBoxEx and RadioButtonListEx.
I have created a simple example showing how to use them. Imagine that an Item can be supplied by a set of suppliers, and each supplier sells the item with a different price. The following image shows the properties of the 3 entities of the sample:
I have created a web page with a DropDownList with some items, and when you select an item in the DropDownList you will see a ListBox with the all suppliers of that item with the associated price for the item. Notice how I show the Id and the Name in the DropDownList and how I show the price, supplier Id and supplier name in the ListBox:
The ASPX of the page follows:
As you can see, the solution is really clean and elegant, and backward compatible with the current controls that inherit from ListControl.
That’s all for now,
Merry christmas!
ListControlsEx_bin.zip (6.53 KB)
ListControlsEx_sample.zip (33.75 KB)Posted by Your DisplayName here! at December 22, 2008 11:35 PM
17 15 15 17 15 17 17 15 15 17 17 15 17 15 15 17
115163 134440 134684 123578 124325 119368 129136 138039 131465 123863 124014 134368 114033 128910 138950 132739
138511 116005 117079 133371 120561 137598 132515 113767 121234 142936 135015 120354 139340 123419 117903 137467
97696 155678 150638 107566 144235 105896 104535 149136 147566 109552 104031 153598 100741 153822 148116 114269
106225 149014 147978 108136 148715 110697 103607 151184 149013 112404 104923 149873 106272 145600 145167 108267
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,},
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,},
{16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,},
{0,0,0,0,0,0,0,0,8,0,0,0,4,0,2,1,},
{0,8,0,0,0,0,0,0,0,4,0,0,0,2,0,1,},
{0,8,0,0,0,0,0,0,0,4,0,0,0,2,2,1,},
{0,0,8,4,0,0,0,0,0,0,0,2,0,0,0,1,},
{0,0,0,4,0,0,0,0,0,0,4,2,4,0,2,1,},
{0,0,8,4,0,0,0,0,0,0,0,2,0,2,0,1,},
{0,0,0,4,0,0,0,0,0,0,4,2,0,2,2,1,},
{0,0,0,0,8,0,4,2,0,0,0,0,0,0,0,1,},
{0,0,0,0,0,0,0,2,8,0,0,0,4,0,2,1,},
{0,0,0,0,0,4,4,2,0,4,0,0,0,2,0,1,},
{0,0,0,0,0,4,0,2,0,4,0,0,0,2,2,1,},
{0,0,0,0,8,0,4,2,0,0,0,2,0,0,0,1,},
{0,0,0,0,0,0,0,2,0,0,4,2,4,0,2,1,},
{0,0,0,0,0,4,4,2,0,0,0,2,0,2,0,1,},
{0,0,0,0,0,4,0,2,0,0,4,2,0,2,2,1,},

Posted by Andreas Naive (noreply@blogger.com) at December 09, 2008 07:58 PM

Posted by Andreas Naive (noreply@blogger.com) at December 09, 2008 07:58 PM
One of the greatest problems when trying to optimize an ASP.NET page to be more search engine friendly is the view state hidden field. Most search engines give more score to the content of the firsts thousands of bytes of the document so if your first 2 KB are view state junk your pages are penalized. So the goal here is to move the view state data as down as possible.
I have seen some approaches to solve this problem rewriting the final HTML code of the response. While this approach works I think that it wastes some precious processor cycles that can be used to do other things. So I needed a way to do the same thing without wasting that CPU time. After some large reflector sessions I found a way to do it. My method uses the ASP.NET Control Adapter Architecture.
A control adapter is a class that can be used to control the HTML generated by the control it adapts. Since the Page class is the responsible of rendering the view state hidden field (Page.BeginFormRender calls Page.RenderViewStateFields), an adapter for the Page is needed. However, the view state hidden field plays a key role in the ASP.NET infrastructure (for example, the Page.IsPostBack property checks if the view state hidden field has been posted) and it is difficult to modify the associated HTML.
A PageAdapter has a method called GetStatePersister() that returns an object that inherits from PageStatePersister. The PageStatePersister is called when it is time to load and save the view state. There are 2 classes that inherit from PageStatePersister: HiddenFieldPageStatePersister and SessionPageStatePersister. The first one is the default, which stores the view state in the hidden field called __VIEWSTATE. The second one stores the view state in the session. So, we can easily create a custom PageStatePersister to control the view state load and save process. The big problem is how to create the hidden view state field before the closing form tag while being a fully transparent solution. After some tries I came up with a solution that I was happy with.
I realized that it was impossible to completely remove the view state hidden field from the top of the page, because it plays a key role in the ASP.NET infrastructure. However, with any custom page state persister the ASP.NET infrastructure renders at least an empty view state hidden field of only 70 bytes:
My page adapter adds a hidden field to the bottom of the form called __SEOVIEWSTATE with the actual view state data, and the only limitation that it has it is that you can not use <% %>expressions directly inside the asp.net form. However, this restriction can be easily avoided putting the <% %>expression in a PlaceHolder control or inside another control. For an in-depth explanation of this limitation take a look here.
Let’s see an example of the adapter in action. The following ASP.NET page:
With the associated code:
after a couple of postbacks, without using the adapter, the HTML looks like this:
and after a couple of postbacks, using the adapter, the HTML looks like this:
In order to use the adapter, you have to add a reference to the assembly and add a file called SEOViewStateAdapter.browser (the name of the file does not matter. The extension needs to be the same. Or also you could merge the contents to another file if you already have one) to the App_Browsers folder. The content of the file should be:
That’s all. Enjoy!
SEOViewState.zip (29.67 KB)Posted by Your DisplayName here! at December 04, 2008 07:26 PM
Posted by Knarfian (noreply@blogger.com) at August 14, 2008 07:28 PM
Posted by Stolistic (noreply@blogger.com) at June 12, 2008 01:30 AM
Posted by Nicola Salmoria (noreply@blogger.com) at February 17, 2007 12:39 PM
Posted by Nicola Salmoria (noreply@blogger.com) at February 17, 2007 10:33 AM