shadow of the beast ST (Mark mc cubbin here)

[swapd0]

yeah, the movem it's in a weird format it's in my TODO list, and the cmp you have to include a '#', it looks that I've a bug in my disassembler and in my assembler XD.

[Dbug]

Interesting, I've never seen this "d1234567/a0123456" syntax for movem, I've been used to things like:
- movem.l d0/d1/d2/a3/a6
- movem.l d0-d4/a0-a5

[swapd0]

Yes, I was lazy when I wrote the disassembler, anyway they are easy to fix.

[Dbug]

Cool that you wrote one
Is it a disassembler running on PC or on the Atari itself?

[swapd0]

First version was in BeOS, now it runs in Mac, the buggy GUI it's done in Interface Builder.

[Dbug]

Gosh, apparently the coder does not like the (an)+ addressing mode:

Code: Select all

l001807	move.w 2(a0),8(a1)
		move.w 4(a0),16(a1)
		move.w 6(a0),24(a1)
		move.w 8(a0),32(a1)
		move.w 10(a0),40(a1)
		move.w 12(a0),48(a1)
		move.w 14(a0),56(a1)
		move.w 16(a0),64(a1)
		move.w 18(a0),72(a1)
		move.w 20(a0),80(a1)
		move.w 22(a0),88(a1)
		move.w 24(a0),96(a1)
		move.w 26(a0),104(a1)
		move.w 28(a0),112(a1)
		move.w 30(a0),120(a1)
		move.w 32(a0),128(a1)
		move.w 34(a0),136(a1)
		move.w 36(a0),144(a1)
		rts

[Cyprian]

Gosh, apparently the coder does not like the (an)+ addressing mode:

or he just likes "move.w" instruction

[Dbug]

@swapd0: Do you think you could make your disassembler generate the ":" at the end of labels, it's optional, but when searching in the code that makes it easier to find where the routine is actually located

[swapd0]

Yes, but maybe it will generate the code with different labels...

[swapd0]

F*ck, I didn't save the project and there are some missing entry points, so the code it's generated with different labels.

If you have changed a lot of code, maybe it's better if you use an editor with regular expression to match a label at the start of a line and replace it with a ':' at the end.

[Dbug]

I've not started anything, just looked at the existing disassembly

[swapd0]

For fun XD, Ok, I'll fix a bug and disassembly it again, yesterday I put the ':' at the labels.

[Dbug]

One thing I'm wondering: Is there a way to detect that some labels are actually the same address?

Looking at the disassembly I see that you have different equates for hardware register addresses that were expressed as .w and .l, so we end up with these two sets of different values, some being correctly names with a symbolic name (eg: SOUND_REG or IKBD_CTRL) but some other are just normal labels:

Eg:
l000029 equ $00008800
SOUND_REG equ $00ff8800

(it happens for the video counter, dma, ym, and a few other).

[swapd0]

This version has the labels with a ':' at the end.

About the last question... I need to think how to fix that, maybe tag each label with a size.

[Cyprian]

unfortunately there are still some strange movem

Code: Select all

error 42 in line 2062 of "beast.s": division by zero
>l000335:       movem.l d01/a01,-(a7)

error 42 in line 2070 of "beast.s": division by zero
>               movem.l (a7)+,d01/a01

error 42 in line 7205 of "beast.s": division by zero
>l000748:       movem.l d123456/a0-a6,-(a7)

error 42 in line 7236 of "beast.s": division by zero
>               movem.l (a7)+,d123456/a0-a6

some hardware addresses are defined wrongly: $0000820a instead of $FFFF820a:

Code: Select all

l002099	equ $0000820a
l000016	equ $00008604
l000004	equ $00008606
l000014	equ $00008609
l000013	equ $0000860b
l000012	equ $0000860d
l001031	equ $000087f6
l000027	equ $00008800
l000028	equ $00008802


l000019	equ $0000fa01
l002076	equ $0000fa07
l002077	equ $0000fa09
l002078	equ $0000fa13
l002079	equ $0000fa15
l000152	equ $0000fa17
l002081	equ $0000fa19
l002080	equ $0000fa1f
l000190	equ $0000fc00
l000153	equ $0000fc04
l000154	equ $0000fc06

