ChoRenSha 68k: Configuration Demystified

[Lander]

5:00AM, Somewhere Northwest of the Prime Meridian



Lander decides to set up Cho Ren Sha on his cogitation terminal.

5:30AM

Spoiler

Meep Meep.

ChoRenSha 68k: Configuration Demystified

I've wanted to give Cho Ren Sha a proper go for a while, having put it off due to the Old Windows / Older X68000 split making the definitive way to play unclear.
Icarus' recent thread on the new X68000 Mini version piqued my interest again, so I went digging to find the best way to experience this gem on a modern machine, and decided to document it here for posterity.

MS Windows

Download Links:
ChoRenSha 68k - Windows v1.01 (Latest build from 2017)
ChoRenSha 68k - Legacy Versions

The Windows build seemed a reasonable first call, being the more accessible of the two on account of not needing emulation.
(In theory, at least - I have to run it via Wine, but will be focusing on platform-agnostic issues for purposes of this post.)

Linux (via Wine)

Spoiler

Cho Ren Sha can run well in Wine, but is subject to certain issues depending on version:

Wine 8.10+ - Game runs as expected, displaying an unscaled 1:1 image surrounded by black bars in fullscreen.

Wine 8.6 - Game runs as expected, displaying in full screen with scaling, but 2x scaling mode results in a black screen.

Proton 8-8, Wine < 8.x - Visuals lock up shortly after entering the menu. Can be fixed by injecting dgVoodoo2. 2x scaling mode results in a black screen.

Resolution

And so to the first problem: The Windows version displays at 640x480, but the internal resolution of CRS is 256x256. Uh-oh, that's not a clean multiple...
The F-keys can be used to switch between scaling modes as follows:

F1 - 1x
F2 - 2x
F3 - 2x w/Scanlines
F4 - 1.875x (Default)
F5 - 1.875x w/Scanlines

...But each is a compromise:

1x - Pixel perfect shooter for ants.



2x - Death lurks in the overscan.



1.875x - That's no diagonal, it's a BrainΦΠΦTemple post in tileset form!



Display

The second problem is filling the display. I'm unsure how this works under actual Windows (please - chime in!), as Wine exhibits different behaviour across different versions, but assume the baseline VGA resolution is similarly non-negotiable.
This isn't ideal, since it can result in excess black bars, blurry bilinear upscaling, or potential aspect ratio issues.

dgVoodoo2 can be used to force a sharp integer-multiple resolution, but is subject to limitations around the original 640x480 aspect that make it difficult to get a fully optimal nearest-integer-multiple display.

Input

Input is also tricky, since the game appears to map DirectInput analog axes to ship movement, and ignores the POV hat that most D-pads are mapped to. And of course, no autofire.
I use a stick that can work around this, but there's a responsiveness issue somewhere in the translation to analog output that adds frequent delays and input drops, so that's no good either.

On real Windows this can likely be worked around via AutoHotKey or similar, but that's still more a patch than it is a proper fix.

Compromise

At this point, I just wanted to play some CRS, so decided to let it be for the moment and put up with the technical trouble.

...Until I encountered the true antagonist of this thread:



God's Holy Trousers, what's an XSP?

Operating a machine I don't understand isn't very Engineer, so back to square one we go.
Screen does nothing, XSP Mode does nothing, XSP Vertical does nothing... Time for a search.

Anyone?
Nope
Nobody here but us chickens
WHERE ARE YOU PEOPLE?!

And thus spake the pros:



Oh dear. But, thanks to the development notes hosted on Shmuplations, I learned that XSP is the sprite framework created so CRS could break the 68k hardware sprite limit, though that didn't explain why XSP Mode and XSP Vertical don't seem to do anything.
XSP Vertical's naming lines up with STK Vertical, which rotates the stick input, so surely there must be something going on here?

Alright, time for some ground truth.

Sharp X68000

Download Links
ChoRenSha 68k - X68000 v1.10 (Latest 2023 build)
ChoRenSha 68k - Legacy Versions

...Or the closest I can get without real hardware or a mini, at any rate. If nothing else, emulation means total control over input and scaling.

Emulators
Windows
XM6 Type-G - Site and documentation is in Japanese, but UI is in english. You want the xm6_typeg_336_20230523.zip link.

Multiplatform
Retroarch (or equivalent Libretro frontend) with the PX68k core
MAME / GroovyMAME

