[request] Not exactly an ST port.... Black Tiger Redux?

[dlfrsilver]

Originally Posted by chadderack

That's for sure. It wasn't coded in a higher level language, that I'm aware of--it seems like it was coded in pure Z80 ASM.

Currently the Ghidra project is going pretty well; I'm finding data structures and several functions. Right now I'm trying to step through the attract mode playthrough. I'm missing something in terms of where the player is animated and the screen is scrolling. What's complicating things is the constant bank switching... but eventually I'll work it out.

Scroll speed seems to be 2-bits per blit (the screen moves 2 pixels for every scroll action). This kind of stuff is important to figure out.

Seems like your gray matter can get pounded into submission single stepping through code that computes offsets from data tables... and you decide to step over something, and the code you step over is the code that animates the player or something.



Cool. That would help!



Right on. I'll check out the video a bit later.

do you have a possibility to get the full game code without the bankswitching ? I imagine it's a gore pain in the ass to get the right portion of code and data at a requested time.

[saimon69]

Considered the usual way Capcom did its games (included the boss runs) i guess for them Bank Switching was almost a requirement ^___________^

[chadderack]

Originally Posted by dlfrsilver

do you have a possibility to get the full game code without the bankswitching ? I imagine it's a gore pain in the ass to get the right portion of code and data at a requested time.

Bank switching is just the nature of the beast. The games were bigger than the address space required to hold all the code in memory.

The same thing happens with pinball roms that I've reversed. Lord of the Rings (Stern Pinball) bank switches. It's just that you have to keep track of the overlays and map them into the correct space, and then all of the opcodes and addresses line up.

If you run the debugger in MAME, you can set a watchpoint for when the bank switches by watching the first byte of the bank area (watch for any change). Then you can trace the code and immediately find the bank switch code.

...

Good progress. I have all of the 16 overlays (graphics/logic) mapped and am working on the sound rom. The sound rom seems harder to reverse, because the audio is right on the chip interleaved with the code.

It has no overlays. But MAME uses an audio driver (or a pair of them) for this game YM1 and YM2. I'll check the source code for that MAME driver to see how they decode and produce the audio. And while I won't probably implement the same logic to play the audio, it will probably at least give me the audio format and locations of each sound.

Thinking about this, triggering the service menu might be the best way to continue and to find each sound/graphic. I need a trigger and a breakpoint... and I can trigger graphics directly and sound directly from the test menu.


ETA: BTW the scrolling happens in the main interrupt (RST1)... the game code moves the scroll vectors and then the interrupt is where scrolling is done.

[dlfrsilver]

Interesting. What is the format type for the IA (the IA moving the enemies depending on what you do and move ?).

[lmimmfn]

If i was taking this on i would split out the gfx/sound and bank switching/I/O routines and write something to convert z80 to 68k assembly. It wouldnt be very effecient but it would keep the game logic intact and the 68k cpu would be a lot faster anyway. Surely there must exist a converter already?

[jotd]

you can't just convert z80 code to 68k because all the low level interrupt stuff won't convert properly. Plus all code related to graphics/custom chips of the arcade machine won't convert.

There are z80 to 68000 converters but you have to target specific parts of the code. I have tried an old one written in Pascal, I had to change stuff, parsing isn't perfect on the Z80 side (asm isn't normalized).. note as easy as it seems.

Better start from the source or reverse-engineered source (with comments and labels) and rewrite by hand.

I successfully converted 6502 games to C, but the difference was that the ROM and low level stuff wasn't included, it was a normal program. When you convert an arcade ROM you get the game code and all the platform handling code (credits, I/O, timers). That part doesn't interest you at all, but it gets in the way.

[lmimmfn]

yeah thinking about it a bit more would be a lot more complex due to little endian z80 and big endian 68k and i doubt it but if there's self modifying code(assuming it has RAM on the arcade board and not just rom).
The integration with the custom hardware wouldn't really be a problem as z80 bus I/O is via the OUT/INI commands and have Amiga specific logic for that

Of course with source it would be a lot easier but i dont think its available, i took a quick look at the MAME source and the ROM memory mapping is described in https://github.com/mamedev/mame/blob...s/blktiger.cpp
Scroll down to "Game driver(s)" and it lists e.g. code(for blktiger rom) as the rom files "bdu-01a.5e", "bdu-02a.6e", "bdu-03a.8e", "bd-04.9e", "bd-05.10e"
Rom files for audio,sprites/tiles etc. also listed.

