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

[Retro1234]

Originally Posted by dlfrsilver

i have traced thru the whole code Boo Boo, there is no blitter access in anyway in the game code of Amiga Black Tiger. no blitter wait, everything is software driven by the 68000.

Thanks for the reply and sorry for going off topic but CPU speed doesnt seem to affect most commercial games.

[dlfrsilver]

well a lot of amiga games are coded to use the hardware abilities. Any game driven by software only will be tied to the processor speed. This is the case here, and in other ST ports.

[saimon69]

Have the feeling is better to rewrite that one from scratch than to fix it, huh?

[dlfrsilver]

well that's almost the right thing to do yes.

[leathered]

Originally Posted by Boo Boo

Silly question im sure - I guess there is some kind of blitter wait so no matter what speed the Amiga is the game is about the same - What about the Atari ST version if this was run on a Atari ST 68060 would it not run super fast.

Since it relies purely on the CPU, and ran super fast in WINUAE, then I'm pretty sure that the answer to the last question is yes.

My opinion on this...
Stingray hinted at a way to go earlier in some context - instead of drawing everything with the CPU you can make a new routine that will take all the data and use the blitter for drawing each frame. This sounds similar in concept to what 'Where Time Stood Still' does in 'blitter mode'.

I wouldn't worry about the colours, to me they are well adapted to 16 (at least the first level). No mean feat...

I agree that there is probably a half decent game hiding in there (you can get a taste of that through WINUAE), and to someone with the skills and the time (and I have neither, unfortunately) then theoretically there's a reasonable means to update this using the custom chips without doing the whole thing again.

[Retro1234]

Originally Posted by leathered

Since it relies purely on the CPU, and ran super fast in WINUAE, then I'm pretty sure that the answer to the last question is yes.

My opinion on this...
Stingray hinted at a way to go earlier in some context - instead of drawing everything with the CPU you can make a new routine that will take all the data and use the blitter for drawing each frame. This sounds similar in concept to what 'Where Time Stood Still' does in 'blitter mode'.

I have to admit ive not tested this game - but noticed a number of games dont seem to run significantly faster on higher CPUs

