That's great news. So now it may be possible to run 32bit apps on AROS x86-64 without re-compiling them. Nice!

Awesome! Good to hear.

I would say quite an achievement, this will make a difference in the AMIGA world !!!

Great news:)

ok thanks

Hi All, I will use this thread to update you on the progress of prototype of this emulator. Right now there is nothing yet to see, but first major hurdles have been cleared: 1) 32-bit test binary (of Tools/Calculator) is loaded and relocated under 64-bit AROS 2) 32-bit emulation mode is enabled in CPU and several lines of 32-bit code has been executed 3) Kernel of 64-bit Linux-hosted AROS has been modified to allow correctly task-switching between processes running 32-bit and 64-bit code

This looks interesting! Many thanks! (y)

Excellent work Sekr...

many thanks Serk;)

Thanks serk ! i will install your software on the next version of AROS One

Uploaded to archives.. see links for more info https://www.glfw.org/ and https://www.raylib.com/ Also a nicely done template a good starting point https://github.com/raysan5/raylib-game-template

[quote name=deadwood post=4427]@deadwood - Nice work! Are you planning on porting some games that use raylib?[/quote] Yes... I have already ported few basic/simple games , i will upload them to archives ,

Great work! It looks very interesting.

Nice work! Are you planning on porting some games that use raylib?

Hi ppl, I have been busy trying port GLFW + Raylib 5 (both latest versions ported to aros) For more screenshot [url]http://serk118.blogspot.com/2024/03/glfw-34-and-raylib5.html?m=1[/url] I will upload to archives later on today.. [img]https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7PyCO_1k7WcyKz1CBqzhy7QsQFSjngTl5pu0H5fnJAPJqKERlvSlqbD86KCBUhWQztAyiE-x1XEYDIUt-IPIdgkqAIigzwC9Idz7Da98srXHgCf6Wevq1xcvyL-cFJ8elz7EKuaE8Q2Np0-d5cjngbqwx5MhrHumECk2I363tdGZ5X5geB7HIGkn4h7q7/s1024/rl5_6.png[/img] [img]https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjlZgy5hTvBJ_XPwtlTvcPBov5nxYWgWVIIuKXfOn156li48GoQt0V9OvxQ1hDKUM8MVCjzr27wAvXwuL_9RJFEGUyzUihI0dEx98pVgQTUtyRhDFdEjSjQ7E0dZ8OtEJlnIW5Gj3CJDvVJQhz1ZtrSC8sWPU8HnLcQJUOFYZ2Uy1CRJSL3uJ2kcHfAuBmu/s1024/rl5_20.png[/img] [img]https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgdL3A3iCVzBzANNgIflTmCQ-ZwLExs9z28nYBRSdMIodJ8lc32IChcxovUJg7omypBQkusFtp5SbWoi-JTSRXSalNdoXcgjxXqFWc9DWUGbAoHQQ49cZU-4uFzwPLAHIm65wlxBEK-vJ4JnyCe5-g5LX0iPyeVg-T-BlegYv6xdnz2OGPhGFDJvF9C_JPq/s1024/rl5_23.png[/img] [img]https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZAlqRDYzHzFHFGCvPBwI3r_qXds9lH4DMH6sFVowCKPsydHbkV72KS9oQEIAf2ZaopLVFaTbnBHL3eaO1R5MmyKyFzc1L1E2ezduYqi92akYjoeSvG2LQOjNzvk8p4NgDOBzO_sMvOJtntSCQv95jLutE1YsxlU-x6OiW-GkseXpapSZkMY7ffVhhk5K1/s1024/rl5_12.png[/img] And few videos [youtube]https://youtu.be/8uq0dmeSch0?feature=shared[/youtube] [youtube]https://youtu.be/iy1qBwxPf2A?feature=shared[/youtube]