I already had a Retroarch setup with the PX68k core installed, which will happily load the v1.10 XDF, so booted it up and was pleasantly surprised to find it seemingly as responsive as the Windows version, even absent support for runahead.

Frame advance doesn't seem to work for discrete testing, but if there's any built-in lag it seems to be within the acceptable 1-3 frame range.
Tight enough for me to one-life up to Stage 6 on my second day of play, at any rate

Anyway, one prod at XSP Vertical later, and...

Whoa, Cho Ren Sha Hori Flaunt that 1:1 aspect ratio, baby!



To wit, it appears that XSP isn't used on Windows - at least not to the same extent - where DirectX is layered on top instead, with the F-keys acting as a skeletal config interface.
Screen appears to be a 68k-specific resolution switch, since setting it to 0x0002 causes a temporary overscan-like zoom that goes away when switching between menu and game.

And XSP Mode - drumroll please - is effectively a quality setting for the sprite rendering backend.

XSP Mode 0x0001 - Flicker is introduced when many sprites occupy the same line.



XSP Mode 0x0003 - No flicker.



0x0002 produces the same results as 0x0003 in my early-game testing, which I assume is to tweak performance on different 68k configurations.
I don't know much about the hardware, but PX68k exposes a clock rate setting with three entries that aren't labeled OC, so it seems a plausible explanation.

Anyway, I dug around and found a couple of other interesting bits, so have assembled a reference for posterity:

ChoRenSha 68k - v1.10 - The Full Extent of the CFG

Configuration
Setting	Values	Description
Game Level	Normal	Baseline difficulty.
	Hardcore	Hard difficulty.
Screen	0x0000	Default screen setting.
	0x0001	Same result as 0x0000 on my emulated machine.
	0x0002	Appears to apply overscan zoom, but corrects when starting a game.
		Note: Does nothing on Windows
XSP Mode	0x0001	Introduces flicker if too many sprites occupy a single scanline.
	0x0002	Same results as 0x0003 on my emulated machine.
	0x0003	No flicker. Default for v1.10.
		Note: Does nothing on Windows
XSP Vertical	Off	Default playfield orientation.
	On	Playfield is rotated 90 degrees CW.
		Note: Does nothing on Windows
STK Vertical	Off	Default stick orientation.
	On	Stick input is rotated 90 degrees CW.
Shot / Bomb	Shot=A Bomb=B	Default button mapping.
	Bomb=B Shot=A	Reversed button mapping.
Start Select	Off	Select locks ship X position. Start locks ship Y position.
	On	Select pauses. Start locks ship Y position.
		Note: Axial locking does not occur on Windows.
Mute SE	Off	Play sound effects during gameplay.
	On	Disable sound effects during gameplay.
Mute BGM	Off	Play background music during gameplay.
	On	Disable background music during gameplay.
SE Test	0x0000 ...	Press B to play the selected sound effect.
Music Test	0x0000 ...	Press B to play the selected music track.
Init Score Data		Reset the high score table.

There are some minor discrepancies between the new and old versions - mainly the mute setting now being split into SE / BGM - but this should cover the important parts.

Conclusion

The Windows version of ChoRenSha is easy to get started with, but is also a bit of a technical mess in comparison to the original X68000 release.

If you're looking to play on a modern machine and don't have access to original hardware or a mini, you should consider emulation for the best experience.
Especially seeing as v1.10 is currently X68000-only, and has some nice audiovisual updates.



On the emulators themselves:

Personally, I use Retroarch with the PX68k core since it's snappy, has rock solid I/O, and allows total configuration plus extra niceties like fanciful GPU scanline upscaling. However, it lacks savestate support.

MAME appears to run the game at full speed with low latency when properly configured, but comes with an imperfect video emulation warning, which appears to manifest as mild background corruption during full-screen flashes. Savestates warn about not being officially supported for X68000, but appear to work correctly once the game has finished booting.

For Windows players who don't want to reach for a big emulation fronend, XM6-Type G runs the game well, and has full support for savestates.

What is it? It's the stuff shmups are made of

fin.

[Bassa-Bassa]

