This web page is a part of buffi's web ring
Categories
Research Arcade

Namco System 10 conversions and proof-of-concept Multi

I don’t think there’s been any public pictures/videos/info of people doing game conversions for Namco System 10 yet. There’s an old thread on Arcade Project, with some people discussing the possibility, and the encryption was figured out only about two years ago.

I’ve been dumping a lot of cheap games for this system, and have always kindof wondered if converting the ROM boards to something more fun would be doable and now it is!

I wish I could say that I’ve done something smart here, but the TL;DR is really just “ask the AI to do it”. Claude (or your LLM of choice probably) will happily take your game dumps and convert them to run on other ROM boards with different protection logic. It will also handle bad blocks if reusing existing ROM chips.

For reference, the exact prompt I used with Fable 5.1 (Opus 5.5 should likely be fine too) was:

I want to try converting one of my Puzz Ball PCBs for Namco System10 to run Gamshara instead.
I have dumps for both of these games in roms/

For system10, each game pcb uses custom encryption/scrambling.

This means making it possible to run that game "as puzzball" with stuff re-encrypted/scrambled

I want to reuse the flash from the puzz ball PCB, so route around bad blocks.

I have mame installed in ~/dev/git/mame

This worked fine, but if you want to save a bunch of tokens and speed things up a bit, you can plug in this “Skill” I exported for doing these things. Just ask the AI how to use it, it will figure it out.

More indepth instructions

  • Install Claude Code or your AI of choice
  • Clone the MAME repo somewhere locally
  • Get a known working Namco System 10 ROM board
    • NOTE: I’ve only tested convering Star Trigon and Gamshara, with donor boards being Puzzle Ball, Medal no Tatsujin and Sugorotic. All of those worked.
  • Dump it. Check if the dump is something undumped, if it is, make sure to share it to someone who can put it in MAME.
    • ROMs are TSOP48 NAND Flash. You pretty much have to use desoldering alloy for removal. Hot air is ROUGH on these boards.
    • NOTE: Since you’ll reuse the ROM chips, you NEED your specific dump, to route around bad blocks.
  • Ask the AI to “Convert GAME_YOU_WANT to run on TARGET_PCB” using this skill.
  • Burn them to the original ROMs and solder the chips back.
  • Enjoy

Board below is running Gamshara.

THE FUN DON’T STOP HERE. IT’S MULTI TIME!

Turns out a bunch of games don’t really use more than two flash ROMs. There’s a lot of open position on the ROM boards… you see where this is going?

Only thing that’s needed is lifting Pin #9 (CS) and routing that to wires + switching logic, to be able to remap ROMs to look like they are placed in the 8D+8E slots (more work needed for games with more ROMs than two).

I threw together a simple proof-of-concept with Gamshara and Star Trigon, where I just have CS for the chips go to a DPDT switch. Works surprisingly well!

This is clearly a quick hack, and something more proper would allow remapping roms to other source footprints as well, to support games with more than two flash ROMs (like Mr Driller G).

None of that should be very complex though, and for something dead-simple and passive, a few 8-lever DIP switches would work.

Note regarding undumped games

There’s still a few undumped System 10 games that would be good to track down. Do NOT use any of them as donors without you or someone else dumping them.

If you are not confident duping flash based games, send them to someone like me, or Guru, or someone else who knows what they are doing.

Categories
Old Hardware Retro Computers

Test IPL for Sharp X68000

I like to repair old X68000 machines, and have been thinking about making a test IPL for running hardware tests.

I threw together one of these with Claude, and it seems to work really well. It even managed to diagnose an issue I wasn’t aware of in my X68000 pro.

The repo is at https://github.com/buffis/x68k-testipl

To use it, burn the IPL in bin/ to EPROMs for your X68000 IPL slots.

What this does

When starting the machine, this replaces the stock IPL (BIOS) with a systems test. Optionally, you can compile the Test IPL to boot into a real IPL once the system tests have completed. The default files in bin/ in the repo DOES NOT contain any Sharp IPL data, so you will have to supply that yourself if you want to do the chaining.

It will do some simple communication with various onboard peripherals, as well as run a memory test. See the repo for more details.

Finding an issue with the RTC in my X6800 Pro

When trying this out, I noticed that the RTC Oscillator test was failing. Turns out this was a real issue, and time was not advancing. Some quick investigation showed that the variable capacitor near the RTC was busted.

A NFG thread mentioned that just adding a fixed capacitor there should work as a replacement, so I did that, which both fixed the actual issue, and made the test show green in the IPL. Nice!

The bodge wire is due to me fucking up a trace when violently removing the original capacitor. Bit of a fuckup, but this machine has seen worse.

Categories
Shmups Arcade

Flying Shark running on a CV1000 Ibara PCB

