This web page is a part of buffi's web ring
Categories
Old Hardware Retro Computers

X68030 SCSI Adventure Part 1

I finally got SCSI working on my X68030 CZ-500C, so thought I’d do a writeup on what I learned. It will be in two parts, where the first one covers the default CZ-500C SCSI support, and the second part covers a new adapter I made for using internal SCSI devices.

CZ-500C SCSI Internals

X68030 has proper SCSI support, not just SASI as some of the earlier X68000 models. CZ-500C does however lack cabling for internal SCSI HDD (which CZ-510C has). The internal connector used from the main board to the SCSI IO board is a non-standard 40-pin flat cable. The schematic for CZ-500C including the SCSI board can be found here.

The IO board itself is quite simple. Other than the connectors and ID switch, it just has a terminating 33oΩ/220Ω resistor network, a bunch of capacitors and a 1A fuse for the external power delivery. It is mounted on top of another IO board for the external floppy, and easy to remove with two screws.

If the SCSI board is not connected to the bottom PCB of the X68030, the system will not start.

External connectors

The external SCSI connector is a “Micro Centronics” connector, which is hard to find proper cabling for. It seems like the Japanese term for these are アンフェノールハーフ50 (Amphenol half 50) or アンフェノールハーフピッチ50 (Amphenol half pitch 50).

When looking for adapters to full-size Centronics, you can search for that in combination with アンフェノールフル 50 (Amphenol full 50), and look for a cable with a male Micro connector that goes to a female full size connector. This can then be hooked up to a Centronics Bluescsi device. Example from an Mercari auction:

There is a SCSI ID switch on the back of the unit. This doesn’t seem to be related to the external device, but rather the SCSI ID that the X68030 uses. Weirdly there’s also an option for this in SWITCH.X so I’m not really sure which option has priority. The compact version of X68030 does not have this switch, nor does other X68000 models as far as I can tell.


Categories
Old Hardware Retro Computers

NEC PC-9801-86 Recap notes

Did a quick recap of my new PC-9801-86, and thought I’d add some notes to simplify for other people. There’s an earlier Japanese caplist here that I used as a base, but they used THT caps for the recap which I didn’t want to do.

Note that C33 and C34 are bipolar caps. The mouser links below link to the proper ones, but in my actual recap I just used polarized capacitors which seems to work as well (the Japanese link above did this too). It should be better to use bipolar caps though, so I might swap them later.

Purchase list

MouserAmount
710-8650904430058
710-8650603430033
710-8652306400041
710-8650903430055
710-8652503400032
710-86523044000132
710-8650606400012
647-UWP1C4R7MCL2

Cap list

PositionCapacitanceVoltageDiameterMouserNote
C133μF25V6.3mm710-865090443005
C233μF25V6.3mm710-865090443005
C333μF16V6.3mm710-865060343003
C40.47μF50V4mm710-865230640004
C533μF25V6.3mm710-865090443005
C733μF25V6.3mm710-865090443005
C847μF16V6.3mm710-865090343005
C910μF16V4mm710-865250340003
C104.7μF25V4mm710-865230440001
C114.7μF25V4mm710-865230440001
C124.7μF25V4mm710-865230440001
C1333μF16V6.3mm710-865060343003
C144.7μF25V4mm710-865230440001
C154.7μF25V4mm710-865230440001
C164.7μF25V4mm710-865230440001
C174.7μF25V4mm710-865230440001
C184.7μF25V4mm710-865230440001
C194.7μF25V4mm710-865230440001
C204.7μF25V4mm710-865230440001
C214.7μF25V4mm710-865230440001
C224.7μF25V4mm710-865230440001
C234.7μF25V4mm710-865230440001
C244.7μF25V4mm710-865230440001
C254.7μF25V4mm710-865230440001
C264.7μF25V4mm710-865230440001
C274.7μF25V4mm710-865230440001
C284.7μF25V4mm710-865230440001
C294.7μF25V4mm710-865230440001
C301μF50V4mm710-865060640001
C311μF50V4mm710-865060640001
C324.7μF25V4mm710-865230440001
C334.7μF16V4mm647-UWP1C4R7MCLBipolar cap
C344.7μF16V4mm647-UWP1C4R7MCLBipolar cap
C3533μF25V6.3mm710-865090443005
C3633μF25V6.3mm710-865090443005
C3747μF16V6.3mm710-865090343005
C3847μF16V6.3mm710-865090343005
C394.7μF25V4mm710-865230440001
C404.7μF25V4mm710-865230440001
C424.7μF25V4mm710-865230440001
C434.7μF25V4mm710-865230440001
C444.7μF25V4mm710-865230440001
C4547μF16V6.3mm710-865090343005
C4647μF16V6.3mm710-865090343005
C4810μF16V4mm710-865250340003
C504.7μF25V4mm710-865230440001
C514.7μF25V4mm710-865230440001
C534.7μF25V4mm710-865230440001
C5433μF25V6.3mm710-865090443005
C5533μF25V6.3mm710-865090443005
C564.7μF25V4mm710-865230440001
C574.7μF25V4mm710-865230440001
C584.7μF25V4mm710-865230440001
C594.7μF25V4mm710-865230440001
C6033μF16V6.3mm710-865060343003
Categories
Old Hardware Retro Computers

