Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
43 user(s) are online (20 user(s) are browsing Forums)

Members: 0
Guests: 43

more...

Support us!

Headlines

Forum Index


Board index » All Posts




Re: My AmigaOs4.1 projects
Just popping in
Just popping in


@Maijestro

Yes, Reah: Face the Unknown

Go to top


Re: My AmigaOs4.1 projects
Just can't stay away
Just can't stay away


@all

# ScummVM AmigaOS4 – Development status 11.03.2026 (evening)

## Current binary
- Version: ScummVM 2026.1.1 “Like a Version” AmigaOS4.1 (Mar 11 2026 16:14:01)
- Stripped size: ~18.8MB
- NEEDED Libraries (9 instead of 10 – libjpeg now static):
- libSDL2-2.30.so, libpthread.so, libogg.so, libz.so.1
- libstdc++.so, libm.so, libssp.so, libgcc.so, libc.so

## Current build status

### Binary
```
scummvm 18.8MB Mar 11 2026 16:14:01 (stripped)
```

### Plugins (all in plugins/)
```
grim.plugin Mar 10 15:16
titanic.plugin Mar 10 19:29 (with PATCH 39)
hpl1.plugin Mar 11 15:06 (with PATCH 42)
+ all other plugins (stark, wintermute, etc.)
```

## The SDA problem (core issue – still open for Grim Fandango)

### What is the problem?
- AmigaOS4 PPC uses Small Data Area (SDA) for global variables
- The binary has `_SDA_BASE_` @ `0x01f93598`
- Each plugin has its **own** `_SDA_BASE_`
- Global variables from the binary (`g_system`, etc.) are resolved in the plugin
using the **wrong SDA base**
- Result: Incorrect/NULL pointer → DSI/ISI crash

### Grim Fandango Crash Analysis (March 11, 2026)
- Crash: DSI Exception, IP=0x7E97C6AC (in scummvm binary, section 10 @ 0x4510)
- Called by grim.plugin
- `DAR=0x00000070` → NULL+offset pointer access
- `LR=0x00000000` → Function pointer NULL
- Stack trace: grim.plugin → scummvm binary → clib4
- Crash immediately upon starting the game (after loading shaders.dat)

### What did NOT work
1. `RTLD_GLOBAL` in sdl-provider.cpp → clib4 crashes on startup
2. `-mno-extern-sdata` → GCC does not recognize the flag for PPC
3. `-use-dynld -ljpeg` → Linker still takes `.a`
4. `g_system` → `g_grim->_system` / `getTitanicSystem()` → helps with
direct g_system calls, but not with all GOT entries

Next steps for Grim Fandango
Find out which function in scummvm is located at section 10 offset 0x4510:
```bash
ppc-amigaos-nm scummvm | awk ‘{print $1, $3}’ | \
awk '{addr=strtonum(“0x”$1); if(addr >= 0x4400 && addr <= 0x4700) print}'
```
Then identify the exact call in grim.plugin and implement g_system replacement
(analogous to PATCH 35 and PATCH 39).

## Game status

Game | Engine | Status |
|-------|--------|--------|
| The Longest Journey | strong | ✅ works |
| Broken Sword 2.5 | sword25 | ✅ works |
| The Feeble Files | agos | ✅ works |
| The Dig | scumm | ✅ works |
| Bladerunner | bladerunner | ✅ works |
| Alpha Polaris | wintermute | ✅ works |
| Starship Titanic | titanic | ✅ works (PATCH 41) |
| Penumbra: Overture | hpl1 | ✅ works (PATCH 42+43, slow ~5FPS) |
| Grim Fandango | grim | ❌ crashes on startup (SDA/g_system DSI) |

## Key findings

1. **SDA issue is fundamental** – affects all plugins that use binary global variables
2. **Static linking resolves GOT issues** – PATCH 41 (libjpeg) and PATCH 33 (FreeType2)
3. **SDL_UnloadObject must be skipped on AmigaOS4** – clib4 v2.1 bug
4. **GL_TEXTURE_RECTANGLE not available** on ogles2.library/X5000
5. **RTLD_GLOBAL does not work** with clib4/SDL2 on AmigaOS4
6. **Penumbra runs slowly** (~5 FPS) – PPC CPU limitation with 3D engine
7. **Grim Fandango** crashes at section 10 @ 0x4510 in the binary – next step:
Identify function and fix g_system access

