@geennaamQuote:

If it uses UNIT_VBLANK it will not have that resolution ...

Looked around a bit in filesysbox sources, and it's a bit suspicious that it has a 100 ms timer (FBX_TIMER_MICROS) and in FbxHandleTimerEvent() it then may possibly call FbxFlushAll(). Susicious because 500 and 400 is multiple of 100.

@joergQuote:

Was removed and replaced with std. AOS classic packet filesystem API long ago.

Quote:

It's easy to get into trouble when trying to replace something old/bad even if intentions are good. For example are there rules in the "better solution", when filesystems now run stuff in app task which used to run in filesystem task, for things like signal/msgport alloction (app is allowed to theoretically use up all the dynamically allocatable ones). Or stack usage? Are filesystems now supposed to check for potential low free stack and then stackswap?).

@joergQuote:

No, that's wrong. Linux does not see or know about Exec tasks inside AROS hosted. Everything is still basically the same as AROS native. What AROS hosted does is to basically emulate/implement interrupts using Unix signal handlers. And for task switches in the Unix signal handler it simply pokes the sigcontext (containsing cpu/fpu context state) structure, so that after the return from the signal handler, the Linux process "AROS" continues executing code from a different AROS Exec task.

A bit like early Linux user lever threading libraries.

Disable()/Enable() for example then works by simply blocking/unblocking Unix signals.

Quote:

Btw, it's really "can use", but does not mean "has to use" at the same time. Some native gfx drivers were developed under hosted version.

Btw2: there are several other big advantages.

It "boots" extremely fast, takes up almost no host cpu time/resources. You could run big number of instances at the same time (https://vimeo.com/191163338 - each blue amiga-style window appearing is a newly booted/running AROS instance, running intermixed with Linux windows). Then if you run one (big) program in once instance, and other (big) programs in other instance, you basically get some kind of memory protection/resource tracking/etc. for free.

You can do symbolic debug of the whole OS including all system libs/tasks and app tasks/libs with gdb, as if it was one single application.

@tonywQuote:

It's always possible to write things in such a way that this is never necessary. Libraries/Devices get SysBase as param in init call and can store it somewhere else for future use. Similiar thing when creating new processes. There's always some way to pass knowledge about SysBase along.

In AROS/hosted for example there is no SysBase at 0x4. Instead trying to access that address causes segfault (AROS/hosted is really just a normal linux process/program but still 99% identical to the native version).

How much sense do this funny shared objs make anyway, with something as big as the QT libs? They are not really shared anyway in most important place (memory), only in least important place nowadays (disk). Only advantage is, that if new version of libs come out, the exe using them does not need to be re-linked statically.

How big is a simple QT gui sample program if linked statically? Size in memory will be somewhat similiar.

If you have same sample program but linked with shared objects then complete huge (I guess) QT shared objs used by program will end up in memory. If some stuff in the shared obj is referenced. Unlike static linking where parts (.o files) in the lib which are not needed do not end up in exe and later in memory. And if you start program twice or have other QT programs running then each will have their own copy of huge (I guess) QT shared objs in memory.

I think ... (I'm no AOS4 guy)

On this page

http://wiki.icomp.de/wiki/P96#Hardware_manufacturer_archive

it's possible to download "CardDevelop.lha" which seems to contain headers and sample driver source code.

68k P96 driver development infos and docs are public since some time:

http://wiki.icomp.de/wiki/P96_Driver_Development

@RazielQuote:

is being said ... but has anyone ever tested this under Linux? I never tried but it seems to be actually possible to have an Amiga-like soft-reboot in Linux using kexec or kexec-reboot. So nothing goes through hardware/BIOS/whatever initialization.

Also in Linux and other OSes you have virtual machines which allow gfx card pass through. Starting/quitting/restarting virtual machine would then for the gfx card be like a soft reboot, where it is not re-hw-initialized in BIOS/whatever. If "nothing can be done about it", it would mean you could start virtual machine only once and second and future starts it would fail, too.

@Daytona675xQuote:

I'm not sure and I don't know OpenGL but https://www.khronos.org/registry/OpenG ... /2.0/es_full_spec_2.0.pdf in chapter "2.10.1" says:

"The name space for shader objects is the unsigned integers, with zero reserved for the GL. This name space is shared with program objects"

In test program print out the the return values of glCreateProgremObjectARB() (data->program) and glCreateShaderObjectARB() calls (data->vert_shader and data->frag_shader) to see what they return.

Quote:

Yes, if shader creation and program creation on Amiga side of things (ogles2.library?) return integer IDs that may match (ie. a created program could return ID 1 and a created shader could also return ID 1) then this is likely what is happening and causing the problem.

@CapehillQuote:

It's only the GetObjectParameterivARB() function call to check compile status which fails at least in first call for some reason (either function buggy or since it is a function pointer, it is not pointing to correct function) and the biggest fail is that it does not set status variable at all which should never happen. That's why the status variable stays undefined after first call and why he can ~"fix" it with magic printf() or other function calls in parent function or by setting it to a defined value (like 1234) before call to GetObjectgParamterivARB().

glGetObjectParameterivARB(), glCompileShaderARB(), etc. are function pointers set up with SDL_GL_GetProcAddress().

But where are this #?ARB functions listed? In https://github.com/kas1e/SDL2_GL4ES/bl ... SDL_os4opengles2wrapper.c they don't show up in the table in there.

Which would normally cause SDL_GL_GetProcAddress() to return NULL I
guess.

Idea was that maybe there's some typo in some table and the function name is resolved to the wrong function.

Btw, what if you change glGetObjectParameterivARB() calls (and function pointer setup) to glGetShaderiv() calls. Seems to do the same thing.

What happens if you call

glFlush();

before

glGetObjectParameterivARB(...);

Buggy glGetObjectParameterivARB() maybe. What happens if you call the function twice:

glGetObjectParameterivARB(shader, GL_OBJECT_COMPILE_STATUS_ARB, &status);
glGetObjectParameterivARB(shader, GL_OBJECT_COMPILE_STATUS_ARB, &status);

[quote]

do

status = 1234;

before calling

glGetObjectParameterivARB(shader, GL_OBJECT_COMPILE_STATUS_ARB, &status);

to see if the function modifies the status variable at all or not (would mean unimplemented attribute or something).

As said IMO it's very likely problem of some uninitialized variable in this shader compiling stuff. Maybe somewhat hidden (compiler may not warn about it) if for exampled caused as side effect of unimplemented/unhandled functionality/attributes/whatever.

The thing with the call of the magic functions (printf(), Delay(1)) that make things work, is, that the calling of this functions will cause modification of things on the stack so they will influence how uninitialized variables look like when they end up being used in other code (shader compilation) which is exectuted after that = ~"in the future".

Funny experiment: If

Delay(1);

works, but Delay(0) doesn't it probably is possible to make the working thing not-work again by calling both:

Delay(1);
Delay(0);

My guess now is that it's most likely some unimplemented functionality which causes some uninitialized variable to stay uninitialized and therefore causing random behaviour (which can be influenced by adding removing "magic" calls)

Like maybe in SDL_shaders_gl.c:

GLint status;

...

ctx->glGetObjectParameterivARB(shader, GL_OBJECT_COMPILE_STATUS_ARB, &status);

If this GL_OBJECT_COMPILE_STATUS_ARB param/flag/whatever is not implemented in the GL libraries or whereever ...

IIRC in AROS I once had a funny situation in a some test program which opened a window and would quit when you press some key. In the shell you typed in the command, pressed RETURN key, the window opened quickly and the RETURN key release happened after that and so the event went to the window/test program which then quit immediately.