FM Towns SCSI boot guide

Had some issues getting SCSI CD-ROM booting working on my FM Towns tower, so thought I’d just do a quick step-by-step writeup on what I did.

The source of this is https://nfggames.com/forum2/index.php?topic=6821.0 but it’s very light on info, and took me a while to figure out how to get this on a floppy from a modern computer.

Hardware needed:

  • 3.5″ floppy drive + floppy
  • Greaseweazle setup
  • SCSI CD-ROM + cable for connecting it to back of FM Towns

Software needed:

Making the floppy

This is honestly the only tricky part, and the main thing is that the disk images are incompatible with greaseweazle as far as I can tell, so first you need to open Virtual Floppy Image Converter and convert it to a FM Towns compatible format.

  • Select “D88 format” as format and click the open icon to the left
  • Select FDMINI.BIN
  • This will then spit out a D88 image.

Connect your Greaseweazle over USB. Hook up the 3.5″ floppy drive to it. Use a twisted floppy cable. Run:

gw write fdimage.d88 --drive=A

This will produce the floppy you need

Booting

Connect the SCSI CD-ROM drive to the SCSI port at the back of the FM Towns and put a CD in it. Use the boot floppy and it will automatically boot from the external CD-ROM.

Works great!

Look at this chunky CD-ROM. So big and cool.

Categories
Shmups

Ibara to Ibara Black Label (Kuro) JTAG conversion

For quite a while now, I’ve known that converting Ibara PCB’s to Ibara Black Label without any soldering is possible with a minor audible difference. The character select music from Ibara Kuro is not present on the regular Ibara roms, which is not solvable without re-soldering.

Other than that, the music roms are identical, and since both the U2 and U4 roms can be reprogrammed through JTAG, that means that a conversion between them is possible, although it will be be noticable on the character select screen.

This post covers that a bit more in-depth.

Difference in music ROMs

If running the Audio_ExtractData scripts in my cv1k research repo on the Ibara and Ibara Black Label romset and then comparing checksums, it becomes clear that every entry in the list of sounds match except the first two.

On the regular Ibara sound ROMs, this seems to be some unused placeholder music from Mushihimesama. If inspecting the name for these in the program data, there’s some strings such as “GOMEN (old)”, which can also be checked in the test menu through memory hacking. Playing these will play some of the Mushihimesama music.

The track at ID=0 is just about a second, but the one at ID=1 is about 28 seconds long.

If inspecting the music in the first two slots of Ibara Kuro, then one can notice that the first one holds the new Character Select music, which is the only new tune (about 47 seconds long).

This means that simply swapping the non-music roms on the board would have the character select music play a second of Mushihimesama music, and then silence… which isn’t the end of the world, but we can improve that slightly!

