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!

March 11, 2010 08:00 PM

March 10, 2010

Tomasz Slanina (Dox)

25 light-years away from home - Vega, part 2

The good news - i have got scans of vega schematics (big thanks to Kold666)
The bad news - hardware is quite old (early 80s .. possibly 1982 or 1983) (read: unique and complicated) and schems are buggy as hell.

The biggest problem so far - no reference images/screenshots/flyer pics. Nothing. I have no f***ing idea about the real game.

So any info will be greatly appreciated.

Schems are as mysterious as the pcb pics i got - no info about the major ICs.
But looking at pinout i have identifed all of them as:

- i8035 (mcu)
- AY 3-8910 (sound)
- PPI 8255 (i/o)
- INS 8154 (i/o + ram)
- DP 8350 (crt controller)

AY is used only for generating sfx. Afaik there's no music. Sound chip is connected in unusual way - AY data lines are tied to address bus and AY address/data write selection is connected to mcu R/W line. So, writing any data to address NNN within range mapped to AY - results in setting AY address register to value NNN. Reading from address MMM store MMM in AY data register. Weird, isn't ?

Graphics hardware consist of four different "blocks":

- text layer - 1bpp fonts with hardcoded (PROM) color for each character. Bullets and some type of enemies are made of characters on text layer.
- four "type1" sprites - simple format, 32x32 pixels, horizontal flip, direct color (1r1g1b + extra unknown bit). Used mainly for enemies (spaseships)
- single "type2" sprite , used for player's ship/explosion only- 32x64 object made of 32x4 slices.
- single (?) "type3" sprite - not emulated yet. Quite big (possibly 64x64) obejcts (planets, asteroids) with special 2kb lookup table.

So far, the most complicated to emulate was the type 2 player sprite. It's auto-animated (based on vblank counter). There's also a 256x4 PROM used as a lookup table , connected in a bit weird way :



Here's some (test/temporary) formula i'm using to draw the sprite:



And now few fresh screenshots. Sprite positions (type1 and type2 (last pic)) and colors may be wrong:

Posted by Tom (noreply@blogger.com) at March 10, 2010 05:59 PM

March 07, 2010

R. Belmont

How to build SDLMAME 0.136u1 and later

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.

Posted by site admin at March 07, 2010 03:45 AM

March 04, 2010

MAMEdev Main Page

MAME 0.136u4

MAME 0.136u4 is now available on the MAME Updates page. Next release will be 0.137.

March 04, 2010 08:00 PM

R. Belmont

White water

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.

Posted by site admin at March 04, 2010 04:30 AM

March 01, 2010

Angelo Salese (Kale)

Me, you and a whole bunch of Dolls

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 Kale at March 01, 2010 03:02 PM

February 16, 2010

Tomasz Slanina (Dox)

Vega

Tym razem na warsztacie VEGA (włoskiej produkcji - Olympia). Początki są obiecujące - na razie działa tylko Text Layer (prawdopodobnie na kontrolerze crt DP8350). Całością steruje CPU Intel 8035.
Reszta hardware nieznana (na jednym z niewielu dostępnych zdjęć PCB większość istotnych IC ma starte oznaczenia ):



Kilka wstępnych screenów:

Posted by Tom (noreply@blogger.com) at February 16, 2010 05:36 PM

February 14, 2010

Angelo Salese (Kale)

I love your sexy talk, it’s so kindergarten, “Poo poo”, “Wee wee”.

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.

Posted by Kale at February 14, 2010 09:15 PM

February 07, 2010

Robiza

adp driver

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 Robiza at February 07, 2010 07:12 PM

Frank Palazzolo

Math problem #1 - piecewise approximating functions

I'm the kind of person that can get very interested in things that others might not notice. For me, his seems to occur from time to time with math problems. I'll be thinking about an engineering problem, and I will get caught up with some mathematical aspect of it. Usually, it's some problem which is easy to state but not obvious to solve. (Then again, I'm not a mathematician)

Over the years, I've gathered up a list of these problems. And now, I'd like to share some of them on this blog. I hope some of you, at least, will find them as interesting as I do.

---