Also it looks like the roms are encrypted but has the sha1 keys listed.

[dlfrsilver]

Originally Posted by lmimmfn

yeah thinking about it a bit more would be a lot more complex due to little endian z80 and big endian 68k and i doubt it but if there's self modifying code(assuming it has RAM on the arcade board and not just rom).
The integration with the custom hardware wouldn't really be a problem as z80 bus I/O is via the OUT/INI commands and have Amiga specific logic for that

Of course with source it would be a lot easier but i dont think its available, i took a quick look at the MAME source and the ROM memory mapping is described in https://github.com/mamedev/mame/blob...s/blktiger.cpp
Scroll down to "Game driver(s)" and it lists e.g. code(for blktiger rom) as the rom files "bdu-01a.5e", "bdu-02a.6e", "bdu-03a.8e", "bd-04.9e", "bd-05.10e"
Rom files for audio,sprites/tiles etc. also listed.

Also it looks like the roms are encrypted but has the sha1 keys listed.

to my knowledge, there is no encryption. The game use an MCU for protection.

[lmimmfn]

Originally Posted by dlfrsilver

to my knowledge, there is no encryption. The game use an MCU for protection.

True, maybe not encrypted, should be easy to compare hex in roms with same in mame debugger.

[chadderack]

Originally Posted by dlfrsilver

Interesting. What is the format type for the IA (the IA moving the enemies depending on what you do and move ?).

Not sure what IA means here. AI? I'll bet it's some sort of array with array values indexing jump tables (decision trees). The AI for each enemy is probably very simple.

Originally Posted by lmimmfn

If i was taking this on i would split out the gfx/sound and bank switching/I/O routines and write something to convert z80 to 68k assembly. It wouldnt be very effecient but it would keep the game logic intact and the 68k cpu would be a lot faster anyway. Surely there must exist a converter already?

As jotd explained, the architectures are very different... what is needed for a Z80 => 68K conversion is the logic. The graphics and sound will have to be implemented (at the lowest levels) differently than on the arcade machine.

Originally Posted by jotd

you can't just convert z80 code to 68k because all the low level interrupt stuff won't convert properly. Plus all code related to graphics/custom chips of the arcade machine won't convert.

There are z80 to 68000 converters but you have to target specific parts of the code. I have tried an old one written in Pascal, I had to change stuff, parsing isn't perfect on the Z80 side (asm isn't normalized).. note as easy as it seems.

Better start from the source or reverse-engineered source (with comments and labels) and rewrite by hand.

I successfully converted 6502 games to C, but the difference was that the ROM and low level stuff wasn't included, it was a normal program. When you convert an arcade ROM you get the game code and all the platform handling code (credits, I/O, timers). That part doesn't interest you at all, but it gets in the way.

Yeah I'm probably not going to implement the Service Menu, for example Maybe an Easter egg after everything is done... but...

Originally Posted by lmimmfn

yeah thinking about it a bit more would be a lot more complex due to little endian z80 and big endian 68k and i doubt it but if there's self modifying code(assuming it has RAM on the arcade board and not just rom).

You might be surprised. In this particular ROM, there's a lot of stack shifts (where it picks up the location of the stack and moves it). There are CALLs with no returns--the return address is popped out of the stack, etc.

But that low level stuff really isn't too important if you can get a general idea of what functions do what at a high level. It's just a black box at some level.
That's the level you'd need to get to.

The integration with the custom hardware wouldn't really be a problem as z80 bus I/O is via the OUT/INI commands and have Amiga specific logic for that

Inputs and outputs are pretty straightforward. The MAME driver code lists them. Mostly accurate.

I've already done the part you've described... split the roms into banks, etc.

Right now I'm identifying data structures. That sometimes leads to insights ("maybe this is a sprite?").

Tiles are 16x8... with a strange configuration:

For a 16 bit word:

Bits 0-11 = Tile number
Bits 12-14 = Palette index
Bit 15 = 0 = normal; 1 = horizontally flipped
And it's little endian to boot.

That's a complicated encoding which wouldn't (for example) translate directly to the Amiga hardware. It's why we just grab the images and palettes and re-implement the Amiga way.

