@Nuder_Try

Please do not post crash logs in the forum. You can submit them directly to the developer on os4depot. Just click the [Show crashlogs] button on the files readme page on os4depot.

I've submitted your crashlogs for you and replaced them with quicklinks.

In case the clib4 hadn't properly activated, rebooted and tried again, got an ISI:

http://crashlog.os4depot.net/cl437

OK, still getting crashes. DLed the version for OS4Depot last night, installed it and clib4, got a DSI:

http://crashlog.os4depot.net/cl436

@smarkusg

Quote:

I don't think it's because of the shaders. I've seen the same behavior with software rendering and Grim Fandango.

@all

It should work on Ultima 8.

@kas1e

Many thanks for the explanation, still a bit confused though.
If the plugins are just just linked to the latest version, why are they changing in size and no longer working with games they did previously?

I'm no dev, so might be missing something very obvious.

Cheers

Ah okay.
I thought it is possible to use modes A5 and A6.
From what i understand, they’ve been removed in linux, but maybe its possible to add them. I have no idea.

*/We support 5(A0-A4) power states excluding turbo(A5-A6) modes */

@Maijestro
Quote:

Maybe just leave the OpenGL shaders alone for now.
Once you’ve built a stable version, have a go at experimenting with the shaders.

I’ve had a quick look at the source code – perhaps something I found might be helpful (I’m not sure, as I’ve no way of testing it).

Take a look at these OpenGL-related options in the MorphOS commit – in the MorphOS version, shaders are disabled.

https://github.com/scummvm/scummvm/com ... 52dfa289fdab5d1e3dc5bdcf5

You already have the stack set up
https://github.com/scummvm/scummvm/blo ... gaos/amigaos-main.cpp#L59

@Maijestro
Quote:

Newlib of course, clib4 wasn't there at this time.. I doubt it's issues in C runtimes to be honest, most possible it just issues with shaders, etc.

And, btw, this one:

Quote:

Pretty wrong: I know it, i do code for os4 and morphos sometime, there are areas where OS4 is better. Morphos just have logical management and no legal issues, as well as they have up2date browser, but it have nothing ground breaking under the hood which os4 didn't have. More of it, OS4 have better support of 3d party libs, SDL, drivers in terms of video, the whole coding over OS4 is more easy, especially when it comes to handle those "hooks" and traps of all sorts, while on morphos they still over-complicated it with all those 68k tricks.

It's just you need skills to use all correctly, be it OS4 or MOS, but in general both oses have exactly same issues and abilities in general, with some small differences in user land.

But that OT of course, sorry :)

@TearsOfMe
Quote:

Yes, but you probably mean set it right once computer boots, and cfe only starts to load things up to speed up whole CFE booting process? Or you mean to change state when we already have CFE loaded till the prompt/menu ?

Why i ask it's because for now we do real-time patches, mean we need environment of CFE from where we run them. So we already in loaded CFE, where we already can do "set pmu -astate=a4" which as far as i understand (seeing linux's cpu_freq.c and cfe's disassembly) doing exactly that, set it to 1.8ghz

So probably what you mean is to set it to 1800 right at the beginning of reading date from EEPROM so to have 1800 for whole process till menu, which can only be done by permanent patches later, not by real time one.

@Maijestro

Well both OSes have there own specialties, thats not the point. It would be great to have SCUMMVM on my X5000 working as well based on you latest version. I just thought that in the SCUMMVM version from 2026 when compiled all engines are just there... but i am probably wrong As Kas1e pointed out it could be that its not enabled yet.

Anyway keep up the good work!! I might try out one of these new games you listed.

@kas1e
It looks very interesting. Thanks for developement!
I will try on weekend.

@kas1eQuote:

At least when i build it before all were fine, but, as i say before, it needs gl4es/ogles2, so shaders, and those ones was (back in past) need a little bit of touching to make them works. See, how it was:

I also built it with gl4es/ogles2 support. In this case, though, I used clib4 exclusively. Do you remember whether you built everything using newlib or clib4?

As I mentioned earlier, there were dozens of commits after 2.9.0, and all builds after 2.9.0 now have issues with some engines. Not all of them, but yes, the issues are there.

@Maijestro
Don't worry THAT much, i am sure you will deal with everything :) It's all just matter of few weeks, and you will know all the details about. Main point just to hold concentrated on this "thing" until it done..

