@capehill
Thanks for the info. But, mednafen is build with SDL2/GL4ES and so is SM64. Mednafen works with my controller and SM64 does not. So I am just wondering why there is that difference.

But my controller works with Mednafen so I am now confused.

@capehill
Do you have any insight?

===

gamecontrollerdb.txt, I do see this being read in SM64 code. Perhaps mednafen uses a different approach and the mappings can be done at runtime. Will have to browse the code at some point.

@mufa

Right. Well, I am using some cheap USB controller and I cannot move at all. Not sure why.

I am not sure if the controller code is actually working on this port, and perhaps you guys have configured AIA to map the controller to the keyboard?

Right, I think you mean that you can just use something like AmigaInputAnywhere to map controller buttons onto keys.

That would be the easiest thing to do.

@samo79
You said it worked with AmigaInput? I have to say, when I tried to move around with my controller that is configured on port0 I could not move using it.

I wonder why it is not using SDL input.

I never really looked into it yet.

There is just no point in going to GCC 11+ without first bringing binutils up to date. Our version, 2.23.2 is now 10 years out of date.

I will work on this myself if I have to, but I wondered if you could provide hints because at the moment I think a manual approach is required; and I find it baffling that you made all of the changes from 0001 manually. If so - well done! I know that you skipped the non OS4 parts too, but that is still a lot of eye straining.

On your branch I see that you applied one large commit, probably up until patch 0010 where you ran into trouble. Because it is one large commit, it is difficult to integrate this back into ADTOOLS. Really, you need to save the diffs per patch, so that you can have a new 0001, 0002 etc.

Hi, @MightyMax

In your original post you say that you applied the patches manually. The first patch, 0001 is 27k lines long - did you really do this manually without any commands?

Curious, thanks.

@walkero fixed it!

Surprise, surprise - I wonder if the command was actually tested on OS4 and not just tested on System v54. Although, using the output of a subshell as an argument to DIR is probably not done that often; I guess such a test case can be forgiven for being missed; personally, I would have tested it. And... that is if there is any testing at all.

Hi. I can reproduce that on my 5020 also.


The reason I used that command was because I was in linux-mode, where expansion happens before the command is executed. This is not the way it works in Amiga land since:

will not perform an expansion before invoking the dir command.

Since that was the case, I decided to use:

with the intention to pull back the relevant script name and then execute it.

But, as you say there is an issue with this for whatever reason. I am not sure if Amiga does perform the expansion in the backticks first - in fact, it MUST. So, why DIR is failing I am not sure.

===

As you know, by default the command script in adtools_testing comments that out - if there is a better approach then please do a PR.

But, the question remains: why is this causing a crash?

@samo79

Hey, I received one message yesterday. It seemed to be an endianness issue which I have since fixed in the released 1.257 version.

Though, I only realised afterwards that there was an annoying bug in the decryption program that makes the progress hang more than expected between 90% and 100%. That has since been fixed, but it is purely a cosmetic thing since it is only a bug in the output logging. But another update to it would probably start to annoy the Os4Depot maintainer!

I think there is now nothing else to do?

They have now been uploaded to Os4Depot, a new version is in the "Uploads" section with endianness of ROM handling. That is version 1.257 for each gl4es/minigl.

@sinisrus
Which language? I only own the US ROM and not legally any others, so that would be difficult.

I have uploaded two versions of the game.

1. GL4ES / ogles, for HD / RX
2. MiniGL / Warp3d, for older

They are currently in the "Uploads" section of Os4Depot.

You need to have the super mario 64 ROM in the same directory as the encrypted binary and run the decryption program to be able to decrypt the binary. At the moment, the ROM file needs to be in BE format, but I have made another change to the decryption program to automatically detect this and byte swap it if needed, but that will not be available until the next version.

Please add more tests by all means.

I also get failures on < gcc11 or with a different SDK, cannot remember which.

Thanks for trying it. You can try the latest version, or just see my reply to the issue you raised. Not sure how far it will get; let's see.

BTW, working with @walkero and @afxgroup

The repo https://github.com/3246251196/adtools_testing

Now also provides an easy way to build a cross compiler with a single command. It handles dependency checks etc.



Is the only command you would need to run on your machine to build the latest cross compiler ready for use.

For more options, run

Thanks @samo79.

Well, the version I sent you was a different build to my original.

The one that other people have been testing with was built with:

And, with a symlink of

pointing to the GL4ES headers.

The one that I sent you was built with:

And, with a symlink of

pointing to the MiniGL headers.

===

As for mednafen. I always built it with full SDL2/GL4ES and yet it works for you. So, perhaps it is some function call in particular in SM64 that is causing an issue and which is not used in Mednafen.

@samo79

Although, for you, I am not sure why it does not work because doesn't Mednafen work on your machine? I build that with GL4ES.

As to why it doesn't work on a non RX/HD card:

https://www.amigans.net/modules/newbb/ ... id=130809#forumpost130809

explains it. I always need to revert back to that thread since the combination of subsystems and their associations ALWAYS confuse me.

Having read that post from kas1e again, I guess I would need to

- re-build sm64 with minigl/core SDL2 (and make an additional release)
- find out a way to make the static binary releasable due to the embedded copyright. Not sure if encrypting the static binary and unencrypting it after performing an md5 sum on the user's n64 ROM and all asset files pass would suffice... Still, whether the bin is encrypted or not - it is considered a copy.

I would upload it to OS4Depot, but there just does not seem to be away to strip out all the in-built copyright material. I seldom come across a build system like it. It would take time to look into it more to see if there is a more appropriate way already existing in the build system, but I have not had the time to do it yet.