We live in a weird time where we can talk to cloud robots and they spit out video game conversions for us. Everything is getting static recompilations and CV1000 games now even works on Mister.

Having worked as a software dev for close to 20 years, I dunno how to feel about all programming nowadays more or less using LLM’s. It’s hard to deny it’s pretty damn efficient at getting shit done though.

So I thought… guess it’s time to embrace the slop. Let’s make some dumb shit that I’d never do otherwise… and here we are.

Enter, “Flying Shark : Slop Label”… which is Flying Shark running on a CV1000 PCB.

TL;DR for getting it running

  • Download this zip containing the engine for running stuff.
  • Slam that in a folder with fshark.zip, fsharkb.zip and ibarao.zip from the latest MAME romset. You’ll have to find those roms yourself you filthy fucking pirate.
  • Run:
    python3 build_fshark.py fshark.zip fsharkb.zip ibarao.zip

Running in MAME (if you are a normal person):

mame ibara -rompath out

Running on PCB (if you are cool):

Write out/fshark_u4.bin as U4 using JTAG to a Ibara PCB. 

If you have one of the CV1000 multis, it will probably run fine on that too (not tested).

So… how did we end up here?

I just asked Claude to do it for me.

… OK maybe not entirely that easy, but also not entirely untrue. I threw this shit together with Claude Fable 5.1 in about a week of messing around on evenings.

Getting things working with the cv1000 driver in MAME was fairly easy, but getting everything working on an actual PCB was unsurprisingly much harder. Early attempts had… interesting issues.

After lots of tweaking and iteration, graphics started looking better and better…

Eventually things looked great, but the game ran way too slowly (since after all the M68000 is basically emulated).

A few evenings of tweaking stuff, and testing things with various debug overlays, and things were MOSTLY playable though.

After a lot of trial and error, I ended up with something that plays fairly well! It will slow down on busy sections, but I’ll just pretend that it’s intentional CV1000 slowdown, since I know that’s what all the Cave sickos are into.

How does it run?

At startup, the Blitter from Ibara is injected into the EP1C12 used as Blitter, and the ROM is copied over to RAM, similar to how real CV1000 games do their booting.

Unlike regular CV1000 games, this port does not use the graphics RAM of U2 at all though. Since Flying Shark is an old small game, the graphics can live in U4 together with the code.

Each frame the following happens:

  • An M68000 emulator (Musashi) runs a frame of the program ROM.
  • All video writes (tilemaps, sprites, palette, scroll…) gets written to memory which gets translated to a command list for the Blitter. Uploads to VRAM only happen when a tile appears in an uncached color combination, or when a tile changes color.
  • Anything the original game hands off to the TMS320C10 math coprocessor just runs as native C code instead, rather than emulating that chip.
  • The Z80 Audio CPU is only minimally emulated, since the game ROM will wait for it. It’s not used for music playback. Each of the 25 sounds of the original game is mapped to a sound sample of the Ibara sound ROMs.
  • Controls are mostly directly mapped, but the port adds 10hz autofire for button 3 and 30hz autofire for button 4.

But why?

It was pretty fun.

Changelog

25 Sep 2026: V1 release
26 Sep 2026: V2: Bugfix for audio cutout issue

Categories
Shmups Old Hardware Retro Computers

I dumped Chobi Ren Sha 68k

This is going to be a slightly long post, so the TL;DR is the following:

What is this thing?

Chobi Ren Sha 68k is a conversion of Cho Ren Sha, which swaps out sound effects, boss sprites and music to other assets. Gameplay is unchanged.

It was created by Fumi of the doujin circle CYNTHIA in 1997.

The most interesting part of this release is that it’s semi-official, in that Yosshin apparently collaborated with the doujin circle that made it, and the original composer for the Cho Ren Sha music Loser Kachigawi wrote the music for this as well (this can be confirmed by looking in the dev diaries present on the floppy).

Somehow it has gone undumped until now. This is likely since I suspect not a lot of these floppies were sold, and I’ve only ever seen it up for auction twice. This one which I managed to snag, and in a huge doujin bundle a while back which went for too much money (see pic below).

The old auction I didn’t win

While this is a VERY niche release, as a big fan of CRS68k, I’ve been very curious about it, and it’s been a bit of a “grail” of mine to find.

Version differences

At least three versions of Chobi Ren Sha 68k exist. This one, which is a conversion that’s applied to an existing CRS68k 0.6 installation, a later floppy version for CRS68k 1.0, and then an even later CD-ROM release, which I believe also has a version for Windows (see discussion here).

Existing videos on Youtube like https://www.youtube.com/watch?v=MRBLrHm8ZFI seems to be from the later releases, since sprites and music has changed.