Modifying the Ibara Kuro U4 rom to play nice with character select music

The simplest thing to do here is to swap the track played on character select screen. After reverse engineering the program code, the TL;DR is that this is controlled by the byte at offset 0xC186F of the Ibara Kuro U4.

By default it’s set to 0x00 which would play a second of Mushihimesama music. Changing it to 0x01 will have it play the longer Mushi tune, which I felt was sufficient. Changing it to 0x10 will have it play “Showtime” which was the original Stage 1 music that was not used in Ibara Kuro for some reason, so that’s also a good option.

TL;DR: Change the byte at 0xC186F from 0x00 to 0x01.

Writing ROMs through JTAG

The TL;DR here is really just to follow the instructions on https://github.com/buffis/cv1k_research/tree/main/JTAG (and especially https://github.com/buffis/cv1k_research/blob/main/JTAG/urjtag_setup.md )

Commands below assumes having checked out that repo and using a UsbBlaster, but if you go the Tigard route, it will be a lot faster.

Either way, it will take a long time (24h or so for Tigard, several days for UsbBlaster), so make sure to have a good space to do it!

Writing U4

First be nice and dump your own U4 and verify it’s not a undumped revision.

sudo jtag
jtag> cable UsbBlaster
jtag> detect
jtag> detectflash 0
jtag> readmem 0 0x200000 u4.bin

Then with the U4 modified for the character select screen:

# This will take a few hours with UsbBlaster, and less than
# an hour with Tigard
sudo jtag
jtag> cable UsbBlaster
jtag> detect
jtag> detectflash 0
jtag> flashmem 0 u4.bin

Writing U2

It’s VERY VERY IMPORTANT to make a backup of the initial block of your PCB first. CV1000 programs around initial bad blocks of the NAND, and if you lose your bad block table, than that can lead to bad behavior later.

# Store this somewhere safe
sudo python3 K9F1G08U0M_JTAG.py read_page --page=0 --filename=u2_page0.dump

# Then run this to print the bad blocks
sudo python3 K9F1G08U0M_JTAG.py bad_blocks

You will then need to align the Ibara Kuro U2 rom to the bad blocks, using: https://github.com/buffis/cv1k_research/blob/main/U2_Tool/u2tool.py

As an example, if blocks 78 and 201 are bad, run:

python3 u2tool.py adjust ibarablk.u2 --outfile=ibarablk_fixed.u2 --bad_blocks=78,201

You can then follow the instructions of https://github.com/buffis/cv1k_research/tree/main/JTAG#write-u2 to write this to the board. With a UsbBlaster, this can take 70+ hours. With a Tigard, I think it’s closer to 24 hours, so still a while.

Should you do this?

Honestly, probably not. The base game plays better, and Black Label feels a bit like a weird romhack. Unless you are confident messing around with expensive hardware, I’d avoid doing it. The setup is somewhat complex.

If you however end up doing it, make extra sure to backup your bad block table and don’t complain to me if you break something.

But yeah, if you have several Ibara boards and you know what you are doing, then this can be fun to do on one of them since you can always reverse it later 🙂

Categories
Old Hardware Shmups

Psikyo Multi

Sometimes you just wanna flex your dank new hardware.

I managed to grab a Psikyo SH2 Multi from aje_fr after waiting in line on the arcade projects forum. It is kindof amazing.

Supports the following games:

  • Sol Divide – The Sword Of Darkness
  • Strikers 1945 II
  • The Fallen Angels
  • Space Bomber
  • Gunbird 2
  • Strikers 1945 III
  • Dragon Blaze
  • Tetris: The Absolute – The Grand Master 2
  • Tetris: The Absolute – The Grand Master 2 Plus
  • Gunbarich
  • Mahjong G-Taste

… which is really nice, because I own most of the early Psikyo games, but on this hardware I only had the original PCBs for Strikers II, Gunbird 2 and G-Taste (best jong game).

