@kas1e

Having an address bar would be great. And personally I don't mind that it (everything) is located at the bottom. Visuals can be improved. I'd be happy when I can add my own images because I am running the dark theme from ImagoDespira

@LiveForIt

Call me a heretic but the way you can navigate in Windows is rather nice. Having similar functionality in OS4 is nothing to be ashamed of.

@LiveForIt
Quote:

One of those small items that make the OS more pleasant to use.

I think because the current situation where all drawers open on top of eachother isn't really user friendly. At least I rather use the shell then use WB when I have to navigate further then two levels.

An easy way to navigate inside a single windows should be a part of the OS. Dopus still feels like it is stuck in the '80s.

Since it isn't and probably not will be part of the OS. A patch is the next best thing.

@joerg

Offtopic: It's such a shame that you don't code for os4 anymore. You obviously know a lot about os4 and its internals.

@sinisrus @kas1e

Would be nice to check if that tool could live up to the expectations.
Because I just checked the source. And like @kas1e already hinted, PowerWB works with OpenWindowTagList().
Unfortunately the interesting part is 68k assembly. So I need to do a speedcourse 68k assembly first

Edit: Looks like it's redirecting and replacing the OpenWindow routine of OS3. So a patch.

@kas1e

That is indeed a hack.

Or at least not the functionality that could be expected from the description. It's not a toolbar but more like an overlay of icons.

Looks like TSK (Tuomas Hokka) made a start for such an OS4 tool: WB Toolbar

Source in C is included so it should not be that hard to expand its functionality

@kas1e

Are you talking about your Pegasos2 with bboot and a RadeonHD/RX?

The audio device is just a second endpoint.

PCIe config register are always readable. Unless something is wrong with your card's address. The Bar spaces need to be enabled in the command register.

@Hypex

If the definition of "ppc for classic" is to run powerup or warpos then I do not see the point. The 68k emulation will probably run the 68k versions just as fast as a ppc emulation would run the warpos versions of an app.

If the reason is to run amigaos4.1 on a classic then the end result will probably be disappointing with a rpi4, compared to even a sam440, for running OS4 apps and games.
Nevertheless it's worth the effort IMHO. Owners of real Amiga hardware in combination with a PiStorm are probably more committed to the Amiga when compared to winuae users and alike. And therefore make better assets for the Amigaos4 community.

@Hitman

The AmigaOS install iso doesn't come with any RadeonRX driver. Only with a lite version of RadeonHD driver. So you'll need Enhancer for RadeonRX support.

Just adding the RadeonRX driver from Enhancer to your kickstart drawer is not enough.

You need to do the following:
1. Add RadeonRX.chip driver the "System/Kickstart" drawer.
2. Add "MODULE Kickstart/RadeonRX.chip" to both "Kickstart/kicklayout" and "/System/Kickstart/kicklayout"
3. Disable compositing in your "Installation-Support/startprefs.bat" by disabling the following lines:

;:Installation-Support/CheckHardwareCompose
;if $RC EQ 0
;copy :Installation-Files/GUI-compose.prefs env:sys/GUI.prefs
;setenv _INSTALL_HWACCEL 1
;else
copy :Installation-Files/GUI.prefs env:sys
setenv _INSTALL_HWACCEL 0
;endif


See this thread for more info:
https://www.amigans.net/modules/newbb/ ... id=135388#forumpost135388

@Mikey_C

Actually it does. It will definitly have an ENIG PCB surface finish and some headers might have gold plating as well

@LiveForIt

It isn't what I have in mind. I want to Benchmark the interface first to see what's possible for difference scenario's.
But sure. The single cycle nature of the xmos chip allows for predictable timing behaviour.
Anyways, for now, access is blocked by the MMU and therefore results in a DSI. We have to wait for a newer kernel which maps the local bus memspace.

@LyleHaze

Yes, the jtag interface is now buffered with a cpld in between. A bit slower jtag is not really a concern for me. I can also use the spi eeprom instead to do a few tests.

Unfortunately the communication and data interface is completely different from the X1000 as well.

The X1000 local bus is a PCI device which connects directly to the xmos chip.

The X5000 works with a mailbox, index pointer and dual ported ram in between. The index pointer is used to point to the interface or register that you want to read/write The dpram acts as shared memory or return register for e.g. Fan speed. In case of the xmos data interface, the sender writes data and receiver gets an interrupt that data is available. Now you could split the memory area into multiple sections where you simply move objects back and forth in a buffered full duplex manner. Or keep it in one piece as a question answer interface

The good news is that the Upd2 kernel doesn't support this X5000 local bus yet. This means that apps and dockies use the microcontroller to get the fan speed. So no collisions are to be expected. The bad news is that I cannot access this bus yet on my X5000.

@K-L

Unfortunately it's just basic information about the XMOS chip and info that is available in the X5000 TRM

@joerg

Ok, I'll try 20 when I've solved the first mystery: Where's the eLBC Mapped. Apparently the LBC on a X1000 is a internal PCI device so you can search for it like a normal PCI device. But the P5020 has it memory mapped somewhere.

Are there any tools available on amigaos4 that are able to load the xmos chip through jtag? Or do I have to do the bit banging myself?

The only info that I can find concerning xena is PA6T/x1000 centric example on wiki.amigaos.net and something called a xena.resource in the sdk.

Since the local bus is different between the PAsemi and P5020 I was hoping that the xena.resource will at least provide an abstraction and basic needs. Yet, the resource is only about getting exclusive access to xena resources like the jtag interface. Not about getting a base address or actually programming the xmos.

The x1000 example is pointing to sys:utilities/Xena/xtools/xrunxe. But this one is not available on my X5000.

I can see in the X5000 TRM that the CPLD interrupt is connected to IRQ4# of the P5020. How can I get the actual exec interrupt for AddIntServer?

Another concern is that the index pointer is shared between the xena mailbox and diagnostics info.

So I wonder how e.g. fan speed readout of the X5000Temp.docky will bite xena communication.

@mr2

Quote:

I get what you mean. Dusting off, re-capping my a1200 and getting a pistorm sounds oddly appealing since Amiwest.

The irony of it all is that AmigaOS4 might now """live on""" in a "digital environment" (as it is now endorsed by A-EON). Independant of hardware and host OS. They could call it AmigaDE or amiga Anywhere. (Not sure if these names are already taken since i've only just started reading From Vultures to vampires volume 1.)

Maybe this could ultimately result in a viable business solution. Speaking of which. How is Tao Group doing these days.

@Hans

Quote:

That is basically what Trevor said in his q&a at Amiwest as well (depends on a1222 sales which we can all guess how that will turn out).

This, coupled with yet another year without progress for Execsg (multicore), OS4 or enhancer. We've hit the end of the road. Mission failed. Emulation can take over the dead platform now.

Let's have a memorial at Amiga 40 and move on on Amiga's with real hardware. Or get ourselves a new hobby

@Maijestro

Lol, it is you that is overestimating the situation. Especially when it comes to new users by emulator solutions. And since you will never buy hardware and are just here for a free ride it is of course in your own best interest that this driver gets developed.

Or did I understand you wrong will you now develop software and buy hardware? Afteral you now know what amigaos4.1 tastes like.

If you need advice how to setup your X5k then I'm here to advise you. Can you give me a hint what software you working on?