@OlafSch
I think you're getting things mixed up it's not AROS 68k that mounts the CD!
On AROS 68k, it's WinUAE running in emulation mode that mounts both the CD and the ISOs—not AROS 68k itself.
AROS 68k alone is not capable of mounting a virtual audio CD.
With WinUAE and an Amiga device running AROS 68k, you can do more—you can even use other players and view the tracks as I showed in my AfA OS screenshot.
We’re off-topic here; start another thread if you want to discuss this.
@deadwood - Ok, I understand now. Thanks for explanation and screenshots.
Are real Audio CDs (real CDs in CDROM, not .cue images) detected and playable on 64-bit AROS?
On 68k I managed to play Audio CDs
You mean physical Audio CDs on nightly 68k AROS? Which tool did you use? What icon does a physical Audio CD get when inserted? (can you make a screenshot?)
The CUE plugin works, but there are some issues
- To see the CD icon, you have to refresh the screen (I use the “Menu Wanderer/BackDrop On/Off” trick)
- On a Data+Audio CD, the audio tracks don't seem to have been mounted; I don't see an icon, and PlayCDDA 1.6—even though it doesn't work—doesn't detect the audio tracks
If I mount an audio CD, it mounts, but I don’t know if it works—PlayCDDA doesn’t detect it.
- PlayCDDA 1.6 detects a physical audio CD, but as mentioned, it doesn’t work on 64-bit systems in VMware
- PlayCDDA in VMware should only work with version 1.5, just as it does on 32-bit systems
@AMIGASYSTEM
If I remember correctly, I reported this a few years ago: basically, the 64-bit version is missing some plug-ins
(or support modules) that are located in Devs/DiskImage.
Yes, it also seemed to me like something we discussed previously. I compiled the CUE pluging for uou. See attached to this post. Not tested.
I checked, and they don't work on ABIv1 either. But then I figured out why.
If I remember correctly, I reported this a few years ago: basically, the 64-bit version is missing some plug-ins
(or support modules) that are located in Devs/DiskImage.
In addition to CUE, DAA, FDI, GI, and MDS are also missing.
Okay, I'm running some tests on ABIv1. I'd like to point out that on 64-bit systems, we don't have a working CD player—PlaCDDA, which is available for AROS 64-bit v11, doesn't work!
I did, however, test it on AROS 68k ABIv1 (aros.sourceforge.io), where there's a new version of DiskImageGUI, but even there, the .cue files don't work.
It's actually important for me to understand if CD images (.cue files) can be mounted under AROS ABIv1 and whether Audio CDs can be played there - since AROS 68k is ABIv1 then it can be used to report on those things (like x86_64 or aarch64). If they can be played then it's a possible regression in my tree or not synchronized new feature.
We're talking about CD images, not actual physical CDs.
CD images don't work on AROS 68k either.
I'll add that if you're testing AROS 68k, you need to disable CD support in WinUAE!!!
We're off-topic—start a new thread if you want to talk about AROS 68k.
@deadwood
Physical CDs work on AROS 64-bit v11, but PlayCDDA does not work
AROS 64-bit associates one of my def_Icons with physical CDs (unknown volume, no file access); see screenshot
@deadwood - Ok, I understand now. Thanks for explanation and screenshots.
Are real Audio CDs (real CDs in CDROM, not .cue images) detected and playable on 64-bit AROS?
On 68k I managed to play Audio CDs
You mean physical Audio CDs on nightly 68k AROS? Which tool did you use? What icon does a physical Audio CD get when inserted? (can you make a screenshot?)
64-Bit:
.cue files are not supported; Data+Audio CDs and Audio-only CDs are not mounted.
PlayCDDA cannot find tracks; if you eject the CD, AROS crashes, sees screnshot
32-Bit:
The .cue file is handled perfectly; Data+Audio CDs and Audio-only CDs are mounted correctly.
PlayCDDA plays tracks and ejects the CD correctly, see screenshot
OS3
This concerns the Icons; on OS3, both Data+Audio CDs and Audio CDs are supported.
On OS3, depending on the type of CDFS, it can even display the tracks!, see screenshot
Can you explain what exactly happens with 64-bit version? It only has a few more changes compared to 32-bit and they should not impact image support at first sight.
As for default icons for AudioCDs - I don't think those are handled via def_icons. def_icons handle file associations and those whole disks. I think disks are either handled by icon.library itself or Wanderer and it looks like code for handling AudioCDs is missing from either of them.
@deadwood
It seems that on AROS 64-bit, DiskImageGUI doesn't support .cue CDs; the 32-bit version works—see screenshot. I used the same configuration and the same .cue file.
Could you tell me how I should name the def_icon files for .cue CDs and audio CDs? AROS assigns ugly, corrupted icons—see screenshot.
Looking at code I don't see how this can be stable, unless it defaults to running all tasks on same core. Does it?
For example there are certain (legal/documented/official) ways to do things that require Forbid()/Permit() protection. Like closing window safely if msgport is shared among multiple windows. Like Zune/MUI is doing for example in workbench/libs/muimaster/classes/window.c. If the Forbid() in there only blocks tasks on 1 core, but not all cores, then that code is not safe in SMP as Intuition InputHandler (input.device task) from other core could still send messages to the port.
Also task exit code/procedure often relies on Forbid() to block all tasks from running. Otherwise it is not safe.
It would be best if you take it up with Kalamatee. He is not a member of this forum though. He can be reached via linen/slack channel. You can find links to this channel in developer section of www.aros.org.
Edited by deadwood on 09-09-2026 00:43, 1 month ago
Looking at code I don't see how this can be stable, unless it defaults to running all tasks on same core. Does it?
For example there are certain (legal/documented/official) ways to do things that require Forbid()/Permit() protection. Like closing window safely if msgport is shared among multiple windows. Like Zune/MUI is doing for example in workbench/libs/muimaster/classes/window.c. If the Forbid() in there only blocks tasks on 1 core, but not all cores, then that code is not safe in SMP as Intuition InputHandler (input.device task) from other core could still send messages to the port.
Also task exit code/procedure often relies on Forbid() to block all tasks from running. Otherwise it is not safe.
I moved your posts to a new thread. This thread will be locked right after release in a few days.
You can view all discussion threads in this forum. You cannot start a new discussion thread in this forum. You cannot reply in this discussion thread. You cannot start on a poll in this forum. You cannot upload attachments in this forum. You cannot download attachments in this forum.
AMIGASYSTEMDistro Maintainer