Quote:

At least when i build it before all were fine, but, as i say before, it needs gl4es/ogles2, so shaders, and those ones was (back in past) need a little bit of touching to make them works. See, how it was:

@kas1e
Very interesting. Nice Work.

Maybe there is a way to change the astate?
200Mhz more can be nice and my procesor temp is always low at around 40 degree Celsius so temp wise ist see no Problem.

@kas1eQuote:

Unfortunately, it’s too late for that—the damage is done, and yes, I’m partly to blame, but it wasn’t my decision to overwrite everything. Bringing everything back to the state of Raziel’s last work would upset some users again. Raziel’s work is firmly established on ScummVM.org and can still be obtained from there. Of course, I am now partly responsible for getting everything back to a clean state, and I will certainly try to do so.
Quote:

Thanks, I understand now and will add it. Of course, I'm just getting started and need to figure out the right way to do this for AmigaOS 4.1. Any help would be greatly appreciated.

Quote:

All the engines have been compiled and are enabled; everything is there, but they just need to be linked so that ScummVM can use them. I have deliberately included only the engines that I have tested myself. The Grim engine shouldn't actually be included, as it causes problems. There are many custom builds available for AmigaOS 4.1, including 3.0 and others, but Grim Fandango no longer works on any of them; there must have been some changes from 2.9.0 to 3.0 that broke it again. Or maybe I didn’t include the necessary changes. Since the source code was also deleted, I have no way of knowing how Raziel did it for 2.9.0. Now I’m starting to debug and test, and progress is slow. Grim Fandango already works, but Manny doesn’t show any arm or leg movements.

I know you tested it relentlessly back then until it finally worked. We’re already in a very good place, and for the first time we also have a stable Wintermute engine for modern games. Hopefully the other issues will be resolved so we can get everything back up and running smoothly. Once again, I apologize for the chaos I caused, but it wasn’t my intention—I just wanted to give something great back using the opportunities I now have.

Preface

As we are all aware (or not), we do not have the CFE source code for the X1000 that includes the
changes from PA-Semi and Hyperion. However, we do have the full CFE source code prior to those
specific changes. Combined with Ghidra for PowerPC decompilation and various disassembly tools-plus
the knowledge I gained working on the PA6T network driver regarding CFE binaries and its API-it is
now possible to create CFE patches even without the original source code.

Note that x1000's CFE firmware is the property of A-EON/Trevor, so I cannot distribute a ready-to-use
patched version of x1000's CFE myself (right? or can i?). But what I can distribute later for the brave
is a tool to patch your own CFE. Of course, I will test everything on my own hardware first; I currently
have a hardware programmer, so I can wipe and re-flash at any time without risk.

That is for later, though. Currently, I am making all patches "real-time," meaning you don’t need to
re-flash anything. They reside only in the current CFE memory and will be gone after a reboot or
power-off.



What is the practical use of this in its current form ?

You can add them to CFE and have them run at boot, or manually load them via TFTP. The real goal is to
verify that they fix existing issues without introducing new ones. Once everything is stable enough,
I will start experimenting with my own flash to make them permanent.

In other words: any X1000 user can play with these now without fear. However, if you "burn and die," I
take no responsibility. You should know what you are doing.


Running the patches

Patches should be executed using the boot -elf -noints xxxxxx.elf command. Both flags are necessary
(without -noints, the system will simply reboot after a few seconds).
You can run patches in any way you wish - just one per session, or all 3 at once
(the hooks are placed at different addresses and do not interfere with each other), like:



or via TFTP if you want to test them one by one:



or if you have no CF card, you can simply put the patches on your Amiga FFS BOOT partition alongside
your amigaboot.of, and run them from there. These patches are built in a way that will not crash even
if run from CFE's AmigaFS, which lacks (or has a broken/unimplemented) seek() implementation, so this will
work too:



To make them run automatically (all patches, or just one - which will likely be keycon for most of us),
change your STARTUP label from just set pmu -astate=a4; menu to:



Now it will run on every boot.

So...

What we have now ?

Patch #1: SATA (sata.elf)

- Added probing for Channel 1, so SATA ports 3 and 1 now work.
- Fixed detection of "slave" devices even if no "master" is present.
- Devices on any port will now be detected. You can have Port 0 (Ch0) and Port 3 (Ch1),
or Port 2 (Ch0) and Port 1 (Ch1) working together, etc.


