superctr / mdsdrv Goto Github PK

asm68k originally came from the leaked Psy-Q Sega Saturn SDK and is an old proprietary assembler that has not been maintained in 25 years. It is also Windows-only, although it does work with Wine.

For Windows users I would like an alternative that can be either easily installed or included in the repo.

Currently, MDSDRV uses a few features which may or may not be specific to asm68k, including equr statements and some fancy expressions that might not work in other assemblers.

Suggested alternatives:
https://github.com/asmotor/asmotor - Is free software (GPLv3) and is currently maintained. It has an equs directive which can replace equr. Not sure about Windows support? -> It cannot output listing files, which makes debugging much harder.

When starting a new song (and not completely stopping the previous one before), there is noise generated by the FM channels.

This is caused by the FM envelope generator not being completely muted before loading a new instrument. To fix, either we mute FM channels or set the RR to max on all operators by default after starting a new song

• Support drum mode (note events call a subroutine similar to the pat command)

The following FM features must be implemented:

• Key on and off
• Pitch calculation and write
• Volume calculation and write
• Channel LFO and panning flags
• Global LFO parameters (can be set with the fmreg command)
• FM3 special mode (#13 )
• DAC enable/disable (#4 )

Build a template ROM that can be used by tools to generate a test ROM without needing an assembler to build the sound driver and tester program.

To generate a test ROM, take the template ROM, append a pointer table followed by the mdsbin and mdsseq files.

example pointer table format:

long: "DATA" - magic bytes to determine that a valid table has been appended
long: pointer to sequence data
long: pointer to PCM data
word: song # to auto-play (0 to disable)
word: song count
long: pointer to song 1 title....
long: song 1 length?
long: pointer to song 2 title....
long: song 2 length...

LFO delay can still be supported, and reuse memory from macro tables when the latter is not in use

Since it's annoying to manually insert effects (especially those that alter the state while a note is playing) in MML, a macro table can be used to automatically insert effects while a note is playing.

The macro table could use the same MML command as the pan envelope, alternatively a new event type is added in ctrmml.

The binary format of a macro table is as follows:

commands:
 0x00-0x3f - special commands
 0x40-0x7f - assign variable
 0x80-0xff - delay (frames - 0x7f)

special commands:
 0x00 - end macro table
 0x01 - jump
 0x02 - add to variable
 0x03 - set panning (mask with 0xc0)
 0x04 - set lfo parameters (mask with 0x3f)
 0x05 - write to FM chip common area (fmreg)
 0x06 - write to FM chip, offset to current port/channel (fmcreg)

The variables should map to internal track state, however to preserve backwards-compatibility in future versions, an internal lookup table should be used. The lookup table can also contain a bitmask representing update flags that must be updated.

Macro table should be handled after the instrument update, and before updating volume. Updating instruments through macro tables may not be supported (it would still require extra work in the MML compiler to remap the instruments in each table).

RAM needed (total 4 bytes)

 (w) macro table pointer
 (b) macro table position
 (b) macro table "restart on keyon" flag (bit7)/delay time

the "restart on keyon" flag must be handled by the key on handler (specific for psg/pcm/fm). I will create a macro for this though.

With this I will remove support for LFO delay. This can be implemented using macro table instead.

To make files generated by ctrmml playable on MDSDRV, the generated files must be linked to generate a coherent data bank. This tool will probably be in the ctrmml codebase.

Example: play a song that allocates FM0 for a track, then play another song that allocates PSG1.

Expected result: FM0 should be stopped
Actual result: FM0 is not stopped

A solution can be to always wait one frame before starting a track (or request slot) if another is occupying the track slot.

Currently the 2 channel mixing mode is supported by the 68000 code. First channel is always on track F (track id 5), Second channel should be on track K (track id 10).

Third channel once implemented will use track L (id 11), maybe fallback to use second channel when 2 channel mixing is used.

• Currently I measured the runtime to 10 lines if 4 FM channels are active but not updated
• Trigger priority calculation based on channel allocation/deallocation rather than always doing it on each frame.
• Skip pitch calculation routine when not needed. I think checking a bitmask of the following new flags:
  • pitch envelope active. Set by new note, cleared if pitch envelope is finished or not active.
  • portamento active. Set by new note, cleared if portamento is completed
  • pitch update triggered by new note, dtn or trs commands

Make a function, to convert FM volume (-0.75 db steps) to the PSG/PCM native value (-2db steps) if bit 7 of the track volume is cleared.

This function could also handle accumulating the fadeout and global volume (#5).

Implement support for FM channel 3 mode.

Since the PCM driver is stable for now, it might be time to do this.

Hey,
for better reach of the community, I would like to suggest to add the following topic to the repository: motorola-68000

How to do this

Read vcounter after each buffer run, and during the idle loop.
If there is less than n samples before vblank, set z_min_buffer to the lowest possible value to ensure we don't enter a new buffer run before or at the vblank.

Based on my calculations, we should stop buffering at 28~35 before vblank. The vblank will last for 32~42 samples (NTSC) or 75~100 (PAL V28) or 61~82 (PAL V30).

The vcounter should not be read during vblank as it requires a 68k bus request (and hence, it will cause the Z80 to be halted by the VDP if DMA is in progress)

• Global/track volume modifier and fadeout for each channel. Preferably the levels should be equal between FM and PSG (may need a table to convert global volume values to PSG volumes)

I might consider only supporting fade in/out for the music tracks only. That will save 6 words of RAM for a feature that probably won't be needed.

Global volume can be a single word containing two byte values. One for PSG/PCM attenuated and one for FM. Fade and volume change routine converts FM value to PSG/PCM only once.

It looks like I am writing a Z80 PCM against better advice. The goal of the new Z80 driver is to offload some tasks from the 68k to improve CPU load and smoother PCM playback (=no need to stop Z80 for longer periods of time)

• 68k sends key on/off commands to Z80 Not needed
• 68k sends frequency commands to Z80. Z80 to convert the tone number+fraction to F-num.
• DAC playback

Advanced features (No need to implement, could be nice to have?)

• 68k sends volume commands to Z80. Z80 calculates actual volume given FM parameters?
• 68k sends instrument data to Z80.

Z80 could write instrument data, however it would not be very useful unless a full command queue is implemented. The 68k instrument loading routine is already very tight.

The following PSG features must be implemented:

• Key on and off (using volume envelope)
• Pitch calculation and write
• Volume calculation and write (#14)
• Volume envelope
• Noise frequency mode (with noise taking priority over PSG3 = PSG3 must always be muted if noise is active)

Currently only "native" volume levels are supported. Supporting 7-bit volume won't be done until global volume levels (issue #5) is implemented, as the logic will be depending on that. (And ctrmml does not currently support that either)