Well, another year has passed and we welcome the new year 2025. Gosh - a quarter of the 21century already over!

Don‘t want to sound bitter or sour, but when the millenium started I looked way more positive into the future. Since 25 years we are living „in the future“ now but it developed other than expected… But let‘s not forget, beside all the bigger and smaller catastrophies, sorrows and othe woohs we also had really nice things. And from a MorphOS POV the millenium wasn‘t actually bad so far. Of course expectations have been higher and recently it feels like momentum slowed down a bit, but eventually we are still here - alive and kicking!

So, what's in the pipeline for 2025 from a MorphOS POV then?

Someone with deams, hopes, actual expectation, announcements - bring them on here!

As always :

Things that should be done > things that I could do > thing I could do in a reasonable timeframe > think I will actually get around doing ...

At least I haven't fallen into my usual post XMax motivation drop of that usually last till at least easter ;)

Happy New Year!

As you write, there's not much to complain from a MorphOS related view. In the last quarter century it has matured very well from an Classic AmigaOS appendix to the most developed Amiga-like OS, bringing out the best for it's limited prerequisites (PPC).

I hope every MorphOS user and developer keeps it's own flame and passion for MorphOS.

I wish the development of Flow Development Studio would be resumed. I love the application and dream of a new version. :)
I hope we will get next version of MorphOS.

I would also like to finally finish working on my game for MorphOS and quickly create ports for other platforms. The work on the 'Orbiton' game has been ongoing for 6 years, and 2025 must be the final year. :D

I'd really like to see more active users in here and some good new software. Even if that means paid software. Its been far to long for new exciting things to come out for MorphOS.

MorphOS 4.00

Oh yes...some more love to flow studio would be nice. With better debugger integration.


[ Editado por tolkien 03.01.2025 - 15:12 ]

Quote:

I have been following the forum for quite some time and I just got myself a MorphOS license for my Mac Mini G4 a few days ago as I intend to brush up my coding skills using this setup. What kind of new software are you looking for? Perhaps you can give some ideas.

+1 for Flow Studio continuance. Are there any public APIs for its syntax-highlighting editor? Also, I'd like to update the ECX plugin for features of EEC as development of the AmigaE programming will likely revert to AmigaOS 3.2+ without it.

-better GPU support (so we get hardware video decoding).

-multicore support, (asymetric at least so cpu-intensive tasks can run in parallel, even if It requires specific support from the application). IIRC Krashan wrote about this years ago.

-x86-64 version availability, even if it was just limited to bigendian ABox running PPC/m68k binaries, I don't care if It required a 2nd hand "old" radeon as the ones we use right now ( looking for old ppc machines is worse). I understand that the team probably wants to wait until more "complete" support, new execution "box" with improved and modern API is ready but I think that It would be more practical ATM to keep the x86-64 side "closed" and force users to just run PPC/m68k code with limited memory)

-64bit ppc support on G5?

@Crumb

"Expectations" or wishlist?

- HW video decoding
Doubt that makes much sense when the majority of users are still on R200/300 cards (well mostly onboard)

- multicore
Pretty much the same thing as above (G5 and X5000 only) and depending on the implementation it could be limited even on most of those. Also adding another binary format for a dead end platform does not sound good.

- AMD64
Sure everyone wants that, but big-endian AMD64-31bit apps are a must to get any reasonable performance.

- 64bit PPC
See "multicore"

MDD has 2xcpu setup also

Quote:

So?

Do you really want to support yet another binary format for 32bit "SMP" PPC?

Quote:

I thought, that binary formats for 32-bit single thread and SMP are the same. It differs "only" in kernel, which support or not supports SMP ( or other multiprocessor system ).
Applications written for SMP can benefits from more hw threads, but overall system performance is increased even for old ( single-thread ) applications.

As I know, binary format differs between 32-bit and 64-architectures, not SMP/noSMP.

MorphOS 3.19 soon

@sailor

There is a reason why I wrote "SMP" and not SMP....

Amiga/MorphOS APIs are incompatible with real SMP, so any multi CPU design would need to live outside of it.
At minimum like PowerUp modules or at an extreme running the ABox hosted on a modern OS.

Now sure one could come up with away where those SMP-modules could simply run alongside the ABox in single CPU systems but that would restrict them to 32bit negating one of the benefits that would make such modules interesting.

So given the limited resources and they need to build/distribute SW for every supported variant I simply see no point in doing anything like that for 32Bit PPC, even with 64Bit PPC it's still debatable.