Mame's X68000 emulation is quite decent these days, but I'm not sure how's currently its support for XVI CPU (X68030 is bad), which this game needs like water. Assuming it's good, Groovymame would be indeed the way to go, as it'll let you run the game at its native refresh (and resolution, if you have the proper hardware) which is quite below Windows version's and you'll likely get lower latency than with any other emulator. The Windows port hasn't even been updated this year like the X68000 version, has it? That alone speaks about what the author himself thinks about the port.

[BIL]

COOKIN ON THE HELL/ten thread, bookmarked

[PC Engine Fan X!]

Where can we still d/l the windows version of ChoRenSha 68K game?

I found it here: https://web.archive.org/web/20190726062 ... nload.html

PC Engine Fan X! ^_~

[Warp_Rattler]

Where can we still d/l the windows version of ChoRenSha 68K game?

I found it here: https://web.archive.org/web/20190726062 ... nload.html

Somebody also uploaded the latest (1.01, from 2017) Windows build separately to the Internet Archive as well, here: https://archive.org/details/chorensha68k_win32_x68k. I thought I remembered someone reporting in another thread that Yosshin was planning to update the Windows version to the new 1.10 eventually, but maybe I'm confusing that with just the new X68 build becoming available outside of the mini console.

(In theory at least; I have to run it through WINE, but won't get too deep into the Linux nerd side of things. In short: Use up-to-date Proton, and inject dgVoodoo2 to prevent the visuals from locking up.)

Hello, fellow nerd person! I actually got inspired a few weeks back when the latest X68 version of the game dropped to see if there was any way of getting it up and running on Linux. After spending a ridiculous amount of time trying to run XM6 Type G under Wine because there seemed to be no native Linux emulators, but the UI itself would only run at a bizarre <5 FPS and refused to load any images, I realized it was a fool's errand. I then dug up the latest Windows build and found it refreshingly plug-and-play, by comparison. Out of curiosity, why did you decide to go through Proton and use dgVoodoo2? I'm running my distro-provided Wine (staging 8.6, on Fedora 38) and the game launches in fullscreen without any special incantations. I played through to the second level and didn't encounter any visual lock-ups (that I noticed).

The Windows version displays at 640x480, but the internal resolution of CRS is 256x256. Uh-oh, that's not a clean multiple...
The F-keys can be used to switch between 1x and 1.875x scaling modes with optional scanlines, but both are a compromise:

How were you getting the clean 1x 256x256? Using F1, I get a much smaller display but it still seems to be at a 4:3 ratio and still with some sort of filter applied. Additionally, when using F-keys, the only ones that worked for me were F1 (tiny size), F4 (4:3 scaled to fullscreen) and F5 (same but with scanlines). Everything else just gives a blank screen--is that supposed to be correct?

Input is also tricky, since the game appears to map DirectInput analog axes to ship movement, and ignores the POV hat that most D-pads are mapped to. And of course, no autofire.

This may be controller dependent? I'm using one of the first batch of RetroBit Saturn USB pads. When I first plug it in, it appears as a generic USB controller, and running an input test in Steam shows the D-pad registering as a D-pad. CRS ignores the directional input, however. When I switch the controller to Xinput (mimicking an X360 controller), the D-pad still appears as such in Steam but now works in CRS as well. I have had that weird "POV hat not D-pad" behavior on other controllers before (it's been a while but I feel like my HRAP EX SE is a major offender), but I don't think it's been an issue on this one.

I recommend Retroarch with the PX68k core, since it has none of issues mentioned, and allows total configuration plus extra niceties like fanciful GPU scanline upscaling.

I haven't messed around much with Retroarch beyond a fairly plug-and-play RetroPie installation connected to my TV; is the X68 core fairly easy to set up? I don't have the time anymore to dig as deeply into the fine details of emulators like I used to, but I have this weird impression that RetroArch cores are generally considered "lesser" than more dedicated solutions such as XM6 or whatever. Is that remotely accurate, or that all on a case-by-case basis depending on the system and the core?

[Lander]

Good call on the links, gents - I've added download sections to the OP under the platform headers.

Also, I spotted a standalone version of PX68k on GitHub, for anyone with a compiler and enough bravery / Japanese knowledge to try and make it go

The Windows port hasn't even been updated this year like the X68000 version, has it? That alone speaks about what the author himself thinks about the port.

Not as far as I'm aware; the new version of yosshin's github.io page doesn't even mention Windows anymore, and I figure it'd be there if anywhere.

COOKIN ON THE HELL/ten thread, bookmarked

