Thanks yes that would explain it. Though i am using a docker image which contains the libpthread.a. I guess when that image was created the wrong lib was used.

I am not sure were i got the so from. But the problems
which i had with the .a are gone with it (no longer uses
threads.library). And i use newlib.

Thanks. Using libpthreads.so (not sure from where it came but probably from the SDK) fixed the crash issues (at least one source of crash issues, there is another one which is unrelated to pthreads but I think I found a solution there too).

If i link with -lpthread should my program use
prhreads.library? If yes how to cause it to?
My program calls threads.library (i do not
directly call it i only yse libpthread.so).

Is it a problem of includes or linkerlib or so lib, that
I use a too old version there?

I would like to go for the new version as the old version
(Threads.library) seems to have bugs but i do not
know how i can make pthreads to use pthreads.library
Instead of threads.library.

If i have to recompile my program to make this change
this is no problem it is not yet released anyways.

Thanks.

Steffen

Still, even if that worked (.) it should theoretically just copy things over to one directory on top.

My suspicion is that the layout of the download version is slightly different and the stuff in "." integrated somewhere else. So probably removing the "." and ".." copy operations and everything else should work fine. If you send me an email address I could make a version which checks if the files exist before copying.

But might also be that by just copying over the exe and stuff the whole thing runs. The point where it aborted nearly all the installation was done already.

Hi!

Yes, of course you can ignore the installer.

What in case of the battle net stuff you definitely need to do though is to run the wartool exe to depack the stuff which is in a "special format" from Blizzard on the original distribution (whether CD or not).

You basically need those two archives from mpqmaster and the "base directory" where your Warcraft2 distribution is in.

Then you would call

c/wartool -v work:distribution/DATA work:Warcraft2/wc2.data

This assumes you have the stuff from the distribution in work:distribution, and the future install would be in work:Warcraft2.

My suspicion is though that if you remove this line

