superfury wrote:

Should I use the mentioned software to play them (the 8088 one)?

You should use any software that correctly plays HSC files. HSC Tracker by Electronic Rats has bugs. I don't know "The 8088 one" will play it without bugs.

Electronic Genets wrote on 2022-05-27, 16:35:

superfury wrote:

Should I use the mentioned software to play them (the 8088 one)?

You should use any software that correctly plays HSC files. HSC Tracker by Electronic Rats has bugs. I don't know "The 8088 one" will play it without bugs.

It's in the post linked last time (Adlib OPL2 module players that can run on XT (i8088 cpu)), pruopl2.exe - HSC OPL2 Player by Spanish Lords player. Can play modules *.HSC . Usage - pruopl2 <module.HSC> (https://yadi.sk/d/X2_sz8LB3aeC7o)

I've just implemented adlib-only sound logging into my emulator (using the same keyboard shortcut as the Dosbox recording shortcut, but using right control and altgr instead of the left ones).
Although it records samples at the native rate, the playback in UniPCemu is slightly faster (due to the slightly faster playback of the samples in UniPCemu because of the 14318180/288 clock instead of it's rounded down value).

superfury, I will try this player in DosBox and if it works under DosBox I will return informtion about bugs.

Regarding Crystal2.HSC - this player on DosBox plays near correct but at:
0:08 - unnatural rhythm absent in Crystal2.exe - bug synchronised with change of track.*
1:15 - in my emulation and HSC interpretation the short high tones in background are stronger.
1:46 - in my emulation there are no strong volume up in this moment. But I don't know it is DBOPL problem or player (also HSC Player has the same problem). I use other interpretation of Ax, Bx and Cx commands in the HSC format in comparison with adplug. I also doesn't "correct instrument" (probably made intentionally for bad emulators with KSL 1.5dB at "01" instead of "10").

I think author was not in the intention sudden volume change at about 01:46. But. Crystal2.exe demo also does this volume change. This is probably not problem of OPL emulation but HSC interpretaion.

*) To check:
Startup instruments are 00, 01, 02, 03, 04, 05, 06, 07 and 08 for subsequent channels.
The startup speed is 2x INT8 (110ms).
The track is changed after delay after "01" command not directly after "01" command.

PruOPL2.exe and WV-OLD-TITLE-TUNE.HSC:
00:48 - additional note not present in the original. This player has more bugs than HSC Player v1.5 by Electronic Rats.
00:05, 00:12, 00:18, 00:19 - Many of cracks but probably present in original OPL2.

What do you mean with wrong coupling for the modulator and carrier?
It's just the modulator output (assumed +/- 0-2047) times 4.
That times 4 doesn't apply to the rhythm channels though.

Feedback is the averaged of the last two outputs multiplied by 1/32 times the feedback setting(x0 through x32).

Edit: Should it be multiplied at all? Times 1 gives a range of 4096 already?

Edit: Anything lower than x4 gives incorrect sounding results with Megarace's Newsan song (not strongly enough modulated).

Although there's no other conversion going on other than the raw outputs from the LogSin and Exponential tables.
The raw Exponential table output is effectively multiplied by 4 to obtain the modulation to added to the phase.
The only other thing that's added is the feedback mentioned above (this is added without multiplier). The multiplier is set to 32/32 for the rhythm channels using it (forced full according to documentation, as it it was set to the highest settable value always in the feedback register (value 7)).

I've just made note-on to no longer reset the phase generator, leaving it's previous phase intact (it was previously set to 0 when this happened). Is that what you meant?
Edit: Reverted that, as it seems to be incorrect behaviour?

That 8088 player has many bugs. But you also have a problem because that player on DBOPL has no strange noise in crystal2.HSC (at 1:00 - 1:05).
You can compare playback on UniPCEmu and from dosbox (you can record WAV with Ctrl+F6). without rhytm mode the differences with playing at 44100 (dosbox) and UniPCEmu (49716!!!) should by unhearable for adult person.

superfury wrote:

I've just made note-on to no longer reset the phase generator

