@Raziel

If you own the Enhancer 1.5 and RadeonHD V3 driver already then this update is free of charge.

@Capehill

See post #7

To those who already have the RadeonHD 3 driver package.
Ignore the updates in the "System" tab of Updater.

Instead go to the "My purchases" tab.
Check the box in front of "Enhancer Software Release 2" and press download. Then install the package again.

It is a bit confusing because this package doesn't show up as updated. But this is the way to install Enhancer 2.0 with all it's new tools and libraries.

@kas1e
I don't know how it works in Russia but when I order something from outside the EU, I have to pay customs clearance fee and VAT. But most likely A-Cube will enclose the replacement value and not the commercial value. This means that you have to pay less VAT.

@duga

When you live in another country within the european union you will pay VAT to A-Cube.
Kas1e has to pay VAT to customs in his country.

So the EUR 620 is excluding VAT.

@thomas

That will work but not realtime. Because the only library function called during playback by AHI is ahisub_start.
And this is called once to initiate the playback. From there on it is an interrupt driven process which hooks to the ahi mixer function to aqcuire the samples for playback.

double post

@all

Ok, my bad. I need to be more precise. The library is in fact a soundcard driver for AHI. AHI drivers are just libraries.

I need to control the volume though a mixer like program. The clean way to do this is to insert volume commands in the communication stream between the driver and the soundcard. The dirty way is to do it is via a debug interface in the soundcard hardware. The debug interface and normal communication stream are mutual exclusive. During normal playback, the communication interface shouldn't be actively sendind commands. But ahi programs could request a certain change through the library/driver interface. That might lead to undefined behaviour when the mixer program is used to control with the volume with the debug interface at the same time.
With all my tests I haven't seen any calls to this control function but it is there for a reason.

In end it is just a question. If it is not possible than I do it in the same way as mixer controls the volume of other soundcards. In this case that would be the debug interface.

Is there a way to create a kind of message port for a library which you can use to provide the library with additional data? So not throught the library interface.

I have a library which can be opened by one program only because it gains exclusive access over hardware. But I want to feed it with additional information from another program.

@trixie

It is low on the priorities list because almost every monitor has dvi or hdmi anyways.

So don't expect it anytime soon.

But if the powerstate ( as i understand it) issues with the rx driver have been solved and a warp3d driver had been made then I see no reason at all to support the displayport. So I understand why it is low on the priorities list.

@benny

I've got confirmation from Hans that DisplayPort is not supported.

About DVI. You already calculated that at 3440x1440@60Hz the dual link dvi is maxed out.

These are the specs of my MSI R9 270X:

DVI CONNECTORS
DL-DVI-Ix1, DL-DVI-Dx1
Max Resolution: 2560 x 1600 @60 Hz

HDMI CONNECTORS
1 (version 1.4a)
Max Resolution: 3840x2160 @30 Hz
4096x2160 @24 Hz

DISPLAYPORT
1 (version 1.2)
Max Resolution: 4096x2160 @ 50 Hz

As you can see, the product of resolution and update rate for DVI is equal to HDMI.

The displayport is clearly superior because the product is of resolution and update rate is 66.7% higher. This would have enabled me to run workbench up to 3440x1440@100Hz (Depending on minumum blanking times) . It would have been a nice to have. But 3440x1440@60Hz is sufficient as well.

When the RadeonRX cards get warp3d support, I'll switch to such a card and the limitation should be gone because of hdmi 2.0b.

@ncafferkey

So the only difference is that I do not need to perform a Cache flush manually?

What I do now is:
1. allocate a contiguous buffer which is physical aligned and is not allowed to be relocated with AllocVecTags(). This function returns the virtual address. (for OS4 access)

2. aqcuire the physical address in supervisor mode (for DMA controller access)

3. Perform a CacheClearE() after I've completed a write sequency to the memory region with the virtual address.

Anyways, that works like a charm now. But if it is more OS4 legal to do it with StartDMA()/EndDMA then I will switch of course.

@benny

Yes, that is the main reason. But it is more just I (my monitor) can than that I really need it.

Seems that Hans doesn't read these forums anymore. So I'll try to contact him.

@samo79

Nice one. Will it also support 5.1 sound like the the pc version? Will add a great deal of atmosphere to the game.

@walkero


Ok thanks. Too bad because the displayport of my radeon is supposed to provide about twice the amount of bandwidth compared to the hdmi port. So it would have been nice to have a 100Hz refresh rate instead of 60Hz.

This also means that UHD (4K) is only supported up to 30Hz. I tried this with my TV and I cannot recommend this to anyone. You can see refresh issues when you move windows around. although there is no processing power issue, the system still feels sluggish.

My new 34" ultra wide QHD display arrived today (Asus VG34VQL1B).

First of all, 3440x1440 brings a complete new experience to AmigaOS IMHO. This resolution and size make it possible to using Codebench, the SDK browser and Odyssey side by side in a convenient way. So the lack of multi monitor support is fully compensated if you ask me.

