C4ptFuture
Xenon II CDTV EUR - Load issue on OS 2.35
Hi there,
Xenon II has weird boot behaviour anyway for stock KS 1.3 and 1.0 OS but sadly it breaks on OS 2.35.
Load behaviour with KS 1.3 and 1.0 OS:
- Boot system without disc inserted (critical as it is often hit or miss on boot up)
- Wait for CDTV OS logo
- Insert disc
- CDTV boot logo appears
- Briefly shows mouse cursor (Red dot, top left) as game is loading
- Boots into Joypad or Keyboard selection screen with CDDA playing
- Hit reset
- Game should boot back up normally
Load behaviour with KS 1.3 and 2.30 OS:
- Boot system without disc inserted (critical as it is often hit or miss on boot up)
- Wait for image to turn red
- Insert disc
- CDTV boot logo appears
- Briefly shows mouse cursor (Red dot, top left) as game is loading
- Boots into Joypad or Keyboard selection screen with CDDA playing
- Hit reset
- Game should boot back up normally but sometimes doesn't
Load behaviour with KS 1.3 and 2.35 OS:
- Boot system without disc inserted (critical as it is often hit or miss on boot up)
- Wait for boot logo
- Insert disc
- CDTV boot logo appears
- Shows mouse cursor (red dot, top left) and no further loading occurs from CD, stays indefinitely (left for 45+ mins)
- Hit reset
- Game starts to load again but constantly retries to boot (either at CDTV logo or red dot cursor), sometimes resets itself
Non problematic titles (e.g. Lemmings CDTV) just boot as normal on any combination.
Xenon II has had issues with booting on WinUAE in the past (related to delays/timings): https://github.com/libretro/libretro-uae/issues/272 https://eab.abime.net/showthread.php?t=98564
CDTV fixed kickstarts (e.g. 3.2 and 3.2.1 from HYperion) also cause issues with booting Xenon II.
Hardware: 2x CDTV-1000 Rev 2.2.1 (fully serviced), 1MB Chip. Both fully pass A500 diagnostic ROM.
Hi,
I am aware of the memory issues this game has starting up, and that it only works if you insert the disc after the CDTV title screen (rotating CDTV logos) appears, but I am not able to reproduce the issue you’re experiencing. The CDTV title works for me and does so both on 1.3 and 2.35.
I tested this on real hw on two separate CD1000 units:
- Kickstart 1.3 - CDTV OS 1.0
- Kickstart 1.3 - CDTV OS 2.35
Machines are stock otherwise (1MB Chip, 68000). They are both PAL machines and the disc I used is the original retail CDTV title of Xenon II.
As long as I turn the CD1000 on without a disc inserted and insert the disc after the CDTV title screen appears it works fine on both 1.0 and 2.35. The title boots up normally and into the game with no problems and I played part of the first level, on both machines. Also without having to do any resets after the joypad-keyboard selection screen. It just goes straight through on both machines without any issue.
Are the CD1000s you used for testing PAL or NTSC? And did you use an original disc or CD-R? Also do you have any peripherals installed?
I tried on WinUAE as well and it shows the same behavior with Kickstart 1.3 and CDTV OS 1.0 or 2.35. Works fine.
I was however able to reproduce a similar issue as you describe with Kickstart 3.1 and 2.30 and 2.35 in WinUAE:
- Title boots up until black screen with red dot mouse pointer and hangs there
- Reset machine
- Title boots up normal
But this works identical on both 2.30 and 2.35. I can boot the game in 2.35 just fine using this workaround, the same way I can for 2.30. So at this point I am not able to reproduce any specifically different behavior between 2.35 and the original Commodore CDTV OS ROMs.
This is almost certainly a memory issue due to the increased memory footprint of Kickstart ROMs higher than 1.3, possibly combined with a potential memory fragmentation issue caused by cdstrap. I will see if anything can be done regarding the memory fragmentation issue in a future version of CDTV OS, because it would be nice if the title could just boot like normal CDTV titles, but I have to be honest that it’s not high on the priority list.
I modified the ISO of the game so it doesn't use the included devs/system-configuration file and we can see the actual AmigaDOS shell on bootup. This confirms it's a memory shortage issue. Booting from a Kickstart 3.1/CDTV OS 2.30 machine:
Hi there, Yes it does indeed seem to be ram related and / or a behaviour HW edgecase with fragmentation. Is your HW revision 2.2.1 (sticker by video output port)? I know they did mess with the ROM HW wise on the 2.3 revision (bodge wires) but unsure if that has any bearing on this behaviour.
I will look to get an 8MB ram expansion for it so I can hopefully overcome this issue to run CDTV OS 2.35 and stock or updated kickstart revisions. I suppose the memorycard option may also help with the slightly extra RAM (40~48KB was it?)
Are you able to share how you patched Xenon II please so I can replicate the change to confirm the output you have there please?
Further info: Retail Xenon II PAL/EUR disc CD-R of the same disc (to rule out physical read issues/ errors) redump version of the same release (to rule out source disc damage / reading issues) & verified Both CDTV units are HW 2.2.1 PAL configured systems; KS 1.3. 1MB stock, No memorycard or extra RAM.
Hi, sure! I just opened the ISO file of Xenon II with a hex editor and overwrote the filename of the SYSTEM-CONFIGURATION file in the directory table. This effectively renames this file and so AmigaDOS is not able to find it and will default to the standard color scheme and 60-column text, making any console stdout/stderr text visible.
The string you need to change is at offset $B065 in the ISO file, or you can search for it yourself by searching for the string SYSTEM-CONFIGURATION;1
Once found overwrite any letter in the filename (but don’t change the ;1 part!) and save the ISO again. Test in WinUAE and if it works burn to CD-R and see what it returns on your hardware CD1000.
Both CD1000s I used for testing were revision 2.2.1, printed on the PCB silk screen and also present on the white sticker. Although as you already suspected as well. I’m pretty sure that any changes in the PCB between revisions will not affect the amount of system RAM available.
Even more bizarre behaviour - edited the .BIN as directed so it doesn't load the SYSTEM-CONFIGURATION file and now behaviour has changed: KS1.3 / 1.0 - Works from both power on and CDTV OS screen KS1.3 / 2.30 - Works from both power on and CDTV OS screen & KS1.3 / 2.35 - Works from both power on and CDTV OS screen!
So if anything I think there is a bug with the SYSTEM-CONFIGURATION file in Xenon II. Are there multiple versions of the disc?
Burned another version of this same .BIN (unmodified) and existing behaviour returns with CDTV OS 2.30 (partially working) and 2.35 (almost never works).
Another thing I have noticed is that both the mask roms in these are unique. Both are KS 1.3 but have some differences around 0x400:
Name: KS 1.3 NEC 315093-02.BIN Size: 524288 bytes (512 KiB) SHA1: 12282843fcd05b93b6a397ce89c56eaac05cc706
Name: KS 1.3 SHARP 315093-02.BIN Size: 524288 bytes (512 KiB) SHA1: aa16928d67d951bf6c3fc90fb0ec0b46ee57faaa
Neither KS iteration here seem to affect behaviour this end, but may differ again from yours?
It is definitely the system-configuration file. And I think I’ve figured out why. For some reason, most likely accidental, the system-configuration has the interlace bit preference set to 1, which makes the system come up in interlace mode, which is completely hidden due to the all-black color palette! This requires double the amount of Chip mem compared to the normal non-laced AmigaDOS screen. Due to this small change the system does not allocate 80KB of Chip RAM, but 160KB. This means there is 80KB less left for the game. I also think this might explain reports of the title booting properly in NTSC mode. Due to the lower resolution of NTSC (compared to PAL) only 128KB is needed in interlace mode, which may leave enough left for the game.
I took the Xenon II system-configuration and hex edited it with the default V34 Workbench colors and it came up with this:
Clearly interlaced mode judging by the 640x512 resolution. AmigaDOS error 103 means not enough memory.
You can find the Workbench interlace byte of the system-configuration file at offset $B8B9 in the ISO image. There is a 01 there. Change it to 00 and the CDTV title should boot up just fine every time without having to do magic voodoo rain dances.
I’m not sure exactly why the original system-config works once you reboot, but that’s mostly academic now, because the root cause looks to have been found now and is really a buggy system-configuration file.
Even though the fix is easy if you play on emulators or can burn a modified CD-R, I would very much like to fix this for the retail CDTV title too. I’ve been disassembling the kludges ROM module, which is used exactly for this purpose, and I hope to add a fix for Xenon II in a future update of the CDTV OS ROM (either 2.36 or 2.37). So I’m going to leave this issue open for the time being.
Thx for the interesting side quest! 😁