ympsr16: pss480 reverse engineering effort

[jbevren]

Hello devs

I had recently discovered the Yamaha PSS-480 uses a 65c02 core by examining a ROM dump and decided it would be a good target to keep my analysis skills sharp on.

While discussing this with some colleagues they recommended I get in touch with MAME developerss regarding my effort so that I can share my findings and improve emulation of the OPU chip that's at the center of machines ympsr16 aims to emulate.

So far, Ive taken advantage of the commonly available service manual for the OPU pinout and traced the pcb image in the pdf to find connection points for the 65c02 bus. The connections are complete with the exception of a couple external IC lines and I have the inverse assembler working reliably on the machine.

Yamaha PSS-480 connected to an HP 16601a logic analyzer

pss480-connected.jpg (1.12 MiB) Viewed 148212 times

HP 16601a logic analyzer under remote control, running inverse assembly of a Yamaha PSS-480 CPU bus capture

pss480-ia.jpg (924.82 KiB) Viewed 148212 times

For what it's worth, this is a project I'm doing in my spare time just to keep some skills sharp, but I'm very happy to share anything I find with devs to help improve emulation. I'm not terribly skilled with software development myself, however I do find the mame machine code to be pretty readable.

If someone could let me know if this is an appropriate forum for hardware discovery info I would appreciate it

Thanks!

-jbevren

[galibert]

Nice.

FWIW, I have a heavy suspicion that the register formats for the sound-related OPU internal registers is very, very similar to the sysex format. You can find the service manual (sadly without schematics) with the sysexes on elektrotanya IIRC.

OG.

[jbevren]

That's a great idea Galibert. I have a similar suspicion, and have been comparing the sysex data format with some discrete FM chips. No matches in the 2operator category with capabilities similar with the PSS480 though. The data format will definitely be a reference once I identify code that changes parameters when loaded over midi. Currently it's face down on the bench so the front panel isn't really accessible

I've largely been quiet as I had been experimenting with different ways to study the machine's behavior and get clues. Last weekend I had an epiphany and decided to start the built-in demo song knowing it sends midi data out while playing. I ran a capture on my analyzer just getting bus transactions from 0x0200 to 0x1fff to avoid stack, zero page, and known ram. One of the highest locations of traffic was 0x328 and 0x0321. 328's outbound data in a second specific capture looked -very- convincingly MIDI, so that's been marked as the midi out port. 321 so far seems to be a status register for the uart.

In the next few days I'll experiment with sending data back in with similar analysis tricks to find the data input port.

Knowing the (likely) data out and uart status ports gave me things to search for in Ghidra, and some behaviors I had been seeing are now making sense. I've identified code that ran a checksum on the firmware rom already, but very recently found some utility code for the overall sysex dump routine. Since this is copyrighted code I'm hesitant to post a ghidra screenshot. I'm not looking to fully re-source the machine anyway so that may be moot.

Getting the MIDI UART understood is pretty critical as it will provide a way to communicate with the PSS-480 using custom code. Using some controller change messages to encapsulate ascii traffic could even do it without violating the MIDI standard and allow me to use existing hardware and API's to make a simple terminal and install a machine language debugger on the keyboard itself. That's the overall next step for me, so that I can work my way around the code and more directly experiment with hardware registers to get them mapped out.

I guess I could include a screenshot of my analysis rig showing the midi sequencer dump and the analyzer's recording of 0x0328.

Pardon the odd image size; the analyzers' control unit runs dual 1024x768 displays at the moment and I do the work mostly via a remote desktop solution.

For now, no new exciting pictures. Just more info being gathered and good paths to follow. Thanks to everyone for their interest

[galibert]

Heh, what I tend to do is patch the rom to add sysexes that do write-to-memory, read-from-memory and call a function at an address. From there I can tweak registers and see what happens. Done that to the psr540 and the mu100b.

[jbevren]

Calling and testing via sysex is probably a better idea. I haven't found the sysex receive code yet, but I did find the midi input port, so that's a great start

tl;dr MIDI in is at 0x320. I still need to work out the status and control registers, though I believe I know where they're at.

Attached is a dump of 0x320 during an incoming sysex voice data change.

[jbevren]

The locations of the 7-segment LEDs are located by examining code that presents errors to the user.

Code: Select all

LED display is numbered right to left:

Digit positions by offset
6 5 4   1 0

Not sure if positions 3 and 2 are used anywhere
but they're apparently not on the front panel

Unsure yet what controls the decimal points.

Digit   IO      RAM
pos     loc     loc
7       180a    2007
6       1809    2006
5       1808    2005
4       1807    2004
[3]     1806    2003
[2]     1805    2002
1       1804    2001
0       1803    2000

Code samples are included in images below because I'm lazy

[jbevren]

Hey all,

Pardon the radio silence. It's been deep code dive mode the last few sessions and that leaves me quiet

In working through the midi input processor I identified the buffer used to store incoming data and then process it. Interesting useless note, the PSS-480 will only sound notes from 24 to 109. 24 is C0, 109 is up there in octave 8. Reasonable range

The code is getting more intricate as I'm working through note tracking software. I just identified code that searches tables for an available voice for sounding an incoming midi note event, handily identified by the 'ful ch' error routine being called before exit if a note slot isn't found.

No shots this time, just posting while I'm taking a brain break

Getting closer to actually sounding a note using the hardware in code bit by bit, and it's getting a bit exciting as more hardware's hopefully going to be discovered. When the code that sounds notes is identified the sysex data and register locations can be correlated. That will help determine if the FM core in this OPU is a match for any IC's out there already, or if an IC of superior capability could be used as a substitute.

No ghidra screenshot, it'll just look similar to the others as they're also processing tables, mostly

-jbev

[jbevren]

Spare time this weekend was largely fixing broken references in Ghidra. I'm entirely inexperienced in using overlays with Ghidra, so calls to the banked ROM area simply don't get properly linked in the disassemblies. This results in areas not being disassembled in the banked area and not cross-referenced in the IO spaces.

This feels like it's largely fixed and a huge majority of accesses to what I suspect is the FM hardware is done through a pair of routines that waits for a flag to clear at 0x200; bit 7 before proceeding. This is hardcoded in the current skeleton code to return values that allows the code to run.

Progress is slow, more later

-jbev

[galibert]

Yamaha hardware of that time stored register values as rotating shift registers, where on every internal cycle all values move one step into the next register. Not only it uses roughly one third less transistors that a traditional static ram bit, but it gets rid of the address decoding entirely. There is only a kind of a global counter that allows to know where you are in all the internal memories.

In each of those rotating buffers there's one place to read the data and one to write a new value. Reading is a beauty, everything is synchronized so that each internal circuit recieves the value it needs at the exact time it needs it. Writing is slow though, because you have to wait until the rotation is on the right step to write the new value in the correct place. That means writing is potentially slow, and the timing is kinda unpredictable. To allow for that Yamaha used one of two methods: either document the write timing with the most pessimist value possible, and say that results are unpredictable if the timing is not followed, or provide a busy flag to say that the write is not done yet. Pretty sure your bit 7 is the busy flag.

[jbevren]

That's great info, thanks a bunch!

I'm not at all familiar with FM chips so notes like these will be very helpful, especially when the FM hardware in question is entirely undocumented

In other news, I did scan and stitch the PSS-480 schematic. I'm unsure if posting it would be in violation of any rules so I'll hold for now. At some point I'd like to do a full scan of the service manual I have since the pdf in the wild isn't very high quality.

I also have the PSR-16 SM and schematic at this time.