That looks a lot like the format of git pack files has changed. Which, let's face it wouldn't be a massive surprise! So compiling would be a great first step as it would allow us to dig into it.

I've just spent another half an hour looking at the build and it's failing massively on building LHA from old sources from around the year 2000. Not sure why it's trying to do that but I guess there's a reason for it. I can only surmise that there's something different about whatever cross compiler setup the original build used vs the docker cross compiler image. I might look into that I suppose.

@smarkusg, @all

I think it's still publishing, but in case it helps anyone. Although I doubt it!

As it says at the end of the video, the sun is shining for once here in the UK, so I'm going out

@smarkusg so, firstly, the fact that sgit works for you there is highly likely down to the size of the repo you are checking out. 1.6MB will likely be fine. My repo is around 19MB and it fails at 98%. Like I said, I cut it down to a smaller repo which isn't a desperately sustainable solution and it did complete the checkout, but then it choked on a symlink.

But more importantly, it would be good to know how you built it. Because cloning simplegit to my Mac, then running the build inside the docker cross compiler didn't work. And I don't believe I'm alone in that. If it worked then we could look into things.

Maybe later today I can find some time to go back to it, have another go and post some of the problems.

[edit] I need to try the idea of cloning to the ram drive. That speedup could get round the SSL error on the larger repo. Only could because I think the speed issue comes from the network on OS4, not the disk.

Would be great if you could spare the time, even if it's just to see if we can work out why we can't build the existing sources so that we can dig into the issues. I'll have to go back and have a look at why the build was failing when trying to build simplegit source itself. It wasn't the easiest of things to track down though as it was downloading stuff and patching stuff and doing a lot of things beyond simply building.

@Hans, yes, for me everything has been too big and it dies. It also lacks the options to be able to limit the size of the checkout. I found the source but it fails miserably to build just like a lot of other stuff. I even tried to create a smaller project by not including a whole section of the project and the checkout worked, then it failed because there’s a symlink in the repo and it died on that. At that point I gave up. Too many concessions having to be made to bother.

Currently there isn't a working git command for OS4. Yet another thing to add to the list of stuff that doesn't work unfortunately.

