FreddyV wrote on 2020-05-28, 08:29:

I had debate with some peoples in facebook group, and even in my association with Amiga Fan telling that putting an SB16 or GUS in an XT is not normal.

"Normal" needs more definition. Putting a Sound Blaster/2.0 in an XT is perfectly normal. They are 8-bit ISA cards, after all.

Putting an SB16 or a GUS in an XT, while technically possible, is not typical. Both cards were intended to be used with software that, itself, required a 286 or higher. They were definitely intended for use with 16-bit DMA transfers. The fact that they still work with 8-bit DMA transfers in some modes (SB16) or can use ports to transfer samples instead of DMA (GUS) is a happy accident, but it is neither typical nor intended.

I'm of the mindset that as long as the host hardware, or the card hardware, doesn't need to be physically modified in order to get them both working together, then it's completely fair to do so. If you have to do a hardware mod to downgrade a board, or make a board more compatible, then no, that's neither "fair" nor "normal".

This new B19 still doesn't mute .dro files at the end. Other files are ok.
Soundcard is CMI8330 on 286 CPU, and AZT2316/YMF718 on 486 CPU.
On 486 CTRL+ALT+DELETE helps, on 286 only hard reset, or power toggle.
Dosbox is ok, I observed this behavior only on real hardware.

Also .dro player routine seems to be CPU speed sensitive. On DX4/100 sometimes random channels doesn't sound. De-turbo helps.

If you are working on other adlib formats, maybe .d00/.d01 will be possible ? (Edlib editor).

zyga64 wrote on 2020-05-28, 22:15:

This new B19 still doesn't mute .dro files at the end. Other files are ok. Soundcard is CMI8330 on 286 CPU, and AZT2316/YMF718 o […]
Show full quote

This new B19 still doesn't mute .dro files at the end. Other files are ok.
Soundcard is CMI8330 on 286 CPU, and AZT2316/YMF718 on 486 CPU.
On 486 CTRL+ALT+DELETE helps, on 286 only hard reset, or power toggle.
Dosbox is ok, I observed this behavior only on real hardware.

Also .dro player routine seems to be CPU speed sensitive. On DX4/100 sometimes random channels doesn't sound. De-turbo helps.

If you are working on other adlib formats, maybe .d00/.d01 will be possible ? (Edlib editor).

I did not test on real hardware, I do the things too fast 😀 Will check tomorrow

FreddyV wrote on 2020-05-28, 08:29:

I had debate with some peoples in facebook group, and even in my association with Amiga Fan telling that putting an SB16 or GUS in an XT is not normal.

Amiga people are weird anyway..

Amiga People also put FPGA Stuff inside their Machines.
I have seen much more Amiga`s with modern "Turbo Cards" and Insane Amounts of RAM then any kind of XT Computer can get at all. Or even RTG Graphics with HDMI Output 😳

And Amiga became extinct.. for Reason.
Its a gameconsole with keyboard on it.
Hence that Custom ICs are like the ones in a Arcade Cabinet 😁

The new revision I did is still bugged, I confirm (Just tested)
I corrected it for real, but need to test one more time.

Here it is, it is corrected for real

Wow ! Just WOW !
I can confirm that now DRO files are played back perfectly fine on the "real thing". That was very fast !
Without a doubt this is the best module player for 16 bit PCs !

Is it better on 486 ?

I would say It is better but not ideal. Still slowing it down results in more faithful playback.

Full speed dx4/100 - speed test - 250'161
De-turbo dx4/100 - speed test - 33'129

adtrack2_004.dro - dx4 fullspeed mp3
adtrack2_004.dro - dx4 de-turbo mp3

onward_n.dro - dx4 fullspeed mp3
onward_n.dro - dx4 de-turbo mp3

Motherboard is Intel Classic PCI Ninja, CPU is Intel DX4 100, Soundcard is Yamaha YMF718.

286/20 with CMI8330 is OK.

FreddyV wrote on 2020-05-28, 07:47:

By the way I am also looking for more files, for examples, I don't know if somebody recorded games music in .DRO format.
I found lot of .RAW in another Vogon thread.

There are number of Adlib Files (archived from MELCOM chiptune archive) here: https://archive.org/details/chiptunes-back2roots-2005-02-05

Hi,

Here is what I am working on

As I don't like working in the interface, It did not code a lot these weeks.

I will work on .VGM as it seems to be quite simple as well and it is a way to replay tandy musics quite easily.
also SBVGM is Too slow on 8086 for OPL3 music replay.
I will still use SBVGM for .VGZ and Not supported chip.

Does anybody have a Pascal or assembly code for .gz unpack ? (For .VGZ)

Well, there is paszlib: https://wiki.freepascal.org/paszlib

But that might be overkill. I assume vgz are really .vgm.gz files, so with full gzip header and checksums?

Otherwise you could try to port tinf to Pascal: https://github.com/jibsen/tinf

I really need something to be used directly, and not too big.
I prefer to spend time on something else than this 😀
It surely has the header as 7zip can unpack the vgz.

Also it is a pity that there is no support in .VGM for PC Speaker games.
Somebody modified DOSBox to capture tandy, but the DOSBox team do not integrate it...

We need to think about doing a PC Speaker capture code...

I think then you would need to code your own inflate implementation and add handling of gzip headers...

PC speaker: sounds like a neat thing to do. One could probably even do this with a DOS TSR. Using EMM386 you could intercept writes to the port 0x61 and then count the time since the last write, and dump the time and the frequency written into some array, writing to disk later when the user requests it. Does that make sense...?

root42 wrote on 2020-06-17, 12:46:

PC speaker: sounds like a neat thing to do. One could probably even do this with a DOS TSR. Using EMM386 you could intercept writes to the port 0x61 and then count the time since the last write, and dump the time and the frequency written into some array, writing to disk later when the user requests it. Does that make sense...?

Yes this is what I think about, Like RDOS

FreddyV wrote on 2020-06-17, 13:19:

root42 wrote on 2020-06-17, 12:46:

PC speaker: sounds like a neat thing to do. One could probably even do this with a DOS TSR. Using EMM386 you could intercept writes to the port 0x61 and then count the time since the last write, and dump the time and the frequency written into some array, writing to disk later when the user requests it. Does that make sense...?

Yes this is what I think about, Like RDOS.

We can propose an extension to the .VGM Format anway..

Hi.
I am still Alive but had less time these days. I corrected the MDA display and added monochrome autodetection as I was playing with my sinclair PC200. I publisher a small video on twitter.

By the way you can follow me on twitter 😀

https://twitter.com/FreddyVETELE/status/12747 … 6572983297?s=19

My priority are still OPLLPT and vgm files.
Then Tandy musics

Hi,

Just started the VGM Code.
I hope to finish the VGM replay end of next week, at least for OPL2 and OPL3.

SBVGM is not able to play DOOM music on the PC1640 (Too Slow), and Mod Master has volume and pitch bars, that is why I would like to add it.

I am also looking forward to play tandy music on other sound cards (SB, OPL3...) that is also not done by SBVGM.

The goal is to play as much music as possible using only an OPL3 SB Card.

Nice. I just tested ModMaster on the 286 with GUS PnP. Works great!

Could someone maybe try Introspection by Necros on their MODM? My b20 Version sounds totally off in the middle of pattern 11 and 12.

Also: on tracks like Satellite One from Purple Motion (and also others), it's not looping as expected. Is there any setting I am missing?