Query: CD32 and CDTV image detection.

[giantclambake]

I'm just looking at the strategy here ~ I'm a tad confused at what happens with a filename that contain both CD32 & CDTV keywords...

Example filename: Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].cue

This .cue file will always prompt amiberry to configure as model=CDTV ~ my understanding is, this is due to the keyword 'CDTV' being detected first. So I set about trying to boot this title in CD32 mode.....I'm failing miserably here =)

Try 1 -- launch amiberry, GUI -> Quickstart -> Amiga model: CD32 (basic or expanded) --> Select image (Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].cue) -- Start

Result: amiberry blackscreens and refuses to boot (Note: I see in Chipset, CD32 has been selected)

Try 2 -- amiberry --model CD32 "Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].cue" -G (boots to model=CDTV)

I know that amiberry will actually evaluate the full path (I think ?) ...ergo...

Try 3 -- amiberry --model CD32 "CD32/Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].cue" -G (boots to model=CDTV)

gcb@gallah:~/Desktop/CD32$ amiberry --model CD32 "Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].cue" -G
gcb@gallah:~/Desktop/CD32$ cd ..
gcb@gallah:~/Desktop$ amiberry --model CD32 "CD32/Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].cue" -G

Perhaps I expected the above cmdline to work, because the keyword 'CD32' is contained in $path to file (1st detection of keyword)...

....but obviously it didn't ;) So.... and this is essentially what I'm trying to avoid.....

Rename "Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].bin" to "Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CD32].bin"
Rename "Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].cue" to "Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CD32].cue"
Edit "Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CD32].cue" to reflect change in filename of .bin file

Guess?....still blackscreens and refuses to boot .... https://ia801407.us.archive.org/2/items/noaen-tosec-iso-commodore-amiga-cdtv/Commodore/Amiga%20CDTV/Games/%5BBIN%5D/Xenon%202%20-%20Megablast%20%281992%29%28Mirrorsoft%29%28M5%29%5BCDTV-CD32%5D.7z

So it seems this title is somehow incompatible with CD32 mode (still boots in CDTV mode, as a music player, but songs do not play)

In any event, this isn't the only Amiga CD title with both the CD32 and CDTV keywords in the title (I'll have to test some others), and in these cases, how do you change Amiga model (when direct loading)?

TIA

[midwan]

The current logic tries to detect it from the filename, and as you said, the CDTV string is searched for first. If that is found, then CDTV is assumed, otherwise the fallback is CD32.

I can change the logic to check for CD32 in the filename in addition to the CDTV one, and if both are found, prefer CD32. Not sure how that will affect the titles, but I assume the newer device would be better :)

[midwan]

Regarding Xenon 2 specifically, it's normally a CDTV title (since it came out before the CD32 did).
I tried another image of that CD (with audio tracks) and booted it on CD32 mode, and it seems to work.

[giantclambake]

Umm.... that commit seems to have broken direct loading of some-filename.cue (lacks CD32 or CDTV keywords)

gcb@gallah:~/Amiberry$ amiberry "cdroms/cannonfodder/Cannon Fodder (Europe).cue"

Result: boots to default A500 config and ks-1.3 insert disk screen

Same is true when double-clicking/Open with... wrt .cue desktop icon.

This wasn't a problem previously, it would load the CD32 expanded config, and said .cue file, and work as expected.

Oversight?

TIA

[midwan]

Thanks, you're right of course. I missed that scenario. Should be fixed now.

[giantclambake]

Regarding Xenon 2 specifically, it's normally a CDTV title (since it came out before the CD32 did).
I tried another image of that CD (with audio tracks) and booted it on CD32 mode, and it seems to work.

I found this blackscreen issue ....not entirely sure if you can do anything about it... this is how the above archive unpacks...

gcb@gallah:~/Amiberry/cdroms/Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32]$ ls 
 'Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].bin'
 'Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].cue'

gcb@gallah:~/Amiberry/cdroms/Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32]$ cat 'Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].cue'

FILE "Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].BIN" BINARY  //<<----
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    PREGAP 00:02:00
    INDEX 01 01:19:67
  TRACK 03 AUDIO
    INDEX 01 05:59:17
  TRACK 04 AUDIO
    INDEX 01 13:05:42
  TRACK 05 AUDIO
    INDEX 01 19:19:05
  TRACK 06 AUDIO
    INDEX 01 24:38:30
  TRACK 07 AUDIO
    INDEX 01 29:49:30
  TRACK 08 AUDIO
    INDEX 01 36:40:30
  TRACK 09 AUDIO
    INDEX 01 41:11:30
  TRACK 10 AUDIO
    INDEX 01 46:49:30
  TRACK 11 AUDIO
    INDEX 01 52:46:30
  TRACK 12 AUDIO
    INDEX 01 59:30:67
  TRACK 13 AUDIO
    INDEX 01 62:53:17

• amiberry direct loads the .cue, which references filename.BIN (note capitalization) --- amiberry of course isn't going to find the 'Xenon 2 - Megablast (1992)(Mirrorsoft)(M5)[CDTV-CD32].bin' file, because in linux we're case sensitive, and no match will be found ...so amiberry sits there at a blackscreen, dazed & confused about what to do next ;)

Effective fix: Edit the .cue file, and change .BIN to .bin --> title now works as expected.

As said, not sure if you can do anything about this when reading in the contents of a .cue file ...

Note: thus far I've found 3 CDTV-CD32 titles that exhibit the same issue ~ the .cue references filename.BIN , but the file being referenced is filename.bin ...

Can .BIN = .bin?

[midwan]

Not easily, and without modifying upstream code (which might in turn introduce glitches).
An incorrect .cue file would also be a problem for other applications, not just Amiberry - and it's not only Linux that would have that, but also MacOS (assuming you're using the default, case-sensitive filesystem).

I think this should be fixed in the file(s) instead of the application.

[giantclambake]

Yeah, that seems like a sound approach ~ this issue seems fixed overall, kudos ;)