Went ahead and converted my Strikers II which was… not too bad! Clearing the holes for the adapters of the sub-pcb was a bit of work, but with a good desoldering station it was fine.

With an inspection microscope, the rest of the install was pretty simple.

Time to play Tetris and Space Bomber!

Categories
Retro Computers

PC-9821 V13 modded to use ATX PSU

Just writing down some quick notes for converting a PC98 V13 to run on a ATX PSU. This is especially useful if you are in a 230V country.

These use essentially a AT power supply, with an additional 3.3V connector. This is apparently also used on some standard PC’s, see this page which describes it towards the bottom.

The PSU is the same size as standard “small” ATX power supplies, which is 150mm (W) x 86mm (H) x 140mm(D). For the replacement PSU, make sure to find something with suitable power placement to fit the holes in the case. Modern PSU’s will usually have different fan placement, so you might have to track down some older ones.

The V13 uses standard AT for the main two connectors except:

  • -5V is not populated
  • PG (power god) is not populated

This means that the cabling is as follows:

  • Black = GND
  • Green = 3.3V
  • Red = 5V
  • Yellow = 12V
  • Blue = -12V

I simply grabbed two AT->ATX power adapters and moved one of the AT cablings to free slots for 3.3V and GND in the ATX adapter. One GND pin is unpopulated, but that should be fine (and does seem to work well).

The (probably nicer) alternative is to simply remove the cabling from the original AT power supply and crimp ATX pins on those, to get the colors completely right too.

For power, rip out the original AT powr wiring and hook up the blue and white wires to PS_ON and GND on ATX. This will make the PSU work similar to the original one.

Categories
Retro Computers

PC-9821 V13 Capacitor List for Recap

Did a full recap on my V13 PC-9821. Here is the cap list.
I did double check the values, but there’s still a possibility for errors, so I recommend checking them yourself too.

Motherboard

  • 1A2: 100u, 16v (6.5mm)
  • 1A9: 100u, 16v (6.5mm)
  • 1A10: 47u, 16v (5mm)
  • 1B13: 10u, 16v (5mm)
  • 1H1: 10u, 16v (5mm)
  • 1H2: 10u, 16v (5mm)
  • 1H3: 47u, 16v (5mm)
  • 1H4: 10u, 16v (5mm)
  • 1H5: 10u, 16v (5mm)
  • 1J3: 47u, 16v (5mm)
  • 1J5: 47u, 16v (5mm)
  • 1J6: 10u, 16v (5mm)
  • 2B5: 47u, 16v (5mm)
  • 2E1: 47u, 16v (5mm)
  • 2H7: 47u, 16v (5mm)
  • 2K3: 47u, 16v (5mm)
  • 3C5: 47u, 16v (5mm)
  • 3D1: 47u, 16v (5mm)
  • 3E11: 10u, 16v (5mm)
  • 3E12: 10u, 16v (5mm)
  • 5B1: 3300u, 10v (12.5mm)
  • 5B2: 47u, 16v (5mm)
  • 5C2: 47u, 16v (5mm)
  • 5M6: 47u, 16v (5mm)
  • 6F3: 10u, 16v (5mm)
  • 6N7: 10u, 16v (5mm)
  • 7F8: 10u, 16v (5mm)
  • 7J7: 10u, 16v (5mm)
  • 7K6: 10u, 16v (5mm)
  • 8G1: 47u, 16v (5mm)
  • 8J1: 10u, 16v (5mm)
  • 9D2: 47u, 16v (5mm)
  • 9D3: 10u, 16v (5mm)
  • 9E3: 10u, 16v (5mm)
  • 9F9: 10u, 16v (5mm)
  • 9G1: 10u, 16v (5mm)
  • 10B2: 47u, 16v (5mm)
  • 10D2: 47u, 16v (5mm)
  • 10F1: 47u, 16v (5mm)
  • 10G1: 10u, 16v (5mm)
  • 10K1: 10u, 16v (5mm)