it generates following error:

Code: Select all

error 2033 in line 2063 of "beast.s": absolute short address out of range
>               lea l000019.w,a0

>l000020:	move.w l000016.w,d0


error 2033 in line 1172 of "beast.s": absolute short address out of range
>               bclr #$0003,l000152.w

there are some "displacement out of range". They can be generated because of previous errors.

Code: Select all

error 2030 in line 1343 of "beast.s": displacement out of range
>               movea.l l000222(pc,d0.w),a0

error 2030 in line 1420 of "beast.s": displacement out of range
>               movea.l l000240(pc,d0.w),a0

error 2030 in line 1533 of "beast.s": displacement out of range
>               movea.l l000285(pc,d0.w),a0

error 2030 in line 1577 of "beast.s": displacement out of range
>               movea.l l000290(pc,d0.w),a0

[swapd0]

Which assembler are you using? I need to make my assembler more robust.

[swapd0]

- Weird register list fixed
- labels at low memory are matched with hardware address before generation
- About errors like this:
error 2033 in line 1172 of "beast.s": absolute short address out of range
> bclr #$0003,l000152.w
Maybe it's because some address are like $00ff8240 instead of $ffff8240, I had to fix that in my assembler.

I was thinking which Atari ST game could be disassembled to improve it...

PD: thanks for the bugs report.

[swapd0]

Sorry, use this file, not the last one.

[Cyprian]

Which assembler are you using? I need to make my assembler more robust.

Devpac and VASM in devpac compatible mode. Below an example from Devpac:

Code: Select all

l000016   equ $00008604
        l000020:   move.w l000016.w,d0

Steem__00001.png

VASM: http://sun.hasenbraten.de/vasm/index.php?view=relsrc
Build:

Code: Select all

make CPU=m68k SYNTAX=mot

Assemble:

Code: Select all

vasmm68k_mot.exe -nocase -maxerrors=20 -devpac -m68000 -no-opt -nosym -Ftos -o TEST.TOS TEST.S

[Cyprian]

Sorry, use this file, not the last one.

Code: Select all

l000004	equ $00ff8606

to use .w mode it should be $ffff8606

after correcting, VASM generates that binary code:

beast.tos.zip

[swapd0]

The problem it's that, when it's accesses without .w it's stored as $00ff8606, if I expand the value to 32bits to have $ffff8606 the bin compare to test the disassembly will fail.

I've no idea how to fix it.

[Cyprian]

Does this picture show original code?
If yes, there were no ".w" used there.

_TMP_Devpac.png

[swapd0]

For that value In some parts it's .w in other ".l", the palette never it's accessed with .w ...

[joefish]

I'm not in that Facebook group so I'll just cross-post this here from an older thread...
http://www.atari-forum.com/viewtopic.php?f=16&t=29599


To see it running:
https://demozoo.org/productions/156249/
https://www.youtube.com/watch?v=NRMOan38qRU

It's 25fps and uses "Spare Colour Playfield" technique: Foreground layer is in 3 colours + transparent, and copied into two bitplanes. Background layer is in 3 (not 4) colours in 2 bitplanes. By not using one of the possible 4 background colours, it leaves 4 palette entries 'spare' for sprites (sprites are drawn to all 4 bitplanes).

Again I've got a 'fake COPPER' interrupt running that can change the sky colour, change the two background colours where needed, and change one of the foreground colours (which means 3 palette entries) to change green to grey for the stone wall at the bottom. The palette is arranged such that index 0 (the border) is the same as the darkest of the foreground colours. The moon is ORed into one background bitplane so it merges with the grey, but is overwritten by the white.

The foreground is pre-shifted in 'chunks' to 4-pixel positions (the chunks are: nothing / small tree / large tree left / large tree right / mixed tree repeater). The background is pre-shifted to 1-pixel positions. Multiple address registers point to the foreground chunks that are visible on the screen, then one row of the screen is made by copying a chunk from each register in turn. This copy function is re-written with self-modifying code, so that it copies and wraps the background in the right place whilst also copying the foreground.

[Cyprian]

just impressive
how many memory is needed? 512kB will be ok?
and how %CPU is free?