@Hans
That was happens only on x5000 and only with fat32 (so crossdos), and only with usb sticks

@All
So i step by step build all this monster-swith-combo, and for now come to the point to choose UPS.

So far what i need to attach to is 4 towers (x1000,x5000,peg2 and sam460) at minimum, so need 4 ins and 1 out at minimum, but will be nice to have something like 8 ins (for monitor, kvm, router and few notebooks). Is anyone aware of some very good and silent one UPS which also looks moderns and works fine ?

The price i want to spend on for about 300-400E, just to make it one time for next 5 years.

Currently, i find this:
https://www.amazon.co.uk/Cyberpower-CP ... ockets/dp/B08MFSX4NT?th=1

Has anyone experience with ? Or maybe some other model to point out which is better ?

Thanks!

@geennaam
Will try then at first to test it as additional device attached, so to simple check how things starts, etc. Every second matter :)

@geennaam
As always, top quality stuff from you, thanks! If only we have cloned you 3–4 times and make clones works on the kernel and whole OS, then probably the progress and improvements of whole OS will be much faster, better and what is more important in the really necessary corners which just no one touch.

Anyway, i can't test it right now, but is it really like this ? I mean, is it really 2-3 times faster in everyday operations as well as your benchmarks shows ?

For x5000 we at least have amigaboot.of on the SD card already, and probably, it should be “only” matter to update amigaboot.of file, so it will know new devices and be able to boot from, but as you point out correctly : never :)

But we can put of course kickstarts also to the same SDcard, and starting from, and then, all the partitions can be NVMe ones, the only disadvantage that real kickstart modules will be on SD card (means ok for casual users, and harder for anyone who plays with modules often)

@elfpipe
Is it crossdos (fat) filesystem you use for ? If so, then it's known that when you use crossdoss on usb sticks on os4, it can put some noise-junk-trash into the files while copy them in some conditions. Bug reports about created, test cases as well, etc, long ago.

But since some time i didn't have those issues anymore, maybe because of beta USB stack, dunno.

@Virgola
For me resolution and boot times matter.. But yeah, progress is good. Hope ATI card emulation will be added soon, and then there will be no limits of depth/screensize.

@Joerg
Quote:

It's only recently peg2 emulation were added, before it was only possible to use sam460 emulation. Dunno through if it is general issue with QEMU not being able to use SFS, or sam460 emulation only.. But Vigrola in previous topic seems to confirm that have same issue with peg2 emulation too.

@joerg
It's the same issue i meet when test QEMU with Sam460 emulation : it just can't handle SFS at all (or at least, at boot times, or to handle it as boot device, dunno). Of course no other filesystem's were involved,etc.

I just found this issue after 3-4 tried to install os4 on qemu just like i did on winuae, and fail, then find out that it works only with FFS (while with WinUAE all ok, so should be no issue with SFS exactly, but probably just issue with sam460 emulation or so).

@Virgola
Btw, is KVM working then now ? Can we use macintosh with QEMU to emulation pegasos2 and have decent speed because of KVM ?

@Virgola
Sounds good that pegasos2 emulation are in now. For me Sam460 emulation in QEMU was really bad expiriene and looks pretty "raw" and buggy. It was much slower than WinUAE on the same hardware, have random DSIs, slower boot times, unability to use SFS for boot devices, etc ,etc. WinUAE in this regards were really winner. The boot times difference was really big one, like winaue 15 seconds for full 1920x1080 workbench ready to use, and QEMU/sam460 for about a minute.


On video from your link i see the working resolution of workbench are pretty low. With WinUAE emulation 1920x180 are fine and fast, because it can emulate gfx card with lot of memory, so compositing and stuff working, etc, and move of windowses and opening of drawers are fast.

Can QEMU with peg2 emulation now with this SM501 card emulation give you ability to use full 1920x1080 desktop with compositing, and all windowses opening/moving/resizing be fast as in winuae ?

@rjd324
If it will be me in end doing it and not someone more skilled like you or max, or andrea, etc, then yeah. But i was in hope someone with better programming skills than me will do so :) All i do there is just simple "puzzle-logic" kind work, no programming.. that mean once changes will be heavier in some version then i will stuck. But then i can ask for help there as always ..

