shadow of the beast ST (Mark mc cubbin here)

[lostdragon]

You're welcome

Kicking myself for not discovering it sooner.

All these years of hoping someone from Gamestm/Edge or retrogamer would branch out just that little bit further and talk to those behind the conversions of SOTB and maybe just take on board how big a presence the ST had in the UK, for a while at least and chat to someone tasked with converting a game designed for Amiga hardware, down to the ST...but no, nothing came of it.


And answers i sought were here all along and i wasn't being asked to pay a magazine price to read them.

Utmost respect to you for putting this out into the community.

[dlfrsilver]

oh thanks I was not waiting such compliments or more for this matter.

I wanted to get the informations from the mouth of the ST coder, i mailed him, and there you go

[lostdragon]

Your welcome.

I think I appreciated what you shared all the more as you went in with the right principles, wanted some information, couldn't find it so approach chap directly..then share findings.

An attitude a few others in Retro community could learn from no doubt

[dlfrsilver]

I have found another information, if you're interested, about Corporation, a game made by Core Design :

Jeremy heath-smith said in amiga power review in july 1991 p.62 that "Corporation sold so well on the Amiga that the ST version didn't prove to be necessary for our financial health at all".

Rob Toone, the Frenetic programmer, explained also that he hated Xenon 2 because it was an unplayable game : "it kept restricting your movements and then sending waves of Aliens right down the path you're forced to take, i can't stand that".

[lostdragon]

Appreciated.

Agree with Rob Toone, Xenon II was all mouth and no trousers.Looked fantastic, but played like a brick.


I much prefered the original myself.

Don't think Jeff Minter was a fan of Xenon II either from Press quotes, if my memory serves me correctly.

[Total Eclipse]

I spoke to Jeff Minter about Xenon II at the 1989 Computer Shopper show. He was particularly unimpressed with the collision detection.

On the other hand, I rate that game as one of my all time favourites.

[lostdragon]

I spoke to Jeff Minter about Xenon II at the 1989 Computer Shopper show. He was particularly unimpressed with the collision detection.

On the other hand, I rate that game as one of my all time favourites.

Appreciated the info.

Frank Gasking (GTW) is hoping to put a few misc Atari related Q's to Jeff on my behalf, if i get anything back, i'll share.

As for Xenon 2, i appreciated the fantastic visuals, but playability wise, the original had the edge on it for myself.


Always felt Bitmaps peaked with Speedball II and Gods myself, liked Chaos Engine, fell for hype of Magic Pockets, much to my eternal shame

[lostdragon]

Found old Jeremy Heath-smith quote regarding Frentic:

"...we were so envious of the Bitmaps, who'd just done Xenon, and we always believe we can do a game better than anyone else but we crashed and burned big style on that one."

[dlfrsilver]

Frenetic had no success and was a fail ? shame, because it has this nice coin-op smell.

[Dbug]

Ok, since I don't like to bash things without poking at them thoroughly, I decided to look seriously inside the code of Shadow of the Beast on the ST.
I got myself the original STX (Pasti) files, the DBUG "hdd/falcon compatible" version, as well as two "filed" versions (one from Automation and one from Medway Boys).

I used a mix of Easy Rider and Steem Boiler 3.9.4 for debugging/tracing, and then applied a bunch of patches to my version to make sure the code did do what I think it was supposed to do.

The bottom line is: NO, Shadow of the Beast is not as good as it could have been, not by a giant margin: The code is as best "good enough" for a prototype, but most of the patterns I've seen in the code suggest a "beginner++" level at best.

Among the issues:
- The coder NEVER use absolute short addressing mode, so all the color changes take way longer than necessary
- All the color changes are done with move.w, he never move.l two consecutive colors, he never (an)+ or movem.l them either
- He uses JSR in many places where he could have used BSR
- He loves to JSR / RTS (instead of JMP)
- The famed "Copper Emulator" is a mess, a lot of time is spent jumping to empty routines
- The code is full of mulu #400 and divu #25
- He often uses clr.l dn instead of moveq #0

For the ones who are interested, I added some posts with screenshots and comments on the "Atari pour toujours and beyond !" Facebook group https://www.facebook.com/groups/1518006 ... 342887471/

Trivia: The Eldritch the Cat logo is just an IFF/ILBM animation in ANIM format, so whoever feels like doing a SOTB++ can easily change that.

Now, from what I've learned:
- The code is a mess, but a proper disassembly should probably not be too difficult to understand
- Adding STe palettes is trivial
- There's enough free cpu time in the small things I signaled to probably either add a music (hint: You have three chiptunes from FFT in the Phaleon you can use for that) or put back the missing scrolling barrier at the bottom

I'm going to stop my investigation there, if some of you want to have fun I've attached my "loader source code".
Just assemble it with vasm, then copy it over the floppy with the original files (or overwrite the original beast.prg).