Today's problem is fairly simple to state - and I thought about it for the first time many years ago. Suppose I have a continuous function y=f(x), defined on an interval from x0 to xn. I know _everything_ there is to know about the function. Now, for some reason, I need to approximate the function using a "piecewise-linear" function. This is just a set of straight lines connected together at "break" points. (You can also think of this as an approximation based on splines.)

For say, a fixed number of break points, what is the "best" way to approximate the function? (BTW - this is something that is practically done all the time, in embedded computer programs, using "table lookups" to approximate functions)

Some clues:

For a given set of breakpoints located at each x_i, you can start by picking the breakpoints at (x_i, f(x_i)). In other words, points on the curve f(x), and connecting the points with straight lines. However, you will quickly notice that the approximation is biased, based on the concavity of the curve.

A better way for a given set of points at x_i, is to solve the linear least-squares problem to find the optimal y values, which minimize the error between the approximate curve and the actual one.

But the key question seems to be - how do I locate my points in x? I see no easy way to do this, without non-linear iteration. It seems strange that it is trivial to locate the points in Y given X values, but hard to locate the X values. I can imagine some heuristic rules like "I should use more breakpoints where the function is 'curvier'". But it's not at all clear what this means :) Maybe I need to think about the meaning of "best" a bit more.

So, to summarize, we have a situation where we have a function which we know everything about, and a simple space of approximating functions, but we seem unable to match the two together, without resorting to nonlinear iteration.

If this one is too easy for you, feel free to handle extensions to this problem with higher order piecewise splines, and/or multidimensional functions. :) I can imagine practical applications for a good algorithm in this area.

Posted by Knarfian (noreply@blogger.com) at February 07, 2010 03:43 AM

January 30, 2010

Luca Elia

Astro Corp. (part 2)

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

January 30, 2010 11:00 PM

January 18, 2010

David Haywood ([Haze])

Back of the Net

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.

Posted by Haze at January 18, 2010 09:01 PM

January 11, 2010

David Haywood ([Haze])

Unification pt.2

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.

Posted by Haze at January 11, 2010 12:10 AM

January 03, 2010

Robiza

cb2001: qualche progresso

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)

Posted by Robiza at January 03, 2010 04:30 PM

January 02, 2010

Luca Elia

Permalinks

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.

January 02, 2010 11:00 PM

July 04, 2009

smf

Rotten to the core

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.

Posted by smf at July 04, 2009 10:52 AM

June 27, 2009

smf

Fishing in Japan

It’s Fisherman’s Bait 2 - A Bass Challenge, but in a different language.

Posted by smf at June 27, 2009 12:33 PM

January 09, 2009

Stolistic

Wingboard Support

Posted by Stolistic (noreply@blogger.com) at January 09, 2009 12:50 AM

December 22, 2008

Manuel Abadia

Binding a DropDownList to multiple properties and to nested properties

<body xmlns="http://www.w3.org/1999/xhtml">

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:

1. When you get the data from the database, return another column with the name and surname.
2. Create a property (f.e. FullName) that returns what you want to show.
3. Use a DataSet and add a computed column.
4. Manually add ListItems with the appropriate values performing the data bind manually.
5. Create a simple class that will be bound (instead of the original one) just to fix the problem.

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:

• DataTextField allows one or more properties (that can be nested if needed) separated by commas.
• DataTextFormatString can be used to control the formatting of the items, using {0}, {1}, {2}, {3}… as the value of the properties specified with DataTextField.

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) </body>

Posted by Your DisplayName here! at December 22, 2008 11:35 PM

December 09, 2008

Andreas Naive

CPS-3 (5)

Resumiré algunas pruebas realizadas durante los últimos días:

