QuoteI need to remove Symbols from it. It could be in any unorthodox way possible, but it needs to be done. Later I need to replace said functions with equivalent ones from .o files.

That is not possible if the ELF file is a EXECUTABLE and was not linked with --emit-relocs as it's impossible to reconstruct where the symbols are used.
You need to find and fixup all references yourself, IDA can tell you where most references are and even has a patch function (although manually assembly is required). This won't work that easily if relative branches were used, that may require using a constant placed in the literal pool.

Edit: You can also just append your modded functions to the ELF file and patch the main function to branch to the modified ones.

Yes, the CAS non-CX OSs are practically unusuable on firebird right now.

Firebird supports all Nspire models except for the CAS+ (which nobody uses anyway, but readding support wouldn't be too hard).

Only issue is that there is no keypad for the clickpad implemented, which the classic CAS OSs somehow need. Classic non-CAS OSs work just fine.

No, you don't need to keep it around.
It may become useful later though and as it doesn't consume much space, why not just leave it?

Quote from: lazydogP on January 23, 2017, 11:36:41 PM
However, it's not as stable as the older one. When you open a document with Lua codes, Nspire crashes and reboots. I don't know whether it's because of Ndless or nLaunchy.

That's not supposed to happen! Can you reliably reproduce the issue? Which OS are you running (CAS)?

QuoteYes, exactly. They were corrupted when i attempted to show them on the screen. Not sure why ?

They're created during runtime. You could try to embed them into the RO-section by replacing the newTexture calls with hardcoded ones.

QuoteSo instead of downloading 3.6, I can download OS 3.1, replace the boot1 with ControlX (which I'm not sure but you said isn't released yet?) and have the same fix for less memory?

ControlX is an nBoot payload and thus only runs on CX HW < W.

QuoteI have made a basic port of Crafti for the Sega Dreamcast !
Like the GCW0 and nspire, it is still entirely software rendered but this DC port does not use SDL. (instead it just talks to vram_s)

QuoteCrafti for the Dreamcast is catching fire, it seems, it's newsed by almost every dreamcast fan website ...

Good job!

QuoteThe Dreamcast only has 16Mb of RAM, at first i encountered memory corruption on the images but i was able to reduce it so it is not noticeable.

Is that the reason for the lack of the overlay textures? (Does it actually have 16 Mb (=2 MB) or 16 MB? The classic Nspire has about 8 MiB free with OS 3.9)

QuoteThis makes me feel a bit bad, as Vogtinator is not even mentioned in the news, even though he made the game.
I'm already getting threats because they want me to improve the perf of the DC port, not even my GCW0 port got this kind of reception.

Hehe If you are able to improve the performance in a upstreamable way, please send patches!
There is certainly a lot of room left, but as I never did any software 3d rendering before nGL I implemented it the most KISS way.

For example, by using spans instead of a z-buffer, only the scanline segments that actually end up on the screen need to be drawn:
https://mikro.naprvyraz.sk/docs/Coding/1/S_BUFFER.TXT

Quote from the DCEmulation forum:

QuoteYou should draw arrays of triangles, instead of calling a function for every vertex (glBegin vs. glDrawArrays)

This is already done for the main geometry: https://github.com/Vogtinator/crafti/blob/master/chunk.cpp#L251

QuoteI should try without those lines, i hope GCC works properly on OpenSUSE !

As I'm using it on several Pis without issues, definitely.

QuoteAlso @Vogtinator, i tried OpenSUSE on my Pi and it gives me a black screen after the EFI messages.
It is giving me signal on my display but it is all black.

After which efi messages? If it's after GRUB2, you could try appending "rd.driver.blacklist=vc4" to the kernel cmdline and try booting with efifb.
Red and blue are swapped to a disagreement between u-boot and the kernel, but that's a minor issue...

Quote from: Juju on January 02, 2017, 07:59:48 AM
Eh, looks simple enough.

EDIT: Aaaah, look what I found. The newer versions were under different branches the whole time. 4.4 is still the default branch, but you can find 4.5 and up if you know where to look.

They don't work. Most drivers just break with porting so every version newer than 4.4 is broken in a different way.

Quotei know that. Unfortunely, their crappy branch is broken and is actually missing code !
I was unable to compile their downstream kernel (4.9 and 4.10 don't compile)

The downstream kernel is only version 4.4 currently.

QuoteUpstream 4.9 kernel does compile but the image file isn't recognized by my pi,
it gives me the rainbow screen of death.

The upstream kernel needs an upstream device tree supplied, did you add that?

QuoteI do wonder if i can't just use the kernel from OpenSUSE...

The openSUSE kernel is a bit special, it needs an UEFI environment to boot.
However, you can use u-boot from openSUSE standalone, which can be very helpful for debugging.

The instructions linked are only for the downstream kernel.

QuoteSince "X11" images is too big, i'm just downloading openSUSE-Leap42.2-ARM-JeOS-raspberrypi3.aarch64-2016.11.25-Build1.12.raw.xz,
is that okay ?
I don't know if JeOS image files are tested...

Yes, that should work as well, it just does not have X installed by default.

QuoteWell i just checked the kernel in Devuan and it seems to use an upstream 4.6 kernel. So i don't think the default kernel has VC4 available.

Depends on the backports, maybe they picked the rpi3 related patches up.

QuoteMaybe it's due to the insufficient power supply, (only 1A is not enough)
as the Leap images for example says that gfxterm was missing then it goes back to the grub menu. over and over again

You'll see insufficient power issues as the power LED flickers during undervoltage.

Did you try this image: http://download.opensuse.org/ports/aarch64/distribution/leap/42.2/appliances/openSUSE-Leap42.2-ARM-X11-raspberrypi3.aarch64-2016.11.25-Build1.18.raw.xz
There are a lot of links floating around to outdated build artifacts (they need to be cleaned up...)

QuoteThere's modesetting available in Devuan but how to load it anyway ?
Do i have to just make sure i'm using the rpi linux kernel from next branch, an up-to-date Mesa and modprobe vc4?

On openSUSE/SLES it's called xf86-video-modesetting. No idea how it's called elsewhere.
Make sure that you're *not* using the raspbian/downstream kernel but rather a very recent (at least 4.9) upstream kernel instead
or an older version with backported patches.
Mesa needs to have the vc4 driver explicitly enabled.