For the President and the Top Brass
I'm willing to bomb ram Boss 5's hardshield for them if necessary.

Hello, fellow nerd person! I actually got inspired a few weeks back when the latest X68 version of the game dropped to see if there was any way of getting it up and running on Linux. After spending a ridiculous amount of time trying to run XM6 Type G under Wine because there seemed to be no native Linux emulators, but the UI itself would only run at a bizarre <5 FPS and refused to load any images, I realized it was a fool's errand. I then dug up the latest Windows build and found it refreshingly plug-and-play, by comparison. Out of curiosity, why did you decide to go through Proton and use dgVoodoo2? I'm running my distro-provided Wine (staging 8.6, on Fedora 38) and the game launches in fullscreen without any special incantations. I played through to the second level and didn't encounter any visual lock-ups (that I noticed).

Ahoy! Interesting - if I switch to system Wine (8.10 installed from pacman on Artix), the lockup doesn't occur, and I get unscaled display - i.e. maximizing just adds more black bar.

I must have tried it on whatever old build was default in Lutris before immediately reaching for the Proton + dgVoodoo comfort blanket; that tends to be my one-stop shop for hoisting creaky old DX renderers into modern Wine.
I note that 8.x Proton sans dgVoodoo suffers from the same lockup shortly after reaching the menu, so will update the OP accordingly.

How were you getting the clean 1x 256x256? Using F1, I get a much smaller display but it still seems to be at a 4:3 ratio and still with some sort of filter applied. Additionally, when using F-keys, the only ones that worked for me were F1 (tiny size), F4 (4:3 scaled to fullscreen) and F5 (same but with scanlines). Everything else just gives a blank screen--is that supposed to be correct?

Curious; I was seeing the same F2/F3 blank screen behaviour previously, but on 8.10 I get:

F1 - 1x
F2 - 2x
F3 - 2x w/Scanlines
F4 - 1.875x (Default)
F5 - 1.875x w/Scanlines

When windowed, 2x clips the top and bottom of the screen to preserve pixel ratio, so I guess it was drawing outside the framebuffer and breaking the Wine renderer until recently.
It might be worth looking at Wine's virtual desktop mode to see if that fixes it under 8.6, since the new default behaviour seems quite similar. Though it looks like a non-starter under Proton.

On filtering, correct pixel ratio happens by default for me with either system Wine, or Proton + dgVoodoo with no overrides set.
That said, I have a wrapper script that disables DPI scaling in my window manager (sway) while running games, since Wayland currently handles that by brute forcing a double-size render and downsampling it, which can be pretty killer on a 4K monitor.

Perhaps that's what you're seeing? Though it wouldn't explain the aspect ratio discrepancy.
Best guess on that front is either WM-specific maximize behaviour, something related to the 8.6-8.10 change, or worst-case a GPU vendor implementation detail - I'm on AMD via the regular MESA driver for what that's worth.

This may be controller dependent? I'm using one of the first batch of RetroBit Saturn USB pads. When I first plug it in, it appears as a generic USB controller, and running an input test in Steam shows the D-pad registering as a D-pad. CRS ignores the directional input, however. When I switch the controller to Xinput (mimicking an X360 controller), the D-pad still appears as such in Steam but now works in CRS as well. I have had that weird "POV hat not D-pad" behavior on other controllers before (it's been a while but I feel like my HRAP EX SE is a major offender), but I don't think it's been an issue on this one.

I wouldn't have thought so, since in theory whatever the XInput / DInput preview says should be the sole source of truth for games outside the Steam sandbox, beyond rare cases like reading directly from USB HID.

What does your RetroBit D-Pad show up as if you run wine control and open the Game Controllers section? I use an XInput-based MadCatz Arcade Stick Pro prototype that can switch between X + Y, Rx + Ry and POV1 / D-Pad via hardware toggle, but only X / Y are acknowledged in-game regardless of whether I override wine to treat it as a DInput device via the Joystick tab.

Though I suspect my analog lag / drop issues are local and lie somewhere in udev or evdev, since I've had to zero out their defaults for other controllers before now.

I haven't messed around much with Retroarch beyond a fairly plug-and-play RetroPie installation connected to my TV; is the X68 core fairly easy to set up? I don't have the time anymore to dig as deeply into the fine details of emulators like I used to, but I have this weird impression that RetroArch cores are generally considered "lesser" than more dedicated solutions such as XM6 or whatever. Is that remotely accurate, or that all on a case-by-case basis depending on the system and the core?