Resized Image

Penumbra: Overture is fully supported for the first time with version ScummVM 2026.1.1 “Like a Version,” so I added this engine as well, but unfortunately it is painfully slow; we are probably reaching the limits of our hardware here. But still, it works

The AI build already contains 42 patches, and yesterday was very frustrating for me because I just couldn't make any progress and wasted all my time logging and testing. Today, many problems were solved, and I'm very happy about that.

@Nuder_Try

You mean “Reah: Face the Unknown”? I'll definitely check it out and add it.

@Yogi

First, I want to finish one project before I start the next one. The port will not be built from the official ScummVM for AmigaOS 4.1 sources, but I will start completely from scratch. It will certainly take another week or two before I have this first project neatly finished.

Please understand that I don't want to do any quick and dirty ports, as I want to use this stuff myself under AmigaOS 4.1. But yes, at the moment I have a lot on my mind that I will look into ;-

MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Go to top


Re: x1000 onboard network opensource driver in progress
Home away from home
Home away from home


@all
Oh my ... I just attached rtl8139 to my x1000, and tried to go on the same router page, and it give me the SAME DAMN STALL !!! For about 30-60 seconds !!! Which mean i two days fight not with issues in driver, damn... But good news maybe it works then, i just need to test it not on router's welcome page then. Dunno what is it.. When i debug onboard driver this "Stall" looks like issues with TCP-recv size or something. Just after some 300-400kb download from router server just stop sending data. From side of driver everything were clear. Changing roadshow's tcp.recvspace to bigger values didn't help. Not sure wtf is that.. Need to test on other browser, but more of it i need just to DL 100MB test file over network and that will be better that router's page.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
Quite a regular
Quite a regular


@joerg
Quote:
Limiting the host ethernet controller to 10 or 100 Mbit might help, at least while developing a network driver and beta testing it.
If you can't do that on your host computer itself most routers have such an option, usually called "ECO mode" or similar.

I started QEMU with ‘-netdev tap,id=mynet0,ifname=tap0,script=no,downscript=no -device virtio-net-pci-non-transitional,netdev=mynet0'
I did simple HTB qdisc shapes traffic in Linux on tap where all traffic goes
tc qdisc add dev tap0 root handle 2htb default 400 r2q 100 
 tc 
class add dev tap0 parent 2:10 classid 2:100 htb rate 2000kbit ceil 200kbit
 
 qdisc htb 2
root refcnt 2 r2q 100 default 0x100 direct_packets_stat 6 direct_qlen 1000
 Sent 17699603 bytes 13217 pkt 
(dropped 14overlimits 12285 requeues 0)

I still get an error, the transfer is limited to 2Mb
[virtio-net] TransmitPacket: TX timeout after 100. Then the transfer drops to low values.
But out of curiosity, I see something like this in tcpdump
14:36:53.167782 be:ef:de:ad:be:ef 67:6f:b2:10:de:adethertype Unknown (0xdead), length 134
        
0x0000:  beef dead beef dead beef dead beef dead  ................
        
0x0010:  beef dead beef dead beef dead beef dead  ................
        
0x0020:  beef dead beef dead beef dead beef dead  ................
        
0x0030:  beef dead beef dead beef dead beef dead  ................
        
0x0040:  beef dead beef dead beef dead beef dead  ................
        
0x0050:  beef dead beef dead beef dead beef dead  ................
        
0x0060:  beef dead beef dead beef dead beef dead  ................
        
0x0070:  beef dead beef dead

I wonder if it's from AOS or QEMU.
The only explanation that it could be from AOS4 is this entry:
https://pl.wikipedia.org/wiki/0xDEADBEEF
https://forum.icomp.de/index.php?threa ... tcp-with-daynaport-amiga/

Go to top


Re: USB Audio driver for AmigaOS4
Amigans Defender
Amigans Defender


I've updated the Ko-Fi page with a new dirver (version 2.1)

At moment in the driver I have these audio cards:

0D8C:0102 USB Audio (0D8C:0102) [C-Media CM106]
0D8C:013C C-Media CM108
0D8C:000C C-Media Audio
0D8C:0014 Unitek Y-247A
041E:324D Creative Sound Blaster Play! 3
1B3F:2008 GeneralPlus USB Audio
1130:F211 Tenx TP6911 Headset