And about my 2025 expectations:

- in first place (of course) bigfoot's Big TinyGL upgrade should be great.
- and maybe something from my several times repeated wishlist:

-- MorphOS:
.support for CD/DVD connected via USB ( CDDA, ATAPI, boot*.img support for CD filesystem )
.SATA2 Promise driver to boot.img
.basic support for graphics cards TeraScale3 ( fastest PPC linux ) or CGN1/4 ( fastest AmigaOS )
.PCIe temperature measuring in Thermal screenbar module
.virtual memory, any system ( mainly for Efika )
.of course above mentioned SMP ( or any MP ) + PPC 64 support
.not swap to X86_64, if new architecture is really needed take ARM, RISC-V or something other non-mainstream. For me MorphOS is hobby, not linux/windows alternative
.X1000, A1222 support ( yes I read morphosdev comments about P1022 CPU )

-- Mac Mini G4:
.temperature measuring in Thermal screenbar module
-- Sam460LE:
.support for PCIe cards with onboard PCIe-PCI bridge - like C-Media CMI8738, Envy24HT
-- Pegasos 2:
.sata.device ( PCI SATA ) recognize UDMA6, and has S.M.A.R.T feature
-- Efika 5200b:
.support for 2nd ATA device
.DMA for ATA ( DMA assisted PIO or something similar ) ide.device - this is not real wish, it is really too much development effort for very small user base.

P.S. it is my wishlist, I know that some points are not real.

[ Edited by sailor 09.01.2025 - 09:37 ]

Quote:
thanks for explanation

Quote:Well, some form of office suite would be nice. There were thoughts of converting Libre Office, but that seems to be a big project, but maybe you're capable of taking that on? If not possible, then maybe as a start, some really good wordprocessor, with good graphics handling/import/editing would be where to begin, with all the usual capabilities such as Cut, Paste, Copy, and Font handling for True/Open Type Font support.

If you were thinking of smaller software projects where do you have expertise, in which area of software or hardware?

For 2025 ...

I'd like to see better support for DVDRW-Dual Layer disc authoring. I know this has been thought of by some as a waste of effort, but as we don't have Blu-Ray disc support then DVDR-DL would be the best we could have with the current hardware, and I would find the additional recordable disc storage space to be definitely a benefit. Also support for Mac formatted discs as sometimes there is data on them that can be used on MorphOS systems, though on a Dual-Boot MorphOS/Mac system you can boot to the Mac OS and access the disc from there, but it would be so much easier to be able to access it without having to do so. Amiga's CD file system used to be able to access Mac "Classic" CDs even though it used the HFS disc format, but it doesn't seem to have this option so it doesn't work on MorphOS AFAIK?

I'd also like to see the "printers" issues fixed, as trying to print some page(s) out only to get issues with the prints is really annoying ... and a waste of paper!

>> multicore [...] (G5 and X5000 only)

> MDD has 2xcpu setup also

...as well as variants of almost all other PowerMac G4 models (Gigabit, Digital Audio, Quicksilver (2002), FW800). Even the Sawtooth can be made dual-G4 with 3rd party CPU cards.

Quote:

we saw x86-64 version working a few years ago, It wouldn't be so strange.

Quote:

It makes no sense to upgrade if there's no support. Following your logic we would still be using a500 without mem expansion because there's no need to upgrade as most users have a500 and not ppcs with morphos.

If Bigfoot adds more shader support It will probably be possible to have access to It using more modern graphic cards. AFAIK OS4 has a player that uses GPU to decode video. You can add RadeonHD PCI cards even to peg1. Supporting more hardware is not bad for existing users, It's a positive reason to upgrade, not an issue.

Quote:

Powermac g4/g5, x5000 and future x86-64 would benefit from It. You don't need a new binary format, you'll need to upgrade your applications so these uses async processes and to use updated libraries that support AMP. It makes sense for reggae for example and probably for number crunching applications that don't interact with the OS. With single core cpus It will be yet another process, just like now.

Read Krashan comments in this thread:
https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=8831&forum=11#95838

Quote:

Even if emulated It would be much better to have MorphOS running on cpus from 5 years ago than going to the dumpster to find 20 year old macs. A pitiful rpi4 runs m68k code more or less like the fastest g5. The x86-64 "native" binaries can be included in the operating system and the team can avoid releasing the x86-64 sdk just in case they decide to modify the binary format. But users will enjoy some native apps from MorphOS team like Iris/Wayfarer/MPlayer and libraries. Emulated PPC apps will use the "native" bigendian x86-64 31bit libs while the MorphOS team works on MorphOS4.0.


