GfxFree() surprise

[Krashan]

I've written following code:

struct MonitorSpec *msp;

if (msp = (struct MonitorSpec*)GfxNew(MONITOR_SPEC_TYPE))
{
  GfxFree((struct ExtendedNode*)msp);
}

This code unexpectedly generates recoverable guru $0200000D. I have decided to disassemble GfxFree() from my Kickstart 39.106. Guess what, the code only supports VIEV_EXTRA_TYPE and VIEVPORT_EXTRA_TYPE. Two other structures are not handled and explicitly call Alert().

My guess is they simply forgot to add the later two moving from KS 2 to 3. It probably went unnoticed because usually monitor spec structures are never freed. I wonder if it has been fixed in KS 3.1.

[Minuous]

Yes, this was fixed for KS3.1.

[EmilAmiga90]

I have almost the same problem with GfxNew while attempting to allocate a VIEWPORT_EXTRA_TYPE structure. I get a recoverable alert 0200 000C.

I am using KS 39.106 on WinUAE

I am going to check if any patch is available.

I wonder if it is safe to simply allocate the ViewPortExtra structure by code. I suppose it could work safe now but pheraps it could be incompatible with possible changes in future versions of AmigaOS...

[Thomas Richter]

Originally Posted by EmilAmiga90

I have almost the same problem with GfxNew while attempting to allocate a VIEWPORT_EXTRA_TYPE structure. I get a recoverable alert 0200 000C.

This error means that the type you passed in is not supported. VIEWPORT_EXTRA_TYPE is, however, supported. Thus, there is no patch needed - "you did something wrong".

Note, however, that GfxNew() and viewport functions are only supposed to be used by intuition, for building screens, namely.

[EmilAmiga90]

Originally Posted by Thomas Richter

"you did something wrong". .

You're right

I was sure I could not have done a mistake on such a simple library call...

The debugger helped me realise that I forgot about about the '#' before the constant name

the correc line is: move.l #VIEWPORT_EXTRA_TYPE,d0

As a matter of fact, I used VIEWPORT_EXTRA_TYPE as ram address... . Now it works ok.

I know that the viewport functions are low level and that using them myself means sort of taking over the machine.

My main goal is an AGA display that is system friendly, so I suppose that using proper Intuition screens do not impact performance and enables mouse functions. Right?

As an extreme example, do you think it would be possible/feasible to code a smooth, coloured and fast platform scrolling game using an intuition screen and OS system friendly calls?

I suppose a 68000 A500 without fastram would probably suffer performance issues. Perhaps 68020 A1200 could make it, with at least some fast memory