Archive for June, 2009

Autopilot is an egocentric dude

Saturday, June 27th, 2009

Me and Phil Bennett moved our efforts over Midnight Landing, the first of the Taito Landing series. The main issue was mostly the “dot writings” that are the characteristic “night drawing” of this game. After some false mis-steps (that were even close to the current status), I’ve discovered that this game uses the same DSP as his sequel Top Landing (the TMS32025) for calculating the dot data to be displayed. Dox also pointed out that the “dot” data in reality is stored in the gfx ram, so in the real world the main 68k feeds some raw data to the sub 68k then the sub 68k processes this data and gives it to the DSP. The DSP then does some math operations and gives this data to the sub 68k and finally the sub 68k converts the data to the proper format and gives it back to the main 68k. In short, it’s (unsurprisingly) an unoptimized mess.





Game has still bugs (sound cpu comunications fails sometimes, palette banking isn’t yet understood) and somebody should explain to me if there’s particular rules about how to play this one (inputs doesn’t seem to be consistant)

Greatest Hits

Tuesday, June 23rd, 2009

Last week Olivier Galibert and Wilbert Pol did some efforts in identifying the CPUs in Pachi Fever and Hit Poker. While the former uses a TMS9900 but we didn’t made any noticeable progress (HW looks awkward or there are CPU bugs, take your pick), the latter one uses a MC68HC11 (that’s used on the Taito-JC HW, some other MESS-related systems and in Deroon Dero Dero / Angel Eyes as MCU). The HC11 CPU core was in pretty bad shape (the Taito-JC really makes small use of it), so after something like 100 implemented opcodes, a bunch of bug fixes and some really basic irq system, here’s the results:




*EDIT*: Fixed 4bpp / 8bpp switches, fixes mostly the cards display:


Now it needs EEPROM emulation (that’s non-standard) and inputs to get it working…

John vs. Arnold vs…Dick? (The Dec0 Pro Tour part 3 of 3)

Monday, June 15th, 2009

And, after Pro Soccer, let’s take a quick glance about Pro Sports (Pro Tennis, Tournament Pro Golf and Pro Bowling all-in-one package). After some tweakery (and after fixed a Deco16 CPU core bug) , Pro Bowling part is working without backgrounds, Pro Tennis doesn’t have score limits (another core bug?) and Pro Golf pushes this PCB to it’s limits and currently has many gfxs artifacts…three games, completely different behaviours…


0024 0028

0030 0029

0031 0001

EDIT (18 June 2009): after some days of fierce coding, I’ve finally fixed the major flaws with this one:

0002 0004

Game now fully working except for some video issues (namely bg flipping and some sprites) and the sound that isn’t yet 100% accurate.

Andiamo a Berlino! (The Dec0 Pro Tour part 2 of 3)

Saturday, June 13th, 2009

Now that 18 Holes Pro Golf is in a much better shape (needs that somebody would like to decrypt the original version to get it fully working), I’ve moved my attention to Pro Soccer. Surprisingly, the main issue is that this one uses some sort of protection involving gfx addresses that are scrambled thanks to 1+ PAL(s). I’ve started to compare it with the Cassette version, and got some results:





As you can see from snap 4, work isn’t yet 100% complete, plus this version is not 1:1 compatible with the cassette one (some gfxs addresses are different). But for sure, this descrambling work is just more time consuming rather than requiring programming skills… 😉

EDIT: noticed that actually the game uses dynamic tiles instead of the aforementioned PAL descramble guess. Weird but possible…

EDIT2: Fixed the Goal Keeper screen, the tilemap was using a vram mirror for the banking. Game promoted to working now.


The only and one Dec0 Pro Tour (part 1 of 3)

Tuesday, June 9th, 2009

I’ve convinced myself in looking the three GNW “Dec0 Pro” games series (a.k.a. 18 Holes Pro Golf, Pro Sport and Pro Soccer). The game with the worst condition was 18 Holes Pro Golf, so I’ve started to look at it for first. It’s basically a nightmare, with a background layer and a tilemap/bitmap framebuffer hybrid mess, with “tilemap cells” that are written to the resulting screen as-is, without any tilemap hook-up for it as you might expect…





And now the bad news: it has issues with the main program (for example hazards doesn’t do anything), that might be caused by a bad rom or a slightly bad decryption (service mode returns “rom bad error 6″ as well).

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.