Ultimate Amiga

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1] 2 3 ... 10
 on: October 18, 2017, 10:40:47 PM 
Started by adrazar - Last post by adrazar
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?

 on: October 16, 2017, 08:31:30 PM 
Started by adrazar - Last post by adrazar
@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.

 on: October 16, 2017, 08:01:05 PM 
Started by adrazar - Last post by KevG
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)

 on: October 16, 2017, 04:28:34 PM 
Started by adrazar - Last post by adrazar
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).

 on: October 16, 2017, 02:46:28 PM 
Started by adrazar - Last post by SamuraiCrow
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

 on: October 14, 2017, 09:45:37 PM 
Started by adrazar - Last post by adrazar
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.

 on: October 14, 2017, 07:01:35 PM 
Started by adrazar - Last post by Volvo_0ne
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.

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

 on: October 14, 2017, 01:19:15 PM 
Started by adrazar - Last post by adrazar
Does anyone know where I can find a pointer to the data structure of a given Bob?

 on: October 14, 2017, 01:12:45 PM 
Started by Hungry Horace - Last post by FOL
Been saying I should start adding general amiga news items, so maybe I can start doing that. We are technically 5 sites rolled into 1. PPSUAE being where it all started and gave me so much pleasure and enjoyment.

Sent from my iPad using Tapatalk

 on: October 14, 2017, 12:49:18 PM 
Started by Hungry Horace - Last post by Hungry Horace

Hi everyone,

Just a word to say that FOL and I have decided to make this site a lot 'cleaner'.

By that, I mean, all links to potentially copyrighted game data has been removed.

This includes;

- The entire Amiga Online section of this site, (a now legacy project anyway)
- The WHDLoad 'game packs' for RetroPie (excluding the .uae configuration files)
- All PSPUAE 'RISS' games.

For the latter, even the links in the Downloads section should be gone, but if you find a rogue link on the board, then it will simply download a '0' (zero) KB size file.

This is partly due to the growth in popularity of the WHDload for RetroPie Project, and I would like us to be able to work with the RetroPie team directly providing support on their board (if they want it), rather than simply ducking under the radar.

There are some projects on this site that already have the blessing of the original authors, such as the Bloodwych Book of Skulls project (via the Bloodwych Facebook group where the original devs are present) and of course AMOS Professional development which Francois Lionet kindly donated the source code for development of.

Amiga In a Box had copyright files removed long ago, so there should be no issues there either.

All other projects hosted here (such as PSPUAE itself) are open-source and form part of this great family of sites.

Although this may cause some disappointment to some, I think the fact that the site has a wider visibility now generally can only be seen as a good thing.


Pages: [1] 2 3 ... 10