2015.04.03
"Making Your Ears Bleed "
April 1st is typically about making your brain hurt with ridiculous concepts
and fake news. This year I’ve decided that instead of hurting your brain I’
m going to hurt your ears with some very preliminary sound emulation.
The Hyper NeoGeo 64 is a system we’ve never quite got to grips with, it’s a
difficult emulation target on several levels, and even the sound system is an
unusual setup; a DSP found on a fairly expensive synth, driven by an NEC V53A
processor (the synth also uses a V53 interestingly)
Over the last few weeks I’ve been looking at the V53 side of things. A V53
is a V33 with added onboard peripherals, and as it happens those peripherals
are basically NEC equivalents / modified versions of a typical PC chipset
(DMA controllers, Serial controllers, and an Interrupt controller). Luckily
with all the advancements in PC emulation in the MESS side of the project,
all of those components are now emulated, so I was able to create a new CPU
type and hook them up to it.
With the peripherals and their associated/configured ports identified and
hooked up the remaining ports on the sound CPU stuck out more, and things
like the ROM banking were immediately more obvious; fixing that up improved
the flow of the V53 code dramatically. I’m actually unclear why they even
need it, they had 2MB of sound program RAM for the V53 program and data
structures, but no game uses even close to that, in fact, everything that is
uploaded could have easily fit into the standard V53 address space with no
banking at all. It looks like earlier in the design of the system they’d
planned for 4MB of sound program RAM too, as there is an unmapped 2Mb space
below the sound program on the MIPS side (if you map it then Xrally gets
confused) and all bank addresses on the V53 side have the highest bit set.
Anyway, despite configuring various devices, I’m not entirely sure the
system makes use of the serial functionality (although there’s clearly an
interrupt associated with it) and all it ever seems to DMA is a buffer of
0x00 data from RAM. Maybe I’ll find out what these are for later, maybe,
like so many things on the system, they were simply underused, or even unused.
Kale hooked up the 2 way communication ports between the MIPS and the V53
(surprisingly they didn’t just use the shared RAM) and also an interrupt on
the V53 side that appears related to those ports, and for most of the games
we started to see communication across the CPUs, commands being sent when
sounds were trigger etc.
During the whole process described above a lot of code was refactored in
preparation for more work.
With all that in place I then hooked what I’d earlier identified as writes
to the sound chip to a new placeholder sound core, triggering some very rough
sample playable. I took what seemed to be the sample start address, and set
up the code so that it would play 0x2000 bytes of samples at that position
for each request. What that resulted in can be seen / heard in the video
below.
https://www.youtube.com/watch?v=6WXWrU_pzDA&feature=player_embedded
Of course, this sounds TERRIBLE. The PCM data format I’m using is wrong (it
seems to be some kind of 8/16-bit hybrid format rather than plain signed
8-bit PCM) and there’s no concept at all of sample length, so some samples
are cut off (Final Round) and others play for too long, resulting in garbage
sounds, or unwanted extra bits of voice clips (Round 1,2) instead of Round 1
etc.
However, as terrible as it sounds, the first time you hear sound in something
is a very special moment, so I decided it was worth preserving in a video.
People have said that I don’t post enough ‘Work in Progress’ news pieces
here these days, so here it is, as raw and ugly as it comes.
There’s still a long way to go with emulating the Hyper NeoGeo 64 to any
good level, I did make some fixes to the texture rendering on Xtreme Rally
(billboards etc.) a few weeks ago, but the 3D is still a flickery mess there
because we don’t fully understand the 3D buffering techniques. The floor on
Fatal Fury still needs hooking up again (I have some ideas) The network CPU
needs emulating properly (otherwise Roads Edge is broken even if you force it
to go ingame) Priorities and mixing need handling properly (I imagine that
will hide a lot of the garbage sprites and layers you see at the moment)
Sprite zoom needs fixing, Mosaic effects need adding, 3D colours and
texturing still needs further fixing, 3D projection needs fixing in some
cases (very obvious on the letterboxed Fatal Fury intro where it clearly
attempts to project to full-screen instead of the letterboxed area) The 3D
needs threading out to improve performance, and even the I/O is still an
issue because the I/O mcus are not dumped, and the exact communication
protocol isn’t understood meaning we’re relying on hacks to get any inputs
at all.
As you can see, there’s a huge list of things that still need doing here,
but, every little step is important with this driver, so finally being able
to hear something is very significant, even if you’re not going to be able
to tolerate it for more than a few seconds.
Some of the tasks are remarkably difficult, the network CPU is a truly insane
Z80 based chip, with many opcodes only taking a single cycle, and a complex
MMU system slapped on for good measure, to make things worse, the only
documentation is in Japanese. The I/O MCU problem we can’t do anything
about, we have no way to dump them, so it’s going to reqiure painstaking
simulation code. Understanding a lot of the video registers is also going to
take time, and maybe even hardware tests, because so many features are barely
used.
来源：http://mamedev.emulab.it/haze/