ympsr16: pss480 reverse engineering effort

[jbevren]

Considering galibert's info, I'm believing that the FM hardware is present at a base address of 0x200. I've attached a screenshot of a bit of code run during reset that presets some variables and other hardware before entering the main loop.

Galibert, does this seem to line up with the addressing behavior you noted?

FM_write does a bit of software delay for 6 NOP's (12 cycles; 4.8us) before beginning a polling operation to wait for the hardware to become ready for the transaction. Once the 'busy' bit clears the data is sent to 0x200.

This feels like it's a slow bus device that is polled with software. At first I was thinking it would have been smarter for it to use the 65c02 core's RDY input to stall the CPU, but there's other code that polls the busy bit and returns if it's set for events that have to be closer to real-time.

Also, some more code references have been fixed. For The Moment(TM) there aren't any invalid jumps, which will help identify base addresses of data tables in the ram, as well as IO device usage by routines in the firmware.

Looks like this coming week will be spent researching the YM series FM chips to search for commonalities with this type of behavior. Thankfully there's tons of examples in the wild, some even on the Commodore 64 in case I need a similar CPU.

-jbev

[galibert]

Posting schematics, especially for old-enough-to-vote hardware, is not a problem. It's roms that are frowned upon in general.

[jbevren]

Thanks for the info. The schematic for the pss480 is attached. I also have schematics for the psr-16 and psr-36 at this point, but I haven't scanned and stitched them. Anyone know of a chain that can scan big sheets of paper in one go?

Interestingly, the psr-36 has stereo outputs from the OPU to the final output path using the CHA and CHB outputs while the PSS-480 uses the TB output for mono. It may be interesting to dig into that machine's code later.

So far I'm still working on the code segment at ca59. It's responsible for translating some of the the sysex format patch data and sending it to a routine that writes to the FM hardware's memory area. There's a lot of shell game going on in the code segment so it's not yet fully understood. This bit may take some extra time but it will need to be fully understood before the FM registers related to it can be mapped.

The ROM patches are stored in sysex format it seems, though all the shellgame work has me confused as to whether theyre interleaved or in linear format. More on all of this later.

The maintainer for ympsr16 may find the schematic handy as it specifically shows how the front panel, keyboard, and led displays are connected.

-jbev

[galibert]

A useful method is also to whip up everything you currently have in a driver, then send sysexes to mame and see what happens to the registers. You can even use the debugger to trace how the bytes move around.

[jbevren]

Just letting everyone know I'm still around. Real Life(TM) stuff has kept me off this for a bit while we transition things here to winter mode.

Still digging in the RYP7 code. Have a screenshot of what compilers do when not properly told how to optimize code. The system changes ROM bank, gets 3 bytes of data, puts them on the stack, pulls them back off the stack, stores them in zero page, and then sets the ROM bank back to normal.

ps: I'm 4 nine's positive that the ryp7 is at $1000-1003. That's all the devices located; now it's time to really dig into the literal bits and figure registers out in detail.

[jbevren]

I wanted to let everyone know I was still around and -then- saw galibert's response.

That's a pretty good idea in fact. I'll have to see what I can do about midi interrupts since the whole program is event-driven. There's got to be a timer interrupt in there somewhere as well but it should be mostly functional without the timer I think, and just triggering an irq in the way the code expects without pre-config Should(TM) be enough to make midi input work.

Now to take a crash course in writing dummy drivers and debugger use.

-jbev

[jbevren]

Taking more looks at the binary code again these days. It took an epiphany to realize why the pcm drum code was accepting program change; now I know how to change the auto-accompaniment via MIDI

I'm up to simulating code on another computer how to fully understand the bit shifting for the actual hardware. That will come as time permits, which has been relatively thin these days.

Still, there's some impressive mix of assembler and compiled code going on. Anyone know what 65c02 development platforms were around in the mid to late 1980s?

Attached is a semi-random shot of current work. This is part of some code that sets what I suspect are several indexes for the auto accompaniment and rhythm during a MIDI channel 15 program change event. Since this has to be pulled from 'far memory' aka banked ROM space, a function dedicated to the purpose was made. There are several of these that fetch different data types. This one is so far the most complex I've tackled.

-jbev