Front IO Board

  • 1A1: 100U, 16V (6.5mm)
  • 1B1: 100U, 16V (6.5mm)
  • 1B2: 10u, 16V (5mm)
  • 1D1: 10u, 16V (5mm)

CBUS Riser

  • C1: 10u, 16V (5mm)
  • C2, C3: Unpopulated
  • C4: 47u, 16V (5mm)
  • C5: 10u, 16V (5mm)
  • C6: 10u, 16V (5mm)
  • C7: 10u, 16V (5mm)
  • C8: 47u, 16V (5mm)

The slots are 100 Pin 2×50 Edge connectors. 5mm between pin rows. Pin rows have 2.54mm spacing

Sound board

Component markings are super confusing here, but it has

  • 1x (near 1C14): 47u, 16V (5mm)
  • 5x (all the other ones) 10u, 16V (5mm)
Categories
Tools

Why I will never use cheap device programmers again

I have dumped a fair amount of arcade ROMs for preservation purposes (a few notable examples being alternative revisions of Batsugun and Dogyuun, as well as several Namco System 10 games), and currently my preferred programmer is a Elnec BeeProg 2C.

This is a nice device, with a big drawback. It’s expensive and the adapters for it are proprietary and very expensive. A single adapter can cost over 200eur and will only be useful for a certain type of IC’s, and this doesn’t just mean the packages type. As an example, TSOP48 NOR and NAND flash will require different adapters.

Easily over 1000EUR in adapters...
Easily over 1000EUR in adapters…

Getting one of these if you only want to dump a few ROMs probably won’t make much sense, but if you are an advanced hobbyist, I think throwing money at this problem is well worth it.

So why get this instead of something cheaper?

Simply put, after using different types of cheap Chinese universal programmers I got annoyed enough that I felt the need to upgrade to something that:

  • Has support for (essentially) all type of chips I’ll want to dump.
  • Produces reliable dumps that I feel like I can trust.
  • Writes ROMs reliably with high success rate.
  • Support writing old CPLD’s with proper vendor algorithms.
  • Feels like a professional device. Has a known manufacturer with non-suspicious software.

Elnec Beeprog2 checks all these boxes. It’s expensive, but KNOWING that it will produce reliable results is worth the extra spend to me.

One of these is not like the others

… So, what’s so bad about the cheap ones?

Quite a few things really, lets try to break it down into a few sections.

The software

Getting software for the cheap universal programmers means dealing with one of the following:

  • Needs to be fetched from random electronics forums, because there’s no homepage for the maker of them or any official means to get the software. Sometimes they ship with this software on a CD. Sometimes they won’t.
  • Can be downloaded from an official webpage that look sketchy as fuck. Hell, TL866II/Xgecu is very popular and their official support is some random QQ email and the software is hosted on mediafire.

It’s not a bad idea to have a separate PC just to use these types of software, cause I have zero faith that they won’t include malware…

… especially since I experienced that myself when I bought a RT809H (don’t ever do this). The software for this device is full of viruses. This is true both for the included CD and from the official website.

If you see this programmer, run away.

Additionally, the UI for the software itself usually looks sort of sketchy, although I will admit the TL866/XGecu software is not too bad, if ignoring the poor translation from Chinese.

Reliability

I’ve had experiences with both incorrect reads and failed writes at a higher rate on the cheaper devices, especially TOP3000. While this can be mostly sidestepped for dumping by reading a ROM several times and making sure that checksums are consistent, it’s not a good feeling.

Failures on burning EPROMs were not uncommon for me with these devices either.

Some devices such as TL866II require manual splitting of larger DIP ROMs, which introduces points of potential failures.

I don’t have high hopes that these devices properly implement the algorithms and settings of more unusual devices, but usually they will kindof work.

Device support

Dumping common ROMs will usually work, but when having to read or write more obscure parts, the cheaper programmers just won’t work at all. For roms this can mean things like TL866II not supporting larger Flash ICs, but I’ve also hit this several times when having to dump devices with internal roms. One recent example is MX10EXA internal rom on “Crazy Bugs”.