But now the question. I have a X5000 with MSI Radeon R9 270x OC (2GB) and V3.6 of the RadeonHD driver.
I do get 3440x1440@60Hz using HDMI. Display port on the other hand shows uboot and the startup animation, but goes to black once workbench is opened. Is this a known limitation of the RadeonHD V3.6 driver? Do I have the wrong Radeon brand? Or are there any tooltypes or settings to enable display port support?

@salass00

The experiment in my first post did exactly that:

1) Enter hypervisor and save context.

2) Flush caches

3) get/set memory attributes on buffer to inhibit caches ( CurrentAttr | MEMATTRF_CACHEINHIBIT).

3) get physical address of buffer and store in PCIe device DMA base register

4) Return to user space and restore context

5) Write the command to virtual buffer address. Physical address access will result in a DSI )

6) Signal pci device that the new command is available.

I don't know why but this didn't work for me. Still no response.


In the meantime I changed the sequence a bit:

1) Enter hypervisor and save context

2) Get physical address and store in PCI device DMA base register

3) Return to user space and restore context

4) Write command to virtual address

5) Flush cache to memory -> CacheCleanE() with CACRF_ClearD Flag set

6) Signal PCI device that the new command is available.

Now I receive an PCI interrupt when the response is available in another DMA buffer in memory. And this second buffer reads the response that I expected.

Strange that inhibiting caches for my buffer didn't do the trick. But at least it works now.

I want to allocate a DMA buffer for a device driver but I am completely lost how to accomplish this.

The PCI device wants to fetch commands from a command ring buffer located in main memory.
I have to provide the base address of this command buffer to the PCI device and the offset pointer where I wrote my last command. The PCI device will then fetch commands from this command buffer until its read offset pointer will match my write offset pointer.

I have allocated the command buffer with AllocMemTags in the following manner:



I wrote the address of pCmdBuf to the command buffer base address register inside the PCI device. Wrote the command to the next entry in pCmdBuf and updated the Write pointer register to match the location of this new command.
I can see that the DMA fetched something because his offset readpointer increased with 1 and matches my offset write pointer. But I do not get a response. This could mean that the DMA controller fetched some bogus command and chose to ignore it. I am sure that the command is valid. I am also sure that the response part of the PCI device is also setup correctly.

I did an experiment with disabling caches for this memory buffer in hypervisor mode but that didn't help. On top of that I acquired the physical addres of the buffer and wrote this to the PCI device command buffer base addres. This also didn't work.

I noticed a IExec funcions StartDMA/EndDMA. But from what I understand these are for devices that support scatter/gather functionality which this pci device doesn't support.

And there is also an older and depricated functions combinations called CachePreDMA/CachePostDMA/CacheClearE. This is supposed to flush caches and provide a physical address.

AFAIK these function are supposed to deal with the fact that the Amigaos4 memory architecture will not provide a contiguous buffer. But I provided the tags in AllocMemVecs to force contiguous memory block and both virtual and physical alignment. And since disabling caching didn't help either, I am right back at where I started this post: completely lost in what is the correct way to handle these kind of buffers. So I hope that someone can help me.

I also do not fully understand the PCI mechanism. Will the MMU handle DMA request to virtual address spaces? Or will a DMA access from a PCI device go to a physical memory address?

The PCI device expects little endian format so naturally everything is manually converted BE<-> LE by me in either direction when it is read/written through the PCI ibus. Only the functions in the PCIIFace for PCI config space are byte swapped automatically.

@trixie

The problem with libraries is that there is no startup code to create global variables for interfaces and variables like IDOS or DosBase. It is supposed to be good practice to store this in the library base structure. And so I did. This is why you see libBase->IExec in my code.

This structure is passed on to every "method" (my Library interface functions). But a child process is not an interface function. It cannot be called by the program which opens my library. So the library base structure with the external library interfaces like IExec is not passed on to the process.

I did a dirty trick by creating an addition global libBase called ProcLibBase and pointed it to the libBase of the main process inside the my library interface function that creates the child process. So now I have a local libBase and a global ProcLibBase. Because it is global, I can now call library funtions in the child process.

I noticed that you use the Tag NP_Child. According to this site (https://os4coding.net/forum/sharing-interfaces-your-children), this mean that both processes share the same context. And that it is reasonable safe to share the same external library interfaces like IDOS.

I only need to signal the process that it is now ok to start. The process will signal the main process when done. So I use signals instead of the message port.
So the signals are exchanged through the global ProcLibBase and this works. Don't know if i get a slap in my face by someone.
Still open for the proper implementation

Another Noob question:
I am writing a amigaos4.1 library and want to save streamed data to a file.
Therefore I've created a child process for saving inside an amigaos4.1 library with:


There is little documentation available but from what is available I understand that each (child) process must have it's own interface to external libraries.
So how does this work? Is it as simple as just opening a second Interface and use this in child process because the library is already opened in the main process?:




Can I pass on the same lib base to the child process and in the same way what is done for the functions in the main process?


Up to now, nothing has been easy in amigaland. Little documentation so a very steep learning curve. But I am not about to give up yet .