Ultimate Amiga
Network Boards => AMOS Language Discussion => AMOS Factory => AMOS Professional Forum => Topic started by: Sergiusz L. on February 28, 2007, 10:17:49 PM
-
question:
Is there any posibility to use AGA chipset in AMOS ?
(any patches...?)
-
There are a few extensions that add some AGA-related functionality.
In order to get full AGA capability support, you'll need to wait for the AGA-specific version of Mattathias Basic that is slated to come out after the SDL version (which seems to be progressing slowly). :-?
-
Can you tell little more about this extensions ?
What they do exactly ?
Can I use screens in 256 color mode ?
Does standard graphics functions like 'paste icon' or 'put bob' or sprites works ?
Yes I already know that some people work on Mattathias but I think they will be working for another years on it... :)
-
Here (http://www.geocities.com/aliensrcooluk/public/Amiga_AMOS_extlist.html) is a list of the extensions available for Amos and AmosPro.
I don't know where to find any of them besides what we have here and on the Aminet.
-edit-
I was about to suggest using the raw AmigaOS function calls to graphics.library using the FD-extension but now I can't find a download site for that extension. :-(
-
I've added the fd extension to the downloads section.
Sorry, but using the Amiga OS function calls is NOT compatible with the AMOS functions. If you want to add sprites and bobs, you'll need to use the Amiga OS functions to create them. AMOS used its own system to create the screens, sprites, and bobs at the hardware level. This method is generally not compatible with the OS.
And I'm working as fast as I can on Mattathias. Sorry for the wait.
-
uhm.. too bad because I don't know OS functions.
Ok then there will not be AGA support :/
---
btw: on which step are you in creating Mattathias ? :)
-
He's got all of the data primatives in place, file handling is in order, and the looping structures have been implemented for a long time.
He's now trying to make an object-oriented extension handler so that people can write extensions to Mattathias in Mattathias. This will allow more users to participate in the development of Mattathias so that development will accelerate.
The Amos-compatibility for the Audio/Visual goodness will likely be added to Mattathias as an extension to keep things flexible. That way we can implement platform-specific features in a portable way so that Amos code can be recompiled for Windows and Mattathias code developed on Windows can be recompiled for AmigaOS and MorphOS.
BTW, what platform are you developing on? Mattathias will likely require more than a meg of RAM since it uses a C compiler as a backend. Most C compilers do enough optimization that about 4 megs fast RAM is put to good use.
The good news is that the optimized code will hopefully run faster than code generated by the AmosPro Compiler. :-D
-
@SamuraiCrow : your list does not contain my personal extension for Amos1.3/AmosPRO that can partially handle AGA chipset. It can be found on Aminet
-
@SamuraiCrow : your list does not contain my personal extension for Amos1.3/AmosPRO that can partially handle AGA chipset. It can be found on Aminet
how well does it work? my experience with AGA extensions to AMOS has not been good.
t'would be best i think if the already existing amos syntax was simply extended to include AGA... and similar commands used to force ecs/aga (some of us would still like to use ECS in Mattathias!)
set display AGA
screen open 0,640,512,128,superhighres for example .... mmm yummy :)
-
in fact, if you want to use 256 colors, my plugin work this way :
- Use 2 screen in 16 colors ( 4 bplanes + 4 bplanes )
- Disable copper
- Use the plugin copper handling
- Use the 2 screen at the same time to display 2x 16 colors sprites/images
- result = 256 colors.
It also handle 2x 16 colors dual playfield with 2 screen using 16 colors each.
-
i'd rather just open a 256 colour display!!
all the bitplane stuff confuses me.... i just want to get my graphics from a 256 colour picture onto the screen!
-
The 2 16-color operations just mean that you have to do everything twice to get a 256 color image. Open 2 16-color screens, make sure all of your 256-color images are divided into the first half in one image and the second half in another image. I'm not sure how BOBs would work, since you'd need the same mask plane for both halves.
-
bobs works the same way than simple paste image
color calculation is done like you explained.
I didn't get time to investigate on opening directly a 256 colors screen because it may cause to rewrite entirely images and bobs ... and I didn't wanted to lose time with that.
-
@freddix,
Very interesting news about your extension, I will have to have a look at it. I am starting over on a new MacBook install of AMOS Pro since my Titanium PowerBook died for the third time and I gave up on fixing it again. I hope the files here will work better during the install than they did last time I tried to install via WinUAE. I kept getting an install error when writing files to the HDD and never made it all the way through upgrading to AMOS Pro v2.0. As this Mac is Intel based I can use WinUAE from Windows XP Pro, instead of VirtualPC which will speed things up about 60 times or more.
Off topic, but congrats on moving to the new server and keeping this site going. I will contribute support when I can (currently retired and looking for second income to survive).
Also off topic, can't wait for Mattathias. It sounds like it is going to be great.
-
I am starting over on a new MacBook install of AMOS Pro since my Titanium PowerBook died for the third time and I gave up on fixing it again.
interesting.... i am considering buying a MacBook Pro in the next few months (although tbh, i think i will be lucky to get one before christmas) and coding AMOS / UAE-usage is one of my major concerns.
Please let me know what emualtor you use and how much success you have with it.... i would be interested in posting a guide for AMOS installation on Macs, as many PC users seem to take the high-end approach of WinUAE for granted.
-
The Intel Mac version of EUAE should support JIT and P96 and other niceties that used to be only available on WinUAE. Plus, since it uses the Mac version of Simple Directmedia Layer, it should take less RAM than running Windows on the Mac since Windows uses DirectX instead.
-
e-uae wip4 has bugs in teh HDF code.
this is why pspuae (based on e-uae) is currently without HD support.
i was wondering if e-uae was the only option for a mac?