@afxgroup

So far I’ve not been able to find clib2 version of ogles2. If you know of one please let me know.

I’ll take a look at the tool chain. Thank you.

@hans

It does matter. The point is this is a repo that apparently builds and works which implies I’m doing something wrong. If it turns out that the examples are known to not work then sure, I’ll look at them and submit a PR but first step is clib2 version of ogles2 and see where that gets us.

@Hans

Note that I’m not doing anything except trying to compile afxgroups code. I’ve not be able to get started on mine yet.

@afxgroup

I think I'm stuck now - but by no means sure.

I used one of Walkero's containers to build GLFW that uses your version of clib2. I don't have a toolchain file so I used the following command(s) to build:



So I'm basically telling it to use clib2 runtime in both compile and link, setting a couple of options and pointing it to where I put ogles2 from the enhancer install. Note that although this lives in the newlib folder, that's just where I put it. I don't actually know if it is runtime agnostic or whether it is newlib or clib2.

At this point all of GLFW builds. There are two redefinition warnings on GL_VERSION and GL_EXTENSIONS but the values are the save between redeclaration so I think that's harmless. What is probably not so harmless is this:



But i really don't know what to include to solve that.

At this point the examples fail. So I just turned them off.

I then went to compile one of the examples (gears) on the Amiga. Of course this doesn't work and I assume it's because the Amiga doesn't have your version of clib2. But I wouldn't have a clue how to replace the SDK one or if that is even sensible, so back to the docker container.

The farthest I can get so far is this (I split the compile and link so I could be sure of what I was doing):


I really don't know how to resolve those last references or how close I am! It feels like I'm close but I could just as easily be way off here.

[edit] IOGLES2 looks like it's an interface definition which suggests to me that libogles2 indeed is shared and newlib. So is there a different ogles2 I should be using rather than the one in Enhancer? Maybe that's the bit I'm missing?

@Maijestro

Oh well, it is what it is. I guess the "due to restrictions" limitation is coming into play. It just means that on my external monitor I still can't go full screen. I don't know why but Qemu scales really, really badly.

It looks like the resulting gears program from the examples does run for someone on real hardware with an RX GPU. For me, under emulation I get no window - which honestly is OK, I was pretty much expecting this but the application crashes on exit. That's not OK.

It would be really useful if you could share your toolchain file. At this point I still don't really have any clue how to indicate to make that I want to use clib2. If I add -mcrt=clib2 then make just dies and cites that it can't build an application. I can get round that, but the deeper I get into it, the more missing libs I seem to have.

Under newlib I had to add ogles2 from Enhancer SDK and also GL4ES SDK by Kase1 (think the user name is correct) before I could build. Along with 3 or 4 other additional options.

Don't really want to interrupt, but is that new SM502 driver meant to support 2560x1440? because it doesn't offer it to me regardless of whether I manually add the resolution or not.

@walkero
Quote:

LOL! That's going to be a tough one to beat.

[edit] Never mind. I've built it. I don't have a lot of confidence it's built correctly given some of the warnings it spat out along the way but time will tell.

OK, thanks for the info. I'll see about creating a toolchain file tonight and switching to your clib2. If it works, it works.

@afxgroup

Is there any information anywhere on what environment you used to build glfw? I assume I need to build it from source since I didn't find it precompiled when I looked.

I know you said you cross-compiled it, but that still leaves a lot of scope. Did you use gcc? vbcc? some other? I was with a friend Friday night and we managed to get it to build but the resulting binary wouldn't work. I'm in the process of recreating what we did.

So far I've checkout out your master (glfw) and run cmake with -D AMIGAOS4=1 from within a walkero gcc container..

On Make I get an error that stdarg.h is not included so I include it.

Then I get an error that MAXPATHLEN is not known so I include amiga_platform.h

Then I get an error that ogles2/ogles2_defs.h does not exist so I zip it up from the 2.2 Enhancer CD and add it to the docker environment.

Then I get multiple warnings about implicit declarations and the fact the linker cannot find libdl. This is the point I'm stopping for tonight but from memory, after that's solved we then run into syntax errors because there are variable declarations inside case statements which GCC doesn't allow. It's simple enough to modify the code to fix that of course, so eventually the library will build. But it isn't going to run because of all the implicit declarations it guessed.

So as you can see I'm beginning to question not only my sanity but whether this was even built with GCC in the first place. I did add cmake to Walkero's vbcc container but I didn't get anywhere because I had no clue how to use vbcc with cmake. I am of course making the assumption that the commit I checked out from master was a working commit but reading the commit history looks like it should at least build.

@balaton

Quote:
It also didn't help when I added a bit of code to set the command to 0 for 0:0.0 - so I'm not sure there's a huge amount of point in worrying about it.

The Bios would be my suspicion too. We know it tries to process it on the RX cards because it fails and causes errors. The HD card I have it doesn't throw an error so must be getting to the end of the ROM.