Since this early version was made before Stage 0 was added to Cho Ren Sha, there is no updated Boss sprite in the 0.6 release.

One very fun find is that the Boss 1 BGM from Chobi Ren Sha 0.6 is actually a PCM version of the TLB music that was used in the 1.0 version of Cho Ren Sha! See video below:

Examples of some sprite differences between the versions:

Stage 1 Boss in 0.6
Stage 1 Boss in 1.0
Stage 2 Boss in 0.6
Stage 2 Boss in 1.0
Stage 3 Boss in 0.6
Stage 3 Boss in 1.0

I am hoping to track down the other versions too at some point, but it’s at least nice to have one preserved dump out for this now 🙂

Gameplay

Here is a quick video of me playing through the first loop of the game.

As you can see in the video, some of the boss sprites are quite different from the release used in other Youtube videos right now.

Installation instructions

Instructions are for original X680x0 hardware. I don’t have much experience using emulators, but I assume it should be similar there.

This version of the game is really made to run with Cho Ren Sha version 0.6 (Comiket 52), but since that version is undumped, and you probably want to play a later version anyways, here’s what I did to get it running with CRS68k v1.01. That version lacks a few of the earlier PCM files, so they need to be grabbed from an earlier version.

It seems to run fine like this (see video above), but it’s possible some stuff is wrong compared to using this with CRS68k v0.6.

Requirements:

  • X68000 or X68030 with at least 15MHz cpu frequency.
    • This is apparently to handle the additional PCM, as noted in dev diaries on the floppy.
  • A HDD . This game can not run from floppies
  • Cho Ren Sha 68k v1.01
    • (Available in x68k_flop/chorensa for MAME)
  • Cho Ren Sha 68k v0.45
    • (Available in x68k_flop/chorensa for MAME)
  • The Chobi Ren Sha dump from archive.org

Steps:

  • Copy CRS68k v1.01 to a folder on your HDD
  • Copy pcm_dat/shot2.pcm and pcm_dat/fmake0d.pcm from CRS68k v0.45 to pcm_dat/ for the v1.01 install
  • Copy all Chobi Ren Sha files into the same folder as well
  • To get the TLB music to work, you need to add the lines at the code-block below this list to BGM_DAT/sz2_bgm.cnf at the top of the ボスBGM section*.
  • Run チョビるぜ!!.BAT to start. (You may want to rename this to something easier to type)
  • Enjoy!

*Stuff to add to BGM_DAT/sz2_bgm.cnf:

* True Last Boss
BGM_No.$20 : FILE = BGM_DAT¥るざりん¥SZ2_B3.MDC

I do realize that these instructions are somewhat complicated. Someone else might want to distribute a pre-patched LZH file with the contents of this at some point and/or include this in the SCSI HDD images with games that people tend to use nowadays.

Misc stuff

The only footage I’ve found of people playing this game (the later version):

Categories
Old Hardware Retro Computers

Using USB Memory Sticks with Nereid on X68000

I looked around a bit recently on what’s possible to do with the USB port of Nereid on X68000, and saw that the currently available drivers seem to be:

  • Mouse
  • Gamepad
  • USB Floppy drive

… but I couldn’t find anyone that have written drivers for using USB memory sticks as hard drives.

I fucked around a bit with Claude and hey, now we have a driver that can do that.

Have been messing around with this quite a bit now and seems to work really well. Since the drive mounts as FAT16 instead of using binary images like BlueSCSI, it’s now extremely easy to transmit files between my computer and the X68000!

Since this is just something I shat out kindof quickly with a LLM, I can’t say I’m particularily proud of this thing, but it’s a weird new world we live in now when making these things is suddenly easy.

If I were to implement this myself, it would have taken me weeks/months of research to figure out how to approach it. Now I can just prompt some machine in the cloud and it spits out a surprisingly well written device driver for and old machine like this.

Things are getting weird.

Categories
Old Hardware Retro Computers

JOYKEY for X68000 – Using game controllers as keyboard

I have a X68000 setup at my work desk which I only use for games, and I found it annoying to have to reach for the keyboard every time I wanted to launch a game through LHES.

My initial thinking was that I could create a custom game launcher which supported controllers, or modify LHES to have support for them. After thinking about it a bit, I realized that a better option would be making a utility for mapping joypad inputs as keyboard inputs.

I wasn’t initially sure if this was possible, but after some experimentation, this turned out really well!

It’s now available on github as x68k-joykey.

As an example, to use LHES as a launcher with the standard SCSI image that people are using (with !Start.bat scripts for launching games), you can run:

JOYKEY ENABLE -P1 -U=UP -D=DOWN -L=BS -R=CR -B=Q -P2 -C -A=OPT1 -B=ESC
LHES
JOYKEY DISABLE
IF EXIST !Start.bat !Start.bat