[quote name=ericxjo post=4412]@ericxjo So my first question is, how does one approach a bug like this? Is it possible to somehow put the kernel itself under a debugger? How to distinguish if it's the kernel or the graphical subsystem? I'm open to any ideas. Right now I'm so new at this that I'm not even sure what questions to ask. But I think this is a nice, deep-end-of-the-pool issue to jump into.[/quote] @miker1264 already gave a few good point about isolating the issue. Here are my two cents: I'd first see if I can repeat this on base system which you can download from here [url]https://axrt.org/downloads-aros[/url] to eliminate distribution-specific bugs. If you have hardware with supported video card, I'd check if the bug is present in both VESA and native video drivers mode. In addition I would check if the bug is also present in hosted version (AROS that starts from Linux (or Linux under WSL under Window) (AROS-linux-i386-system.tar.bz2). The reason is that debugging hosted AROS is much easier than debugging native (the one for real hardware or VMs). The other thing that you can do in parallel is to set up development environment. If you are a Linux user, follow this guide: [url]https://github.com/deadwood2/AROS/blob/alt-abiv0/INSTALL.md[/url] If you are a Windows user, first setup WSL using first part of this guide: [url]https://arosnews.github.io/how-to-cross-compile-aros-hosted-wsl/[/url] and then follow the guide I linked above. In addition in this thread, you will find more developer resources: [url]https://arosworld.org/infusions/forum/viewthread.php?thread_id=1201[/url] I'm happy to help you onboard to developing AROS. If you have further questions, just post them here or contact me via PM.

It's good that you are familiar with C programming for Amiga. In that respect you will find that AROS system files and structure is very similar. But there are some differences such as Cybergraphx Library and HIDD drivers such as for the Graphics Drivers, and other drivers. When I first started with trying to program for AROS by updating picture datatypes I had been doing C# programming off and on for 10 years prior to that but I had absolutely no C experience. It was a very difficult time for me for the first 2 years as I learned mostly by trial and fail. But eventually I learned that memory management, string handling and error handling were the basics for C programming. Most errors are related to those categories. So look there first. As for the problem you have described it could be memory related or it could be due to the graphics driver being faulty. However, it's not conclusive. I would try to narrow down the problem by doing a series of tests that you can set up yourself to isolate the problem further. Also, you must be aware of which version of AROS you are using for testing. Is it AROS Native or AROS hosted? Are you using Wanderer or Magellan? Is it AROS One x86 or Icaros or Tiny AROS? Which version of system files are being used? Such as AROS One v1.9 or 2.4 or other. For example several years ago I was testing datatypes on Icaros Desktop Native with Native Nvidia graphics driver installed. It was Icaros v2.0.3 I believe. Quite often I would get memory errors and the system would freeze after a few operations. This happened a lot. I suspected the datatypes were at fault. Especially BMP datatype constantly caused graphics glitches. The BMP images were distorted. Having exhausted all possible explanations I decided to upgrade to Icaros v2.10. Surprise! Everything worked well. The previous version of Icaros was really buggy. So test the graphics or memory related errors in the same way on Native and Hosted if possible and on different versions of AROS to get a better idea if it's really a problem that can be fixed. But when you get into AROS programming further we need some updated Nvidia graphics drivers. Happy coding!

Hi! Many, many (many!) years ago I used to code on the Amiga in C and 68k. Now I'm playing with AROS. Back in the day I mostly just played with it, or helped my older brother with his more serious projects (also on Amiga in 68K or C). Playing with AROS, I do like it quite a lot, but there's a couple of bugs and oddities I'd like to fix. To be straightforward here, I'm not sure I'm up to the task. Partially because I haven't dug into the details of systems like this since I was in my teens -- but in any case -- I do have experience programming in general, programming in C specifically, and programming on Amiga-like machines specifically. So here goes. There's an odd bug in AROS where, if you put the system under some graphical stress (specifically, running a bunch of demos, either from Extras/Demos or from Extras/DemoEffects -- side note -- I do appreciate an OS that comes preinstalled with lots of cute desktop toys -- thumbs up from me! -- and then drag the Wanderer screen up and down a few times, the system will freeze hard. I have no idea if it's freezing at the kernel level or if it's something in the graphical system. I have turned screen composting off, and any other thing I could find which I could think of as a complication. I have also tried quite a few different combinations of demos. No one demo seems to trigger it. It's triggered when a sufficiency (at least 3, at most 9) demos are running at the same time and you flick the screen up and down rapidly. I am aware that the OS this one is based on did not have any kind of concept of memory protection, and therefore one task can happily corrupt another, or even the OS itself -- but even with that idea in mind -- I'm pretty sure (a solid 65% sureness or so!) that this is a true kernel or graphical subsystem bug. This bug, which I admit is basically meaningless (I mean, who flicks the screens up and down? For fun?) just irritates me. So my first question is, how does one approach a bug like this? Is it possible to somehow put the kernel itself under a debugger? How to distinguish if it's the kernel or the graphical subsystem? I'm open to any ideas. Right now I'm so new at this that I'm not even sure what questions to ask. But I think this is a nice, deep-end-of-the-pool issue to jump into.

hitchhikr it is also possible to have the midi driver for 64-bit aros;)

deadwood about audio recording these days I try out the builds