There's definitely mileage in still using bboot if it can patch the 64 bit BARs. That's a pain to do manually. So far I was not able to get it to boot using bboot with the pegasos2 rom. It would fail to find initrd start. Maybe I've done something wrong in my zip file. I haven't debugged it yet.

I'll message you this evening. The changes weren't anything major. One missing file (missing from OS4), one tiny code change and one linker change.

@geennaam

It doesn't happen with pegasos2.rom either, only with bboot. So this was why I was trying to find out what was different between the two but it doesn't appear to be anything that's obvious from the printed output.

If I use the old method of pegasos2 rom with my manual fixes I can boot and use OS4 normally albeit it with Interrupt=No in the HD driver. It's slow however so something isn't right.

@kas1e

So this means that what we're doing should really work, yes? I didn't try morphos. I could do, but so far it has never been happy with the card whichever method I use.

@balaton

I've spent some time tonight looking at PCI Passthrough for 5450 GFX. BBoot 0.4, Qemu Master. I can't get it to work. Boot hangs before workbench even starts to load and leaves me with a grey sceen with the text "Workbench" in the top left in an old PAL-like resolution.

Hopefully I've not omitted any info. Let me know if I have.

I've compared bboot output from using pegasos rom with my manual forth patch:



To the same through bboot:



Unless you can spot anything, the only thing I could really see was that the command for bus 0:0.0 was 0 when using pegasos firmware and 7 with bboot. In addition, we know we are adding an empty assigned addresses property when there are no addresses.

I modified my bboot to match the command on PCI bus 0 but it didn't change anything:



I did also do a further test with the empty assigned addresses removed just in case this was confusing OS4 in some way. Again, no change.

At this point I'm not really sure where else to look!

@Maijestro

Quote:

When it works, it should work very well. I used to run all my Windows games in a Windows VM using GPU (and USB) passthrough. Ideally there will need to be ways to switch monitor inputs and keyboard / mouse (or pass them through too). It's all possible but obviously needs extra work.

Of course, I agree that OS4 drivers is also a nice way to go and I'd see the benefit there too on my laptop.

Quote:

I am part of a team that has created a sort of game engine but it was never completed. I intend to look to se if it could be brought to OS4 and maybe the goals re-aligned a bit so it could be completed. No public info yet and potentially may never be.

Unfortunately, at the moment Qemu is never going to work properly on my Mac Mini. The sound doesn't work with my USB Audi Interface and I don't want to route all the sound through the Mini's internal speaker to get round it. This is kind of a known thing. At one point Qemu couldn't even start a linux VM as it would kernel panic and shut off prior to login. Switch off the audio interface and it was OK. This was "UTM" but I believe it was Qemu behind the scenes.

Qemu is fine on my laptop for a bit of tinkering about but the GPU is the sticking factor there. And not the resolution, 1440x900(x2) is the native resolution of the screen but developing games is a non-starter.

So, the GPU passthrough stuff is a bit of fun to play about with but that will reach a pause when my X5000 arrives as I'll need the case the "passthrough machine" is in, not to mention the GPU.

@geennaam

Yes, I thought the one on Enhancer was for X1000. Let's face it, if that wasn't the case then there never would have been a reason to have yours

Well, whatever your reasons, I hope you're able to bring it back some day soon. I will keep the Audigy FX since it wasn't much money but in the meantime after speaking to Amigakit today I ordered a CMI8738 based card off Amazon.

@Maijestro

Sure, at the moment we don't know for sure on GPU passthrough if the register addresses (I think that's what we're talking about, I know which addresses I mean in the output / code anyway) should be left undefined as they appear to be on real Pegasos2, whether the IRQ's should be mapped when they are unassigned by firmware and so on.

I could keep coming back here, posting log output and then Balaton can make a minor change with "try this", or I could try the changes myself first. If I understand where to make the change of course. It doesn't matter if I do it exactly how Balaton would do it, or not, at least then I can say "well, I tried x and y but it didn't help, here are the logs". Etc.

Unless I'm wrong and we've exhausted all options but I don't think that is the case. I also have access to HD5450, RX550 and RX580.

One thing I will say is that I've switched to a different PC and the PCIe slots are a bit blocked by the CPU cooler so I'm a bit limited now. "New" (actually older) PC is Intel 6700K based but actually, that has a faster single core frequency than my Ryzen system so it's better for Qemu really. The IOMMU isolation is not as good however and I think it might be causing me problems.

I managed to build bboot on OS4 last night (in Qemu on my MacBook). I had 3 issues with the code compiling but they were all sovled in the end. I don't know if it's worth listing them because I doubt many people are likely to be building it on OS4. Just try as I might I could not easily get a cross-compiler set up.

The whole reason I'm even building it at all is so that I can at least attempt to try different things out when things don't work. Hopefully that's helpful!

Unfortunately my time continues to be limited this week and there will be no time at all soon due to vacation. But I should be good for tonight to at least check that the bboot that I built runs.

Isn't there one for X1000 in addition to this one?

That’s a shame. I just ordered an Audigy Fx