Durante una charla informal con Haze, hablando de las zonas de memoria que están asignadas a la BIOS y a las ROMs 10 y 20, se me ocurrió cómo comprobar cuál era el primer bit que cambiaba en la dirección de comienzo de la BIOS y la ROM 10 (ya sabíamos que, aparentemente, en sfiii2, la BIOS está asignada a la dirección 0 y la ROM 10 a la dirección 0x06000000): si encontraba dos zonas en blanco en la BIOS y la ROM 10 que ocupasen la misma posición con respecto al inicio de la correspondiente ROM, podría inferirse algo de información sobre la diferencia entre las direcciones a las que están asignadas simplemente mirando qué bits coincidían (pues sabemos que f#4 muestra ciclos puros de periodo 2^19 máscaras, f#5 de periodo 20, y así...).

Las zonas «en blanco» escasean en la BIOS (parece que ahí tuvieron mayor cuidado en no dejar «pistas»), pero finalmente fui capaz de encontrar dos tales zonas correspondientes en Warzard y en Sfiii (de 15 y 9 máscaras, respectivamente); se podía ver que, al comparar la BIOS con la ROM 10, en ambos casos los bits f#4, f#5, f#6, f#7 y f#8 eran idénticos, pero f#9 no. Ello indicaba que la diferencia de las direcciones de asignación de la ROM 10 y de la BIOS es un múltiplo impar de 0x02000000 (lo que es compatible con la hipótesis de que están ligadas a las direcciones 0 y 0x06000000 como en sfiii2, pero no la prueba).

ElSemi llamó mi atención sobre la tabla de 256 bytes situada al final de la BIOS; tras un análsis de un par de tablas, resulta claro que: 1º) la tabla se ha generado usando algún tipo de algoritmo que funciona a nivel de octetos, pues el bit #1 de cada octeto muestra regularidades estadísticas significativas cuando se observa la tabla completa (en Jojo, de hecho, ese bit es siempre 0); 2º) por consiguiente, no es razonable suponer que esa tabla esté encriptada, sino que se trata de datos sin encriptar.

Una hipótesis tentadora es considerar que se trata de una tabla de subclaves indexada de alguna manera; sin embargo, no disponemos por el momento de ningún argumento sólido a favor o en contra de esta hipótesis, por lo que no insistiré en ello por ahora. En todo caso, si así fuese y estuviese siendo indexada con bits de la dirección, yo esperaría que fuese con bits de la parte baja, pues los bits altos de la dirección muestran propiedades de difusión mucho peores, lo que no me cuadraría con el hecho de que usasen diferentes entradas de una tabla.