@rjd324
Don't remember exactly details right now, but i for sure just take next version of binutils to our one (not the last one, not 3 versions after, just the next, so to have as small as possible changes). Then i have 2 version of adtools : one original (so to see how code looks like after "patching"), and one with newer binutils, and there i just simple following the logic of code and improve it the same exactly way as it was. I.e. it just matter of non-programming works, some delarations changes, some name of functions, some lines shifts, etc.

But what is most important , is to get rid one time at one of this ifdefs for aros, morphos, amithlong and os3-68k, so patches will be really small, and easy to fix later.

Check the page 13 on this topic:
https://www.amigans.net/modules/newbb/ ... &order=ASC&status=&mode=0

So you will see how i do/test this all. Why i didn't put it to adtools : because i didn't get hot to make patches properly (as you can see in this thread i provide one single DIFF, but wasn't able to find motivation to deal with adtool's patch mechanic). In general you already can take the diff from the link in this thread on page13, and see what i change (but i don't do any programming there of course, it's all just following the function-names, correcting includes, types and stuff)

@afxgroup
Updating binutils is more or less easy, just no need to jump on the latest ones, and figth with tons of differences, just one by one, step by step. I already made a next version after our port, together with removing of morphos, amithlon, os3 and whatever no-one-anymore-use-from-adtools code, and patches start to be much smaller, and more or less clean.

But, i just waiting a little bit as MightyMax (if i remeber right) was almost done with fresh binutils port.

@MightyMax
If you stop working on binutils port by any of reasons, or you do not know when you will have time to work on, maybe then better if i will at least made next-version jump for binutils, that will be at least something than nothing.

@Afxgroups
Sure, sobjs may needs sometimes, but everyone should be aware that using sobjes with browser will slow the starting, and that will be noticeable.

But in case with exactly this port from morphos they didn't use sobjs, and all fits fine in the ram and so on. Using sobjs just in our version because it may easy some porting, will just slow starting up with no reasons.

@Raziel
In case with ScummVM, sobjes need it (at least for now) only for building on the amigaos native, the running are fine in static version still when it builds on cross-compiler. And it definitely noticeable when i just run 2 the same versions of scummvm : the one which build statically runs in a second. The one which use sobjs, take a 3 seconds for just a startup.

Quote:

Sure, just if it will slow starting up much, then on the same machines with limited ram (and then probably slow cpu), the loading speed will be even more noticeable and slower.

@rjd324
Is there real needs to build newlib based version too ? I mean, we all know that os4's newlib is closed, and when there will be needs to fix something in newlib, it will mean rely on years of waiting for bug-fix to be released ? With clib2 there no such issues anymore.

Also, is there needs to have "sobjs" support for ? I mean in meaning of webkit port. Morphos version didn't have that, so why should we ? (and usage of sobjs, slowing down the whole loading on startup, always). ScummVM are good example : the static build loads up in a second, the sobjs based one take 2–3 seconds to loads up. With such a heavy beast as browser, every second count IMHO.

@Hans
Quote:

X5000 do have DMA accelerated graphics.library too : this was added by Salas00 2 years ago or something (you may remember i offer 1000$ for this in beta list), but I do not remember if this graphics.library were in the latest os4 public updates through …

@rjd324
As I mention everywhere never use minigl4gl4es , it was a fast hack, for radeonrx users while there wasn't novabridge. Minigl4gl4es have real issues and bugs, and should be avoided. And the bugs are hardcore ones : crashes on starts, crashes on exit, unability to run 2 minigl apps at time (crashes again), black sprites in many games, etc,etc.

You need to use novabridge + normal minigl from os4depot, not minigl4gl4es one

Yeah, dwarf issue of course remain, and binutils 2.29 at minimum need to be ported firstly. I'm doing all my tests with dwarf 2/3 of course.

@Afxgroup

Prepare for some wall of text :)

binutils

Newer binutils generate dwarf4/5 sections, which our-old-current one can't. But, the newer GCC we use now, of course, will create dwarf4/5 sections for any debugging purposes. Because of this, you can't load any binary created with newer GCC to the old GDB, which only know about old dwarfs. And the same about other debugging tools which has those old/new dwarf differences. If i remember right you can provide the version of dwarf being added into the resulting binary, but with my tests even if i say directly to use older dwarf, some link libs or whatever of new GCC still add pieces of drarf4/5.

