Hyperion announces OS 3.1 update

[Georg]

For CGfx, none of us has the sources, so it remains completely unclear of why that fails.

You don't need sources to figure out such simple things. As said elsewhere, just make sure to trash registers before screen bitmap allocbitmap call to force enforcer hit/crash to see which registers (apart from allcobitmap params) CGFX expects to contain some additional info.

You could probably also just write a little test AllocBitMap patch (no need to modify ROM for tests) which you run on a working CGX setup (after CGX init) which does something like:

New_AllocBitMap:
  save_all_regs
  trash_all_regs_except_params
  ret = call (*Old_AllocBitMap)
  restore_all_regs
  return ret;

[Georg]

But I'm not talking about "simple things". It depends on more than just AllocBItMap, and the register dependency is more than "oh, please use register a4 to get the MonitorInfo". I'm talking about the stack frame, and the structure layout, and there are many more structures in intuition than what is in the official includes.

You talked about Intuition now being compiled with different compiler and that was enough to break CGX. But structure layout and internal structure for the relevant things (to openscreen/modeinfo/etc.) is still the same, isn't it?

The code doesn't crash or hit in case the register layout isn't right.

Yeah, registers/pointer being "not right" in AOS is often not enough to cause immediate crash/hit. That's why you need to trash registers hard to increase likelyhood of crash/hit.

Unless you try with a patch like suggested or other things, you can't say beforehand if it's something simple which prevents CGX from working with new Intuition or not. So why not just try? Btw, with UAE's debugger it's probably easy to debug inside ROM, too (and UAE as said can run CGX as it emulates some gfx cards supported by it).

You also said:

For P96, it is possible to get it supported with a kludge, but that's basically because the authors of the V45 had the P96 sources available and could load registers with the values P96 expects.

so, if it was something simple in case of P96, why do you exclude from beginning that it may be something similiar simple (load register with values P96 expects) for CGFX?

[Georg]

The code doesn't crash or hit in case the register layout isn't right. AllocBitMap() is a user-callable function, and the code probably goes in hoops to find out whether it is called from intuition, and whether the registers are consistent, and if not, it will do anything to *prevent* a hit and just operate normally.

It cant do that ("operate normally") in case of OpenScreen AllocBitmap and some info it needs isn't there. That's what you need to try to trigger on a working CGX system -> make it fail to open a RTG screen. No need to try to trigger crash/hit. With some luck it's something simple like trash a certain register: then you know it expects some info in that register.

When writing a test patch (or realtime patch in ROM with UAE debugger) one should of course first test, if a do-nothing-patch still works (it could theoretically break the CGFX-is-this-the-allocbitmap-call-from-openscreen check).

[Georg]

I *personally* do not believe the job is done by understanding how AllocBitmap is expected to be called.

With "and some info it needs isn't there" I meant some info it expects in a place (register/stack) that isn't allocbitmap param registers.

So for example if CGX in it's AllocBitMap patch would rely (after detecting the call is
the screen bitmap allocation call inside openscreen) on A4 to point to some info which helps it to figure out the screenmode, then a way to figure that out without knowing about that would be:

- on a working CGX RTG system patch the allocbitmap call such that all registers which are not params for allocbitmap call are trashed.

- this would cause CGX to no longer be able to open RTG screen, because it does not find the necessary info in register A4

- you do not know that the register is A4, so you would change patch so long to narrow it down to register A4

- then you look into original 3.1 openscreen code to see what A4 happens to point to before call to AllocBitMap()

In reality it may be something different, but if you are lucky it may be one part of the puzzle solved. Without having source/interface. And without disassembling CGX AllocBitMap and/or breaking/trapping/single stepping AllocBitMap() call when it happens in OpenScreen, which may be easiest of all, but maybe you prefer to avoid such in your opinion maybe (?) illegal (?) sneaking into foreign code.