Code: Select all

vasm.exe -m68000 -Ftos -noesc -no-opt -o %SOTB%beast2.prg %SOTB%beast.s

BEAST.s.txt

rasters_jitter_timer_b.png

muls_jsr_rts.jpg

timer_b_palette_change.png

[ggn]

Let's just wait for the village idiot's response now!

[Cyprian]

well done Dbug

[christos]

Let's just wait for the village idiot's response now!

Let me make a guess. The st can't do a better sotb. Those who coded for the Amiga were bad programmers that didn't care for the machine. The st coders were brilliant but just couldn't do anything better because the st is crap.

I also read the Facebook thread and it seems like you could save a lot of clock cycles with very little patching. Now if only it could be done for a good game.

[swapd0]

Where can I find an executable to disassembly? I've several versions but they are protected/packed and it's hard to execute into MonST and then save the binary before the game start.

[Dbug]

I started from this one:
http://ftp.pigwa.net/stuff/collections/ ... med_087.st

The data is compressed with "Ice!" Packer, the source I attached is a modified "beast.prg" (you don't need MENU87.PRG), the Eldritch the Cat intro is in "INTRO" and the game is in "MAIN".

In the code you will see that I added INTRO.DPK and MAIN.DPK, loading the INTRO.DPK directly with the TOS functions work, but it did not work for MAIN.DPK for some readon, maybe some uncleared BSS or something obscure done during depacking (or maybe I did not use the right version of the depacker, that's also possible).

For tracing/debugging, I found out that after all, Steem Boiler Debug was working very very well, specially the BREAK ON VBL and BREAK on TIMER B

[swapd0]

I got a doule bus error with Hatari 1.8 and the emulator hangs. I'm trying to execute the code to get the MAIN.DPK file, it's supposed that the file it's loaded and depacked to $55000 and the start address it's $6AABA, isn't it?

[swapd0]

Fixed

[swapd0]

wow, the code has a lot of jump tables... still working on the disassembly...

[Dbug]

Yeah, the code has jump tables all over the place, the main ones are identifiable with the "jsr (a4) / rts" and the other one is in the timer_b interrupt.
Considering the game does not run at 50hz, it means the timer_b slow code is actually running more than once per frame, so there's a some performance upgrades laying there: Instead of having the IRQ run at fix step and have it do jmps to RTS when there's nothing to do, have instead multiple IRQ handlers, and have them daisy chained, each one setting the delay and address to the next one.

Do you think you will manage to get a clean disassembly that can be rebuilt and optimized?

[swapd0]

Do you think you will manage to get a clean disassembly that can be rebuilt and optimized?

I'm working on it, at least I could fully disassembly Frontier some years ago.

[swapd0]

It's possible executable can have some dead/unreachable code? Because I've some parts that it's code but I can't find a jump table neither a reference to it.

[Dbug]

Well, if you look at one of my pictures, there are parts of the code that make absolutely no sense in the context of "I have the source code, I'm writing code, I made a mistake here, let's fix it".

The routine I showed looked like it was patched over an existing binary, nobody sane would do a JSR to three color changes placed just above, followed by a RTS followed by one color change and then one RTS.

So maybe... at some point they lost the source code (corrupted floppy / hard drive?) and patched an existing executable?

A simple way to test if the code is reachable would be to use my patching executable:
- Add a small "ColorCycle: add.w #$123,$ffff8240.w / bra ColorCycle"
- Patch the location where you see dead/unreachable code with some JSR ColorCycle

then run the game, going through both the main level, the well and the tree house, die, ... if the color change does not happen it's probably never called

[swapd0]

I think that it's done, I've assembled it, I did a bin compare with MAIN.DPK and it's the same. By the way my assembler output GenST syntax style, not sure if it's compatible with vasm.

[swapd0]

I forgot to include a jmp at the start (and change the org to X - 6), because the entry point it's at line 19002.

[Cyprian]

great job swapd0.

VASM in devpac compatible mode shows following errors:

Code: Select all

error 42 in line 334 of "beast.s": division by zero
>l000005        movem.l d1234567/a0123456,-(a7)

error 42 in line 349 of "beast.s": division by zero
>               movem.l (a7)+,d1234567/a0123456

error 42 in line 599 of "beast.s": division by zero
>l000067        movem.l d01234567/a0123456,-(a7)

error 42 in line 613 of "beast.s": division by zero
>l000041        movem.l (a7)+,d01234567/a0123456

and:

Code: Select all

error 9 in line 20868 of "beast.s": instruction not supported on selected architecture
>               cmpi.l l001577,d0               ;Reference Hint

error 9 in line 20883 of "beast.s": instruction not supported on selected architecture
>l002347        cmpi.l l001577,l000913          ;Reference Hint