MSU1 Audio Support

[dentnz]

Initial pull request. Work in progress.

• MSU1 AUDIO support only so far - some datafile code is present to handle it gracefully, mostly commented out for now
• EXT bus is used for messaging (audio track selection, sector request, track missing, etc)
• FXPak-compatible MSU1 hacks only - no support for the manifest file now, maybe ever
• Main_MiSTer update also required - separate PR
• Credit to ElectronAsh for his help on overall design, audio summing and volume handling
• Credit to Qwertymodo for his test rom and assistance
• Credit to Near for MSU1. RIP.

[birdybro]

Might want to convert this to a draft, it doesn't currently meet timing requirements.

This may improve however if the framework is updated by sorg and you merge that change into your branch later.

[dentnz]

Might want to convert this to a draft, it doesn't currently meet timing requirements.

This may improve however if the framework is updated by sorg and you merge that change into your branch later.

Not sure if it met timing requirements beforehand. This is using latest framework, so I don't think that would help.

[dentnz]

Might want to convert this to a draft, it doesn't currently meet timing requirements.

I am trying a recompile of the master branch to see if it meets timing constraints. As I said, I didn't think it did the last time I checked. Will report back.

[dentnz]

Might want to convert this to a draft, it doesn't currently meet timing requirements.

This may improve however if the framework is updated by sorg and you merge that change into your branch later.

@birdybro. As I suspected, the core without any MSU1 code (master) also has these timing constraint issues:

Granted, the MSU1 changes would increase timing constraint violations fractionally (and they have according to your screenshot versus mine), but the problems were there prior to my work. Thoughts?

[birdybro]

The current master branch from mister-devel does not have the timing improvements that were done by @wickerwaka so merging won't change anything anyways. EDIT: Oh you meant the current master to compare, got it. :)

Nice catch. The framework for the SNES core should probably be updated first anyways. :)

[dentnz]

I won't step on anyone's toes and leave the framework update to Sorg or Srg320. I also don't have much experience with timing constraint violations and fixing them. That said, I am aware there is a good chance that the MSU1 code could be optimized, and am very open to improvements. Probably some of the internal registers are on the large size. And some of the calculations (division by 4 for example) could be handled bitwise, which may mean less logic on the FPGA. For now though, I am most interested in the overall design and ensuring that it's acceptable. I'll probably work on video/datafile next without that approval. Getting the audio side of the functionality in officially is the most important part as 95 percent of MSU1 content is audio 'enhancement' only anyway.

[sorgelig]

well, since it was hard to check changes i missed one important change which would stop me from merging.
MSU is connected to CPU data input by default without being explicitly selected. Old code used OPENBUS, and it was there not for fun.
Therefore please provide the fix ASAP, so MSU won't be on bus without explicit selection and connect OPENBUS as it was before.

[sorgelig]

one more important fix should be added on both FPGA and HPS sides: if no MSU files are available for current ROM then MSU should be completely shutdown and don't reply even if its registers are selected, so it won't produce bugs in games not expecting MSU registers on bus.

[sorgelig]

I've added MSU enable flag based on availability of pcm files for rom. It fully hides MSU. I don't have MSU ROMs for test, so hope i didn't break anything.

[paulb-nl]

It doesn't seem correct. According to here the MSU registers range from $2000-$2007 so MSU_SEL should be MSU_ENABLE and CA = $2000-$2007 otherwise OPENBUS won't work correctly: http://helmet.kafuka.org/msu1.htm

Also is it correct that MSU_SEL is only set at 96Mbit section?

[sorgelig]

Also is it correct that MSU_SEL is only set at 96Mbit section?

yeah, i had similar question but thought all MSU roms are big to fall into 96mbit range.

My fix was to isolate MSU roms from all others. So i've made sure that MSU is disabled if no CD tracks are found. But how MSU is selected on MSU-enabled ROMs i don't know. It's up to original implementation

[sorgelig]

generally speaking MSU mapper implementation doesn't follow original concept and do selections inside its own module instead of mapper.

[sorgelig]

i've added some tweaks and fixes including better way to enable MSU1.
I found Zelda MSU1 - it doesn't work.. Actually core sends track number in BCD format while Main expects it in plain binary format. Even after change it to BCD it doesn't work. Game requests the same track "million times" and then hangs...

[paulb-nl]

First issue is msu_audio_download is not connected to hps_ext in SNES.sv so it stays 0.

SNES_MiSTer/SNES.sv

Line 1149 in c31e523

hps_ext hps_ext

SNES_MiSTer/rtl/hps_ext.v

Line 39 in c31e523

input msu_audio_download

Second issue is Main doesn't send MSU_AUDIO_TRACKMOUNTED because msu_trackrequest is set to 0 here:
https://github.com/MiSTer-devel/Main_MiSTer/blob/12ea16f024779515cb067998898387692ddd2fa2/support/snes/snes.cpp#L523

Here it checks for msu_trackmounted == 1 && msu_trackrequest == 1:
https://github.com/MiSTer-devel/Main_MiSTer/blob/12ea16f024779515cb067998898387692ddd2fa2/support/snes/snes.cpp#L545

After fixing those I have music in Zelda.

SNES MSU: Track requested
SNES MSU - New track selected: 0x1
SNES MSU - Full MSU track path is: SNES/msu/alttp_msu-1.pcm
Mount SNES/msu/alttp_msu-1.pcm as read-write on 2 slot
SNES MSU - Track mounted
SNES MSU: sending track mounted - 201

Haven't touched anything about BCD format so it doesn't seem to matter.

[paulb-nl]

audio_fifo_dout should be 32 bit now. The right channel stays silent.

SNES_MiSTer/SNES.sv

Line 1245 in c9c1431

wire [15:0] audio_fifo_dout;

[sorgelig]

Making commit before going to sleep probably wasn't good idea :)
I was testing on display with mono speaker.