It seems distro dependent; the retroarch package on Artix / Arch disables the built-in core updater and ships them as separate packages, of which PX68k is not one.
I ended up having to compile and install from source, but it was a painless make && sudo make install affair. I expect it's in the updater for more conventional setups, since PX68k has a page on the official site.

The core itself is effectively plug and play - the default settings all seem compatible, and CPU clock can be boosted to speed up the somewhat lengthy CRS boot sequence.

And I think core quality is case-by-case; if a given emulator is well-structured, its libretro core will be the same code minus any frontend, and thus have feature parity.
Most are, and in those cases I find Retroarch a better experience since the universal video / audio / input frontloads common configuration, freeing you up to worry about more interesting game / system-specific fixes and enhancements.
I'd even consider some of the libretro-maintained Beetle cores to be best-in-class, since they're compatible, featureful, and support runahead lag reduction.

On the flipside, PPSSPP is the one core I've encountered that's given me pause versus the standalone; its mapping to the libretro config is quite clunky, and performance doesn't seem great.
Per-game / system / core setting overrides can be a bit finicky until you understand their priority, and the playlist system is picky - it's fine if you have meticulously-curated romsets, but will fail to catalogue content it doesn't recognize (i.e. obscure dumps, most romhacks), and needs to be edited via text file or third-party program for full control.

Outside of those quibbles, couldn't recommend it more for general-purpose emulation on Linux:

Spoiler

[Warp_Rattler]

Cheers for the RetroArch info--like I said, I know it's running under the hood of my RetroPie installation, but that's been largely plug and play and I haven't bothered with any of the cores that aren't for console systems. Looks like my distro offers RetroArch and a small assortment of cores as separate packages, so it may be the same situation as you had, with having to manually compile from source.

Good call on the links, gents - I've added download sections to the OP under the platform headers.

Not to be pedantic, but (but of course it is pedantic) I think the latest Windows release was 1.01, not 1.1.

Also, I spotted a standalone version of PX68k on GitHub, for anyone with a compiler and enough bravery / Japanese knowledge to try and make it go

I downloaded the repository and took a stab at it--the source is a good 7+ years old and needs a lot of older i686 libraries (C headers, SDL), but it seems like it will build with a simple make. I tried installing the missing 32-bit libraries but some of the SDL ones wanted questionable dependencies that looked like they might play havoc with my system, so I'm going to hold off on any more tinkering with that, for the time being. Probably the PX68k core on RetroArch is the more painless way to go (and is likely more up-to-date).

Good to note that Wine 8.10 may fix some of the odd scaling/filtering issues--I ran an update to see if it's available yet, but it seems like it's still in the pipeline for my distro. I haven't gone too deep into the rabbit hole with Wine tinkering beyond using winetricks to hunt down missing Windows components and the like for standalone games--I use Proton with Steam, but haven't tried running non-Steam programs under Proton.

On filtering, correct pixel ratio happens by default for me with either system Wine, or Proton + dgVoodoo with no overrides set.
That said, I have a wrapper script that disables DPI scaling in my window manager (sway) while running games, since Wayland currently handles that by brute forcing a double-size render and downsampling it, which can be pretty killer on a 4K monitor.

Perhaps that's what you're seeing? Though it wouldn't explain the aspect ratio discrepancy.
Best guess on that front is either WM-specific maximize behaviour, something related to the 8.6-8.10 change, or worst-case a GPU vendor implementation detail - I'm on AMD via the regular MESA driver for what that's worth.

I'm on AMD with standard MESA as well, and it's not an issue with Wayland since I'm running Gnome under X11. It seems like it's probably something related to Gnome's handling of the window, as when I set Wine to emulate a virtual desktop the pixels look a lot sharper (though small, even at the 1.875x scaling). 2x scaling modes still just show a blank window.

What does your RetroBit D-Pad show up as if you run wine control and open the Game Controllers section? I use an XInput-based MadCatz Arcade Stick Pro prototype that can switch between X + Y, Rx + Ry and POV1 / D-Pad via hardware toggle, but only X / Y are acknowledged in-game regardless of whether I override wine to treat it as a DInput device via the Joystick tab.

