Os 3.2 development preview

[SamuraiCrow]

Will there be an integrated virtual memory solution someday?

Memory.library comes with MMULib and is already written.

[SamuraiCrow]

Likely not. I do not even know what this should mean (what is a "copperlist fade"? What is a dynamically updated copperlist? UCopperListInit and friends exist already, so you can certainly update them) Essentially, the way how the graphics.library code looks, it is more at the end of its lifetime, and we should really replace that by something different and more "cleaned up".

For 3.2, no major works on graphics are planned, except a better integration of AllocBitMap() into the P96 model that doesn't change a thing for native graphics. I believe this is about it.

MrgCop() and it's macros do not expose sufficient capabilities on AGA or earlier so the OS routines should not be used by anyone trying to target such systems.  At least I agree that Graphics.library is EOL.

Personally, I think that a full VM like what AmigaDE started to be would allow such things as inline code contained in the graphics drivers.  This would allow demo-code like capabilities to be accessible to what otherwise would be considered system-friendly code.  The AOT style JIT of AmigaDE did that (or would have done if Amiga Inc. had ever targeted their own systems  ).

[SamuraiCrow]

MrgCop() and it's macros do not expose sufficient capabilities on AGA or earlier so the OS routines should not be used by anyone trying to target such systems.

I'm not quite sure which capabilities this should be. The copper writes a value into a register - that's really it, it did not become more capable on AGA.

However, this aside, the problem is not even MrgCop(). The problem is that the system creates copperlists in one way, and then has a couple of extra functions that "poke" on the created copperlists, bypassing the regular copper list creation functions. This is particularly tricky for the copper "wait" functions as several (hardware) copper instructions need to be combined to make up a wait for an arbitrary position. Unfortunately, these "other" functions expect for that a particular form of the copper lists.

So we have two (actually even three) sets of functions that operate on the copper lists. Partially in C, partially in assembler. One abstract "copper list built-up function" aka MrgCop(), to which CMove and CWait() also belong, and the SetColorMapXX() functions (poke directly into the copper list) and the VideoControl functions, which also directly poke into the existing copper lists - both bypassing the abstraction layer. Changing one makes another one explode in your face.

As a side remark, Os 3.1 had exactly in this mess a bug: If you had a productivity screen and a workbench hi-res screen, and a 35ns sprite on the productivity screen, and a 70ns sprite on the workbench, and you closed the productivity screen, graphics would have scrambled your memory. The sprite size adjustment tried to "poke" an already existing copper list (instead of using the proper abstraction), but the copper list it referred to belonged to the screen that was just being closed, and thus was already released memory.

The biggest problem with MrgCop and its macros and support functions is that it doesn't and cannot sort blocks into the order that they are supposed to go in.  If you are using dual-playfield mode and color changes for the sprites, for example, trying to get all the copper instructions to line up with both playfields and 8 other moving objects requires sorting, not just merging.  One hardware banging engine written in C uses a "blocks mode" where the first instruction in a block is a copper wait and all additional copper move instructions are after it in a form that resembles Chomsky Normal Form.  This allows all the blocks of copper instructions to be properly sorted with minimal overhead.

This allows the "infinite vertical scroll wraparound" that uses the modulo register to make the bitplane pointers all jump to the top of the buffer when the end is reached with a negative signed addition and then reverts the modulo register the next rendered row of pixels.  It's only 2 waits and 2 moves but they aren't always in the same order when you do it on both playfields.

[SamuraiCrow]

I'm sorry, but I'm not sure what you want to tell. CMove and CWait both go into the user copper list, and MrgCop() does not change the order of instructions on this list. What it does is that it merges the (abstract) user copper list, the (abstract) copper list of the VSprite system and the (abstract) copper list of the view port arrangement into one hardware list. As long as there is a single VPort, it does not matter whether it runs in dual playfield mode or not.

Thus, while you cannot guarantee the relative order of the user copper list relative to the vsprite copper list, the relative order of instructions within each list is stable.

The main problem with the current abstraction is that it stores one virtual instruction per "block" and CBump() moves immediately to the next instruction which prevents grouping of related instructions.  A wait followed by a variable number of moves should be treated as a single "block" of memory so they can be sorted into the order needed regardless of the position being waited for at the beginning.

The ACE (Amiga C Engine) source is available as open-source on GitHub.  I should check the licence and make a Chipset.library to replace Graphics.library on systems that need chipset support.