@LiveForIt

Quote:

Great tip! Thanks. I'll try this one. I've got that one Workbench which almost always freezes on boot so be good to "talk" to it. I'm sure WaitTOF() is going dead, after writing some test code, but be good to command it after it locks up since the system is still ticking away.

Quote:

That's a good question. I suspect not but OS4 does have some generic drivers for devices like floppy. You know I don't even think I thought of testing this. Or didn't bother. It's just I'm always going from Amiga machine to terminal so didn't need it.

@Gregor

Is there an update? From Updater would be very useful but I don't know if it's possible for OS4 software to update the firmware. If it's on SD card that makes it easier though usually a UBoot shell and technical commands used for that kind of thing.

But, at least your X5000 is supported, even if slow till update. I've been waiting decades for an X1000 update which should happen sooner rather than later given they have the source now. The X1000 loading speed is shockingly slow compared to an X5000.

@Tuvok

Those error messages were common when PartitionWizard was incompatible with system libraries or when PartitionWizard was older than the system it was designed for. Unfortunately, the FinalEdition DVD doesn't help here, because the included PartitionWizard is faulty and designed to work with a previous OS4 version. If it does in fact load up at all you see those particular messages.

To compare I just ran Snoopy while loading PartitionWizard and saved a log. I've filtered out some non relevant or repeated lines. See here:

@Tuvok

I had a problem with Odyssey back in Easter. Have you installed any 68K software at all that may conflict? Check my thread here for issues:
https://www.amigans.net/modules/newbb/ ... 637&keywords=consistently

TL;DR my own issue was a 68K AsyncIO library. Now, your issue is likely a different one. But it can be something to check just in case.

What does your crash look like in the stack trace?

@Boabster

Quote:

They are Logitech Z120.

@MigthyMax

Sorry delayed reply.

Quote:

It taught you well then. There are some examples on the Amiga where busy waiting was the norm but I still don't like the idea. One example is music modules. Common music interrupts set the audio playing, then busy wait inside an interrupt until a couple of raster lines have passed before setting a loop. I don't know why the loop isn't set on the next interrupt. If a 50 FPS interrupt was too slow how would anyone hear the samples? Some players did use two timers to avoid the busy waiting.

Quote:

It is but still different to how AmigaOS usually works. For example a Forbid lock will increase counter and then wait if it isn't the first to lock. But this PPC example loops around until it's freed. So although it can work the same way, as it just needs to divide the add into primitives, the proper AmigaOS way would put the task into a wait state immediately if the reservation failed to store. At least as I see it.

Quote:

After looking into this it looks like they need to be present for all interfaces. This makes sense as it also needs to track "main" access. See this as an example. Would help if it included links to facts it states. It mentioned required but not where this is stated.

https://wiki.amigaos.net/wiki/How_to_create_an_AmigaOS_4_library

Quote:

Some can be NULL but required ones need filling in. They should maintain counters and return counts. According to this here.

https://wiki.amigaos.net/wiki/Exec_Libraries

@MigthyMax

That's interesting. I've used the SDK IDLTool to generate template code and didn't notice this at all. It was a number of years ago.

The GCC function is more portable than pure ASM. Being part of a standard C lib would be better. I can see this avoids using a Forbid lock which would use the same mechanism. Because of how PPC atomics work it works like a spinlock. I think any kind of busy waiting is inappropriate for AmigaOS but it's common elsewhere and on PPC, being RISC, it needs a spinlock for atomics. However, it is unlikely to be stuck in a loop, even for a few iterations.

I don't see much difference. Apart from the GCC code using an extra register and an isync. The embedded code looks slightly more optimised using only one register, but I have seen GCC generate strange looking code with random looking or odd register usage. Good job.

@tao

You've brought up a few other things I had forgotten about.

The datatypes MultiView were built around are considered a stand out Amiga feature. But the ones included were a bit sparse. Mostly they just covered native Amiga filetypes. It supported ANIM. But lacked video and sound together.

Funny about the text editor. They did actually have a Notepad. But it was almost more like a word processor being to use different fonts. Then they removed it! And what they left was editors for techy people in the CLI. Ed and MEmacs. I never got MEmacs since I didn't know the IT history of it and it looked like some quirky programmers editor.

The Workbench remained too simple. Accidentally drop a file in the wrong spot and you can't undo it. Then you have go searching for where it went.

So by right click menu do you mean context menu? This was a real sore point. I had a conversation with a woman who had a 286 or similar and the lack of a context menu in AmigaOS meant that her 286 with Windows was way superior to the Amiga A500 desktop because it had a context menu. This was a real short sight. Even the Mac, which had a single button mouse by design, could not operate fully without a menu button and crippled the interface.

I know what you mean about the icons. I think what they needed was an Amiga dedicated filesystem or extension to FFS that supported icons with icon block types. Like the Mac had data and resource embedded in the filesystem. The icons being in separate files looked wasteful after a while. Default icon images wasted disk space and time loading when icons could have had preset images. And otherwise an icon cache could have existed inside the filesystem where the icons were all cached in a large block, but exposed to the outside world as regular files.

@NinjaCyborg

I see a few issues that even the latest OS3.2 doesn't solve. But back then they were more urgent to solve. If they wanted AmigaOS to be taken seriously.