Thanks for the info I belive `Where Time Stood Still' runs faster in CPU mode than blit on higher CPUs.

So youve already got a speed increase on higher CPUs without waiting for the blit?

[dlfrsilver]

Originally Posted by leathered

Since it relies purely on the CPU, and ran super fast in WINUAE, then I'm pretty sure that the answer to the last question is yes.

There is no blitter wait at all, because this game makes NO access to any custom chip (Blitter, copper, whatever).

So the answer can't be yes.

My opinion on this... Stingray hinted at a way to go earlier in some context - instead of drawing everything with the CPU you can make a new routine that will take all the data and use the blitter for drawing each frame. This sounds similar in concept to what 'Where Time Stood Still' does in 'blitter mode'.

that would be fine, but it would be hard..... a game like BT should run at 50 fps on amiga, for that the whole video engine must be changed.

I wouldn't worry about the colours, to me they are well adapted to 16 (at least the first level). No mean feat...

The color scheme is horrible. 32 colors is really the minimum for a game which such a big palette.

I agree that there is probably a half decent game hiding in there (you can get a taste of that through WINUAE), and to someone with the skills and the time (and I have neither, unfortunately) then theoretically there's a reasonable means to update this using the custom chips without doing the whole thing again.

The game is half decent indeed , i think it would need quite a big amount of time of time to work out the whole thing

[chadderack]

Sorry to dredge this up; but it's directly on-topic for what I wanted to ask.

I LOVE BLACK TIGER. I played the hell out of that game in college. Instead of going to class, I would play BLACK TIGER. I would play it over and over again. I could beat it on a single quarter and score over 1M points every time and my intitials would stay on the machine the whole day.

That's the kind of drive a coder needs to stick with a (potential) project

My question: Is anyone you know of actively working on a port to the Amiga? I've been looking for an asm project for the Amiga--demos are not my thing; games are something I have a passion for.

I just finished a game I started at age 16(!) on the C64--a Zork-like game all in asm. Am just working on the packaging.

I bought an Amiga 500 at age 21 (in the early 90s) hoping to write games on it, but got discouraged by a visit to Akklaim's offices (for a job interview). All they were hiring were people coding on the PC platform at that time.

...

How I want to go about it (if I'm going to do it):

1) I'd like to not just reverse (engineer) the graphics and sounds via MAME--I'd also like to reverse the game LOGIC. Reason? In many games there are hidden features that a coder might not even know about. How would you implement the hidden items in the walls of Black Tiger (for instance) if you didn't know about them? Reversing the logic of the original arcade machine would give you a logic map to go from.

I've heard that Ghidra might be able to help here.

2) Have the sounds and music be as exact as possible. No point in anything less, I'm afraid.

3) Get this done before I'm dead I do have a girlfriend and need to spend time with her daily... but Saturday and Sunday are good days for coding


I've already pulled the tile sets and sprites from MAME. Just to be thorough, I pulled a copy of each set in each of the available palettes. (Might think that is overkill--but sometimes little hidden features are only shown by certain palettes... example: the outline of a knife that goes in the HUD only shows with certain palettes. Mostly for visual reference.)

Will be studying Graeme's (mcgeezer's) work heavily for this. I really like his toolchain and might mimic it.



Chad

[dlfrsilver]

Originally Posted by chadderack

Sorry to dredge this up; but it's directly on-topic for what I wanted to ask.

I LOVE BLACK TIGER. I played the hell out of that game in college. Instead of going to class, I would play BLACK TIGER. I would play it over and over again. I could beat it on a single quarter and score over 1M points every time and my intitials would stay on the machine the whole day.

That's the kind of drive a coder needs to stick with a (potential) project

My question: Is anyone you know of actively working on a port to the Amiga? I've been looking for an asm project for the Amiga--demos are not my thing; games are something I have a passion for.

I just finished a game I started at age 16(!) on the C64--a Zork-like game all in asm. Am just working on the packaging.

I bought an Amiga 500 at age 21 (in the early 90s) hoping to write games on it, but got discouraged by a visit to Akklaim's offices (for a job interview). All they were hiring were people coding on the PC platform at that time.

...

How I want to go about it (if I'm going to do it):

1) I'd like to not just reverse (engineer) the graphics and sounds via MAME--I'd also like to reverse the game LOGIC. Reason? In many games there are hidden features that a coder might not even know about. How would you implement the hidden items in the walls of Black Tiger (for instance) if you didn't know about them? Reversing the logic of the original arcade machine would give you a logic map to go from.

I've heard that Ghidra might be able to help here.

2) Have the sounds and music be as exact as possible. No point in anything less, I'm afraid.

3) Get this done before I'm dead I do have a girlfriend and need to spend time with her daily... but Saturday and Sunday are good days for coding


I've already pulled the tile sets and sprites from MAME. Just to be thorough, I pulled a copy of each set in each of the available palettes. (Might think that is overkill--but sometimes little hidden features are only shown by certain palettes... example: the outline of a knife that goes in the HUD only shows with certain palettes. Mostly for visual reference.)

Will be studying Graeme's (mcgeezer's) work heavily for this. I really like his toolchain and might mimic it.



Chad

I have already all the sprites with the right color palettes. I have not finished the extraction of the level tiles.

Next, the game code is in z80 asm. Are you fluent with this code type ?

[chadderack]

Originally Posted by dlfrsilver

I have already all the sprites with the right color palettes. I have not finished the extraction of the level tiles.

Next, the game code is in z80 asm. Are you fluent with this code type ?

I'm getting there. I'm more used to the Motorola flavors (6502/6809/68x)... bigendian. The Z80 is little endian, which is trippy.

The syntax is a bit odd compared to Motorola but I've managed to disassemble quite a bit of the ROM so far.

The trick has been to use Ghidra, which (unlike IDA Pro) seems to allow you to define your own overlays. The rom images from MAME are split into 4K pieces (except for the first one) and they are the banked ROM. There are 16 banks.

Stepping through the code in the MAME debugger takes a lot of time; but I'm finding functions. Just found the function that displays the initial warning... and then the one that clears the screen and draws the Black Tiger logo.

I suspect the reversing step (via Ghidra/MAME debugger) will take some time... especially to get anything useful. But the MAME driver for Black Tiger and the other documentation has been super helpful so far.

It looks like the Z80 references screen memory in Black Tiger similarly to how a Commodore 64 (!) does. Character bytes are mapped directly to the screen.

More later. Maybe you and I should start a new thread(?)

[jotd]

Serious attempt there it seems.

I used MAME to run a Z80 game (Bagman) in order to understand the logic and reverse engineer it for a now complete remake. It was invaluable of course, as static disassembly has its limits.

But Black Tiger is something much more complex than the old 1982 game I analyzed. Good luck. Specially when remaking the game for Amiga, with 8 way scrolling and all. Have you considered using an engine like Scorpion Engine?

[chadderack]

Originally Posted by jotd

Have you considered using an engine like Scorpion Engine?

Hi jotd. Just kind of early days. I'm exploring the code via MAME and finding some good info.

Mostly this is an attempt to uncover game logic. Since the architecture of Black Tiger and the Amiga are very different, it's unlikely I'll plot the characters and switch the palettes the same way that the Z80-powered system does. I'm kind of searching for the higher-level logic. Good progress being made.

I'll look into engines if need be--but will burn down the bridge when I get to it

[saimon69]

I am building an experience on redoing game music using hoot to capture samples - little downside is things get a bit big, but if your target is a one meg machine can be done

[saimon69]

It seems there is a version of Black Tiger for Sharp x68000, could be used?
note that am not sure this is a legit x68000 game and have no emulator handy, can someone check?

ok forget about it, link is not working and cannot find any other mention of a Black Tiger/Black Dragon for that platform so i might have been fooled

[chadderack]

Could be you're thinking of the US Gold version for Amiga. I have that, and as I remember--it's quite bad. The scrolling is very chunky and the animation is terrible. There are a few places where the player just freezes as well. The graphics aren't terrible; but if we're going to do Black Tiger right, I'd like to do as well as possible with the graphics.

Hopefully we can redo things with the full game palettes and graphics as well as the music. Not sure how practical reversing the music and sounds would be (to put into something like ProTracker) but we'll get there eventually.

[Belgarath]

There was a Black Tiger listed in TOSEC for X68000, but that was just a mislabelled rom. It was actually Twin Cobra/Kyuukyoku Tiger

[dlfrsilver]

Originally Posted by chadderack

Hi jotd. Just kind of early days. I'm exploring the code via MAME and finding some good info.

Mostly this is an attempt to uncover game logic. Since the architecture of Black Tiger and the Amiga are very different, it's unlikely I'll plot the characters and switch the palettes the same way that the Z80-powered system does. I'm kind of searching for the higher-level logic. Good progress being made.

I'll look into engines if need be--but will burn down the bridge when I get to it

what is sure is that Black Tiger is coded in ASM Z80. There is no a single inch of object code inside the roms.

Can't wait to see black tiger internals

[dlfrsilver]

Originally Posted by chadderack

Could be you're thinking of the US Gold version for Amiga. I have that, and as I remember--it's quite bad. The scrolling is very chunky and the animation is terrible. There are a few places where the player just freezes as well. The graphics aren't terrible; but if we're going to do Black Tiger right, I'd like to do as well as possible with the graphics.

Hopefully we can redo things with the full game palettes and graphics as well as the music. Not sure how practical reversing the music and sounds would be (to put into something like ProTracker) but we'll get there eventually.

I can try to extract the samples if you want

EDIT : the musics & sound effects are in the program code. They are not external.

[saimon69]

As i said before, the best way to get music and SFX is to use Hoot (if compatible), capture single instruments and chords in wav, export and readapt via audacity+protracker or, in my case milkytracker.
To have sound and music three channel for music can be used and one for sound effects.
Results can be pretty good, albeit a discrete amount of RAM is used, like in this Robocop song for Seko port.
Subsongs like game over, dungeon etc. are in different positions of the mod file.
[ Show youtube player ]

[chadderack]

Originally Posted by dlfrsilver

what is sure is that Black Tiger is coded in ASM Z80. There is no a single inch of object code inside the roms.

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.

Originally Posted by dlfrsilver

I can try to extract the samples if you want

EDIT : the musics & sound effects are in the program code. They are not external.

Cool. That would help!

Originally Posted by saimon69

As i said before, the best way to get music and SFX is to use Hoot (if compatible), capture single instruments and chords in wav, export and readapt via audacity+protracker or, in my case milkytracker.
To have sound and music three channel for music can be used and one for sound effects.
Results can be pretty good, albeit a discrete amount of RAM is used, like in this Robocop song for Seko port.
Subsongs like game over, dungeon etc. are in different positions of the mod file.
[ Show youtube player ]

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