Para tratar de validar el que una operación de tipo rotate_left(x,4) XOR (x AND ???) estuviese siendo hecha (ver CPS-3 (4)), se me ocurrió el siguiente experimento: al actuar, como operandos, una variable de 16 bits y ella misma desplazada 4 bits, se consigue que se creen cuatro clases de equivalencia en el conjunto de los 16 bits, perteneciendo a una misma clase aquellos que se afectan mutuamente por efecto del desplazamiento de 4 posiciones (de este modo, los bits #0, #4, #8 y #12 forman una clase, los bits #1, #5, #9 y #13 otra, y así con el resto). Si ahora estudiamos los números formados al juntar los cuatro bits de una misma clase, obtenemos una nueva variable x' y la operación se reduce a rotate_left(x',1) XOR (x' AND y); y aquí empieza la fiesta: si, aun sabiendo que x' e y tienen que estar necesariamente correladas, suponemos que son lo suficientemente independientes una de la otra como para que la correlación sea pequeña, cabe suponer que la distribución de valores que sigan los datos reales nos dé información sobre si ese tipo de operación está siendo usada o no. Esto es así porque, si suponemos, en la operación anterior, que x' e y son totalmente independientes, y nos hacemos una tabla tabulando las 256 posibilidades según el resultado (de 0 a 15), obtenemos la siguiente distribución:

17 15 15 17 15 17 17 15 15 17 17 15 17 15 15 17

está distribución también la tiene la operación rotate_left(x',1) XOR (x' OR y), pero no así otras posibles operaciones compatibles con lo que ya sabemos (o, al menos, yo no he sido capaz de encontrarlas)

Pues bien, al obtener las distribuciones reales para las cuatro clases de equivalencia correspondientes a JojoIm1, se obtiene lo siguiente:

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

Se puede ver que la distribución para la segunda clase de equivalencia muestra, aproximadamente, una proporcionalidad directa con la distribución de arriba, mientras que el resto de clases muestran una proporcionalidad inversa; lo mismo ocurre con JojobaIm1 y con Sfiii3Im1 (aunque, en este último caso, el cuarto grupo es directamente proporcional, y los otros tres inversamente proporcional). Este tipo de distribución es la que yo esperaría si, después de haber realizado una operación como las de arriba (rotate_left(x',1) XOR (x AND/OR y), se hubiese efectuado un XOR con un número fijo; dependiendo de la paridad de ese número, se obtendría una proporcionalidad directa o inversa.

Este experimento, de por sí, ya fue bastante interesante, pero no acabó ahí, pues, al día siguiente de haber hecho eso, tuve la feliz idea de tratar de obtener información sobre los términos x' e y haciendo uso de esa misma distribución. La idea fundamental es que el resultado de la operación te da información sobre los operandos, pues no todos los resultados se producen con la misma probabilidad; de esta forma, si uno dibuja la tabla de frecuencias que relaciona el resultado final (una fila por cada uno, de 0 a 15) con el término y que le dio origen (una columna asociada con cada uno, de 0 a 15), obtiene esto:

{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,},

y si hace los mismo relacionando el resultado con el término x', esto otro:

{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,},

La primera tabla da algo de información, pero no mucha: dado un resultado, asigna sesgos distintos a la probabilidad de un operando y únicamente en función del peso de y (número de bits puestos a 1). Ello hace que no se discrimine bien entre los valores para los bits individuales de ese término y, e imposibilita que se pueda usar con facilidad esa información para reconstruir los ciclos esperados de los bits del término y.

La segunda tabla, en cambio, tiene un aspecto excelente :D Permite discriminar las probabilidades de los bits individuales de x'; así, si cogemos un bloque de 2^19 máscaras consecutivas de JojoIm1, calculamos el sesgo a priori (usando la tabla mencionada) de que f#0 valga 0 (valores positivos indican que es más probable que valga 0 que 1; valores negativos lo contrario) y hacemos un análisis de autocorrelación, obtenemos esto:



Se observa claramente el ciclo de 2^15 máscaras que esperábamos.

Empero, si tratamos de usar esa tabla de probabilidades condicionales para calcular el valor de ese mismo bit para cada una de las 2^15 posiciones del ciclo (es de esperar que x' muestre un ciclo puro), el resultado, siendo aceptable, no es espectacular: el número de datos disponible para cada posición no es suficiente para obtener resultados incontrovertibles para cada posición. Pero la fortuna nos sonríe, porque, si observamos con más detenimiento la tabla, veremos que hay filas (correspondientes a ciertos resultados de la operación) que sólo se pueden dar para ciertos valores de los bits del operando x'; por ejemplo, si el resultado de la operación es 2 (tercera fila de la tabla), entonces necesariamente el bit #0 de x' será 1.

Esto nos permitiría recuperar los valores de algunos bits del ciclo, pero hay algo que debemos no perder de vista: dada la forma de la distribución, suponíamos que un XOR con un valor fijo estaba siendo efectuado después de la operación; cuando probé a recuperar esos bits para cada una de las máscaras XOR aceptables, otro hecho afortunado nos ayudó: al analizar los resultados, había una y sólo una máscara XOR que conseguía que en los bits del ciclo recuperados no se diesen valores idénticos separados por la mitad de tamaño del ciclo (algo que yo esperaba/deseaba, pues es una característica que es invariante ante bastantes de las operaciones que era probable encontrar antes de la que nos ocupa).

Una vez dado el salto de suponer que, efectivamente, esa característica (ser la segunda mitad exactamente como la primera pero invertida) la comparten todos los bits de x, se obtiene, por una parte, la máscara XOR aplicada después (0xd86e en el caso de JojoIm1 y JojobaIm1, y 0x54ca en el caso de Sfiii3) y, por otra, se pueden recuperar más bits de los ciclos (esta forma de obtener más bits y la anterior se retroalimentan). La escasez de máscaras disponibles no nos permite regenerar los ciclos completos, pero, al menos, obtenemos un porcentaje apreciable de algunos de ellos (los primeros bits, que muestran ciclos de longitud menor, son, por supuesto, los que pueden ser regenerados de forma más completa).

Y esto, a su vez, ha hecho surgir interesantes conclusiones:
- La parte del ciclo de tamaño 2^15 (del bit #0 de x) que se recupera encaja perfectamente con el que recuperábamos al estudiar f#5 módulo 2^15 (ver CPS-3 (3)). Esto ha supuesto una confirmación inesperada de algo que, si bien suponía, no encontraba manera de demostrar. :D
- Lo mismo ocurre con el ciclo de tamaño 2^16 pero invirtiendo los bits (lo cual es efecto de la operación XOR hecha después, por lo que no nos debe extrañar a estas alturas).
- El disponer de reconstrucciones parciales de los ciclos de los bits de x' nos permite, a su vez, estudiar y; esta es la actual línea de ataque que estoy siguiendo, pero todavía queda trabajo por hacer antes de extraer conclusiones...

Y este es el estado actual de las cosas... continuaré trabajando en esta línea, pero no será ahora. Hechos felices de la vida real (que algunos conocéis) van a alejarme de los ordenadores y de mi casa por espacio de dos o tres semanas; seguiremos con esto cuando vuelva.

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

Implementación de reglas

Últimamente no he dispuesto de demasiado tiempo libre, lo que me ha impedido trabajar en esto lo que me hubiese gustado... pero algo hemos avanzado:

• Tras muchas pruebas, creo que he fijado los modelos de las piezas; he cribado los vértices de los modelos de Morio hasta un punto en que el motor 3d pueda moverlos incluso sin aceleración hardware (en un ordenador relativamente moderno).
• La iluminación también ha sido fijada, después de haber tenido bastantes problemas al hacer pruebas (se hace uso de sombreado Gouraud, por cierto).
• Gracias a la amabilidad de Will McGugan, que me ha autorizado a utilizar su módulo python de ajedrez, me he ahorrado tener que implementar por mí mismo las reglas; puede que haya que corregir algunos errores, pero me encanta cómo está diseñado el módulo. ¡Gracias, Will! ;)
• He continuado con la implementación del protocolo de comunicación, y ya se pueden enviar los movimientos de un tablero al otro sin problemas.

Aún quedan muchas cosas por hacer, no obstante. Amén de terminar de implementar el protocolo (rendición, coronación de piezas, propuesta y aceptación de tablas, tablas reclamadas por un jugador, etc), hay que corregir algunos errores con los movimientos especiales, arreglar la selección de escaques (que, no sé debido a qué, está dando problemas), presentar las condiciones de finalización de partida al usuario, etc.

Seguimos en la brecha. ;)

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

December 04, 2008

Manuel Abadia

Search Engine Optimization - Moving View State to the bottom of the page

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

August 14, 2008

Frank Palazzolo

Yikes - more than 2 years without blogging!

Not the kind of anniversary I wanted to celebrate. Anyways, I'm in the middle of a move to a new house, and work is heating up. So, hopefully around October, things will settle down...and I will try to post something more regularly.

Posted by Knarfian (noreply@blogger.com) at August 14, 2008 07:28 PM

June 12, 2008

Stolistic

Lots of Slots

I decided to revisit the PE+ driver specifically to find out why all the video slots did not accepts coins. I assumed the slots had some special code that maybe affected the coin-in timing, but after a lot of tracing, I couldn't find any differences. Eventually, I noticed that the last page of the operator screens was blank and the Spin button was lit. Pressing the Spin button didn't seem to do anything. Using some experience I learned from the S+ slot machine, I figured this screen was used to show the reel stops. Each time you press Spin you would see the next reel stop etc.

But the screen wasn't painting the reels and seemed to be stuck in a loop. After much tracing, I finally found that the Timer 1 interrupt at 0x001b stopped firing. Without this interrupt, the game would basically sit in an endless loop waiting for the timer bit to update.

It turns out that the split timer code in the i8051 core needed a small tweak. Once the code was fixed, the reel stops showed up in the operator screen, and the game started accepting coins.

Now that I could see the slot games play properly, I found that PS0716 was not "Quarter Mania", but rather "River Gambler".

With the video slots working, I added support for 5 new romsets to the driver:

• (PS0014) Super Joker Slots


• (PS0022) Red White & Blue Slots


• (PS0043) Double Diamond Slots


• (PS0045) Red White & Blue Slots


• (PS0308) Double Jackpot Slots

Posted by Stolistic (noreply@blogger.com) at June 12, 2008 01:30 AM

February 17, 2007

Nicola Salmoria

CPS2 not much left to do

When I originally wrote the key searching program, that was on the assumption that the key for the second Feistel network was 96 bits long.

Each (E,D) pair reduces the key space by a factor of about 2¹⁶, so to isolate the correct key with good confidence one would need at least 96/16 = 6 (E,D) pairs.

The big problem is finding those pairs. Remember that they must be at compatible addresses, that is addresses whose bottom 17 bits are the same. This is a serious limitation, because the code of several games only covers a range of 0x80000 bytes, which would give a maximum of 4 pairs at any address. For the Super Puzzle Fighter 2 games, the range is just 0x40000 bytes, giving just 2 pairs per address.
One can find hundreds, even thousands of of (E,D) pairs, but if they are not at compatible addresses they are of no use to find the key using this attack.

However, now we know that the key actually has only 64 significant bits, some of which are repeated. I therefore rewrote the program to take that into account. This means that only 4 (E,D) pairs are needed to isolate the key.

Also, I made several important optimisations that I missed the first time around, like caching intermediate results and speeding up the s-boxes calculations by using precalculated tables (this last optimisation also made into MAME so the decryption when loading a game is now faster).

The end result is a program that is orders of magnitude faster than the previous one.
Now it takes just 15 seconds to find the key given 8 (E,D) pairs. With 5 pairs, which was just plain impossible before, it takes 5 minutes. With 4 pairs, 35 minutes.

These improvement made it simple to find most of the remaining keys, even for games that didn't have a matching revision already decrypted (most notably some of the Steeet Fighter Zero versions).

But there's more: the program is now fast enough to go one step further, and look for the key with just 3 pairs. Of course 3 pairs are not enough to isolate the right key: they only reduce the key space by about 2⁴⁸, therefore leaving about 2¹⁶ keys which are compatible with the data. Once a 64-bit key for the second Feistel network is selected, the compatible 64-bit master keys can then be easily generated, and used to verify other (E,D) pairs at different addresses. This allows to find the correct key in less than one day, and I had to use this extended attack for a couple of the most problematic games.

In the meantime, Andreas Naive has been busy implementing the attack he had described on his blog, and was able to find the keys for two of the Super Puzzle Fighter 2 games. Unfortunately, the attack failed on the third. Work is still in progress on that one, and there is some hope that the key will eventually be found.

The only other games that are missing a key are the two CPS2 versions of Mega Man. There is no decrypted CPS2 version of that game to compare with, and the CPS1 version seems to be too different to be able to find good pairs.

Posted by Nicola Salmoria (noreply@blogger.com) at February 17, 2007 12:39 PM

CPS2 Key Bit Order

As previously mentioned, the 64-bit keys I'm currently using should be the same as the hardware ones, except for a fixed permutation of the bits.

The permutation is actually irrelevant as far as the algorithm is concerned, since it is already taken into account when generating subkeys. The difference that it does make, however, is that there are strong suspicions that some of the keys are not random numbers, so what looks like random gibberish currently would show some order if we had the correct permutation.

Take the ssf2 versions for example. There are currently 6 different versions supported: World, USA, Asia, Japan, Tournament World, Tournament Japan. Here are the keys (in a different order):

3D9E1E15A58C32CE
3599DF35AD98284C
B74433502F4653D7
8758E3923FFA1A50
F0AE3D08420DD6BF
6260014FD857F7A7

there is something immediately obvious about those keys: they all contain exactly 32 0s and 32 1s.
When picking one random 64-bit numbers, the likelihood of this happening is about 1 in 10, so it's ok. But the likelihood of it happening for SIX numbers is about 1 in 1 million! So we can be pretty sure that those keys are not random numbers.

What is one particularly simple sequence that has exactly 32 1s? Well, of course 0123456789ABCDEF. And sure enough, after looking at the bits for a while and applying an appropriate permutation, here is what the above keys become:

0123456789ABCDEF
1032547698BADCFE
45673210CDEFAB89
67451032FEDC98BA
89ABDCEF45672301
CDEFBA9823016754

looks much better doesn't it?
Though there's no way to tell how close it is to the real thing.

Posted by Nicola Salmoria (noreply@blogger.com) at February 17, 2007 10:33 AM