Icons were a mess and easily became sloppy. There was too much work organising it and saving it, usually needing 3 menus to do it, which didn't always look right. The "E310" format was designed for updating but lacked any major version updates. It remained stuck at 640x256 screen size icons in 4 colours. After 1.3 the colours didn't match either. But a related issue was icons didn't scale. By this point they needed to become vector images so they could scale. Being natively planar meant that the hardware was suitable for layered vector images.

It needed TCP built in. Even the attempts from OS3.5 and OS3.9 were third party. So integrated TCP is another on my list.

An obvious one is RTG. And not with an external CyberGfx or P96. Again, integrated into the system. And easier to setup. RTG was and still is too technical to setup. Amiga OS3 RTG lost it to Windows 95 but Amiga OS4 RTG gained some back. Embracing DDC standards would help but mostly being able to easily setup a monitor with standards resolutions.

System management was too awkward. While Storage was a nice idea there was no system utility to manage it. Instead you had to manually open up windows and drag icons around. The windows themselves opening up for each drawer you opened made it become cluttered. So some kind of paged or browser based windows would be next to alleviate that.

The system became modularised by introducing user scripts and moving mounts into separate files. But the idea wasn't developed enough. For example, User-Startup became a mess, with a mix of random scripts. There was no script drawer to split them into separate files and organise them. Nor an assign manager. So assigns remained complicated to manage. When it became obvious that moving assigns into their own drawer was another next step. The Installer helped but it had to modify one file to add or remove scripts, which didn't always work out, so was forced to install or remove the hard way. The Installer also wasn't installed to HDD as standard so needed to be included with every program package using it. And on that note a package manager also became an apparent need.

There would be others but there's 5(+) main ones off the top of my head.

There's not AFAIK. I would have thought a copy function would be in place, to standardise this, with an optional hook to account for progress bars.

So there's only the old fashioned way. Open, read, write, rinse and repeat. Just using newer functions to examine file info. Not sure about being able to open file for write with specific attributes, to avoid resetting it later and causing wear.

@kas1e

Ah yes, I see that now. Don't know what happened there. In this case it would be built on alfkil's work.

@elfpipe

Nice job. Been wondering how much work this is. Looks like a cleaner build system than dealing with old style configure that always break.

Is your build based on Alfkil's work or a new port from scratch?

@Raziel

I wouldn't say so yet. As it's a first working release. In the least I think it would be best to have it set up in a test SDK. I tested it from RAM. Being able to reassign SDK to use it on the fly would be useful.

@MigthyMaxQuote:

Yes! Confirmed. I tested the command in my current SDK and it works fine. For some reason the current ld command doesn't see the xbn or xc files which exist in the expected place. Youre build does.

@kas1e

That explains it. Thanks.

@kas1e

Quote:

Great start. Yeah, I should have been more clear, I meant the GDB TUI. Which I haven't seen in any OS4 version of GDB. SDL would complicate it and since it's intended for console, not a game, needing SDL seems overkill and not the Amiga way of doing it. It's been a while but I'm sure NCurses was one I tested years ago. At least, when I was playing with MoL, trying to port it to OS4. Don't see any others but PDCurses on the Depot though.

Quote:

A ReAction GUI is definitely out of scope for a GDB port. I agree remote debugging would be awesome as it open up possibilities. Also being able to use a gdb server would be beneficial as well. If a server could be compiled in then perhaps a full gdb running on a remote machine would provide superior debugging with a full GUI. Possibly even a VSCode session could debug OS4 code over the network. A crash or freeze could be located more easily.

What would be good, though an obscure example, would be ability to debug firmware code. Say when testing client code running direct in UBoot or CFE. A crash that core dumps over serial is cryptic and not very helpful. However, being able to single step live, and catch the bad line would be helpful,

@MigthyMax

Quote:

It can be caused by specifying it like this below. The first two examples demonstrate elf32ppc emulation failing. The last demonstrates the OS4 amigaos emulation working.



Quote:

I've noticed in the O4 build that they lack the -tui- option.

@kas1e

Thanks for the link. Would this fix the elf32ppc emulation bug in current bintils? I'll download and test.

Good to see work put into GDB. Would this include the GDB GUI? I suppose that may be too much to ask given GDB hasn't worked for decades. A console GUI also looks like a DOS or Linux thing so it's not exactly an Amiga thing. But it would be good to have some kind of GUI like that of MonAm.

I bought at a good time. I just got back into my X1000 and needed to sort out the drivers. I managed to miss the boat on a beta Radeon driver.

At the time Enhancer 1.5 was current. I bought this and got the Plus edition as it wasn't too much more and included more drivers. I also saved money by buying the digital edition. As well as time and postage. While a DVD package is nice with an OS4 software CD inside it also creates physical clutter. Later there was some graphics upgrade I skipped but it turned out to be an upgrade to Enhancer 2.2. Having missed the upgrade I ended up buying Enhancer 2.2 which only had one paid edition.

Just checked AmiStore. So, there is Warp3D-SI, RadeonHD v1 and v2 still on there. Those are the older drivers. I don't know if the Warp3D driver is still needed. I haven't tested enough older games. I just wanted to test current 3d games like Spencer and OS4 ports like Shogo. They ran fine with my Enhancer purchase.

@Boabster

While this doesn't help with USB audio I did buy some USB speakers a while back. But, they were USB powered speakers. So I could have speakers without needing another power point. My current monitor has no speakers. I do find that sometimes there is some static though.