Quote:

AROS does It. Compatibility with old apps wouldn't be expected. It could be a good starting point to move drivers and low level stuff to the qbox and perhaps have abox32 and abox64 running in parallel and communicate through qbox.

@Crumb

>>we saw x86-64 version working a few years ago, It wouldn't be so strange.

Sure but how realistic is it to expect a (public) release this year? (take a look at the topic of this thread)


>>It makes no sense to upgrade if there's no support. Following your logic we would still be using a500
>>without mem expansion because there's no need to upgrade as most users have a500 and not ppcs with morphos.

Again "wishes" vs "expectations".
Most current users are on PowerBooks, MacMini (+a few iMac) were a GPU upgrade is impossible and others are on AGP based systems where such upgrades are an issue. RadeonHD-AGP on G5 seems to be hit and miss, PMac G4 even worse (I couldn't get it to work) Pegasos impossible (they all seemed to keyed for AGP3.0). PCI cards do exist but would be expensive and slow.

Sure could be done, but should it really be a priority?


>>Powermac g4/g5, x5000 and future x86-64 would benefit from It. You don't need a new binary format,
>>you'll need to upgrade your applications so these uses async processes and to use updated libraries
>>that support AMP. It makes sense for reggae for example and probably for number crunching applications
>>that don't interact with the OS. With single core cpus It will be yet another process, just like now.

Most important rule here: no half measures
As in everything done in that direction needs to be done in a way it won't create extra hassle down the line.
Sure you could do it in a way that allows such threads to just run alongside ABox, but what would be the gain?
You'd still be limited to 2GB of RAM (maybe it'll kinda work with 4GB on G5/X5000) and most G4 users won't see any performance increase on their single CPU systems. But you did create yet another API that needs to be supported in future updates.

So no any "SMP" API needs to be fully 64Bit and have some "modern" features like memory protection.
If those can run on the same core as the ABox, nice. If not you have further restricted the user base, and even this user base would only get limited performance gains.


>>Even if emulated It would be much better to have MorphOS running on cpus from 5 years
>>ago than going to the dumpster to find 20 year old macs. A pitiful rpi4 runs m68k code more
>>or less like the fastest g5.

Apart form Apple's Rosetta all PPC EMU range from bad to dumpsterfire, so unless the team puts a lot of work in it will not reach good performance even on fastest Zen5 core.


>>AROS does It. Compatibility with old apps wouldn't be expected.
No half measures !!!


If the team decides to really go for AMD it needs to be sensible with it's limited resources. I mean it boils down to about 5 guys who could any of these lower level tasks.

As such any work on PPC should only be done if it can be easily be transferred over to AMD.

My list of priority (which is just the rambling of a guy who won't be doing any of it):

- get the old demo into a useable state even if on super specific HW
- expand that HW support to a whole class of CPUs and motherboards (1st beta may appear here)
- get non essential onboard stuff working (USB3, NVME, Sound etc)
- define basic APIs for "SMP" and 64bit
- push basic support for newer GPU cores (any APU would be the long term goal here)
- create "user" API on the 64bit side allowing for pure QBox apps
- select specific laptops for full support (we are way in the future here)

Upgrades to the PPC ABox would still be made by developers outside the "kernel group".

If on the other hand AMD is silently cancelled, then sure go nuts on obscure PPC stuff.

Quote:

It would be very nice if 2nd-IDE-channel could be activated (can use eg. ide-cdrom then....)
And USB should be reworked - it always crashes EFIKA during copying many files......

And of course, virtual memory

@Amigaharry2

AFAIR maximum cable length for IDE on the EFIKA is 0.
Read all attempts to just move the HD failed on a HW level.

USB issues might also be on HW level, but....

I realized that copying many files from Shell works fine, while doing it in Ambient fails.

Not 100% sure why and while it is something I might be able to fix (or at least investigate further), it is just not at the top of my priority.

Quote:

There are dual CF adapters, I don't know if there are ide-sata adapters with two ports (I haven't seen any)

Years ago I reported that when you played a sound or ann mp3 and switched screens quickly the sound went bonkers and It started playing like "Andy and the chipmunks", perhaps something related to interrupt handling? I also noticed that in the first MorphOS versions the devices disconnected and you had to unplug and plug them back again and that in the next ones It crashed. I did a small program to test It.

Code: