!KinoAmp issue or by design?

Not sure if this is an issue or by design, but if I double-click !KinoAmp to launch the app, I receive the following error:

Internal error: abort on data transfer at &0000AD48

Postmortem requested
ad48 in function read_modes
dbf4 in function main
Arg2: 0×0000dad0 56016 → [0xe1a0c00d 0xe92ddbf0 0xe24cb004 0xe24dcd05]
Arg1: 0×000194b8 103608 → [0×6f6e694b 0×7552213a 0×616d496e 0×63006567]
fc186c28 in shared library function
f174 in anonymous function

Press SPACE or click mouse to continue

If I double-click on a video file, !KinoAmp opens and the video plays without issue. Noticeably, however, the !KinoAmp icon does not appear in the tool bar.

I’m running RISC OS Open 5.30 on a Raspberry Pi 3 Model B+. RISC OS is running from an attached SanDisk Extreme Pro 160GB SSD USB stick. The system boots from a 1GB micro SD card that includes the necessary Raspberry Pi boot ROM, etc..

Everything else appears to be working as expected.

KinoAMP 0.58 starts up here to the icon bar on an RPi4B OS5.31 (16 May 2024)

Thanks, David.

Yes, I’m sure it was working here and appearing in the icon (apologies) bar. Maybe I could try using the latest ROM build here and see how it goes.

Aha!

Seems the culprit is !ADFFS. If I close that app down, !KinoAmp starts up without issue if double-clicked and appears in the icon bar. I will post over in the !ADFFS forum and see if they know why this is happening.

I think memory-hungry applications won’t like the AppSpace clamp that’s applied by Aemulor (e.g. Fireworkz and PipeDream try to avoid using Dynamic Areas when running on RISC OS 5, expecting to be able to grow Wimp Slot as large as necessary) – does ADFFS do something similar perhaps?

Hi Stuart. Oooh, this is all very complicated for me! I’ve only just found RISC OS, so am a complete noob! I believe !ADFFS is similar to !Aemulor, as it (!ADFFS) allows for the running of old RISC OS games. I did have to remove !Aemulor in order to get !ADFFS to play nicely.

does ADFFS do something similar perhaps?

ADFFS does not clamp AppSpace.

I suspect the root cause is the GraphicsV driver in ADFFS that provides the legacy screen modes, that’s the only thing active when ADFFS is loaded and not actually doing anything. I’ll have to take a look at what read_modes is doing in KinoAmp to figure out how to fix it.

ADFFS does not clamp AppSpace.

Good to hear!

It might be a bug in KinoAmp:

    // Try to obtain a list of supported colour depths, RISC OS 5
    regs.r[0] = 11; // set/read current driver number
    regs.r[1] = -1; // read
    if (_kernel_swi(OS_ScreenMode, &regs, &regs) == NULL)
    {
      regs.r[4] = 17 + (regs.r[1] << 24);
      if (_kernel_swi(OS_CallAVector, &regs, &regs) == NULL)

should probably be setting R9 for the GraphicsV call:

    // Try to obtain a list of supported colour depths, RISC OS 5
    regs.r[0] = 11; // set/read current driver number
    regs.r[1] = -1; // read
    if (_kernel_swi(OS_ScreenMode, &regs, &regs) == NULL)
    {
      regs.r[9] = 42; // GraphicsV
      regs.r[4] = 17 + (regs.r[1] << 24);
      if (_kernel_swi(OS_CallAVector, &regs, &regs) == NULL)

EDIT: I forgot to mention that for GraphicsV 17, ADFFS just passes the call onto the underlying GraphicsV driver unmodified so I can’t explain why KinoAmp might crash with ADFFS loaded – other than the issue noted above where it doesn’t appear to actually call the GraphicsV vector as its not setting R9 for OS_CallAVector.

EDIT2: I’ve now debugged KinoAmp and confirmed it’s the issue noted above. I’ve dropped Andre an email so hopefully he’ll investigate soon.

Thanks, Jon.

Fixed. See in Annoucements