Another example is writing to CPLD’s. For some research I was doing on Cave CV1000 hardware, I had to write to a EPM7032 CPLD which as far as I could tell, none of the cheaper programmers supported.

Original one + repros. You wont write to these with a cheap programmer.

If you are going to dump and/or build stuff as a hobby, you will keep running into issues like this basically. It is not great.

Ok… but is it a Beeprog worth it though?

I mean… if you have sufficient disposable income to motivate buying one without significantly impacting your personal economy, and want to make sure you have a reliable device that always works then yeah, definitely!

If you just want to burn/dump a few common types of ROMs then probably not.

It’s the same as any other tool really. If you just wanna do some simple cuts of plywood, you don’t need a Festool TS 55 track saw… but if you are going to use it a lot, you are unlikely to regret getting it. For now I’m just renting a TS 55 when I need one, but there is no such option for a Beeprog…

So anyways yeah, I recommend it.

Categories
Retro Computers

Sharp X68000 VRAM Repair

My X68000 (CZ-600C) was failing VRAM checks for Text RAM, and there wasn’t much info available about that online, so I’m writing some up here.

TL;DR information that is good to know:

  • On CZ-600C, IC1-IC16 is Text VRAM. IC17-IC32 is Graphics VRAM. All 32 of these RAM chips are on the Graphics sub-board.
  • The RAM IC’s used are MB81461-12 (32 of them).
  • Addressing for these can be found on the X68000 schematic. This will help narrow down which one is faulty, if you know the bad adresses.
  • Donor RAM IC’s can be found in Mega Drive units (two per unit).

Debugging the issue

Running MEMTEST (philly 1993) showed this error for TEXT MEMORY.

For more indepth understanding of the errors I ran Memtest68k which showed the range 00e725c – 00e725fc being bad, with Bits in Error Mask: 0000f000.

Looking at the technical guide for X68000 available here , this means that the error is in the last page of Text RAM, and the problematic bits are the highest 4 adresses. Looking at the schematic available on that page, this looked to be either IC16 or IC32 (turns out later it was IC16).

Addressing for Text and Graphics VRAM is slightly different, but the lower numbered IC’s map to the lower address ranges (as expected), and the data bus numbers for the pins in the schematic can help narrow down where the issues is.

To verify if it was IC16, I desoldered pin1 and pin2 on it, and wiggled them a bit while running memory checking. This produced more errors in the page of the already faulty range, which verified that it was indeed this IC that had issues. The main reason for doing this verification was that I was not sure if the first or last 16 RAM chips were for the Text part of VRAM.

After this, I was sure which part was bad.

Fixing the issue

Fixing the issue at this point was pretty straight forward, since it just meant swapping the bad part. Sourcing these are a bit awkward, but there are some available at aliexpress. I didn’t feel like waiting though, so I opened up my Mega Drive and grabbed the video RAM from that, since it uses the same IC’s. I’ll replace that later with the aliexpress ones, whenever they show up.

For desoldering these, you NEED a proper desoldering station/gun. I use a HAKKO FR301-22, but you can use cheaper ones as well. Overall, extracting this type of package is more annoying that DIP packages, but it worked out fine, with not messed up pads.

Removing RAM from Mega Drive

Next step is removing graphics sub-board and RAM chip from the X68000. Then just solder the Mega Drive RAM in the place of the bad RAM.

And there we go, memory test works now! All is good.

Categories
Research

Input lag in Psikyo games in MAME

Background

There’s is a long-standing belief that MAME has high input lag for Psikyo games (especially earlier titles), so I decided to have a look.

Some people use an ancient MAME-fork called “Shmupmame“, since it has less input lag for these games. I assumed this was due to bugs in the MAME driver, so I started probing some PCBs of mine to figure out how they work.

The MAME drivers report 4 frames of lag on the earlier titles (which is also what I saw when emulating them), and while I did find some things worth adjusting in the MAME driver, these things don’t have any impact on latency. I did however find something else interesting…