I always forget about the Game Controllers applet in the Wine control panel--one of the few things I miss from Windows is an easy graphical way to test/confirm controller settings. When the RetroBit is in X360 mode ("Controller (XBox 360 for Windows)" according to the control panel) , the D-pad reads as the left analog stick (not the D-pad as I had suspected). Unfortunately, the Game Controllers applet bugs out on me when the controller is in regular USB mode ("USB Gamepad1")--pressing the D-pad in any direction only registers as, and then gets stuck in, D-pad down + left in the Xinput tab, and down/left/down-left on one of the POV hats in the Xinput tab. Steam still shows it mapping to the D-pad as expected, though. Now that I think about it, it could be an issue with this particular controller--I've got one of the newer models somewhere that added support for the PS3 and Switch, but I don't recall it being as fussy the last time I used it.

[Lander]

Not to be pedantic, but (but of course it is pedantic) I think the latest Windows release was 1.01, not 1.1.

Ah, good catch - amended. And thank goodness; going from 1.1 to 1.10 is truly a cursed approach to versioning.

Good to note that Wine 8.10 may fix some of the odd scaling/filtering issues--I ran an update to see if it's available yet, but it seems like it's still in the pipeline for my distro. I haven't gone too deep into the rabbit hole with Wine tinkering beyond using winetricks to hunt down missing Windows components and the like for standalone games--I use Proton with Steam, but haven't tried running non-Steam programs under Proton.

Lutris is the only reason I even try to fiddle with Proton outside of Steam, since the manual setup makes it very clear that it was designed for internal use first and foremost.
Worth a look if you have a library of older / DRM free stuff - I was hesitant to begin with since monolithic programs that try to do everything often fail, but it's pleasantly competent at UI-ifying things like non-system Wine versioning, game mode, library injection, and so on.

I'm on AMD with standard MESA as well, and it's not an issue with Wayland since I'm running Gnome under X11. It seems like it's probably something related to Gnome's handling of the window, as when I set Wine to emulate a virtual desktop the pixels look a lot sharper (though small, even at the 1.875x scaling). 2x scaling modes still just show a blank window.

I'm less familiar with X11 these days, though would still point the finger at DPI handling for any kind of unwanted scaling. Lutris has a toggle to disable it (which somewhat predictably, doesn't work under sway) so there's probably some underlying mechanism to sidestep the problem if Gnome's display scale / large text accessibility settings don't have an effect.

I always forget about the Game Controllers applet in the Wine control panel--one of the few things I miss from Windows is an easy graphical way to test/confirm controller settings. When the RetroBit is in X360 mode ("Controller (XBox 360 for Windows)" according to the control panel) , the D-pad reads as the left analog stick (not the D-pad as I had suspected). Unfortunately, the Game Controllers applet bugs out on me when the controller is in regular USB mode ("USB Gamepad1")--pressing the D-pad in any direction only registers as, and then gets stuck in, D-pad down + left in the Xinput tab, and down/left/down-left on one of the POV hats in the Xinput tab. Steam still shows it mapping to the D-pad as expected, though. Now that I think about it, it could be an issue with this particular controller--I've got one of the newer models somewhere that added support for the PS3 and Switch, but I don't recall it being as fussy the last time I used it.

I suspected that might be it; if my retro pads are anything to go by, chances are there's some arcane button combination to flip it between LS / DP / RS without changing protocols - not that it'd be of any help for CRS.

[copy-paster]

XM6 TypeG runs the game no problem on my end, much preferred over MAME/Retroarch because of the functioning save states (technically unlimited use) and full autofire support. Really hope Yosshin would port the new version on Windows too!

[Lander]

Nice, I'll add it to the OP.

I found what seems to be the official page and managed to run it in Wine to get an idea of the UI. The japanese site and manual are a bit intimidating, but it seems pretty straightforward once you've emplaced the BIOS and reached the english interface.

Though just to confirm, it's meant to render to the main window by default, right? I was able to load the floppy, hear attract sounds, see the CLI / main menu via the Text Plane window, and view loaded sprites in the Buffer windows, but couldn't find anywhere showing the gameplay
Almost certainly a Wine bug, but I figure I should check.

Good point on savestates too - it's worth noting that PX68k doesn't have those, at least under Retroarch.

