Ultimate Amiga

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Bob Base  (Read 456 times)

adrazar

  • A600
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 18
  • Generic Amiga User
Bob Base
« on: October 14, 2017, 01:19:15 PM »

Does anyone know where I can find a pointer to the data structure of a given Bob?
Logged

Volvo_0ne

  • A600
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 32
  • A1200 lover
Re: Bob Base
« Reply #1 on: October 14, 2017, 07:01:35 PM »

In the manual, there is a section entitled "Memory Bank Structures"
which seems to have useful info on the whereabouts of the Bob Images.

If you don't have the manual do a web search for "AmosPro.pdf"

Hope this helps.

also
Code: [Select]
AMOS:Sprite and Icon bank formats
A sprite bank and an icon bank share very similar attributes. They define graphic data which can be drawn onscreen.
4 bytes: "AmSp" for sprites (bank 1) or "AmIc" for icons (bank 2)
2 bytes: the number of sprites or icons to follow
many bytes: the above-counted sprites or icons
64 bytes: a 32-entry colour palette. Each entry has the Amiga COLORx hardware register format, which is 0x0RGB, where R, G and B represent red, green and blue colour components and are between 0x0 (minimum) and 0xF (maximum).

Each sprite or icon has this format:
2 bytes: width, in 16-bit words
2 bytes: height, in raster lines
2 bytes: depth, in bitplanes (1 to 5)
2 bytes: hot-spot X co-ordinate
2 bytes: hot-spot Y co-ordinate
many bytes: width*height*depth*2 bytes of planar graphic data
(taken from http://www.amigacoding.com/index.php/AMOS:Sprite_and_Icon_bank_formats
« Last Edit: October 14, 2017, 07:53:36 PM by Volvo_0ne »
Logged
Transuranic heavy elements may not be used where there is life.

adrazar

  • A600
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 18
  • Generic Amiga User
Re: Bob Base
« Reply #2 on: October 14, 2017, 09:45:37 PM »

Sorry, no :( I was talking about a pointer to the entity created by the Bob instruction. I think (after reading about system tasks, library functions and that sort of things) a proper answer requires having had a look at the Amos-source found on this site.
Logged

SamuraiCrow

  • compile-time wierdo
  • Forum Mod
  • A1200
  • *****
  • Karma: 3
  • Offline Offline
  • Posts: 838
  • Compile-time wierdo
Re: Bob Base
« Reply #3 on: October 16, 2017, 02:46:28 PM »

I don't think AmosPro uses OS structures for its bobs.  It would probably be faster if it did.

What were you hoping to get a pointer to?

Sent from my Prism II using Tapatalk
« Last Edit: October 16, 2017, 02:48:39 PM by SamuraiCrow »
Logged

adrazar

  • A600
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 18
  • Generic Amiga User
Re: Bob Base
« Reply #4 on: October 16, 2017, 04:28:34 PM »

There exists certain blocks in memory which corresponds to previously defined Bobs. These blocks contains information about the Bob's x and y position for instance (the ones returned by X Bob() and Y Bob()). I also expect them to contain the information associated with the Set Bob instruction. Since Set Bob fails to have any effect on already defined Bobs, direct manipulation of the data structure seems like the only way to simulate Set Bob on defined Bobs.

I can't find any trace of the pointers to these Bob structures using pointers provided by Amos, like Sceen Base. But they ought to be somewhere in the computer :P However finding them seems to require looking at Amos from the outside, and not from within. (and that's how I got into reading about the OS).
Logged

KevG

  • A600
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 73
Re: Bob Base
« Reply #5 on: October 16, 2017, 08:01:05 PM »

Not sure this will help you but just type in Listbank in direct mode to return the base address of bank 1 (sprite and bob images).

1. Create a bob then use listbank
2. Create another bob then use listbank

Doing this should give you the offsets and size of the data for each bob image.
However, it would require some work to identify the structure for the bob images.
If your images are say 16x16 pixels and ONE colour then that would give you something to work with.

Kev G.

p.s. Just read your post again and realized that you wanted 'pointers' and not the data structures themselves. How about...   Pointer=Start(1)
« Last Edit: October 16, 2017, 08:04:05 PM by KevG »
Logged

adrazar

  • A600
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 18
  • Generic Amiga User
Re: Bob Base
« Reply #6 on: October 16, 2017, 08:31:30 PM »

@KevG: This is the same misunderstanding as with Volvo_0ne. I want pointers to Blitter Objects. Start(1) is only a pointer to the set of images that a Blitter Object may use.
« Last Edit: October 16, 2017, 08:42:01 PM by adrazar »
Logged

adrazar

  • A600
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 18
  • Generic Amiga User
Re: Bob Base
« Reply #7 on: October 18, 2017, 10:40:47 PM »

It just hit me that I would like access to the Bobs also in a compiled version of the program. This might narrow down where its feasible to look... or not. It depends how much the compiled version differ from the interpreted - a subject in which I find myself to be completely blank.

I believed the pointer could be be dug up from one of the following three locations: tc_UserData, tc_MemEntry or tc_SPReg, in the "task structure" (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node064B.html)
Could some of them be ruled out?
Logged

Volvo_0ne

  • A600
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 32
  • A1200 lover
Re: Bob Base
« Reply #8 on: November 18, 2017, 07:17:04 PM »

I would think that there are more ways than one to write bob code, so I think (as you say) a detailed inspection of the AMOS system coding is probably the only way forward for your answer.

I like to (try) code in AMOS, but I know little about how it work internally.

Hope you find your answer.

V1
Logged
Transuranic heavy elements may not be used where there is life.

adrazar

  • A600
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 18
  • Generic Amiga User
Re: Bob Base
« Reply #9 on: November 21, 2017, 02:15:22 PM »

Quote
I would think that there are more ways than one to write bob code, so I think (as you say) a detailed inspection of the AMOS system coding is probably the only way forward for your answer.

I like to (try) code in AMOS, but I know little about how it work internally.

Hope you find your answer.

V1
Thanks for the kind words :) It appears a bit of encouragement worked miracles this time, as I seem to have found the solution :D It really did help to examine the sources (which I actually couldn't find online before yesterday...)

Here are the ingredients I needed:

Now, in +w.s the register a5 is generally used with the offsets defined in the file "AP20_Vect.s". Among the bob-related names contained in this file we find T_BbDeb = -6172 (likely short for Bob Debut). When checking its content in AMOS
Code: [Select]
BB=Leek(Areg(5)-6172) : Rem Areg(5) contains the value in register a5it turns out BB contains precisely the pointer I have been looking for!

There is one thing that worries me with this method though, and that is how much it can be trusted that Areg(5) will contain the right address at any given time while the program is running.

A simple way to verify the address runtime is by comparing Leek(Areg(5)-476) with Screen Base, as these should be equal when Areg(5) is correct. (-476 is one of the offsets listed in AP20_Vect.s).

However *should* the register Areg(5) happen to contain the wrong address, there does exist a way to recover the right one either way. That's because the address normally found in Areg(5) really is tc_UserData (see my previous post). This address is obtained through the following not-so-simple piece of code:
Code: [Select]
Set Equate Bank 12 : Rem (arbitrary bank number)
Areg(1)=0
TASKBASE=Execall(Lvo("FindTask"))
A5=Leek(TASKBASE+$58)
' Now proceed using A5 instead of Areg(5)

The reason I hesitate to recommend this over using Areg(5) is that it didn't compile very well last time I tried.
Logged
Pages: [1]   Go Up