Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

[Anima]

Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

At first I would like to say that I am not sure if the Atari STE will be able to have the power for a good port. Considering that the CPS1 system is clocked at 10 MHz (even worse: the ported game source code runs on a 12 MHz machine). Anyway, at least the Falcon will be definitely a good target but needs some gameplay code changes to get it running. Unfortunately they're playing with the stack frame data on certain places and this is clearly a no-go on the MC68030.

The game code has been ported using a special version of MAME in combination with a special disassembler which produce a source code which can be reassembled with vasm and reused by MAME. This was important to check if the code can be changed by adding/removing code parts. This method works for any MC68000 based games so theoretically almost anything running on that CPU can be ported "easily".

The Daimakaimura game code runs in the same address range like on the arcade machine so that (undetected, non-relocated) addresses hidden in the data area didn't break the game logic.

JagPad/PowerPad support is implemented so you can start and play the game. In fact, the gameplay is complete and "only" the sound and graphics are missing.

So let's have a look how far I can get.

[shoggoth]

Chuck Norris of code.

[EvilFranky]

Superb Anima.

[EvilFranky]

Daimakaimura (Ghouls 'n Ghosts) for the Atari STE

At first I would like to say that I am not sure if the Atari STE will be able to have the power for a good port. Considering that the CPS1 system is clocked at 10 MHz (even worse: the ported game source code runs on a 12 MHz machine). Anyway, at least the Falcon will be definitely a good target but needs some gameplay code changes to get it running. Unfortunately they're playing with the stack frame data on certain places and this is clearly a no-go on the MC68030.

Was this the reason why you gave up on the Final Fight (also a CPS1 game) Falcon port Anima? This rings a bell...

Just realised how many amazing games are running on CPS1 actually. Not all of them are candidates for ports obviously.

[Estrayk]

Great News Anima! you are the master!
I know that its very soon for requests, but I'd like make a question about the sound & music. Also will be implemented? YM2151 emulator? without sound but with audio effects? If you decided launch it for Falcon, can be used the DSP for load the original music (like a sample) meanwhile we play?

thanks for your epic work!

[MM41]

Great ☺, thanks Amina !

[CiH]

Whoo!

[AtariCrypt]

Oh boy!!!

[Anima]

Thanks!

Was this the reason why you gave up on the Final Fight (also a CPS1 game) Falcon port Anima? This rings a bell...

Yes, but also having a decompression/decryption routine at start was a problem for a straight forward disassembling of Final Fight on the X68000. That's, in fact, a good thing with a program stored in ROM: you don't have to fear self modifying code.

I know that its very soon for requests, but I'd like make a question about the sound & music. Also will be implemented? YM2151 emulator? without sound but with audio effects? If you decided launch it for Falcon, can be used the DSP for load the original music (like a sample) meanwhile we play?

It depends what is possible on the specific system. For the Falcon I have same ideas based on an optimised version of the Cho Ren Sha 68k DSP sprite engine so that I could also think of adding sound emulation. But this is something for the future.

[EvilFranky]

Was this the reason why you gave up on the Final Fight (also a CPS1 game) Falcon port Anima? This rings a bell...

Yes, but also having a decompression/decryption routine at start was a problem for a straight forward disassembling of Final Fight on the X68000. That's, in fact, a good thing with a program stored in ROM: you don't have to fear self modifying code.

Thanks for the explanation Anima

So actually the Final Fight CPS arcade board would be a better target for a conversion rather than the X68000 version, with some effort anyway. Interesting.

[Anima]

So actually the Final Fight CPS arcade board would be a better target for a conversion rather than the X68000 version, with some effort anyway. Interesting.

Yes that's correct. Well, a CPS1 "MMU emulator" for the Falcon is actually a tempting idea on the first look. At least it's a way less technically "demanding" system than the Neo Geo. Unfortunately a special MC68030 MMU approach will not work on accelerated systems.

[dlfrsilver]

Very interesting.... ok, so i guess that Strider X68000 for which i put my hands in also use the same decompression/decryption system......

Anima, do you plan to make the game code ressourced available ? Anyway that's a great idea

How much ram do the game will need on STE ? 4mb of ram ?

[Anima]

Anima, do you plan to make the game code ressourced available ? Anyway that's a great idea

How much ram do the game will need on STE ? 4mb of ram ?

I think there are two issues making the source code public. First it's still not completely relocatable and (even more important) there are legal questions about the copyright. Besides that, I'd like to share it, why not.

Regarding the memory requirement it'll need 4 MB RAM on the Atari STE for sure. The game code itself is 1 MB in size so there's not much space left for a scrolling double+background buffering. Also the sprites will take another huge chunk of RAM as well.

[leech]

This is awesome and has a lot of potential. Though if it basically uses MAME code (if I'm misunderstanding this, please tell me), does that mean it would need the rom from the arcade to play? in which case the actual source code for the modified MAME should be freely distributable, right?

(Oh, maybe re-reading that, it sounds like MAME was used to disassemble the original ROM and then its source was modified, which is absolutely brilliant, though I also would think that any patches to the source could be distributed, just not the actual source, which would need to be disassembled by anyone who wants to work on this modification, right? Yeah, you're right, that gets into weird legal areas).

[Anima]

(Oh, maybe re-reading that, it sounds like MAME was used to disassemble the original ROM and then its source was modified, which is absolutely brilliant, though I also would think that any patches to the source could be distributed, just not the actual source, which would need to be disassembled by anyone who wants to work on this modification, right? Yeah, you're right, that gets into weird legal areas).

The MAME source has been modified so that it will save telemetry data when the game is running. This telemetry data and the program ROM are being processed by a special disassembler which produces a real source code of the program.

Here's an actual snippet:

Code: Select all

L_00016dca:
    cmpi.b  #$2,$50dc(a5)                           ; [00000001] 00016dca: 0c2d 0002 50dc 
    beq.b   L_00016df4                              ; [00000001] 00016dd0: 6722 

    move.w  d0,d5                                   ; [00000001] 00016dd2: 3a00 
    jsr     L_00002184.w                            ; [00000001] 00016dd4: 4eb8 2184 

    beq.b   L_00016df4                              ; [00000001] 00016dd8: 671a 

    addq.b  #$1,-$766c(a5)                          ; [00000001] 00016dda: 522d 8994 
    addq.b  #$1,$50dc(a5)                           ; [00000001] 00016dde: 522d 50dc 
    jsr     L_000026dc.w                            ; [00000001] 00016de2: 4eb8 26dc 

    bsr.w   L_00016e32                              ; [00000001] 00016de6: 6100 004a 

    add.w   d5,d5                                   ; [00000001] 00016dea: da45 
    move.w  L_00016df6(pc,d5.w),d5                  ; [00000001] 00016dec: 3a3b 5008 

    jmp     L_00016df6(pc,d5.w)                     ; [00000001] 00016df0: 4efb 5004 



L_00016df4:
    rts                                             ; [00000001] 00016df4: 4e75 


L_00016df6:
    dc.w    L_00016e74-L_00016df6
    dc.w    L_00016ed4-L_00016df6
    dc.w    L_00016f9c-L_00016df6
    dc.w    L_00016f14-L_00016df6


L_00016dfe:
    cmpi.b  #$2,$50dc(a5)                           ; [00000001] 00016dfe: 0c2d 0002 50dc 
    beq.b   L_00016e28                              ; [00000001] 00016e04: 6722 

    move.w  d0,d5                                   ; [00000001] 00016e06: 3a00 
    jsr     L_00002184.w                            ; [00000001] 00016e08: 4eb8 2184 

    beq.b   L_00016e28                              ; [00000001] 00016e0c: 671a 

    addq.b  #$1,-$766c(a5)                          ; [00000001] 00016e0e: 522d 8994 
    addq.b  #$1,$50dc(a5)                           ; [00000001] 00016e12: 522d 50dc 
    jsr     L_000026dc.w                            ; [00000001] 00016e16: 4eb8 26dc 

    bsr.w   L_00016e32                              ; [00000001] 00016e1a: 6100 0016 

    add.w   d5,d5                                   ; [00000001] 00016e1e: da45 
    move.w  L_00016e2a(pc,d5.w),d5                  ; [00000001] 00016e20: 3a3b 5008 

    jmp     L_00016e2a(pc,d5.w)                     ; [00000001] 00016e24: 4efb 5004 



L_00016e28:
    rts                                             ; [00000001] 00016e28: 4e75 


L_00016e2a:
    dc.w    L_00016ea4-L_00016e2a
    dc.w    L_00016ef4-L_00016e2a
    dc.w    L_00016fcc-L_00016e2a
    dc.w    L_00016f34-L_00016e2a

As you can see, the source is formatted and even jump tables are being detected and resolved. Unfortunately, there are still some dirty tricks in the code which will definitely lead to a crash when "moving" the whole program to a different address.

Reassembling this source with vasm without any changes will produce an identical program ROM and this can be reused by the modified MAME.

So what's different in the code on the Atari STE? Actually some program code below $800 has been moved to a higher address location and the exception vectors for the VBL and HBL have been hijacked. The Atari STE VBL now draws some red blocks, the JagPad/keyboard input is being processed and then it calls the original code. That's basically all.

[dlfrsilver]

Anima, do you plan to make the game code ressourced available ? Anyway that's a great idea

How much ram do the game will need on STE ? 4mb of ram ?

I think there are two issues making the source code public. First it's still not completely relocatable and (even more important) there are legal questions about the copyright. Besides that, I'd like to share it, why not.

Regarding the memory requirement it'll need 4 MB RAM on the Atari STE for sure. The game code itself is 1 MB in size so there's not much space left for a scrolling double+background buffering. Also the sprites will take another huge chunk of RAM as well.

there's another thing : This game takes a lot of memory, because all the game is directly accessible.

Are you planning to make the game loading only the needed parts for each level ? This will also allow to reduce seriously the amount of colors without making the graphics too much painful to convert in term of palette.

[Anima]

there's another thing : This game takes a lot of memory, because all the game is directly accessible.

Are you planning to make the game loading only the needed parts for each level ? This will also allow to reduce seriously the amount of colors without making the graphics too much painful to convert in term of palette.

That's right. The main problem here is to find out which tiles will be used at what stage. Sometimes sprites will be reused on later levels just only with a new palette.

[dlfrsilver]

there's another thing : This game takes a lot of memory, because all the game is directly accessible.

Are you planning to make the game loading only the needed parts for each level ? This will also allow to reduce seriously the amount of colors without making the graphics too much painful to convert in term of palette.

That's right. The main problem here is to find out which tiles will be used at what stage. Sometimes sprites will be reused on later levels just only with a new palette.

I think i can do something here

What i propose, is to make an excel file for each tile bank, and then indicate like :

Sprite level 1
Sprite level 3
Sprite level 5
Boss sprite part 1

Background level 1 Background level 5
Foreground level 2 Background level 3

I can do that puzzle, by indicating you the tile word references, that are stored inside the game code. That's easy in the capcom games. But it can also take a bit of time. but it's doable.

Oh and the best, i have started a while ago to extract each tile part, and then via a specific mame version, extract the palettes, and then use a tilemapper, which allowed me to get the tile sheets exactly like how the capcom guys have them in their archive service

on the palette side, it's going to be fun, because basically, the arcade machine is doing palette changes very often ingame. using the same thing but applied to the 16 colors palette of the ST would be very cool, graphically and technically.

[dlfrsilver]

oh and a good new : each sprite has a fixed palette of 16 colors. The palettes changes are done on the backgrounds.

[NGF]

Awesome project!

Anyhow, why not use the original ST versions music for the STE, it's pretty good actually for ST standards and then use the arcade versions sfx?
Then maybe the Falcon is able to playback more "advanced" music.

[Anima]

What i propose, is to make an excel file for each tile bank, and then indicate like :

Sprite level 1
Sprite level 3
Sprite level 5
Boss sprite part 1

Background level 1 Background level 5
Foreground level 2 Background level 3

I can do that puzzle, by indicating you the tile word references, that are stored inside the game code. That's easy in the capcom games. But it can also take a bit of time. but it's doable.

Ok, that sounds interesting. Are you also able to find out which sprites/tiles will be flipped horizontally and/or vertically? This is quite important because it increases the graphics memory usage by a good margin.

In respect of the graphics I'm about to extend MAME to create images out of the sprites with a realtime mapping to a given 16 colours palette. This data will be used later on to create the compiled Blitter sprites.

Anyhow, why not use the original ST versions music for the STE, it's pretty good actually for ST standards and then use the arcade versions sfx?
Then maybe the Falcon is able to playback more "advanced" music.

That sounds like a good idea.

[dlfrsilver]

Ok, that sounds interesting. Are you also able to find out which sprites/tiles will be flipped horizontally and/or vertically?

Well all the sprites are at least flipped horizontally in ghouls'n'ghosts. What do you plan, keeping the routine which flip the sprite frames, or do you need to have the sprites already flipped ?

This is quite important because it increases the graphics memory usage by a good margin.

Just tell what you need.

In respect of the graphics I'm about to extend MAME to create images out of the sprites with a realtime mapping to a given 16 colours palette. This data will be used later on to create the compiled Blitter sprites.

that's a great idea

Anyhow, why not use the original ST versions music for the STE, it's pretty good actually for ST standards and then use the arcade versions sfx?
Then maybe the Falcon is able to playback more "advanced" music.

That sounds like a good idea.[/quote]

Or transcoding the YM2151 partitions data to make the music working on the STE YM chip ?

[Anima]

Well all the sprites are at least flipped horizontally in ghouls'n'ghosts. What do you plan, keeping the routine which flip the sprite frames, or do you need to have the sprites already flipped ?

When you're certain that you can sort out the tile/sprite usage of each stage than I'll try to include all flipped sprites as well. Other assets can be loaded when the level changes.

I guess the 4 MB will be filled up quite easily without a loading strategy. The ugly part is that all TOS related variables and other stuff is killed in the lower address range so I will have to restore that before getting access to the OS file functions. However, I think this will be still fast enough to be a viable solution.

[Anima]

First sprite extracting attempts:

[EvilFranky]

How are you going to approach the limited STE 16 colour display Anima? Will be a challenge converting...