Related, it looks like the Kakusi menu isn't accessible on Sharp, at least not via the same means; I can trigger it on Windows by holding up for 5 seconds in the Config menu, but nothing happens on the v1.01 or v1.10 X68000 releases.
So stage select and SHOW TIME! seem to be off the table unless anyone has the low-down.

[Lander]

Because I'm a stubborn fool, I ended up plumbing the depths of MAME-in-Retroarch for the sake of having savestates on top of my existing setup.

And sweet lord, I suppose it's to be expected, but MAME in Retroarch is a clunkfest.
By default, it's not set up to acknowledge anything outside of arcade titles, so won't pick up X68000 ROMs via the UI. Instead, you have to dive into the dark underbelly of software lists

ChoRenSha 68k in MAME in Retroarch

1. Grab x86k_flop.xml from MAME and place it in <retroarch>/system/mame/hash/

2. Create a copy of your CRS rom and rename it to chourensha 68k v1.01 (1995)(famibe no yosshin).dim to match up with its entry in x68k_flop.xml
(This worked with the v1.10 XDF, so it seems file extensions / formats don't need to match)

3. Zip up this file into chorensa.zip, and put it in a folder named x68000 to comply with MAME's naming scheme

4. Copy MAME's x68000.zip (containing the various X68000 BIOS files) into the x68000 folder

5. Boot a MAME title in Retroarch to get access to the Core Options menu, and turn on Read Config File / Write Config File to enable editable INI files

6. Boot CRS by loading /path/to/x68000/chorensa.zip via the Retroarch UI

7. Edit the newly-generated <retroarch>/system/mame/ini/x68000.ini and set ui_active to 1 to prevent keyboard lockout

8. Boot the game again, and use the MAME tab menu to configure input, video, etc

And presto, CRS in MAME in Retroarch with working savestates and various other bells and whistles.

HOWEVER

There's a catch; it turns out that MAME's X68000 resolution switching - at least inside RA - is quite inelegant.

The initial CLI boot displays correctly, as does the intermediary 256x256 loader, but the transition to the title screen results in a reported aspect ratio of 2:4, and vertical pixel doubling.
This can of course be resized to the proper 1:1 aspect via RA's scaling settings, but results in doubled scanline density for CRT shaders due to incorrect framebuffer resolution.

You can mediate this by switching Screen to 0x0002 via the CRS Config menu, resulting in a 16:15 aspect with no pixel doubling, but with 1/16th of the image clipped off vertically.
MAME has an alternate renderer whose resolution can be forced, but it only supports a fixed set of non-1:1 resolutions, so is a non-starter in this case.

Bah! So close to a perfect setup, but no dice.

[sorhp]

Im running windows 7 and cannot seem to get any version to load at all, can some please help a guy out? Im using windows 7 on my shmups arcade machine, I can usually get just about any new and older game to run, but not chorensha??!!??

3 hours later...
EDIT: I got the 2017 version to run! For it to run, windows must be in normal orientation, when I rotate the windows screen, the game locks up, so It doesnt like something with the resolution, only res I can run is 800x600 on the high res arcade monitor Im using. So I looked in the settings of the game, and nothing stands out at rotating the screen to tate mode, so now Im stuck figuring this part out. Any help please on rotating the pc version of chorensha to tate?

Also, if it would be better, I could run it in mame, but im using a mame version of .145, I would need to create a link that would auto load the game, I can write a script and configure all other settings for the rotation and controls. no matter the research, nothing I seem to do to load the game in mame actually works, I need a little help there.

[Lethe]

Just for completeness' sake, the latency difference between Win2025 and MAME is noticeable (to me). At a guess the port is 1 frame lag and MAME 3.5ish, and naturally the gap feels bigger if you're comparing 60fps to 55fps. I don't know if this is true on hardware or other emulators, haven't tried.

EDIT: I got the 2017 version to run! For it to run, windows must be in normal orientation, when I rotate the windows screen, the game locks up, so It doesnt like something with the resolution, only res I can run is 800x600 on the high res arcade monitor Im using. So I looked in the settings of the game, and nothing stands out at rotating the screen to tate mode, so now Im stuck figuring this part out. Any help please on rotating the pc version of chorensha to tate?

You can use dgVoodoo to wrap the game to a modern DirectX version and see if that helps it behave. (It seems to be DX3 wrapping to DX5 internally... lol)
I would update OS if you can. Lots of things have abandoned Win7 by now.