The problem (as far as I've seen anyhow) is that many people don't develop directly on OS4 and I've even had the comment (more than once) you would be mad to try. Personally I think you'd be mad to spend £2k on the hardware and NOT use it to develop on! But there appear to be few of us that think like that.

Anyway, I've been sat here trying to work out if I could get libgit2 to build against AmiSSL but I wouldn't have a clue how to even tell ligbit2 about AmiSSL. While AmiSSL says it's 100% OpenSSL compatible, at the end of the day it's not OpenSSL and without cmake find scripts and the like, it's probably beyond my skillset (again) to get it building.

I spent a day last weekend following along to one of the "build yourself a git client" articles, which happened to be in Python. It was fun. Everything looked do-able. Until you realise that everywhere they hit complicated bits, they skipped them (clone being one of the big ones, pack files being another - though I'm sure I could work that out). All the same it was fun and I thought I could take that approach instead.

Then I realised that OS4 has an ancient version of Python and I hit a very similar brick wall looking for a 3.x version of Python for OS4. There at least appeared to be a v3.8 but as is often the case, it's alpha and not been released, so may as well not exist.

Apologies if my tone comes off as negative, but it's how I'm feeling about the platform in general at the moment and consequently it's not getting anything like as much of my attention as I would have liked.

If someone is asking about purchasing hardware it would be better not to guess based on screenshots since I’ve had cards that are meant to be supported for stuff not work because they were the same in name only but different specs. Obviously feel free to guess. I’ll just go back to what I was doing.

@white

I don't know, you'd have to ask Geennaam. As far as I was aware the 'HD7000' is a series of cards so I don't know which specific card he tested, what memory config and so on.

Nice to see it's moved on then. I'll have to have a look over the weekend and see if my system is in any state to test it or not. I can't remember if I reformatted it or not. I had 3 or 4 cards I could test. None were 7000 series though.

I also might not get too much time as it's my birthday at the weekend which tends to mean family, despite everyone claiming it's up to me what I do

Just seen this thread.

Regarding GPU passthrough, yes, I got it "working", but it was not properly working. And I might be wrong but I don't think we ever truely fixed it (IRQ issues from memory maybe?). In small part because I just went and bought an X5000 system instead which obviously works much better - or as best as any OS4 system can :D

I think the system may still be setup (it's my workbench system for when I'm working on PCB repair), but that's a guess. I might have reformatted it when I took it out to the workshop.

From memory, it "worked" but was pretty slow. At the time it was enough for me to test some software I was building and that was that. I wouldn't recommend the setup for anyone on a day-to-day basis or for anyone to spend money on hardware unless they are doing so in order to progress the issues. And by that I mean actually develop and / or debug the issues. I don't feel it's fair to just push everything onto Baleton all the time, and probably also Hans.

Nice video. Unfortunately the timing didn't work out for me yesterday. Either I was offline when other people were playing or vice versa. I did spend a few hours on solo play though so that was good.

@TheMagicSN One quick question - how will those of use that bought from other places like RetroPassion be able to pick up updates? Will they be having a similar mechanism, or can Alinea add the downloads to my account (I have one?)

I appreciate you may not have the answers to those questions! Just wondering in advance :D

OK, so I've now succeeded in building two versions of Raylib v4.5. One against newlib that I can build with on OS4 and one against clib4 which can only be used with a cross compiler environment.

I've run a bunch of tests (from my project) and everything looks OK except 3D. But I can't tell yet whether the issues are my end or my build of Raylib / GLFW / ogles (bear in mind I had to rebuild GLFW for newlib).

So my next step is going to be to look at the examples supplied with Raylib to determine if the 3D issues are my end or not. It's quite likely they are issues in my project as the bulk of my focus has been 2D since that's what I understand more.

Once I'm happy things are stable then I'm going to look at Raylib 5. And then finally spend some time on my project :D

https://www.amigans.net/modules/newbb/viewtopic.php?topic_id=9235

Post number 9. The 'stdargs.h' include issue, then the 'MAXPATHLEN' issue, but then by the time I've added 'stdargs.h' and 'amiga_platform.h' I'm left with the following output, for which I have a vague clue what the issue is (newlib not handling library opening in the same way clib2 does and also being missing some things you added to clib2), but I wouldn't know how to solve them.



[edit] But I did wonder, that if clib4 is just your clib2 renamed to prevent naming conflicts, then can i just compile raylib using clib4, put a copy of it in the clib2 folder and just tell gcc to use -mcrt=clib2 ? Or are they different enough for that not to work?

So the newlib path is a non starter for someone of my skill level. I just tried to build GLFW against newlib (needed by Raylib) and it throws up a bunch of problems. I hack about a bit, get it part way there, start to use google search only to be pointed to my own posts on here from last year which never got resolved because I moved to CLIB2. I thought we were going round in circles and it looks like I wasn't wrong.

So I have two choices right now. Go back to clib2 where I can cross compile (in docker - I don't use a linux host as such) and native compile as I choose, or stick with clib4 and suffer the pain of the build / copy to NAS / switch machine / copy from NAS / test cycle for even a single line code change.

I'll try the clib2 route to see if I get up and running with that but I thought that was where I started 2 days ago and something didn't work which was fixed by moving to clib4.

OK, just to keep this thread up to date with what I said on discord, I'll turn my attention now to your current Amiga Raylib sources and Newlib. I know that's what Hans would prefer anyway. I know that's where I started and couldn't get it to build but maybe things have changed now there has been more work done on it.

Personally I just want whatever works and allows me to focus on my software rather than constantly wrestling with libraries!

Yeah., I've already posted that PiStorm is currently stuck at Pi4 Max but I guess my posts are not visible or new readers (not you geennaam!) just don't want to believe it.

Reading through the thread again, I don't desperately see the point of PiStorm PPC to run OS4.1 on classic hardware. The vast majority of software (games at least) that we use OS4 hardware for would end up a terrible experience at best, if not a slideshow.

OK, you'd get a nice workbench experience and some utility stuff would probably run just fine. But I think that's about it. And it's all hypothetical, someone would need to do it first. And is it that much nicer than a well put together OS3 workbench running at 1440p? Probably not. Mine's pretty sweet for example.

The concept is sound. And we wait to see if CM5 helps with the GPIO situation (I think I read that it won't, but don't quote me on that), but I think the concept is better applied to other projects like other 68K targets or other architectures.

Were there even any other 16bit architectures? It all seems to be about 68000 all the time.

So, I built glfw, libgl4es and raylib against the now renamed clib2 (now clib4)

I can cross compile from docker a small test program. It sort of worked and sort of didn't. This is the bog standard raylib hello world window. It comes up nicely, I'm off looking at other things for maybe 10 minutes. Come back, click the window to focus it (I had other windows in front) and it just froze the system. I rebooted and just ran it without letting it sit there for 10 minutes and it was fine. I hit escape and the command line program ended but left the window there. Ignore that last bit. I was missing a CloseWindow() statement.

OK, so I figured I'd look at another example that I had which plays some audio. This is code on OS4 I don't have it on my laptop. I modified the Makefile to tell it to use clib4, tried to build it and gcc just tells me I've specified an invalid C runtime.

I guess this is my lack of experience here. I am searching the internet and not just assuming others will give me the answer, but how do I use this new clib4? I have run the installer for clib4 from github.

One last edit: Found the answer: https://github.com/AmigaLabs/adtools

Oh man, I'm not done yet it seems. I've got to rebuild libgl4es now against clib4! Definitely some banging heads against brick walls going on right now.

The updated miniaudio.h works fine incidentally. I'm all built now. Don't know what happened but GitHub clearly had a brainfart at some point.

I'm not 100% sure yet but I think you might have a corrupt copy of miniaudio.h in your amigaOS4 (v4.5) branch?

I've rebuilt glfw against your clib4 and when I try to compile Raylib4.5 it all goes well until I hit miniaudio.h at which point it throws hundreds if not thousands of errors. The file is huge so it's not the easiest to work on but somewhere around line 45000 there appeared to be a part duplicated block of code that just abruptly ends. The errors don't appear to be code errors, more like unterminated #defines and so on, basically like git has not pieced the file together correctly. This is on Github as well as locally so I don't think it's my end.

Search for "/* ScriptProcessorNode." to find the first place it blows up for me.

I have copied the version of the header file from commit c8ae696 (7 months ago) and Raylib build completes without issue. But of course you may well have made valid changes to miniaudio since then as it looks like you've added support for AHI.

I haven't tried Raylib 5 yet as I wan't to do some testing on my project with the existing version before getting into upgrading Raylib. No doubt I will anyway, but one step at a time!

[edit] The copy from the Raylib5 branch looks like a more sane copy that also includes AHI support and if I use that file it also compiles, so maybe it is a correct file in 4.5 branch and the one from 5 is OK? Too late tonight to try to test on X5000 though.