Use USBAudio.prefs if you want to use an unlisted card

i'm really tired...
Go to top


Re: 2027, end for AmigaOS in California?
Just popping in
Just popping in


Oh no! I didn't want the link to be clickable..

Go to top


2027, end for AmigaOS in California?
Just popping in
Just popping in


Well, what do you think about this? Is this guy a click-baiter? The document really is on the Cali fornia gov ernment website seems to be legit.

Well, I better go back to TickTock an burry myself in an endless make-up, girlie hair extensions, and how to use a faucet or door handle clips.

Video:

Your Phone Is Now Required to Spy on You. It’s the Law
https://www.youtube.com/watch?v=hI9oy0t4JUU

Go to top


Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
Home away from home
Home away from home


@joerg
Quote:

- The author of the OS4 RTL8139 driver found bugs in the QEmu emulation of it, that's why there were some special QEmu beta version of it.


Nope, it was like this version deal with issue, but in end turns out that it not, and this unnecessary change were reverted after all (and few more beta versions were out since then, none of which fix it).

In other words , i test about 10 version of rtl8139 where the "fixed on from os4welt" (which fix nothing in end) were a middle one, so 5 before and 5 after : all same or kind of same issues. No differences.

@balaton
Quote:

Polling is not an option as it would be very ineffifient so I don't think it's usable. It may only be used to test if the problem is in interrupt handling.


Yes, that exactly what i mean, just to check if issue persist. If no we know where to look at. If yes, we then also know where to not look at :)

@All
In other words, i only one time somewhere on os4welt from one user read that he make rtl8139 to work, with "fixed" driver, which didn't fix anything for me, but then, when i read this topic, it was "today fixed, tomorrow not fixed, i changed params, nope didnt' changed, oh all works, not not works" , so no proper tests were done.

Also, it's now clear (or still not?) that it's not only windows build problem, as smarkusg confirm right now he have same on Linux machine as well.

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: x1000 onboard network opensource driver in progress
Home away from home
Home away from home


@ncafferkey
Quote:

It is strange to me that the two on-board NICs enumerated by PCI don't have BARs (is the one that's actually connected to the RJ45 port the 1 Gb or 10 Gb one?). Normally, driver code just gets the virtual address from the BAR and doesn't need to care about the offsets etc. you mentioned.


From TRM found that:

Quote:

A single CPU SerDes channel is configured for SGMII protocol and this is connected to a Vitesse VSC8221 Gigabit Ethernet PHY. This is wired in turn to an RJ45 uplink connector at the rear


And on architecture diagram this Vitesse Gigabit PHY comes to Quad 5 Line 3 of CPU.

As for BARS: at least from tests i do it looks like they (MAC,DMA,IOB) have no BARs (at least GetResourceRange surely return NULL for, and test code should be correct : i in loop checked all pci devices, many of which have BARs and return it OK).


Quote:

However, the PCI entries do have interrupt numbers, so why shouldn't AddIntServer() work with them?


There is how i understand it all and how i did it for now (correct me if i wrong somewhere):