I was trying to update binutils, and was able step by step update version by version, but then, month or two ago MigthyMax starting working on the latest binutils, and i was in hope it will be "soon for testing", but since then nothing, so maybe we need to back to our old route, and update binutils version by version (as it will less and less major changes if step by one version), to the version which can generate dwarf4/5 stuff.


To give a little more general info, the DWARF-5 support was added in 2017-02, so the version of Binutils coming after was 2.28. So we just need at least update on few versions up (to 2.29), without needs to port the very latest one which will be harder as it have more changes.

gprof

Related to the gprof: I was digging in pretty well, and find out why it didn't work for us currently:

short story: Gprof didn't generate proper output now because base address in elfs changes from 0x00000000 to 0x100000000, but respective parts in gprof weren't updated.

long story: gprof still working in SDK 53.2 (from the year 2008) even on today's amigaos. Things got broken in SDK 53.3 when gprof stops working (the same year 2008, just 9 days later). I start to compare everything between 2 versions of SDK, every single component, and find out that the default ldfscript was changed, and instead of :



It starts to have :



So, when we have there 0x01000000 in two places, then gmon.out created with wrong data inside, and profiling info can't be taken by clibs'2 profiler code. Once I manually change those 0x01000000 on 0x00000000, then gprof start working, and gmon.out output is correct one. Even on todays amigaos4 with today's 11.x GCC.

Of course, it may still have other issues, but at least the main one, is the change of the base adresses.

I even created for myself a patched ld.exe binary, where i just change 1 to 0 in necessary place, so base address start to be again from zeroes, and it makes gprof works. I even can profile a bit of things like for example Capehill's "Tequila" CPU profiler, and more or less big app "Horny" (binary size 1.5MB). And I even was able to use some python script which was built from gprof profiler to output colorful dot graphs. Just check this out:

(hit to open images in new tab for full size)

Tequila:



Horny app:



Then, I asked Thomas WTF, why there 10000000 as base address since some version, and he says that change to 0x01000000 was necessary for sobjs, since these did add a .plt section, potentially in front of the .text (which means 0 as text base address was no longer working).


Need to add, profiling works only with clib2 builds, the newlib one seems broken (or maybe even didn't implemented). Even if i change base address to 0x000000, the newlib one didn't works.

What we can do with all this information i honestly do not know, but, probably we need to fix in adtools gprof related code, to work with 0x1000000 , which probably only require changes in loadseg() stuff or whatever. As you know, files separated well in clib2, and relevant ones here:

https://github.com/afxgroup/clib2/tree/master/library/profile

But probably firstly, we need to port the version of BinUtils which can handle dwarf4/5, and then, step by step start fixing all other issues including support of GPROF again (as it really cool, with all those 3d party scripts and tools from Unix world).

Thomas back then when i asked him about all this, had a quick look at the gprof implementation, and seen that it implements a symbol table for the binary in question. And since we need to translate from the actual LoadSeg() address to .text segment addresses, the symbol table should take care of the translation.

Also, the code relate to gprof have some "/* FIXME: was p->lowpc; needs to be 0 and assumes" notes , but those wasn't added by Thomas.

Additionally, Matthias starting working on all this some time ago, and he added profiling support to kernel for x5000,x1000,sam and stuff , and a little patch this clib2's profiler code (patch should be in your repo too, as it was in Sodero's one for sure), but, he didn't finish sadly the whole fixes for this 0x100000 vs 0x000000 base address thing. Probably we can ask him how far he was, and what he did already, maybe his help will help to finish this.

PS. I wrote mail to Mathias, possibly help will be able to share his findings there. As i remember, he was close with all those 0x100000 vs 0x0000000 things, so possibly he can share some code showing how far he got.

@afxgroup
I can be wrong, but seems we again miss the libauto.a in beta8 ?

@AMIGASYSTEM
Thanks a bunch ! Now i at least can look at those game icons and not thinking about myself being stick to the past too much :)