Ultimate Amiga
Network Boards => AMOS Professional Re-Development => AMOS Factory => ClassicAMOS Development => Topic started by: bruceuncle on June 12, 2013, 12:37:35 AM
-
I'm currently analysing and documenting the AMOS Pro loader - AMOSPro (relevant sources +B.s, +Verif.s, +InternalJumps.s and +LibOffsets.s). This is fascinating stuff and has thrown up some possibilities we maybe hadn't considered before.
At the same time, james666 has been looking into AGA for AMOS. And run into the usual problems associated with the AMOS Pro screen and associated data structures being incompatible with AGA structures. We've been corresponding on this subject for a while and discussing possible solutions.
If you haven't had a look at how AMOSPro starts everything up, this is a quick high-level overview:
The loader is in two code hunks. One is permanent (the interpreter and some internal library functions) and one is discarded after use (the loader and linker).
The loader/linker hunk takes care of:
- Loading and initialising amos.library plus a few of the essential Amiga libraries.
- Allocating and initialising the AMOS data structures (base address pointed to by a5 with both positive and negative offsets).
- Iterates through the AMOS Extensions listed in the editor config file. It pays particular attention to AMOSPro.Lib (for obvious reasons). But I haven't yet figured out what the heck it's doing with those codes in the source that generate Toktab_Verif.Bin. It all takes time...
- It calls Library_Patch, which adds the library functions to AMOSPro.Lib's list of functions. This is needed as that library is split between the library itself (+Lib.s and +ILib.s) and the loader (the permanent hunk of +B.s). So those functions are added here. They're the ones defined using the Lib_Int macro.
- Each loaded library is then subjected to a relocation pass which looks for those AFLINE instructions (as tokens). Each is decoded and, as all the necessary libraries are in memory at that stage, the appropriate instruction and absolute address are inserted as replacements for the original AFLINE instructions and the one or two words following them.
- The relocation action taken depends on whether the library is AMOS Pro V2.0 or an earlier one. This is identified by the AP20 token in the 'new' libraries.
- The earlier libraries are just relocated as above. In addition, a table is used to re-map and replace any 'old' system instruction numbers with 'new' ones.
- The V2.0 libraries also have each instruction's parameters examined (if any) and the appropriate parameter jump addresses are inserted into the functions. These jumps replace those GetP markers in a V2.0 library put there by the Lib_Par macro.
- I haven't looked at the compiler yet (I'm leaving it until last) but comments in +equ.s suggest it does a similar load and link. But against discrete code chunks for each instruction and using relative addressing instead of absolute.
From the above, you can see that AMOS Pro is already doing re-mapping depending on context. The interpreter also does similar re-mapping when it encounters instructions like Double Precision.
From the work that james666 has done, we know that the existing AMOS screen, window and associated data structures can't cope with the extra data storage required for AGA. At least, not without a very messy solution and the inevitable slow down as new storage areas are re-mapped "on the fly".
So, to get around the problem of retaining compatibility with previous AMOS programs and extensions, there would appear to be two courses we can take:
- Give up on compatibility and rewrite an AGA-only version of AMOS.
- Explore the possibilities presented by re-mapping screen structures "on demand'.
We don't like the idea of option 1 as I think the appeal would be very limited.
Option 2 would use techniques already present in the loader and interpreter. (And presumably also in the compiler. But note that I haven't analysed that yet.)
So how would it work?
I've been thinking it over from the programmer's point of view. I.e. the real AMOS User. They're used to context switching in their existing instruction sets. So giving the choice of AGA or non-AGA with something like a Set Aga command at the start of a program would come as no real surprise. We're already used to Set Buffer, Set Accessory, etc.
From the programmer's perspective:
Advantages
- Existing software and extensions would still work (non-AGA) without any changes. This includes any system calls and/or direct access to the AMOS data structures. They would remain as they are.
- The existing AMOS Pro included libraries can be easily converted as we have the sources. Only +B.s, +ILib.s and +Lib.s would require any major surgery anyway.
- Authors of any new extensions can make the choice between AGA and non-AGA simply by choosing the appropriate "compatibility token" - we would suggest using the existing AP20 for non-AGA compatible and AP21 for AGA compatible. If they choose AGA, then the new AMOS AGA data structures would be automatically re-mapped for them. As this is done by the loader, there's no impact on performance. The AGA structures just sit there until the interpreter sees a Set Aga instruction. Then it just switches the structures and remaps any related calls. Note that this is done at program Test time, so again, there's no performance impact when a program is actually running.
- Most existing 3rd-party extensions could convert to AGA compatible as long as they don't use any graphics (to be defined!). The conversion could easily be achieved even if the sources are not available (simply change the AP20 token to AP21 with a hex editor, or insert it for an earlier library).
- Whatever the programmer's choice, hardware AGA availability is the governing factor. If the loader does not detect an AGA chipset, the Set Aga instruction throws an error at Test time.
Disadvantages
- Some significant existing third-party software would need re-writing if it wanted to take advantage of AGA. Eg. TOME.
- More complex environment for the hard-core programmers, extension writers and assembler fans. But at least the structures and code would be available and documented.
- Some memory size bloat. But as we all seem to agree, that's not really an issue these days.
We (james666 and I) are very much in favour of this approach for the post-bug-fixing phase of development.
What does the forum think?
-
Sounds like a sensible solution... Personally, I think TOME needs a re-write anyway (hello... 8x8 tiles??) and/or a number of the better functions of extensions should be "borrowed" an included in AMOS directly anyway...
I can envisage how even using a SET AGA command and suitable AGA CHECK , a program could be witten to work on both AGA and EcS, and commands such as LOAD IFF could be shared bit simply point to a different file depeding on some program initialisation
-
Sounds like a sensible solution...
Thanks Hungry Horace :) . The more I think it through, and the further I get into the analysis, the more I like the idea myself. AMOS already does similar so the 'outline' of what would be needed is already there. And two separate AMOS data structures (the AMOS original and the AGA extra) means no change for existing programs and extensions no matter how they used the data or system functions.
Personally, I think TOME needs a re-write anyway (hello... 8x8 tiles??) and/or a number of the better functions of extensions should be "borrowed" an included in AMOS directly anyway...
Erm, well, if the original authors agree there's a lot to 'borrow' into the new AMOS.
If the authors don't agree, well we can always just rewrite their concepts from scratch. I've done some cursory exploration of some of the more useful extension functions and there's nothing particularly 'commercial in confidence' about them. Some of them seem to have come from what people did using the AMOS 'Machine Code' instruction set anyway in AMOS 1.3 programs.
I can envisage how even using a SET AGA command and suitable AGA CHECK , a program could be witten to work on both AGA and EcS, and commands such as LOAD IFF could be shared bit simply point to a different file depeding on some program initialisation
I don't want to clutter the concept with too much detail at this stage. Just a "Do we agree this is the way to go?" question.
However, you can take it for granted that there would be instructions supporting AGA beyond simply making the existing graphics instructions work. You mentioned one yourself ;) : an Aga function working similarly to the existing Ntsc one. It would just check both hardware and loaded library compatibility. We would also need stuff to do things like set sprite resolution and anything else that may only make sense in an AGA environment.
So, for example, you could code something like:
If Aga
Set Aga
Sprite Lowres
Screen Open 1,320,256,256,Lowres
Dim G_PAL(255)
Else
Screen Open 1,320,256,32,Lowres
Dim G_PAL(31)
End If
And I really want to see that cute AGA animation in the sources (/Dot_AMOS/AA_Logo.AMOS) pop up when AMOS starts in an AGA environment... 8)
Back to the here and now. The main work at the moment is understanding what we've got and the bug fix phase. But that won't stop any AGA work going on at the same time. (And a special thanks to james666 for his input.) I'd just rather we nailed down how it's going to be integrated now, rather than tearing our hair out later.
I'll be publishing analysis as it proceeds. In my usual fashion "real soon now". ;D (It takes time, it takes time...)
-
Re:TOME extension additions
I agree with Hungry Horace. The TOME command structure is more useful than the TOME extension itself is. TOME uses blitter-scrolling and a row of Icon Paste equivalents to do its tile-maps. This causes a spike in blitter activity which can lead to delays.
After having read the documentation to ScrollingTrick (http://aminet.net/package/dev/src/ScrollingTrick) and the included C sources, I think that we need a way to make a seamless wraparound from the bottom of screen memory to the top using a custom Copper-list. Normally this is done by a Cop Wait instruction at the end of the last row of screen memory followed by COP MOVEL for each bitplane pointer at the top of the Screen RAM.
Also, we need to look into interleaved bitplanes since ECS or AGA have much wider strides for bitplane widths. This allows all of the bitplanes to be allocated in one big chunk of Chip RAM starting with row 0 of bitplane 0, followed by row 0 of bitplane 1, up until row 0 of bitplane n where n is the number of bitplanes in use. It is only at this point that row 1 starts for bitplane 0, followed by row 1 bitplane 1 and so on. The advantage of this is substantially faster Icon Paste instructions since they can be accomplished with a single tall blit rather than one for each bitplane. This reduces the number of blitter interrupts and/or blitter waits necessary. It comes with Kickstart 3+ but can be implemented in Amos without the need for Graphics.library 3+.
Also, will there be a Set Ecs command to widen the screen allocation capabilities?
-
Also, we need to look into interleaved bitplanes since ECS or AGA have much wider strides for bitplane widths. This allows all of the bitplanes to be allocated in one big chunk of Chip RAM starting with row 0 of bitplane 0, followed by row 0 of bitplane 1, up until row 0 of bitplane n where n is the number of bitplanes in use. It is only at this point that row 1 starts for bitplane 0, followed by row 1 bitplane 1 and so on. The advantage of this is substantially faster Icon Paste instructions since they can be accomplished with a single tall blit rather than one for each bitplane. This reduces the number of blitter interrupts and/or blitter waits necessary. It comes with Kickstart 3+ but can be implemented in Amos without the need for Graphics.library 3+.
Thanks for the info. I'd read about this but hadn't realised the implications. Makes me wish I wasn't bogged down so much with understanding and documenting the AMOS framework. I think I'll have to put some 'play time' aside and have a look.
Also, will there be a Set Ecs command to widen the screen allocation capabilities?
Don't quite understand why you'd need one. Doesn't AMOS Pro assume that as the default anyway? Or do you mean those screen resolutions that make my eyes hurt? Keep in mind that I'm an Amiga hardware novice so I need some of these things explaining. :-[
At this stage I'm not so much interested in all AGA details (but they're all noted) as in ensuring that we get a stable and extensible framework for AMOS. Without that, we'd be getting into a very messy state. The existing AMOS framework isn't all that bad and is reasonably well structured. It's too tightly coupled for my liking but I can live with that.
By using context switching for AGA (which fits neatly into that existing framework) we get flexibility. The only cost is ensuring that the AMOS AGA data structures are extensible. I.e. "Woe betide he who uses fixed arrays for any new stuff.", "Don't mess with the data structures or we'll cut your hands off!", "Linked Lists are my best friend.", etc., etc. ;D If we can get that right, it means any future development can easily extend within the new AGA context or, if absolutely necessary for some special purpose, create a new one. That would be a big step to take as you'd also have to add some suitable switching and functionality to what would already be available within amos.library.
To make that concrete with an example, assume that most of the current clamour in AGA wish lists seems to be for 8 bitplanes and 256 colours at current resolutions. And assume that is what we implement for AGA support. Then suppose you want to add in AGA productivity resolutions. You'd already have most of what you need just by using the AGA context switch. If you needed more, the AMOS AGA memory structures can be extended to accommodate what you need. If that solution meets your needs, no problem. If it doesn't, canvass the community for support for a new context. Add a new library token, something like AP22 or whatever, and create your own. Backward compatibility would still be assured.
Unless, of course you're aiming to include all AGA functionality in one hit. In which case, the above example is irrelevant. I'd be happy either way, it's just a case of who wants to take on the tasks involved?
But all this depends on a stable community-owned base version. So that's why I'm up to my neck in the framework instead of doing interesting and exciting stuff. ;)
-
Don't quite understand why you'd need one. Doesn't AMOS Pro assume that as the default anyway? Or do you mean those screen resolutions that make my eyes hurt? Keep in mind that I'm an Amiga hardware novice so I need some of these things explaining.
OCS and Kickstart 1.3 allow a maximum scrolling width of 1024x1024 pixels. With Kickstart 2 and ECS that was lifted to 32768x32768. If we had an ECS enhanced mode that would also be included in AGA, that is the only significant difference I'd need. It's used for making faster-scrolling tile-maps and bitplane interleave.
-
I have to read all of this thread from beginig to end to know exacly what its cooking here but only the idea of AGA posibilities in Amos for me its simply Amazing!!!!
A dream for me, say many thanks to the people are involve in this projects and my best whises can make reality.
King of regards
Amiten
-
I agree with Amiten. You guys are making great progress :)
-
Looks good - I think you should drop TOME it was ok for its time but doesnt offer anything intresting all the scrolling routines can probably written alot quicker using regular amos commands
-
If you included wraparound etc there comes a point where what is left for the progarmer to do this routines should be writen by the author of the game or app etc not dumbed down into amos commands - if you go to far this is no longer Amos
-
Looks good - I think you should drop TOME it was ok for its time but doesnt offer anything intresting all the scrolling routines can probably written alot quicker using regular amos commands
I'm not sure that's true!! I've seen very impressive scrolling using TOME on YouTube (and tried a little of it myself) and it was certainly far better results than I have ever managed!!
I am not sure i agree about "dumbing down" by adding more commands / functions.... programming in AMOS should be about easily realising a vision - with the minimum of amount of "complex" coding needed - it's things like TOME that make this possible IMHO. If you chose to go the "long route" , that's obviously ok (and may have benefits) but can be detrimental to productivity.
-
as far as I know TOME uses screen copying?
with wraparound you can use hardare scrolling the speed you can program you could probably write 8way wraparound in a day in Amos.
-
I honestly satisfied to be able to use all resolutions and colors offered AGA mode,
besides all the functions that you have as originally Amos even AGA bobs and sprites a. for me this would be amazing That.
okay, I'd be moving Tiles AGA fantastic, but for me I do not see indispensable if is to difucult to inplement.
what for me if it would be very important is that all the result of using the new capabilities of the Amos AGA, the compiler compile it without problem, whether it would be a great pity and almost for me would be meaningless without being able to use AGA compiling the result.
Good look with the Work I hope one day not so Far Can use AGA in Amos definitely.
King Of Regards
Amiten
-
as far as I know TOME uses screen copying?
with wraparound you can use hardare scrolling the speed you can program you could probably write 8way wraparound in a day in Amos.
I haven't looked into the TOME sourcecode, but if it did it the fastest (and logical) way it would use BOTH methods. The fastest way to create large scrollable levels (think Super Mario World, Sonic The Hedgehog, Turrican etc.) is to use hardware scrolling then paste the next set of level tiles just offscreen.
I tried doing it purely in AMOS a few years back and couldn't get it working properly (or fast enough).
I agree with Horace. AMOS is all about making it easier for the programmer, and adding new commands to give them access to previously unavailable functions is always going to be welcome.
Yes, you could code the equivalent routine in AMOS, but dedicated commands will always be faster (as long as they are written by competent 68000 ASM programmers).
-
AGA would be great for AMOS to allow the basic building blocks and obvious predecessor of AMOS, AMOS AGA and TOME is ok but anything beyond this should stay with extentions and be warp amos or something.
This is in no way a criticism of anyones work its just with time exploring intresting routines written in amos this has realy made me enjoy using amos and if the course of amos is to then simplify it doesnt seem great.
-
Just a quick update: This thread is going off on two tangents. TOME extension usability/upgrading, and AGA/ECS updates to AmosPro.
TOME rewriting is off-topic for this thread since it doesn't support AGA or ECS-specific features. It does need discussion so let's move this to a separate thread.
Now back to the AGA/ECS features:
Interleaved bitplanes work best on ECS or AGA because they require a y-stride that is equivalent to a single row of pixels containing all bitplanes one after another. This stride exhausts the 1024-pixel maximum on OCS and therefore would warrant an ECS mode since interleaved blitting would be faster on all of the Icon Paste instructions that could take advantage of the bitplane interleave, as well as any other opaque blits.
As far as the ECS modes that hurt BruceUncle's eyes, I assume he's talking about the 4-color super-hires modes. Since these are of such limited usability, I wouldn't lose any sleep over these being left out anyway.
This brings me to the next subject: Should we focus on getting full ECS scrolling support and interleave implemented first or should we tackle AGA specific attributes all at once?
-
As far as the ECS modes that hurt BruceUncle's eyes, I assume he's talking about the 4-color super-hires modes. Since these are of such limited usability, I wouldn't lose any sleep over these being left out anyway.
They are hardly ever used - but I think that's down to few people knowing how to actually activate the mode (I think Toni Wilen mentioned how to do that over on EAB recently).
Do we lose the ability to have sprites when super-hires mode is on?
This brings me to the next subject: Should we focus on getting full ECS scrolling support and interleave implemented first or should we tackle AGA specific attributes all at once?
If AGA uses similar mechanics as ECS, I'd suggest doing ECS first then AGA.
-
Thanks you to everyone for the responses. Any encouragement is always welcome.
Just a quick update: This thread is going off on two tangents.
Yep. They usually do ;D .
But seriously, this topic is about context switching in the AMOS framework. What we can do with extending AMOS with context switching in place should really branch into other specific topics. They will need to come together at some time in the future so I know what's needed in the framework.
I assume he's talking about the 4-color super-hires modes
Spot on ;D
Back to earth, I can see now why we might need both Set Ecs and Set Aga as context switchers. Which is mainly the sort of stuff I needed to know to pursue this concept.
Bear in mind that context switching need not be a total replacement of the existing V2.0 AMOS data structures. Only those parts that require extra data storage outside of the existing limits.
As an example, and food for thought, consider the problem of 6 bitplane addresses in the current structure. This doesn't necessarily mean setting up yet another fixed array of 8 bitplane addresses and switching context to that. As I made plain earlier in this thread, let's not make the same mistakes as the original AMOS did. Instead consider using the first address of those 6 bitplane pointers as a pointer to a simple linked list containing just two long words:
That's infinitely extensible (okay, okay, it's probably a bad example for extensibility) but you get the idea? The code to handle the pointers just needs to check for an AGA flag and switch to code to handle the linked list instead of the fixed array. At the bare minimum suggested above, the memory needed is 8 bytes which fits neatly with the Amiga's AllocMem() base unit of allocation (8 byte chunks). And it doesn't actually extend the existing structure at all. It just adds some temporary extra storage (which is fine as long as the programmer remembers to clear it down afterwards!). I'm particularly bad at pulling examples out of thin air. So take the above with the proverbial grain of salt. But I hope it gives you some idea of where we should go with this.
The same sort of approach should be applied to the code as well. Whilst we're not as concerned about memory usage as we used to be, it may well be preferable to switch code blocks as required, or switch within existing code, rather than have (up to) three sets of routines permanently switched depending on context.
In any case, it's time to emphasise what we're doing and where we're going with all this:
- First, we fix the bugs!
- Second, we fix the compiler!
- Third, we add context switching and all hell breaks loose!
What I wanted to promote here is the realisation that any work done on AGA and specialised ECS modes must take into account how those modes are going to be integrated into the AMOS instruction set.
Before anyone gets too far down those tracks, think hard about what the AMOS instructions would look like:
- Would the majority of the existing AMOS graphics instruction set suit with only different parameter range checking? Eg. is Screen Open still suitable in its current format or does it need a different format added?
- Think carefully about the format of any new graphics instructions you would need. Do they fit the AMOS "look and feel"?
- How far is "too far" in trying to integrate instructions that may be too specialised for "everyday" AMOS usage?
- What impact does any specialised screen mode have on the existing instruction set? Eg. How difficult is it to print text to, etc.? Note that AMOS Pro V2.0 already checks for an AGA chip set to ensure that your sprites don't suddenly appear in Hires. Apply the same sort of thinking to what you might affect.
I'll be getting on with documenting how AMOS fits all this together so you've all got a clear picture of what's involved. If you haven't looked into this yourselves, some of it is quite interesting and highly relevant to our plans for AMOS.
-
As an example, and food for thought, consider the problem of 6 bitplane addresses in the current structure. This doesn't necessarily mean setting up yet another fixed array of 8 bitplane addresses and switching context to that. As I made plain earlier in this thread, let's not make the same mistakes as the original AMOS did. Instead consider using the first address of those 6 bitplane pointers as a pointer to a simple linked list containing just two long words:
That's not bad, but perhaps keep the current format with only the last of the current bitplanes pointing to others, for example:
- Bitplane 1 address
- Bitplane 2 address
- Bitplane 3 address
- Bitplane 4 address
- Bitplane 5 address
- Bitplane 6-8 address block address
The addresses for bitplanes 6-8 would be stored as a block elsewhere in memory...
- Bitplane 6 address
- Bitplane 7 address
- Bitplane 8 address
Thus anything with 32 colours or less functions as normal, with anything going above that needing minor modification. Perhaps that is a bad idea too? ???
-
Perhaps that is a bad idea too?
No, not a bad idea at all. Just not necessarily the best way to go.
It's just easier to code if both 6 and 8 bitplane address lists can be accessed in simple iterations. I.e. iterate the array for (up to) 6 bitplanes, or iterate the linked list where more than 6 bitplanes are needed.
james666 could probably answer this better than me (or anyone else for that matter ;D ) as he's been coding stuff in this area. The code gets pretty messy when you start trying to update copper lists and deal with a non-linear array at the same time, which is what I understand james666 has been trying. Usually ends with a guru!
For maximum flexibility, I'd prefer to stick to linked list extensions and/or complete replacement structures where necessary. For instance, I hadn't considered those ECS modes until they were pointed out to me. If we don't stick to simple, consistent and extensible graphics data structures, it can get very messy when we try to expand functionality in the future. The resulting code should also be written to be easily understandable (although we are talking Amiga hardware here ;) ) and modifiable. We won't always meet those criteria but that's what we should be aiming for.
The limitations of the original graphics data structures is why AMOS V2.0 is giving us a headache when we consider AGA. We just shouldn't make similar mistakes for any new additions.
My main problem is not getting my hands dirty with some hardware programming. So it could reasonably be said that I'm talking out of my posterior ;D . But if I get distracted with that, I'll never get the stuff I've already committed to out of the way. (Remember the AMOS Reference manual?) And the understanding and documenting of the framework is currently more critical than the details of how particular changes to AMOS are coded.
All the changes for ECS speciality modes and AGA modes will be going into the amos.library and AMOSPro.Lib, not into a new extension. So everyone involved needs to understand how that all works and how it's used by the loader, interpreter and compiler. That's why I'm emphasising that people should consider what format any necessary AMOS Basic instructions should take as well as concentrating on the "how to code it". You'll see what I mean (I hope) when I release the docs on how it all fits together.
We're in the lucky position of having a system for which 99% of it works fine. Within the original (OCS) constraints it's relatively stable and easy to expand. We should aim to keep that same flexibility with enhanced ECS and AGA modes.
By the way, has anyone else looked at bug fixes yet? ;) That's still our primary objective for this phase of development. AGA was supposed to be a later phase. But I can see it creeping into this one (and don't object to that at all). Let's get our priorities back on track. Get those bug swatters out!
-
Re: Arrays of bitplanes in Amos' structures
The proper way to do it on AmigaOS was to use a pointer to a BitMap structure (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node05DC.html#line45). Note further that the array at the end of the BitMap structure can be allocated fewer or more than 8 pointers because it is always at the end of the structure. Also, the pad word is used by implementations of Chunky modes and should be initialized in the future AROS 68k version of AmosPro.
-
By the way, has anyone else looked at bug fixes yet? ;) That's still our primary objective for this phase of development. AGA was supposed to be a later phase. But I can see it creeping into this one (and don't object to that at all). Let's get our priorities back on track. Get those bug swatters out!
Before anyone else jumps on the bugfixing wagon, has anyone documented the current bugfixes that have been done?
Secondly, we should document who is working on fixing which bug, otherwise two people could end up working on the same bug with one person potentially wasting their time.
I'll look at the Limit Mouse bug if noone else has started working on it.
-
Re: Arrays of bitplanes in Amos' structures
The proper way to do it on AmigaOS was to use a pointer to a BitMap structure (http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node05DC.html#line45). Note further that the array at the end of the BitMap structure can be allocated fewer or more than 8 pointers because it is always at the end of the structure. .
Yeah, I would definitely be inclined to use the official Bitmap structure for the new AGA modes. It makes the screen swap logic much cleaner and it's easier to leverage the Amiga library functions. Amos already uses graphics.library and layers.library for drawing primitives but does it in a very messy fashion, with bitplane pointers from its own Screen structure being copied to a dummy OS Bitmap structure after every screen swap.
Regarding support for interleaved bitmaps, given that this will need just as much rewriting of the Amos.library as AGA support, it makes sense to plan both together when we think about new structures. Note that if we want to take advantage of interleaved blitting we also need to store bobs/icons in interleaved form.
-
Regarding support for interleaved bitmaps, given that this will need just as much rewriting of the Amos.library as AGA support, it makes sense to plan both together when we think about new structures. Note that if we want to take advantage of interleaved blitting we also need to store bobs/icons in interleaved form.
True enough. And along those lines, we need to consider that the .abk files containing Icons and Bobs may need an alternate loader and saver if we want to save them in interleaved format as well. However, since files are generally buffered to any memory first and then copied to Chip RAM as a scatter-load, it might be able to save the bitplanes in the old file format without too much runtime cost, just by processing the conversion at load-time and save-time.
-
I've checked the AmosPro Manual and it documents the Icon and Sprite/Bob banks quite explicitly as non-interleaved. I guess that means that we'll have to have new formats for the new interleave capabilities and palette depths.
-
Whilst I am aware of what interleaved Bitmaps are for... Could someone please explain to this layman the advantage of supporting them?
-
It removes the need to do multiple blits for a single image. This removes some processor overhead in the form of interrupts to speed up opaque blits so the Screen Copy command and the Icon Paste command will go faster.
-
It removes the need to do multiple blits for a single image. This removes some processor overhead in the form of interrupts to speed up opaque blits so the Screen Copy command and the Icon Paste command will go faster.
Thanks SamC.
So simply by extracting tiles "nomally" but storing them and pasting as interleaved, there could be a small speed gain?
Seems too good to be true! (I am very on favour of any speeding of Amos performance)
-
I've checked the AmosPro Manual and it documents the Icon and Sprite/Bob banks quite explicitly as non-interleaved. I guess that means that we'll have to have new formats for the new interleave capabilities and palette depths.
Don't worry too much about *.abk formats. They were changed (slightly) for Pro V2.0 and we can change them again. Eg. Resource Banks now allow more than two sections (to allow DBL progs to be stored) and use both packed and unpacked bitmap formats for the images. François was very fond of using "magic" tokens to identify the changes (eg. his birthday for a packed bitmap image). I thought that maybe "magic" meant something slightly different in French, but apparently it means "magic" ;D
You might need to consider extending the Set Xxx instructions to indicate what AMOS should expect. That would solve the AMOS AGA problems. The problem then comes in getting pre-AMOS AGA progs to reject such a bank. So you could also consider using one or more new Bank identifiers. If you do, note that only the first four characters are checked in the code. Eg. "IlbSprte", "IlbIcons", "Ilb.Pac", etc.
As long as existing software and extensions can seamlessly be used with the new AMOS, there's nothing much else to limit what new features you want to add. The interpreter and compiler just need to reject any new formats if they're running a non-AGA environment. Where environment means both hardware and software extension compatibility. Using a set (sic) of Set Xxx instructions should alleviate any potential problems.
-
@HungryHorace
You are correct. The limitation is that the width of the image may be too wide for OCS to handle. ECS or AGA will handle bitplane interleave just fine.
@Thread
For that reason, I'd propose that the on-disk format for icons and BOBs will not change for ECS, only the loader for Icons will change to support interleave. AGA, however, will require an expanded palette with more and larger entries for the 256 entries of 24-bit color in addition to the interleave loader.
-
Hi how is goes this amazing project? Any news? Follow with the good works
King of regards
-
Hi how is goes this amazing project?
Thanks for the interest. It is going slowly as what we are proposing will take some time. Especially as anyone involved is likely to be doing stuff in their spare time (which can be a rare commodity these days ;D ).
I'm documenting the loader, interpreter and compiler. It's complex! But we need to understand it fully before we can make any major changes (like adding AGA).
Bug fixes are separate from adding AGA (and there hasn't been much feedback there yet!) but I would like to see a bug-free AMOS Pro (minus AGA) released as soon as we can manage it.
AMOS Pro already recognises AGA hardware even though it isn't implemented yet. It does this to ensure any AGA registers are set correctly to prevent non-AGA software suddenly turning on hi-res sprites. I haven't found any other references yet but it's early days. The original AMOS team were certainly well aware of what they were doing.
Another example is the problem of modifying code (relocations, etc.) on a system with a 68020 or higher. These have an instruction cache which must be flushed after changes are made to avoid the wrong instructions being picked up from the cache instead of memory. So they flush the cache through an operating system call.
They were well aware of where the Amiga hardware was heading back then.
Will keep everyone posted on progress but expect a few "quiet weeks" while we actually do some work rather than posting ;D.
As encouragement, I've attached a PDF of the loader/interpreter docs up to the start of where the AMOS libraries (extensions) are loaded. I'm currently in the middle of the next section. The diagrams are just about ready (along with multiple sketches of what's happening) just got to put it in Visio (wash my mouth out!). That section looks like the heart of where any context switching code for loading would need to go.
Please regard this attachment as very-much-work-in-progress (although constructive suggestions always welcome).
It all takes time :o ;D
-
You've done a great job on that documentation, bruceuncle :)
-
You've done a great job on that documentation, bruceuncle :)
Thanks mate. All encouragement helps ;)
The next bit's the fun bit. What it does loading and relocating a library is very interesting to say the least! I'll keep feeding it out on the forum as I work through it.
I still haven't decoded what all those 4 byte codes for each token are for (in +Toktab_Verif.Bin). When the context is that a program is running, they're swapped for another (code-generated?) table for "rapid tokenisation", then swapped back when testing or editing is the context. I haven't pulled all the tokenise, test and run code apart yet but it will be in there somewhere. I can't see the original AMOS team hard-coding them all, so how did they derive them? More importantly, what do we use for any new instructions? Is there any benefit in applying the technique to other V2.0 libraries and extensions?
It's hard not to go wandering off chasing through the sources instead of sticking to "start at the beginning and work through to the end". ;D
I'm only intending to document Loader/Interpreter and Compiler to this level of detail in case anyone wondered if I'd found a job for life! amiga.library may get the same treatment if necessary for AGA conversion. I think we all need to understand how this core of the AMOS system really works before we try carving new stuff into it. We're going to need new and modified AMOS Basic instructions for an AGA version and they should go into amiga.library and AMOSPro.Lib to prevent fragmenting the system under AGA.
More next week.
-
Just the next instalment of the AMOSPro analysis. I'm currently in the middle of the code relocation and token table parameters bits. That resolves the Rxxx macro-generated and "GetP" tokens in a library's code. This attachment goes to the point where everything is loaded and the Routine Address Tables created.
Please treat this as still in the very-much-work-in-progress state ;)
But there should be enough in the document to see how context switching can be easily accomplished:
- There are three spare bits in the LB_Flags byte in each library. So plenty of room for AGA and ECS flags. I don't know enough about the hardware yet to know whether we would need to treat AGA and ECS switches differently. So would we need a flag for each?
- Any extra Routines required for AGA (and/or ECS) would be added to AMOSPro.Lib. These will be resolved to a Routine Number and a Routine Address when the library is loaded. Unfortunately, a context switch cannot directly swap these Routine Addresses in the Routine Addresses Table as each Routine's code would have to be relocated all over again if we did.
- We can, however, add a Switcher Table. In the source for amos.library this would be hard-coded and just contain Routine Numbers for each entry:
- Original OCS_Routine_Number
- Related AGA_ECS_Routine_Number
- If it's ok to use AGA or ECS (hardware check) the loaded libraries would be scanned to see if their AGA/ECS flags are set. These just indicate compatibility, not that the library contains AGA/ECS code. If all the libraries check out (software check) then AGA or ECS functionality needs to be available. This must be done before relocation so it would slot in after the Library_Patch() routine in the existing source.
- If the previous steps indicate that context switching may be required, a global flag would be set to indicate this and the Switcher Table would be built. This would only apply to AMOSPro.Lib as long as we do AGA/ECS in that library only. Each entry to contain:
- OCS_Routine_Number
- AGA_ECS_Routine_Number
- Code for a jmp OCS_Routine_Address instruction (the one in the Routine Addresses Table before this Switcher Table is built)
- Code for a jmp AGA_ECS_Routine_Address instruction (the one in the Routine Addresses Table before this Switcher Table is built)
- A blank entry to hold code for a jmp Address instruction. This is the Switcher Instruction.
Each entry is initialised with Routine Addresses from the Routine Addresses Table. The blank Switcher Instruction entry is initialised to be identical to the OCS jmp OCS_Routine_Address one. The original entry in the Routine Addresses Table would now be replaced with the address of the Switcher Instruction.
A global flag would be used to indicate the current state of the switcher. Initially it would be cleared to indicate OCS. So the initial effect is that nothing is changed. Except that now the original instruction's Routine Address points to a jump to the OCS Routine.
- Library relocation can now be done exactly as it already is in the existing source.
- When a switch is required (i.e. when a Set Aga or Set Ecs instruction is encountered) the Switcher Table is iterated, simply moving the jmp AGA_ECS_Routine_Address instruction into the Switcher Instruction for each entry. The global AGA/ECS flag is set to indicate the Switcher Table's state. This must be followed by a jsr Sys_ClearCache to clear the processor's instruction cache for 68020s and above.
- The reverse is done at the start of any Test or Run for a program. The Switcher Table is iterated, moving the jmp OCS_Routine_Address instruction into the Switcher Instruction for each entry. The global OCS flag is cleared to indicate the Switcher Table's state. Again, this must be followed by a jsr Sys_ClearCache
Assumptions
- Appropriate AGA/ECS structures have been added to extend the AMOS Basic data area (positive offsets from A5) or as new structures pointed to from that area. Note that the amiga.library data area (negative offsets from A5) cannot be extended as you'd overwrite the buffers area in existing software!
- amiga.library is used as the software-to-hardware interface for AGA/ECS. In other words, it provides the low-level hardware routines necessary, just like it does now for OCS.
- AMOSPro.Lib is used to provide the AMOS Basic instructions. It uses amiga.library to do the donkey work.
- The majority of AGA/ECS functionality switching can be done without using a Switcher Table approach. There's no point in doing it for each and every graphics instruction when all that may be required is a simple check on a parameter. For example, checking a Colour Number parameter already involves looking at the current number of bit planes. So adding a check for a global AGA/ECS flag would have little performance hit. In other words, the existing AMOS Basic instruction routine would just be modified.
- Where a separate routine is required for an AMOS Basic Instruction, it would be added to the library and be prefixed Aga. As an example, if we need to replace the existing Screen Open instruction with a new routine:
- The existing Instruction Number label is L_InScreenOpen.
- The AGA/ECS Instruction Number label should be L_InAgaScreenOpen.
- The AGA/ECS Instruction's parameters definition MUST match the original's.
- The L_InAgaScreenOpen Instruction Number is NEVER called directly. Only through the Switcher Table. In other word, there will be no matching Aga Screen Open token in the Token Table.
- If different parameters are required for an existing OCS Instruction, insert a "token continuation" after it in the Token Table using the "!" and "-2" notations. In the Screen Open example (unrealistic I think, but this is just a "f'r'instance") this would then use a Routine Number label of L_InAgaScreenOpen1. That routine (and all AGA routines) should check the global AGA/ECS flag and throw an error is it's not set!
I think that about covers it. If it's a bit daunting for those out there working on the low-level AGA/ECS stuff, don't worry. I intend to take care of all this housekeeping and integration work. I'll publish a diagram of how it would all work when I've finished the current doc ;) That would probably be easier to follow ;D
(Which is why I'm writing these docs. It helps reinforce my own understanding and I need to know all this stuff inside out before we start carving new functionality into AMOS. And, of course, so the community gets the knowledge too. ;) )
-
Sorry, I just noticed the last post had an unanswered question in it.
There are three spare bits in the LB_Flags byte in each library. So plenty of room for AGA and ECS flags. I don't know enough about the hardware yet to know whether we would need to treat AGA and ECS switches differently. So would we need a flag for each?
I think a 3-bit enumeration would be a more practical endeavor. That way future softcores on FPGA machines would be able to have their chipset features supported as well. (This may be solved by a future AmosPro for AROS 68k.)
-
Sorry, I just noticed the last post had an unanswered question in it.
There are three spare bits in the LB_Flags byte in each library. So plenty of room for AGA and ECS flags. I don't know enough about the hardware yet to know whether we would need to treat AGA and ECS switches differently. So would we need a flag for each?
I think a 3-bit enumeration would be a more practical endeavor. That way future softcores on FPGA machines would be able to have their chipset features supported as well. (This may be solved by a future AmosPro for AROS 68k.)
Good point. That would give much more scope for future enhancements.
Bear in mind that it will be some time before I get to actually working on an AGA version. The current bug fixing, Help Files and Ref Manual will take a while yet to complete. So I've got AMOS AGA "sorted out" in my own mind as "do-able". That allows me to "shelve" the problems for the time being and lets me concentrate on the current tasks. The fine details I'll worry about when we get to actually designing it (any volunteers? :D ).
-
I got the permission to include "Game Master System" in "Aros Vision"
I have just tested "The Game Extension" in AMOS that is based on "Game Master System". It supports AGA including Sprites and Bobs
To test it I wrote this short program that loads a IFF picture and waits till left mouse button pressed:
G Init Gms
G screen open 0,320,256,256,lowres
G Load IFF "clown.pic",0
G Wait Lmb
G reset
Opens AGA screen with 256 colors
Screenshot below
(http://www.aros-platform.de/Clown.png)