Patch #2: Keyboard/Console (keycon.elf)

- Key repeat - Holding a key now auto-repeats (500ms delay, ~33/sec repeat)
- Home/End keys - Jump to beginning/end of line
- Delete key - Forward delete with repeat
- VESA cross-line backspace - Backspace at column 0 now wraps to end of previous line
(was moving cursor off-screen to pixel x=-8)
- VESA cross-line left arrow - Left arrow at column 0 also wraps to previous line
- VESA ghost character fix - Up/Down history no longer leaves remnants of longer commands
(VGA's writechar didn't implement it originally)


Patch #3: External commands (cmds.elf)

- "cls" - clear the screen
- "version" - returns the CFE version.


Download them from there:
https://kas1e.mikendezign.com/aos4/x10 ... rmware/cfe_busted_v01.zip

Have fun and let me know how it goes, thanks !

@TiredOFLife

The matter of having any engine build into ScummVM is just simple enabled them in the build line telling scummvm build process what engines will be build into, and that all.

Everything which does not support opengl/shaders/, simple enables and works, that all : Majestro should simple enable EVERYTHING, if i remember right scummvm build system have option for.

Them when it comes to opengl , when i made my own builds, there were issues with shaders which need fixing : some of them were go to main scummvm trunk, some of them no (if i remember correctly), but the main point , that without normal testing and knowing what you do, none opengl Engines will work : especially that one which handle Grim, Moneky Island and co.

@Majestro
IMHO, as you only on the start point of learning how to make amigaos4 apps (And even with AI help you will need all this understanding) , maybe it worth right now to upload on os4depot Raziel's 2.9 version back , and then, there in that thread continue testing , and once it stable and tested, only then upload it to os4depot ?

Also, you need to know that every "big" project on amigaso4 need so called "stack cookie" inside of the binary itself (not an icon options or whatever), and it should be usually 2mb for good (Odyssey have 1 or 2mb for example, scummvm should have at least 2 too). That done with one single line putting somewhere in the source code (doesn't matter where), but better right before main() at top, like that:




Then, you should also be double sure that you enable ALL engines in scummvm , i do not remember the switch, but there was one for sure. Or, simple list the supported engines, and enable it command line build string yourself. But be sure that the one which use opengl need deep checking to make it all correctly : i did it before, just didn't upload over Raziel's work, and not sure if he did it too as well or not.

Also, you can enable all experimental engines too, that no problems as well.

@kas1e

Quote:

Thanks for your testing.

Quote:

I knew it had to be something like that. I would prefer it follow a known standard. But even CFE matching the numbers would have been nice.

Quote:

Sounds like the annoying dots on screen when the A1/XE couldn't find a master. But I have had a drive disappear on my X1000 right after a reboot and CFE stop with no drives found. Don't know what it is but my X1000 can be fine for an hour or so, usually with Linux, then I reboot and suddenly get SATA errors on boot.

Quote:

They did. The plot thickens. Maybe they wanted the best of both worlds. There is UBoot support in CFE.

So Just noticed the following in the AmigaONE X1000 Firmware and Booting Guide Version 5:


If Amigaboot cannot read or detect any USB devices, then how can it disable USB?

@Maijestro

Am I right in thinking that newer versions of ScummVM need the engines recreating?

Cheers

@Skateman

You know, AmigaOS 4.1 lags behind almost everything MorphOS already has. Congratulations—then the new engines and games shouldn't be a problem

Necronomicon: The Dawning of Darkness
Crime Patrol
Crime Patrol 2: Drug Wars
The Last Bounty Hunter
Mad Dog McCree
Mad Dog II: The Lost Gold
Space Pirates
Who Shot Johnny Rock

Since Ultimate 8 is in high demand, I’m going to try to get this engine running next. I’ve since bought the game because no one is properly testing it or providing information about it. What no one seems to realize is that new versions sometimes bring a lot of changes, all of which need to be taken into account so that I can continue using the new version without any issues.

Right now, I don’t want to rush out new ports; it’s more important to me that everything works properly. I’m still dealing with some engines that aren’t fully functional, including Grim Fandango and other games like Syberia 1 & 2. I’ll think about it once those issues are resolved. But yes, I know Syberia 1 and 2 also run on MorphOS, just like the Wintermute Games