(copyfiles(source (tackon #strat-dir "wc2.data/."))(help "")(dest(tackon #strat-dir "wc2.data"))(all))

from the installer at line 1014, that it would run (possible that the next line also needs to be removed).

It seems the wartool-depacking has been correctly done, but that in your version the stuff looks different.

Maybe you can send me a list (just do a

list Programs:Games/Warcraft2/wc2.data all >ram:filelist.txt

and then send me filelist.txt so I can check how the archive of the distribution differed from the CD.

Another possibility might be that you have some tool installed which actually does the "./" as on Linux instead of creating a directory named ".". Is this possible ?

Best regards,
Steffen

The Battle.net version i tried with was an actual CD.

I assumed the digital content blizzard sells would be the same files.

Does the installation work after the workaround or is there still an issue?

The whoole mpqmaster stuff is due to the depacker for those “tome”
files could not be ported (not an endian issue btw on other
Big endian systems it runs).

The easiest though is to use the old dos cd this also enables you to
convert audio tracks (admitted you might have to reencode the cd
As the amiga has problems with “red book” multi session cds).

When i am back home tomorrow i will check on the error message
and how i can adapt the installer to the obviously different layout
of the version you got.

Feel free to send me an email.

Steffen

68k beta is now also available, at the same conditions;)

WarpOS version is sent to two testers if it works (68k beta is
already tested). If it works it will also be included to
the installer (install archive contains both os4 and
68k version)

@Estrayk

Yes, the lower ones should work fine (the very low ones like Gameboy Advance or A5200 will of course be no problem but I expect something like SNES, Sega or Supergrafx16 also to work).

I can check to get you fps data if you like.

@Estrayk

Yes, the lower ones should work fine (the very low ones like Gameboy Advance or A5200 will of course be no problem but I expect something like SNES, Sega or Supergrafx16 also to work).

I can check to get you fps data if you like.

Thanks. Yes, sounds like it that I should not waste more time with Frodo Core then.

Currently trying to get NeoGeoCD to work.

Vice I will look at later. Basically "line too long" with linker command. Same problem like Mame.

I sent you the latest beta ;)

Btw anyone here experienced with frodo c64 emulator? I compiled a core but when i type on the emulated c64 a not usable onscreen keyboard pops up and i am unsure if it is a bug in retroarch or in the frodo core. If someone can give me a hint that would speed up the look for the error. Thanks (i also tried compiling the vice core but have still an issue with the linker there)

List of currently supported Cores in the Amiga Version:

- SNES9x
- GenesisPlus GX (MegaDrive, MegaDrive CD, Sega Master System)
- Mednafen Supergrafx (SupergrafX16, PC Engine)
- PicoDrive (MegaDrive, Sega Master System, Sega 32x)
- Virtual Jaguar
- A5200 (Atari 5200)
- QuickNES (NES)
- mgba (Gameboy, Gameboy Color, Gameboy Advanced)
​- Final Burn Neo (NeoGeo, Capcom CPS-1,2,3, Namco System 1/2, Sega System 1/16/18, ...)

Sega 32x Emulation and Virtual Jaguar are pretty slow (both playable on x1000 but only without sound - maybe on x5000 fully playable ?) all others are pretty fast (like 50-60 fps on x1000, and yes this includes the stuff from Final Burn Neo ^^).

There is a Playstation Core in an Alpha version but without GL (later I will add GL hopefully ^^) it is pretty slow (again the "without Sound halfways okay on a fast system). Also the playstation core crashes on exit, I still need to investigate this.

Beta Versions are still available for people who donate

Best regards,
Steffen

@davebraco:

Now that the big one (Move from 1.7 Codebase to 1.21 Codebase) is out of the way, new cores can be made. Though also still the 68k and WarpOS compiles are to do.

RetroArch is a modular Emulator, which supports "cores" (like libraries) for all sorts of retro systems - from Atari VCS 2600 till Sony Playstation.

To adapt a new "core" is easier than writing a new emulator - stuff like sound, video refresh etc. only needs to get implemented once, in the main exe.

RetroArch for AmigaOS (initially only OS4, I try to make WarpOS and 68k versions later too) will be different to my usual way of distribution - FREE (too many emulator cores have restrictive licences which do not allow commercial exploitation).

Of course as this is a mammoth project to port many cores it would be great to have some donations to allow me to spend more time on this project.

There might be a few "commercial core ports" later (thinking PSX, N64, Gamecube etc.) but asides from the "3D cores" all other cores will be free.

Donations can be done by PayPal to tirionareonwe@gmail.com. If you donate remember to also send me an email so I know to whom to send a Beta version And if you prefer to wait for a stable Beta, or want one immediately.

Every one who donates

At least 10 EUR -> gets the Beta versions. And if there will be "commercial cores" at least one commercial core free.

At least 15 EUR -> gets the Beta versions and if there will be "commercial cores" all of them free.

Note I cannot guarantee a specific core will be successfully ported. But I will try to make a lot of them. I also will try to port a recent Mame port (included in the "free cores") but also there no guarantee.

If you donate now you can immediately get a Beta. The Betatest already started (current Beta crashes on Exit though, I will fix this with the next Beta ^^).

RetroArch includes a GUI and an installer. A future version could also be used as Videoplayer (RetroArch supports using it as frontend for ffmpeg - current Beta does not include this, but probably I will add this in later).

Currently supported Cores in my port are:

SNES9x - SNES
Mednafen Supergrafx16 - SupergrafX 16, PC Engine
Genesis Plus GX - all Sega 8/16 Bit machines, including Megadrive CD

There will be more cores.

Total list of possible cores to be ported:

https://docs.libretro.com/guides/core-list/

MagicSN

Thanks. Actually i could not yet compile it
Without -mhard-float (which probably breaks it
on a1222) but i will try still. Concentrating on getting
It to run on os4 with the new version 1.21 now.

Note that at least some of the 3D Cores use stuff we do not have (Vulkan and/or 3.x GLES - I think we only have 2.0 GLES).

Of the PSX core I think there is a Software renderer only (Software or Vulkan or 3.x GLES as the 3 options if I remember right).

N64 is I think GLES based but uses a bit a different API than what we have for some functions, not sure what is going on there. Ah, I just checked, there are several versions of the N64 one, one is for GLES 3.x, one is for GLES 2.x. Maybe I did my test compile on the wrong version Pretty sure this was the issue. As to PSX there is indeed one with software renderer and one with hardware renderer.

Sega Saturn core compiles through, but before I updated to RetroArch 1.21 it does not make sense to test complicated cores.

Just a few minutes ago I actually got a version of 1.21 which links (though not yet re-integrated all my changes from 1.7, first doing a quick test if it still works, then integrating those changes will be the next task).

@Maijestro

Want to port ? You have mail ^^

For the rest of you:

I have already ported an older version of RetroArch (with Bugs, and due to the version being pretty old only few cores run with it - I have 3 cores running right now, SNES, SupergrafX16 and Sega 8/16 Bit one). I am working on updating my code to the latest version so more cores will run.

The 3DHW cores will be tricky though, and how much work I can invest (How much time I can spend on it) probably also depends on - donations (PayPal tirionareonwe@gmail.com). No guarantee one specific core will run. But I want to get a lot of cores running.

@All:

Interested people in doing a donation of 10+ EUR could get access to the Beta (against NDA). Due to the nature of the project (many cores do not allow commercial usage) this won't be a "pay for download" project, but obviously a few donations by PayPal to tirionareonwe@gmail.com would give me better ability to spend some time on this. And remember - current version has bugs.

I have a range of cores which compile but do not work (mostly due to the outdated version of RetroArch I am at currently - around 50% of the newest version already compiles though).

@K-L:

Do not worry, I do not give that up. Sin is heavy in work (and the Sin mission CD especially, works pretty good already). And there is one more title I hope to have up till Amiga40. And a third title were I hope it can be licenced.

Hi, Estrayk!

Many thanks for this video and also for the video on Stratagus in the other thread!

BTW I left still open on a question further up in one of the two threads by someone, on what I would be working now.

For one this is Sin (and the Mission CD of Sin). The second project is RetroArch, this is a modular Emulation system which has "cores" for nearly all famous emulators. Already running is a SNES9x Core, a Mednafen Supergrafx+PC Engine core, and a core running all sorts of Sega 8/16 Bit hardware, including Megadrive and Megadrive CD.

Best regards,
Steffen

@Mr_byte:

Absolutely agreed and thanks.

And yes, i am very impressed with what HunoPPC
Axhieved, he needs the support. It is probably harder
for him as people can download his ports for free.
I think if you use them you should donate. And especially
that direct a1222 support is hard.

Note i am trying to get new stuff also.