Replace uPD1771c high level emulation with a cpu core. #13106
Conversation
Software list items promoted to working ------------------------------------------ Star Speeder
src/devices/cpu/upd177x/upd177x.cpp
Outdated
| - Noise, time, and external interrupts not implemented | ||
| - CH1/CH2 not implemented | ||
| - Not all instructions implemented | ||
| - Are PNC1 and PNC2 updated every machine cycle or only when the noise counter overflows? |
There was a problem hiding this comment.
PNC1/2 are updated when a specific bit of the noise counter (selected by MD_NSF2/3) is cleared (negedge). That specific bit is bit 8 by default, so the update event precisely coincides with the noise counter overflowing. (The PNC1/2 update event is also the noise interrupt trigger.)
In the attached image, cycle 513 shows the PNC1/2 update trigger (#pnc_en) being asserted, and cycle 514 shows PNC1 has advanced.
There was a problem hiding this comment.
That is how I have it currently implemented.
In the description of the MIX command there is some text mentioning that the PNC2 output is updated every machine cycle. That is where my confusion came from.
Thanks for confirming that following the noise counter is correct.
src/devices/cpu/upd177x/upd177x.cpp
Outdated
| upd177x_cpu_device::upd177x_cpu_device(const machine_config &mconfig, device_type type, const char *tag, device_t *owner, u32 clock) | ||
| : cpu_device(mconfig, type, tag, owner, clock) | ||
| , device_sound_interface(mconfig, *this) | ||
| , m_program_config("program", ENDIANNESS_BIG, 16, 16, -1, address_map_constructor(FUNC(upd177x_cpu_device::program_map), this)) |
There was a problem hiding this comment.
Any hope that I can convince you to align with my MiSTer FPGA SCV core, and change the ROM to little-endian? Having two emulators which require different ROM endianness could cause chaos. :(
For my emulator, I chose endianness based on the behavior of the TBL* instructions. They byte-address the ROM in little-endian order, by selecting the lower byte when PR bit 0 is low (even). It also matches the RAM endianness for 16-bit stack accesses.
There was a problem hiding this comment.
Just to confirm: the file you use has a crc of 975bd68d?
I had chosen big-endian simply because in test mode the top 8 bits are output to PA and the lower 8 bits to PB.
There was a problem hiding this comment.
Answering my own question: I see we would have the same checksums.
What an interesting coincidence, I was not aware that you were also working on a cpu core for the upd1771.
There was a problem hiding this comment.
I was also not aware of your work. No worries! It's a good time to be working on the Super Cassette Vision. The more people involved, the merrier. Happy to take what I've learned from the experience and help you.
There was a problem hiding this comment.
No worries, no one knew I was working on this; it started out as an experiment. I am normally quite bad at sound emulation so I am very happy that I got this far with it.
Your comments are very much appreciated. Thank you.
|
Fantastic work on getting Star Speeder working and playing its lovely digital effects in MAME! ❤️ |
src/devices/cpu/upd177x/upd177x.cpp
Outdated
|
|
||
| void upd177x_cpu_device::device_reset() | ||
| { | ||
| m_pc = 1; // Yes, this is odd, but otherwise there are sync issues between writing and clearing PA in scv kungfurd when playing back adpcm. |
There was a problem hiding this comment.
That's an elegant hack.
FWIW, on silicon, an external write (from the main CPU) takes priority over 'OUT PA'. And because the 'OUT PA' completes while the external write of 0x1F is still in progress, the external write wins.
There was a problem hiding this comment.
Thanks for that background information. I already thought it should be something to do with low level timing between the chips.
I have updated the comment on that hack.
Edit: I put a workaround for the sync issue in the scv driver itself such that m_pc can be set as expected in the upd177x cpu core.
src/devices/cpu/upd177x/upd177x.cpp
Outdated
| break; | ||
| case 0x0002: // OUT PA | ||
| m_pa = m_a; | ||
| m_pa_out_cb(m_pa); |
There was a problem hiding this comment.
There isn't much use for a callback here. There's no external indication of the 'OUT PA' at instruction execution time; the port pins don't immediately change. In order for the outside world to observe this instruction's effect, an external read (from the main CPU) must happen.
There was a problem hiding this comment.
You are right. I have removed the callback.
Thank you. It is not just Star Speeder, also Kung Fu Road and Pole Position 2 now have some speech being played back. |
wilbertpol
changed the title
src/mame/epoch/scv.cpp
Outdated
| @@ -587,6 +601,9 @@ ROM_START(scv) | |||
|
|
|||
| ROM_REGION(0x400, "charrom", 0) | |||
| ROM_LOAD("epochtv.chr.s02", 0, 0x400, BAD_DUMP CRC(db521533) SHA1(40b4e44838c35191f115437a14f200f052e71509)) | |||
|
|
|||
| ROM_REGION(0x400, "upd1771c", 0) | |||
| ROM_LOAD16_WORD("upd1771c-017", 0, 0x400, CRC(975bd68d) SHA1(e777217c622331677ac1d6520a741d48ad9133c0)) | |||
There was a problem hiding this comment.
I'm not sure what MAME's rules are for ROM filenames, but should it have an extension? We've been naming this ROM "upd1771c-017.s03"... just because ".s01" and ".s02" are listed above it.
There was a problem hiding this comment.
Normally the location on the pcb is put in the extension like u1, or u2, but I have not found any pictures of the pcb where such markings are visible for the upd1771c chip.
However by combining
and
it looks like the location should be s03.
There was a problem hiding this comment.
TIL something new, thanks!
Here's a pic of my NTSC board. What a funny coincidence 😂
Not a great idea to approve a pull request that breaks the build due to build scripts not being updated… |
cpu/upd177x/upd177x.cpp: Add NEC uPD177x cpu core.
scv.xml:
Software list items promoted to working
Star Speeder