AEP Emulation Page reports that EightyOne, the Sinclair ZX80/ZX81 and Jupiter ACE systems emulator for Microsoft Windows, has been updated to version 0.42e. This version is a test build only, and below are the changes in this version (quoted from AEP Emulation Page).

- Preliminary TZX tape format support, still very buggy though.

- Fun feature - emulated RAM

- Pack wobble (Press Ctrl-F12 for chuntey on demand).

- New hardware, DK´Tronics Graphics ROM (Thanks to Simon Holdsworth for dumping this).

You can visit the official homepage of EightyOne here, or simply download the latest test build here.

Ipher finally got around compiling another ZSNES WIP release.

Here's what's new:

ZSNES January 5 WIP

 

WIN: Fixed video mode selecting via command line for Windows (whoever updated it last didn't change everything he was supposed to). [Nach]

SRC: Updated copyrights. [Nach]

SRC: Fixed pushes and pops for x86-64. [Nach]

SRC: Can now compile objects internally if desired. MSVC and GCC handling cleaned up a bit. (parsegen) [Nach]

SRC: Made cfgparse.o depend on PSR compiler. [Nach]

SRC: Fixed a variable which was being used improperly. [Nach]

Get it here.

* News grabbed from the ZSNES Board.

Massive Gaming League

 

Using new technology that allows for the placement of cameras within an actual videogame, DIRECTV will produce a videogame tournament and cover it as a sporting event, complete with producer, director and technical crew. Stories of the competitors will be told via interviews and features, complemented with coverage of their exploits in actual competition. DIRECTV plans to launch the Massive Gaming League in 2006.

New CPS-2 algo related discovery.

 

While playing around coding on a dead CPS-2 board I have today I found that the encryption algo is still fully in place even after the CPS-2 board has suicided. That said, on examining values the number do not match those of the expected game. This almost certainly confirms that their is only _one_ algo over all CPS-2 games with the only difference being key data (like Kabuki on CPS-1).

 

I passed some test code onto Charles MacDonald so that he can see the values he gets there on his dead SFA3 board. That should match what I see here and to be honest it looks just a formality. When you consider the watchdog on a suicide board is 0xFFFF,0xFFFF,0xFFFF (MOVE.L #$FFFFFFFF,$FFFF0000 will trigger it) it all starts to make sence.

 

There was a big debate over this going back to when we first broke past the protection. The worry voiced by some DEVs was that all boards would be needed again to get the algo for each game. This new discovery certainly confirms that once the algo is known for one game all the others can be brute forced using the XOR tables as templates.

 

As for figuring out the algo itsself whats needed now is a complete dump of tables (8gig) of the algo executing in this default state. Using this the algo should be easier to understand because any key data used for math should be 0xFFFF. I have quickly dumped a complete table for a couple of addresses and while it still looks a mess there are certinally more patterns compared to a normal game.

http://cps2shock.retrogames.com/

Update.

 

I've got word back from Charles and after some work (over irc) he has managed to get the same data I was seeing. This basically confirms what I mentioned above.

 

There were some initial problems with his transfer system (which is far superior to mine) giving different results. It turned out that at some point during the process the protected RAM was being reprogrammed!!! The exact way this is happening is not yet known but it opens up some large posibilities if the cause can be found and understood. This situation did not happen when he was dumping games that were non suicide.