[chadderack]

A couple of screen shots after starting the service menu.

Seems you can't get to the service menu in the MAME debugger directly by clicking F12... I had to set a breakpoint in the main rom at $01B4 and then set the PC = 1AC and continue.

Now I have the test menu functions figured out.

I should be able to figure out all of the sprite locations in data with this, although it's probably not necessary. I already have the sprite and tile sheets ripped. What I'm finding out is a bummer is that the sounds aren't playing in the test menu. The MAME coders probably didn't bother with sound tests in arcade test menus.

[saimon69]

So, i remember the arcade using several sprites for the player depending on what armor level it uses; based on this i would consider good practice (if the target is OCS/ECS) convert assets for the landscape and enemies (beside dragons of course) at 16 colors in a superpalette (with some of the landscape colors changing for different environments) and keeping 16 separated colors for the player sprite, plus all in-game arcade screens like the store at 32 colors.

[dlfrsilver]

Originally Posted by chadderack

A couple of screen shots after starting the service menu.

Seems you can't get to the service menu in the MAME debugger directly by clicking F12... I had to set a breakpoint in the main rom at $01B4 and then set the PC = 1AC and continue.

Now I have the test menu functions figured out.

I should be able to figure out all of the sprite locations in data with this, although it's probably not necessary. I already have the sprite and tile sheets ripped. What I'm finding out is a bummer is that the sounds aren't playing in the test menu. The MAME coders probably didn't bother with sound tests in arcade test menus.

Attachment 72767
Attachment 72768

Which amiga do you target? A500 or A1200 or both?

[chadderack]

Originally Posted by dlfrsilver

Which amiga do you target? A500 or A1200 or both?

I have an Amiga 500 so I'll be targeting that. If it becomes clear that the project will need more RAM or a faster CPU then maybe that will change.

[chadderack]

Just found the sound queue. As suspected the queue is filled in the normal code and kicked off in an interrupt. There are 16 slots in the sound queue; presumably you can kick off 16 simultaneous sounds, though sound effects seem to not overlap each other. But the music and sounds do overlap.

[dlfrsilver]

Originally Posted by chadderack

I have an Amiga 500 so I'll be targeting that. If it becomes clear that the project will need more RAM or a faster CPU then maybe that will change.

Then keep the future source for an A1200 possibility. I know that 32 colors is better than 16 colors, but it will be then just a little bit better than the regular A500 version graphically wise. An A1200 version with 64/128 colors would be great

[jotd]

AGA = bigger hardware sprites too. Use a sprite for the player and maybe for other enemies

7 bitplanes can be slow. Don't underestimate blitting time to draw characters and save background (this kind of game needs a hardware scrolling)

[saimon69]

On OCS/ECS the player HAS to be a sprite if we do it the way Capcom envision it, with different armors and colors according to the armor level so to have its own changing palette; plus, if we remove the player from the processing of landscape and enemy sprites there will be a better reduction to 16 colors than the one made by US Gold - that had to consider the main player too

[chadderack]

Originally Posted by jotd

AGA = bigger hardware sprites too. Use a sprite for the player and maybe for other enemies

7 bitplanes can be slow. Don't underestimate blitting time to draw characters and save background (this kind of game needs a hardware scrolling)

Thank you for the heads up.

Currently going very well. Have found a ton of functions relating to the sounds... which actually allow me to label functions like "OldManAwardsPlayer100ZennyCoins"... and stuff like that.

Will keep peeling the onion...

[jotd]

way to go: disassemble the thing, then rewrite your own.

The most important would be to understand level layout: tiles, enemy placement and types.

Once you have that, you don't need much more, maybe some A.I. part. See Kroah's excellent reverse engineer of Gods and others http://bringerp.free.fr/RE/index.php5

More & more I think that A.I. in those games is pretty much invisible: the player sees an enemy and kills it before he can notice how the enemy moves Frustrating for the coder...

That's how I did the bagman remake: understand how enemies move (specially the speed ratios player/enemies) and use the same method. In that case, I was more interested in the A.I (it's a pacman-like game) than the rest. I ignored all graphics, just ripped some maps and enemy automated movement table, and the game plays almost the same than the original.

All those dreams about automatic converters are just... dreams.