The name changes came from the idea to unify all Amiga Classics around Amos Professional.
Here are the first steps completed these days :
Step 1 : Rebuild a flexible Amos Professional Version from the original
|1.1||Rebuild Amos Professional source code Structure to fit requirements for new flexible files structures|
|1.2||Makes the default Amos Professional uses AmosProUnityECS.library instead of AMOS.library|
|1.3||Modify internal source code to use the new library name AmosProUnityECS.library|
|1.4||Update configuration files for compiler, interpreter, editor to uses new AmosProUnity config files instead of the older ones.|
Now Amos Professional Unity reached 1st step in its development.
I can run Amos Professional Unity under the new files structure (similar to the one I prepared for Amos Professional AGA).
More will come soon...
It makes some time I did not post news. But don't stress, project is not stopped. It continues.
Firstly, I want to thanks David Brunet for the new about Amos Professional AGA in the excellent obligement website :
Support him if ou can as he spend many time to concernate news about Amiga and makes them available for us in obligement website. Thank you David.
Secondly, I'm actually working on Rainbow system.
The way rainbows are setup and created is particular and need to decode how it is inserted inside the screens.
It's the 1st thing on which I'm working now.
The second will depend on something totally new, and about what I may be able to tell you more, before the end of the year.
It will require to mind about a globally compatible and "mutual" internal structure for AMOS.
It is linked with the idea to extract all graphics methods and put them all in the AMOS.library.
Theorically AMOS.library "Is" the AMOS graphics library, but many methods (like load/decode iff) are in others libs and are directly dependant on the chipset the program is running.
I'm also working on this point.
So, things continue to progress, even if there are no new version to test.
I'm in the works of 2 parts of the development of Amos Professional AGA.
1. The learning of Amos Profesisonal's native Rainbow system. As it seem to be a bit complex, I read all method associated to Rainbow creation and update. I comment these methods and rename them to "more talkative" names. The objective is to find a way to insert a new AGA Rainbow system using RGB24 colors datas instead of current RGB12 one.
For the moment, I have relabeled some of them :
- Relabeled AmosProAGA_Library.s "RainAd" to "getRainbowD1Adress"
- Relabeled AmosProAGA_Library.s "TrSet" to "SetRainbow"
- Relabeled AmosProAGA_Library.s "RnDel" to "DeleteD1Rainbow"
- Relabeled AmosProAGA_Library.s "RainEr" to "RainbowError"
- Relabeled AmosProAGA_Library.s "TrSynt" to "TRSyntaxError"
- Relabeled AmosProAGA_Library.s "TrDel" to "TRDeleteRainbows"
- Relabeled AmosProAGA_Library.s "RainTok" to "RainbowTokenisation"
- Relabeled AmosProAGA_Library.s "RainTE" to "RainTechnicalError"
- Relabeled AmosProAGA_Library.s "RainEE" to "RainExecutiveError"
- Relabeled AmosProAGA_Library.s "TohhE" to "TohhError"
2. WIth the way Amos Professional setup itself and plugins, I can protect some of my new methods by putting them inside the agaSupport.lib.
In fact, I use a system similar to a list of calls with equates. With that I can call my agaSupport.lib from everywhere inside Amos Professional source code. I can call it from AmosProAGA.Library, from AmosProAga.lib, etc.. This work is for when Source code will be released. I want to be sure that badly intentionned person will not try to win money on a product that may be free for everyone.
Here is the list of the methods actually protected this way :
- Method EcSHam8BPLS moved to AgaSupport.lib internal methods.
- Method EcSPalAGA moved to AgaSupport.lib/SPalAGA_CurrentScreen
- Method EcSPalAGAa4 moved to AgaSupport.lib/SPalAGA_ScreenA4
- Method EcForceFullAGAPalette_ScreenA0 moved to AgaSupport.lib/SPalAGA_ScreenA0
- Method EcSColAga24Bits moved to AgaSupport.lib/SColAga24Bits
- Method EcUpdateAGAColorsInCopper moved to AgaSupport.lib/UpdateAGAColorsInCopper
Some methods were nativelly developed using this principle to allow an expandable system of color effets (and fading):
- Method AGAfade1 ; Fade to black
- Method AGAfade2 ; Fade to specific color palette
- Added "Create Aga Rainbow INDEX, LINES_COUNT"
- Added "Delete Aga Rainbow INDEX"
- Added internal rainbow deletion when leaving Amos Professional.
- Added "=Aga Rainbow Exist( INDEX )"
- Added "Set Aga Rainbow Color INDEX, YLINE, RGB24COLOR"
- Added "RGB24COLOR = Get Aga Rainbow Color ( INDEX, YLINE )"
- Added "Hide Aga Rainbow RAINBOWID"
- Added "Show Aga Rainbow RAINBOWID"
- Added internal getRainColor callable from AmosProAGA.library to get rainbow line color.
Here are the latest news from the last dev. diary update :
- Added new method : "Fade To Aga Palette INDEX, STEP"
- Fix : "Delete Aga Palette INDEX"
- Updated compiler/acData to uses new AmosProAGA_Compiler.config name
- Updated default AMOSPro .lib source code files to be located to src/lib_%libName%/
- Updated default AMOSPRo .lib building scripts to handle new .lib source code files location
- Updated default aext script to use updated .lib building scripts.
- All sources codes are now located inside 'src' directory
- Updated all includes of all assembler source code to use the new directories structures
- Updated all the AmosPRO ECS Tools with the new directories structures : Check_CLib, Get_Chunk, Library_Digest, Make_Labels and Make_Toktable
- Finished the whole update to reorganize source code per dedicaced folders.
- Project roots now contains only batch files and directories for the project.
- agaSupport.lib restructured and organized methods per groups.
The project is now fully restructured and fit what I expected to obtain as files organisation.
It makes code update more easier as everything is clearly identified.
For example, the root of the project does no more contain source code files.
It contains especially all the .batch files (AmigaDOS scripts) to compiles Amos Professional AGA components, or prepare a release build.
All the source codes are located in the src directory and each component is located in a specific sub directory like : AmosPro_Editor, AmosPro_Monitor, AmosProAGA_lib, AmosProAGA.library, compiler, Lib_AgaSupport, Lib_Compact.
All the Amos Professional specific includes are located directly in the src directory to be available for all files.
Here are some screenshots to show you more details
Only one details remain to be completed for the project structure. It's the cut in parts of the AmosProAGA.library that is not yet completed. You can see which components are extracted from the main AmosProAGA_library.s file ...
Next step will be the integration of RGB24 rainbow system. I have in mind exactly which methods will be available. Now this development will be done in 2 parts. The first one to create the methods in the agaSupport.lib, the second one will be to integrate the new RGB24 rainbows datas directly inside the AmosProfessional Copper list system ... The hardest task ...
In order to makes Ham8 pictures works correctly as they uses 24 bits colors precision, I had to improve the AGA colors supports.
Previously copper defined colors using old 12 bits color system. With this system High 12 bits values are automatically copied to low 12 bits values. This makes for example $58A colors becoming $5588AA without having to define low bits.
But with the Ham8, this lead to corruption when colors are not in the real palette but the result of shifting using control bits. I then had to improve the copper list support. To do this, 3 things were required :
- Update storage in internal Amos Professional Screens structures to support RGB24 colors instead of RGB12. As Copper list works using 2 pairs of RGB12 colors to define RGB24, color palette is automatically splitted in 2 groups of 256 colors, each in 12 bits.
- Update global copper list color palette from register 032 to 255 from RGB12 to RGB24.
- Update Screen copper list color palette 000-015 and 016-031 to support RGB24.
The "=Colour( I )' command always return RGB12 color value.
The '=Get Rgb24 Colour( I )' new command return RGB24 color value.
The Load Iff is in progress and get good results but specific values in CAMG that are not clearly documented makes some HAM8 iff pictures not working correctly. I'm working to fix this before preparing a new alpha/beta test update of the binary GitHub repository.
Once this work will be completed, I will have to update the banks to handle RGB24 colors instead of RGB12, and allow them to Save/load datas containing RGB24 color values too.
Here are the latest news concerning Amos Professional AGA updates after a long time without true news.
I have fixed an issue that did makes Amos <-> WorkBench switching no more working. No you can again switch from Amos To Workbench and reverse ... Default key is LEFT AMIGA + A
I'm also working on HAM8 support for Amos Professional AGA and it get good progress.
The main challenge was interesting because HAM6 and HAM8 own differencies in the way they are handled by the graphic chipset..
HAM6 uses bitplanes 0-3 for true colors and 4-5 for control (fakes colors shifting update).
HAM8 uses Bitplanes 2-7 for true colors and 0-1 for control
These are reversed working behaviour from one to the other.
Due to this, AMOS Professional AGA draws to true colors in HAM8 will lead to makes AMOS Professional AGA write in the control bitplanes ...
I had to find a trick to fool AMOS Professional and not have to rewrite everything. And in fact, the solution was really easy to deploy !
I just had to update 2 datas areas.
1. Makes the BitMap structure bitplanes content being shifted/Rolled by 2 bitplanes, giving this order : 2-3-4-5-6-7-0-1.
2. Makes the EcCurrent(CurrentScreen) bitplanes structure content being shifted/rolled by 2 bitplanes too, giving this order : 2-3-4-5-6-7-0-1
3. Leave Copper list display bitplanes in the order 0-1-2-3-4-5-6-7
With 1. All graphical operations (ink, draw, plot, etc...) now works perfectly with the correct colors as AMOS uses BitMap/Layer and OS for these operations.
With 2. , the CLS operations that directly uses BLITTER, clear with the correct colors.
Now, I will have to update the AMOS Professional AGA IFF Loading methods to correctly handle HAM8 mode with correct colors settings.
HAM8 Should soonly be available for tests.
Starting a new employment as Software qualification engineer takes much energy.
It makes me literraly out. If forces me to put the Amos Pro X project in standby until my adaptation to the new job will be complete.
I hope to restart soonly.