Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SamuraiCrow]

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?

[Lonewolf10]

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.

[bruceuncle]

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  .

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 


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:

• Next
• BPAddress

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.

[Lonewolf10]

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:

• Next
• BPAddress

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? 

[bruceuncle]

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  ) 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  .  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!

[SamuraiCrow]

Re:  Arrays of bitplanes in Amos' structures
The proper way to do it on AmigaOS was to use a pointer to a BitMap structure.  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.

[Lonewolf10]

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.

[james666]

Re:  Arrays of bitplanes in Amos' structures
The proper way to do it on AmigaOS was to use a pointer to a BitMap structure.  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.

[SamuraiCrow]

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.

[SamuraiCrow]

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.

[Hungry Horace]

Whilst I am aware of what interleaved Bitmaps are for... Could someone please explain to this layman the advantage of supporting them?

[SamuraiCrow]

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.

[Hungry Horace]

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)

[bruceuncle]

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" 

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.

[SamuraiCrow]

@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.