Early Psikyo PCBs have quite a bit of lag!

So yeah, the TL;DR is that MAME is accurate, because the Early Psikyo PCBs also have the same amount of input lag. The relevant games are:

  • Sengoku Ace / Samurai Aces
  • Gunbird
  • Battle K-Road
  • Strikers 1945
  • Tengai / Sengoku Blade

“Frames of input lag” is a ambiguous term though, so to be clear:

  • Button/lever is pressed during frame 0
  • No sprite movement on frame 1
  • No sprite movement on frame 2
  • No sprite movement on frame 3
  • Sprite movement on frame 4!

Also note that when playing original hardware, the input lag will vary by up to one additional frame depending on the raster beam position of the screen at time of button press, since inputs are sampled once per frame. Additionally sprites further up on the screen will be updated quicker, since the beam scans up-to-down.

Here is two typical example of what it can look like on Tengai shot in 240fps.

Note that time from button press until bomb animation starts is the same as for lever input to player movement in this game (in some other games that is not true).

“Fast case” for Tengai

See images at: http://img.buffis.com/psikyo/lag_fast/

  • Img 5: Button is pressed (see LED), right before it gets sampled.
  • Img 6-9: One frame of no sprite movement
  • Img 10-13: One frame of no sprite movement
  • Img 14-17: One frame of no sprite movement
  • Img 18: Bomb animation starts

“Slower case” for Tengai

See images at: http://img.buffis.com/psikyo/lag_slow/

  • Img 5: Button is pressed right AFTER it gets sampled.
  • Img 6-8: Game still doesn’t know button was pressed
  • Img 9: Finally button is sampled
  • Img 10-13: One frame of no sprite movement
  • Img 14-17: One frame of no sprite movement
  • Img 18-21: One frame of no sprite movement
  • Img 22: Bomb animation starts

Tengai in MAME

In MAME, the easiest way to verify that its similar timing as on PCB is to do the following:

  • Bind buttons for “Pause” and “Pause – Single Step” (UI input menu)
  • Pause game while not inputting anything
  • Hold bomb button (or direction) when paused, and doing steps below
  • Pause Single Step (One frame of no sprite movement)
  • Pause Single Step (One frame of no sprite movement)
  • Pause Single Step (One frame of no sprite movement)
  • Pause Single Step (Animation starts)

Basically… everything seems fine.

What about later games?

Later games have much lower input latency on PCB. These include:

  • Sol Divide
  • Strikers 1945 II
  • Strikers 1945 III
  • Gunbird 2
  • Dragon Blaze
  • …

… but they do on MAME too.

When testing Strikers 1945 II on PCB, I get one frame of no sprite movement. MAME produces the same result as PCB if using the Pause+Step method described above.

Basically, the newer games have two frames less input lag on both PCB and MAME compared to the older games.

But shmupmame has less lag on the early games right?

Yes, shmupmame has less lag than MAME and original PCBs for early Psikyo games. It does this by shortcuts that are possible since some buffers can be safely skipped in emulation, if not worrying about emulating the hardware accurately. If you prefer to play these games like that, then that’s fine too. It’s just not how the games worked originally 🙂

Other stuff I fixed in the MAME Psikyo driver

Still made some solid improvements though.

  • Measured accurate HSync and VSync timings. Previously they were not correct.
  • Fixed various issues in documentations
  • Corrected vertical blanking interrupt level (was irq1, should be irq4)
  • Removed MACHINE_IMPERFECT_TIMING from all relevant machines, since they’re now verified to work correctly

For reference, correct timings are:

SYNCS:  HSync 15.700kHz, VSync 59.923Hz
   HSync most likely derived from 14.3181MHz OSC (divided by 912)
   262 lines per frame consisting of:
   - Visible lines: 224
   - VBlank lines: 38 (Front/Back porch: 15 lines, VSync: 8 lines)

TL;DR

MAME is fine and accurate for Psikyo games in terms of input latency, you don’t need old forks.