It looks like when you use some external card , chip of this card handle everything at one interrupt : be it DMA events, or MAC wire events , etc. In your prism/atheros you just did AddIntServer(((struct PCIDevice *)card)->MapInterrupt()", and have in return an interrupt number installed handler for which can cover everything: recv, send, DMA, link stats, errors, when fire interrupt after which N packets, etc, you just read/set config registers.

Now when it come to onboard, we have 3 different PCIs : MAC, DMA (moving data) and IOB (handle interrupts).

MAC: just single device-level interrupt: link,state, errors, flow, i.e. wire level only, currently i skip it completely as interrupt, but, we still use config registers of course (i do so to completely mimic as on linux done), i.e. write some stuff right on initialization stage as linux driver did, but most important there is : DMA channel routing bit, so to say to which dma-channel sends packets.


DMA: it have one device-level interrupt: not of big use by itself (fires for start/stop of whole engine,etc) and we also didn't install handler on it, but its actual number of big use to know from where to start calculating offsets to the DMA channels we need and then install interrupts on them only. From linux code i see that DMA engine have 64 RX channels and 20 TX ones. And their vectors calculate by formula:

RX = base + num_txch + rx_chno.
TX = base + tx_chno.

And then they just installs 2 interrupts for 2 channels rx and tx.

request_irq(mac->tx->chan.irqpasemi_mac_tx_intr, ...);  /* TX done */
  
request_irq(mac->rx->chan.irqpasemi_mac_rx_intr, ...);  /* RX done */



So on Os4 i just do for rx:

base->irq_number base->dma_dev->MapInterrupt() + ntxch + (ULONG)base->rx_chno;

    
base->irq_handler.is_Node.ln_Type NT_INTERRUPT;
    
base->irq_handler.is_Node.ln_Pri  10;
    
base->irq_handler.is_Node.ln_Name DEVNAME;
    
base->irq_handler.is_Data         = (APTR)base;
    
base->irq_handler.is_Code         = (VOID (*)())PASemi_InterruptHandler;

    
BOOL ok IExec->AddIntServer(base->irq_number, &base->irq_handler);


Tx i completely ignore for now, doing "fire and forget".


Now, after i set correct (as on Linux) values for MAC and point on correct DMA channel, then install interrupt on RX, which, when generated (with it's DMA channel config registers) didn't provide necessary info, only some bits like where it in memory, is it working, but says nothing if packet arrive, if many pending, should cpu interrupt : this is done by IOB


IOB:
And this third one we setup at initial state a bit, and then in the handler which we set for DMA-channel 5, we do our job : one IOB read (may be optional) and one IOB write (to say wath for next interrupt).


So, looks a bit complicated of course, and i do not know, if i can get rid of some steps there and replace with StartDMA() / EndDMA() for example somehow..


But keep invistigated, at this moment i still have good 0.5ms ping for router , stable, no packet loss, but when i do try load over TCP in browser something, then it stalls for long time like 30 seconds after random loading, and then continue again. And again stalls.. So trying hard to mimic what linux does to understand what happens.

All in all, it looks just like network stop send packets. Not like i have broken or missed return, etc...

--------------------

Btw, may i ask why in your driver you use EmulateTags() copy for RX/TX/etc ? Just for having same code working for os3/os4 , or there were other reasson for ?

Also can we call ReadConfigLong() from IRQ context ? Probably not ?

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top


Re: Introducing the Rear Window blog
Amigans Defender
Amigans Defender


@jabirulo

I can't reproduce this either. However, I reviewed the waveform gadget's selection hook, and I found a situation similar to the one that caused the race condition in the Settings, so I applied the same kind of fix just to be on the safe side.

The Rear Window blog

AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
Go to top


Re: NEW AMIGA BOOK: Bootblock Rebels - The Hidden Stars of the Amiga Underground
Just popping in
Just popping in


All four stretch goals have been reached!

1 - Galahad chapter

2 - Amiga cracktro

3 - Cover design by J.O.E.

4 - J.O.E. poster


Late pledging will be available after the official campaign ends on March 15, 2026, and there may be an additional surprise in the works if new backer momentum remains strong.


Back the campaign:

https://www.kickstarter.com/projects/bitman/bootblock-rebels


Go to top


Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
Quite a regular
Quite a regular


@balaton
Quote:
I haven't heard reports from there but I don't usually hear anything from MorphOS people. Not many people use MorphOS with QEMU as you can't register only try the demo and maybe the few who do use it use mac99 with sungem instead.

I have a MorphOS disk image version 3.19 for PEG2 somewhere and I can take a look.
Generally speaking, apart from MorphOS, we would have to redo the tests for RTL8139 on the current version of QEMU and AOS4.
There have been a few changes over the past few years. UP3 Roadshow had an update to version 1.15, drivers... Even the systems on which QEMU runs.
It is possible that some of the old reports are outdated regarding AOS4 and may be incorrect.
Even if someone wrote that everything works correctly on Windows, it was true, but they did not provide any details.
If anyone is willing to test RTL8139 and QEMU, please let me know. It would be best to start a new thread related to this on amigans.net.
I will definitely not check it myself because it is time-consuming on all QEMU machines where QEMU runs (A1, PEG2, Sam460), various macOS and Linux systems, and possible stupid changes in system settings (e.g., MTU).
If no one is willing to do it and everyone is waiting for a ready-made solution, they will certainly not find out whether RTL8139 is currently working properly.

Go to top


Re: Introducing the Rear Window blog
Just can't stay away
Just can't stay away


@jabirulo

Quote:
When clicking (click or click and drag) on right side border of waveform preview/gadget the apps crashes/freezes system.

I tried to reproduce it, but couldn't. But I'm not sure I understand exactly where you click/drag. Can you show it in a screen grab or something?

Also, that is on a Sam460, IIRC?


Best regards,

Niels

Go to top


Re: USB Audio driver for AmigaOS4
Not too shy to talk
Not too shy to talk


Excellent!!

As it happens, one of my three current projects is also USB audio.

So much to talk about.. I also have some working code for Audio2,
written for the Behringer 404HD.

There are quite a few challenges to making AHI work for USB. I hope you beat them all and I'll help if I can in any way.

There are a few things in Audio1 that were left undefined, so there's a few different ways of doing things. My latest code is for one specific device, on the thinking that if I get one "just right" then release the code it might grow from there. I was/am writing for the creative SoundBlaster Play3. Nothing particularly special about it except it's a name brand and should be available everywhere.

I suspect you're already past where I am right now. I look forward to downloading and testing tonight if I get a chance to do so.

///////////////////////edit/////////////////////////////
The Play3 is recognized, but when I play a test sound
everything stops..
Also it offers 7.1, which is not a supported mode in this adapter.

But I am very enthusiastic. It wouldn't hurt my feelings at all
if your driver is ready before mine is.

My "Amiga Time" is very limited, perhaps this weekend
I'll find a NULL modem cable and grab some debug for you.

//////////////////Another Edit ////////////////////////////
Based on Sashimi output, it all looks good until it tries to set
interface 1 to alternate 1. That is the correct choice, but immediately
after that everything stops.

That stop is from the libusb code..

I might be all wrong, but I don't have a null modem cable handy
tonight, it'll, have to wait for the weekend.

Good Luck! We're all rooting for you.


Edited by LyleHaze on 2026/3/10 23:05:20
Edited by LyleHaze on 2026/3/10 23:31:01
Go to top


Re: x1000 onboard network opensource driver in progress
Just popping in
Just popping in


My DMA-based network drivers assume there is no cache coherency. They use Exec cache-related commands (wrapped in macros for compatibility) to flush caches before and after DMA transfers.

I wasn't aware of the MEMATTRF_CACHEINHIBIT flag until now, so I can't say for sure if that could be used instead.

It is strange to me that the two on-board NICs enumerated by PCI don't have BARs (is the one that's actually connected to the RJ45 port the 1 Gb or 10 Gb one?). Normally, driver code just gets the virtual address from the BAR and doesn't need to care about the offsets etc. you mentioned.

However, the PCI entries do have interrupt numbers, so why shouldn't AddIntServer() work with them?

I also second what Niels said about the battery: a low voltage can have strange effects, as I found out recently: my X1000 wouldn't turn off!

Go to top


Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
Just can't stay away
Just can't stay away


@kas1e
Quote:
Why then on all machines include x5000 rtl8139 show no bugs ? Too slow in compare with qemu ? But imho x5000 faster than qemu emulation, shouldnt be issue with too many irqs ?

CPU speed probably does not matter here more network speed. X5000 uses different kernel so problem may only be with pegasos2 or with IRQ sharing. If there's a problem with interrupt handling in AmigaOS it could explain a hang. Is it possible to get a stacktrace of a hung driver to see where it stopped?

Quote:
Also, all in all, we can try non interrupt way for virtionet.device , i mean this busy-waiting/polling by cpu instead of irqs ? I tried it on real x1000 now (i mean non interrupt way) and while have ai bugs it works, and i didnt see lot of cpu loading (if at all) probably because roadshow limited speed anyway .. maybe as test worth of try ?

Polling is not an option as it would be very ineffifient so I don't think it's usable. It may only be used to test if the problem is in interrupt handling. With polling if you limit the number of polls to avoid high load it will limit the speed and if you do it too often it will generate constant load even if nothing is transferred. That's why these normally use interrupts which is a better way to handle these async events.

Go to top


Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
Just can't stay away
Just can't stay away


@smarkusg
Quote:
I also don't remember how MorphOS worked with RTL8139 and Qemu.

I haven't heard reports from there but I don't usually hear anything from MorphOS people. Not many people use MorphOS with QEMU as you can't register only try the demo and maybe the few who do use it use mac99 with sungem instead.

Go to top


Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
Just can't stay away
Just can't stay away


@joerg
Quote:
Using RTL8139 with QEmu doesn't make any sense, instead you should always try to emulate the simplest hardware as it's less likely to have emulation bugs and emulating simple hardware is usually faster than emulating more complex hardware.
For example NE2000 (rtl8029.device), or if it's supported by QEmu the 3Com (AmigaOne) or VIA Rhine (Pegasos2).

There are limited number of cards emulated by QEMU and limited number of cards with AOS4 drivers. The rtl8139 seems to be the only common in both that mostly works. I did not write any of these just used what's already available. There's also ne2k_pci but I don't know what's with that. It seems to work with AROS but others here said it does not work with AmigaOS4. Since no driver source available I have no idea why.

Quote:
Also very important: Make sure the IRQ used for the network card (emulation) isn't shared with other PCI devices.
Ethernet I/O causes a huge number of IRQs per second anyway, with fast emulation maybe more than the kernel, other parts of the OS or drivers can handle, but if the same IRQ is shared with other PCI devices as well it's nearly guarantied to fail...
It may be a problem on the Pegasos2 which AFAIK uses a single IRQ for all PCI devices, but on the AmigaOne you have 4 IRQs which are freely configurable for each PCI port.

In case there is a problem in the kernel, the TCP/IP stack or the SANA-II drivers handling thousands of IRQs per second it's getting worse with virtio: Less overhead -> more speed -> more IRQs and task switches per second.

Amigaone also has specific IRQ mappings, see here so having more than 3 PCI devices could also share interrupts. To use the on-board ethernet card slot you can do -device rtl8139,addr=6 on amigaone which would use the IRQ reserved for this card and avoid potential sharing. I think this was tried before but did not help.

Go to top


Re: working virtio-net.device for QEMU : no more issues with rtl drivers !
Just can't stay away
Just can't stay away


@joerg
Quote:
- The author of the OS4 RTL8139 driver found bugs in the QEmu emulation of it, that's why there were some special QEmu beta version of it.

Maybe I missed something but I think he looked at the emulation but could not find anything that's not in accordance with the chip specification so we could not identify anything that could be fixed there. That's why he made changes to the driver instead. I'm not sure what the workarounds added in beta version were but apparently these did not fix all problems. If the problem is not in the rtl8139 emulation or driver (as it's seen with virtio-net too) then maybe no surprise it can't be fixed there. The rtl8139 in QEMU is not the most tested or maintained network card but seems to work with all other OSes apart from AmigaOS so this suggests problem is more likely on the AmigaOS side or in machine emulation not in actual network related stuff.