Player 1 controller is used for navigating into games (Double tap B to quit LHES and run !Start.bat). Player 2 controller is used to swap between HDD drives.

No changes are needed to AUTOEXEC.BAT/CONFIG.SYS. Just run the util to remap things.

Only tested with LHES, SWITCH and ED so far, but should work for a lot of stuff.

Note that since this relies on hooking things up to the VBLANK interrupt, apps/games which require ownership of this will NOT work.

Categories
Old Hardware Retro Computers

Installing a FM Towns ODE in a 2F tower

I bought a FM Towns ODE recently to install in my old FM Towns PC tower, which is a model 2F.

The listing on Booth states that the CX version supposedly works in 2F models, but the cable is too short, and this turned out true.

Since I had some JST PH crimp parts at home, I reused the connectors shipped with the ODE and crimped longer ribbon cables for the connectors.

After a few mistakes with the crimping, things worked fine!

Havent had time to use this much yet, but considering the stock drive in mine is very dead, this seems pretty great!

Previously I was SCSI booting games through an external SCSI CD-ROM, which I think I’ll keep connect in the future as well for playing discs.

Categories
Old Hardware Retro Computers

Fixing 16Mhz mode on my X68000 Compact

A while back, I bought a cheap X68000 Compact that didn’t boot, and fixed it up well enough to be able to boot in 10Mhz mode, but not 16Mhz mode.

This involved both fixing issues with RAM accesses + bad logic IC’s related to audio. See earlier post here.

Considering it was bought broken and that repair took a lot of debugging, I was mostly happy with that outcome, but wanted to get back to fixing the 16Mhz mode too.

This summer, I finally went back to it and managed to fix it, so here’s a quick writeup.

Figuring out the crash

I started by probing the address lines of the X68000 until HALT was asserted, and noticed it crashed at the same spot as it did previously in 10Mhz mode before i fixed that mode.

It fails after a read of FF0636 which is a RTS instruction. The return address is incorrect, and things blow up.

Since that was what happened originally in 10Mhz mode, I could just assume that my previous fix was only _mostly_ correct.

Probing the RAM IC’s verified that only two of them were getting CS pulses in 16Mhz mode when LDS and UDS were asserted, while they all were in 10Mhz mode.

Looking back at the earlier “fix”

The previous fix I had for the RAM access was:

  • IC84 Pin #13 -> IC84 Pin #4
  • IC84 Pin #7 -> ASA Pin #3
  • ASA Pin #3 lifted off pad

This was inspired by the schematics for the non-compact X68000 XVI (CZ-634C), since the schematics for compact was not available, and it appeared to be wired the same when inspecting signals.

Going back and reverting those fixes and probing things more carefully, I noticed that the compact does NOT have this exact wiring though.

When looking at UDS which were known to work, I can see that Pin#15 and Pin#6 are wired together, and continuity testing shows that this is also wired to the ASA UDS port.

On my machine, I could see that IC84 Pin #13 was NOT connected to Pin #4, which seemed weird, since I’d expect LDS to be have the same as UDS. Trace should be under IC, but assuming trace damage, the previous initial patch was correct.

What was wrong was the IC84 Pin #7 -> ASA Pin #3 part (which should be correct on the non-compact).

Simply reverting that fix, and cleaning up the bodge a bit made the machine boot in 16Mhz mode too.

Happy ending

Very glad to have this fixed. Machine now works 100%. Getting sidetracked a bit by messing up the wiring in the previous repair was awkward, but simply going back and probing things carefully made for a rather quick fix!

The best type of mistakes are ones that can be easily reverted.

Categories
Old Hardware Retro Computers

Putting spare X68000’s in storage

Realized that I’m only using my X68030 and X68000 Compact right now, so putting away the rest of my X68000 in Storage until I need them for something.

All of these are bought broken and repaired. Ended up a fun stack of machines.

Fun pics below

Categories
Arcade Research Shmups

Cave CV1000 Video Timings

Realized I never looked at the video timings of Cave CV1000 back when I was looking at how the blitter worked, so went ahead and did that.

Results are at https://github.com/buffis/cv1k_research/tree/main/Video_Timings and they have been merged into MAME as of yesterday.

The quick summary is:

  • Pixel clock: 6.4MHz
  • Lines per frame: 262 (including sync)
  • Lines of VSYNC: 3
  • Active lines (rest is overscan): 240
  • Pixels per line: 407 (including sync)
  • Pixels of HSYNC: 29
  • Active pixels per line (rest is overscan): 320
  • Framerate: 60.0183806291 Hz (6,400,000 / (262 * 407)

For people emulating the games, this should not have any effect really. This is mostly for documenting the behavior of boards, and for people doing stuff such as custom video scalers.