On KEY-ON (at 0xB0 to 0xB8 registers) you should reset phase generator. On KEY-ON at 0xBD register you should not reset phase generator. Without reset I had strange effect in past.

Changed bit 0x20 from 0 to 1 should reset phase of both operators to 0 (commands 0xB0 - 0xB8)

Electronic Genets wrote on 2022-05-28, 21:16:

That 8088 player has many bugs. But you also have a problem because that player on DBOPL has no strange noise in crystal2.HSC (a […]
Show full quote

That 8088 player has many bugs. But you also have a problem because that player on DBOPL has no strange noise in crystal2.HSC (at 1:00 - 1:05).
You can compare playback on UniPCEmu and from dosbox (you can record WAV with Ctrl+F6). without rhytm mode the differences with playing at 44100 (dosbox) and UniPCEmu (49716!!!) should by unhearable for adult person.

superfury wrote:

I've just made note-on to no longer reset the phase generator

On KEY-ON (at 0xB0 to 0xB8 registers) you should reset phase generator. On KEY-ON at 0xBD register you should not reset phase generator. Without reset I had strange effect in past.

Changed bit 0x20 from 0 to 1 should reset phase of both operators to 0 (commands 0xB0 - 0xB8)

It sounds like some buffer ran out during playback or perhaps some cutoff (16-bit overflow)?

superfury wrote:

It sounds like some buffer ran out during playback or perhaps some cutoff (16-bit overflow)?

Do not forget that in Additive Synth mode the output can be greater than 16-bit.

superfury wrote:

The multiplier is set to 32/32 for the rhythm channels using it (forced full according to documentation, as it it was set to the highest settable value always in the feedback register (value 7)).

Can you please quote this documentation? I don't know about any feedback for Rhythm Mode. The feedback is not used in TT, HH, TC and SD. It is used in standard mode only in Bass Drum.

Electronic Genets wrote on 2022-05-28, 21:56:

Do not forget that in Additive Synth mode the output can be greater than 16-bit. […]
Show full quote

superfury wrote:

It sounds like some buffer ran out during playback or perhaps some cutoff (16-bit overflow)?

Do not forget that in Additive Synth mode the output can be greater than 16-bit.

superfury wrote:

The multiplier is set to 32/32 for the rhythm channels using it (forced full according to documentation, as it it was set to the highest settable value always in the feedback register (value 7)).

Can you please quote this documentation? I don't know about any feedback for Rhythm Mode. The feedback is not used in TT, HH, TC and SD. It is used in standard mode only in Bass Drum.

That's documented in the description of the OPL3 rhythm mode in one of the earlier linked threads in one of our two threads ( http://midibox.org/forums/topic/18625-opl3-pe … ssion-mode-map/ ).
The orange and yellow PM -> waveLUT -> feedback is clearly there.
It's explained in more detail in the box to the bottom left of those.
Edit: There is an error probably in UniPCemu there: it's supposed to be pre-AMP and pre-EG, but UniPCemu applies those two first for feedback, which is incorrect?
Edit: Just modified the forced 100% feedback for those rhythm instruments to become taken from a pre-AMP and pre-EG source instead of after those.

superfury wrote:

That's documented in the description of the OPL3 rhythm mode in one of the earlier linked threads in one of our two threads ( ht […]
Show full quote

That's documented in the description of the OPL3 rhythm mode in one of the earlier linked threads in one of our two threads ( http://midibox.org/forums/topic/18625-opl3-pe … ssion-mode-map/ ).
The orange and yellow PM -> waveLUT -> feedback is clearly there.
It's explained in more detail in the box to the bottom left of those.
Edit: There is an error probably in UniPCemu there: it's supposed to be pre-AMP and pre-EG, but UniPCemu applies those two first for feedback, which is incorrect?
Edit: Just modified the forced 100% feedback for those rhythm instruments to become taken from a pre-AMP and pre-EG source instead of after those.

It looks like an error in documentation. The HH and SD are only two instruments in OPL2 with noise generator not feedback generator. I think author thought the noise is generated by "feedback 7" loop but it is not generated in this manner but by XOR and shift right function.

1/* For each cycle */
2if(noise&1) noise^=0x800302;
3noise>>=1;

The noise generator is absent in this documentation...
Mute feedback or oscillator input... looks like no knowledge about the noise generator and real algorithm for HH and SD. There is no feedback (also for TT). The implementation is very ease. Easier than for true FM synthesizer. HH, SD and TC looks like non-FM synthesis with bits and noise operations. The "phase generator" for these instruments works only as counter (source of bits) not as true phase generator...

Superfury, I checked for you my algorithm and DBOPL algorithm and I played test file with Snare Drum that due to the midibox documentation uses feedback. NO, THERE IS NO FIXED FEEDBACK.

1uint16_t hh=(p13>>22);
2uint16_t tmp=0xC0*(hh&0x100) ^ ((noise&1)<<14); 
3/*... here standard code for waveform ... tmp -> waveLUT -> Envelope Generator */

In this case the waveLUT can be reduced, because only three values are possible after it: 0, -1 and 1.

The "fixed feedback" doesn't exist. It is a bug in documentation.

The RAW file you can play with use of RDOSPLAY.EXE application for DOS.

Electronic Genets wrote on 2022-05-31, 19:50:

Superfury, I checked for you my algorithm and DBOPL algorithm and I played test file with Snare Drum that due to the midibox doc […]
Show full quote

Superfury, I checked for you my algorithm and DBOPL algorithm and I played test file with Snare Drum that due to the midibox documentation uses feedback. NO, THERE IS NO FIXED FEEDBACK.

Copy code to clipboard

1uint16_t hh=(p13>>22);
2uint16_t tmp=0xC0*(hh&0x100) ^ ((noise&1)<<14); 
3/*... here standard code for waveform ... tmp -> waveLUT -> Envelope Generator */

In this case the waveLUT can be reduced, because only three values are possible after it: 0, -1 and 1.

The "fixed feedback" doesn't exist. It is a bug in documentation.

The RAW file you can play with use of RDOSPLAY.EXE application for DOS.

I see it sets bit 15&14 only if bit 8 is set in the phase, after which it flips bit 14(always) based on the RNG(XOR)? So that's 4 possibilities in the top bits:
00(RNG&bit8 cleared)=0(0 degrees)
01(RNG set, bit 8 cleared)=0x4000(90 degrees?)
11(RNG cleared, bit 8 set)=-0x4000(270 degrees)
10(RNG and bit 8 set)=-0x8000(180 degrees==0 degrees)
So it would only be 3 possibilities indeed?

Although I don't know the 16-bit range to phase conversion it uses(0-1023).
Or should they just be shifted to bits 8-9?
Is that what should happen?

superfury wrote:

00(RNG&bit8 cleared)=0(0 degrees) 01(RNG set, bit 8 cleared)=0x4000(90 degrees?) 11(RNG cleared, bit 8 set)=-0x4000(270 degrees) […]
Show full quote

00(RNG&bit8 cleared)=0(0 degrees)
01(RNG set, bit 8 cleared)=0x4000(90 degrees?)
11(RNG cleared, bit 8 set)=-0x4000(270 degrees)
10(RNG and bit 8 set)=-0x8000(180 degrees==0 degrees)
So it would only be 3 possibilities indeed?

Although I don't know the 16-bit range to phase conversion it uses(0-1023).
Or should they just be shifted to bits 8-9?
Is that what should happen?

Yes, The 0x4000 in my code means 90 degrees. I don't know what range you use. I use range 0x0000-0xFFFF for angle <0, 2π). If you use range <0,1024) the formula will be

1uint16_t tmp=3*(hh&0x100) ^ ((noise&1)<<8);

Snare drum doesn't use operator 17 phase but only operator 13 phase (p13 in my code). Operators are numbered from 0.
You should not use a "RNG" from documentation if you know the documentation has bugs (for example "fixed feedback" doesn't exist). Treat this unofficial documentation only as a help.

Regarding three states. Yes, 180 degrees you can treat as 0 for snare drum without changes in output.