Quote:
- It's emulated. If your host has a 1 Gbit or even 10 Gbit ethernet controller that's the speed you get from the emulation as well. With the slow (every packet is copied several times around inside the TCP/IP stack while processing it) and ancient TCP/IP stacks on AmigaOS flooding it with that many packets and IRQs per second is similar to a DDoS attack

Limiting the host ethernet controller to 10 or 100 Mbit might help, at least while developing a network driver and beta testing it.
If you can't do that on your host computer itself most routers have such an option, usually called "ECO mode" or similar.

I'm not sure this would help much as QEMU sends packets through the host OS so it may be taken by host OS before it's sent or packets received could be buffered by host OS so guest might see faster speeds.

Go to top


Re: USB Audio driver for AmigaOS4
Not too shy to talk
Not too shy to talk


Hi Andrea and all

As I reported in Discord channel I tried 4 different USB Sound Card

UGreen
Cheap 7.1 USB
Cheap 8.1 USB
Behringer U-Phobia UM-2

I can see USB Sound cards in Prefs/AHI or Prefs/Sound (A-Eon version), but I when I click Play A Test Sound, it locks the machine (Sam460)

Does anyone have the same problem ?

Sinan - AmigaOS4 Beta-Tester
- AmigaOne X5000
- AmigaOne A1222
- Sam460ex
Go to top



TopTop
(1) 2 3 4 ... 7638 »



Polls
Running AmigaOS 4 on?
AmigaOne SE/XE or microA1 12% (26)
Pegasos2 3% (8)
X5000 22% (48)
X1000 14% (30)
A1222 8% (19)
Sam 440/460 18% (40)
Classic PowerPC Amiga 2% (6)
WinUAE emulation 7% (16)
Qemu emulation 9% (21)
Total Votes: 214
The poll closed at 2025/12/1 12:00
8 Comments


Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project