Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Hungry Horace]

wow, that's amazing bit!!

can you tell me the amiga resource ' lb ' labels for those, so i can update the disassembled version? I am finding the more and more labels and comments i am adding (and this includes marking our the graphics blocks) is slowly making it a bit easier for me to trawl through!!

(maybe soon i will see if i can can actually start getting it to re-compile, as i didnt have many errors on it when i last tried)

[Bit]

will do so!

Things get even more interesting since I found your ADF-file.
That one starts pretty fine in UAE, so I could make my urgently needed
memory-dump at the main menue. It fits pretty fine to bruceuncle's labels, and I now know why the remaining $-adresses differ and could adjust them. My emulation loads that, bypassing all complex initial hardware-responses - which I don't need then - and I can run it.
Once I have the Amiga-screen format decode (and found mouse/keybd input), I will soon have the Amiga-version running too. By that we can check a lot more.

[Hungry Horace]

I can send you the 439 version as an uncracked disk ... You may need the SPS plugin to make UAE accept it though.

You may find any adf is changed to remove copy protection

[Bit]

So far I'm pretty satisfied. Let's see how far I can get.

Because it's related to the format-questions, I will post a very first routine-label and add some comments.
I know, you work with BW not for the first day now, so I deserve copse' s post - but at this point each detail seems to be very important, so I better repeat  it. With that important first routine, the question is answered if Amiga uses Atari-format everywhere. The answer is NO.
Everywhere it is called, code will differ plotting something to the screen.
There is an interface in the PC-code, but not in the Amiga/Atari-versions.
So, please tell me where we can collect 'cards' like this one:

Code: [Select]

BW_xy_to_offset

  AMIGA: 0D8B0  Atari: normal 216F6, extended 221E0
 
input parameters: D4.w = x, D5.w = y
output: D0.w

result gives an (screen)offset in bytes

for the Amiga the result is aligned to the next bytemargin:
  D0 = (320 * D5 + D4) / 8

for the Atari the result is aligned to the next pixelblock to the left:
  D0 = V_SCREEN_BYTES_PER_LINE(160) * y + ((x / 2) & 0xf8)

Note:
 Amiga label: bruceuncles' 439-disassembly
 Atari: basic offset of program start (version?): 0x14000


This one seems to be the last gamecode-routine.
After it I'd say there's only data left, beginning with Label
'WordsText'.

the upper end:
--------------
The screenbase/framebuffer (1st&2nd screen) locations
are 0x60000 and 0x67D00.

0x7D00 is 32000, so 320x200x16 size.

So probably there's nothing anymore from 0x67D00 + 0x7D00 = 0x6FA00 on.

Now the area before 0x60000:

If you check that line:
00006C   lea   $0005FFFC.l,sp
you'll see, that the area before the screendata gets used for
the stack.

Watching bruceuncle's listing, there are the labels
 lbW058484
 lbW05886C
 lbW058CF8

The first one is located at the border of the last non-zero-datas
and zero-only-datas. But that doesn't mean that this zone is usable.
When I compare the routine using those labels with the Atari, then
this is in the middle of the action. This looks like a RAM-zone.
Can't say yet how far this goes, and how deep the stack will fall.
But for any modification, I'd go for the space after the screens...

[Hungry Horace]

This is all really good thank you, and I appreciate obviously our end goals are different!!

I think the "cards" can just go into a new thread if it helps to keep things clear? I look forward to adding them in!!


Regarding the blank data space, I have kept it "reserved" and all of my new code/data is appended to the main executable.... I'll dig out the memory address I arrive at for you when doing that.

I think am going to design my own data block which is used by my editor to make any game patches /changes.
I'm hoping this will make any modifications easier to place into alternative versions (eg the HTML version) as I appreciate that it's not otherwise easy to put such changes in programmatically.

[Bit]

Amiga screen format wasn't too hard after all
Screenshot doesn't mean that it's running completely.
That's just: passing the initialization stuff by the memory image.
Then let the emulation code flow to paint the init-screen and grab the framebuffer during the wait-for-key-loop. Still, first essential things are running: memory-image fits fine to 439-disassembly, assembler-to-c-emu-conversion works and screenconversion too.
If that all works in the end (like for the pc and the atari), you can later just take this source, write your assembler modification stuff using the corresponding c-functions, and test all with that one - having much more debugging options!

[copse]

Nice work.  What is 439 assembly?

[Hungry Horace]

439 is the version of Bloodwych being used (taken from the SPS number for the disk)

There are three versions in all... 102, 439 and 1927 iirc

There's only one version for the extended levels!  (SPS 43)