OK so I captured the output from PT4DOS (DOSBox SVN) and the PT2 clone, and I can't hear anything being off in the pitch in the very beginning of "back again.mod":
https://16-bits.org/etc/pt4dos_then_pt2clone.flac (warning: very loud!)

I think you either use an emulator that is not precise for SB16 at 45454.54Hz, or you are hearing an absolutely tiny pitch difference that 99.9% of people won't hear. Feel free to record the output of the emulator you use, as well.

8bitbubsy wrote on 2023-07-10, 13:11:

BTW, comparing to FT2 makes no sense, as FT2 doesn't have the same middle-C tuning as ProTracker. ProTracker is more like A4=~436Hz, while FT2 is closer to 440Hz.

Uhh, good point!

I'll test this out properly later in the week and get back to you. I'll use a known-good reference point, then compare everything else to that. PT 1.2B/2.3D in WinUAE should be definitive (too lazy to wire up my real A500 for recording, and I trust WinUAE is 100% accurate when it comes to pitch).

Did you listen to the clip, though? It sounds exactly the same as the PT2 clone, and the PT2 clone sounds the same as real PT1.x/2.x on Amiga.
Do note that PT1.x/2.x requires you to set the "DMAWait" value in the SETUP screen to 9999 (max) if you don't use a cycle-accurate A500 emulator configuration.

8bitbubsy wrote on 2023-07-11, 11:40:

Did you listen to the clip, though? It sounds exactly the same as the PT2 clone, and the PT2 clone sounds the same as real PT1.x/2.x on Amiga.

Yep, I've just listened to it now and indeed, it's in perfect tune with your PT2 clone.

It's also in perfect tune with the 'sbpro1' and 'sb2' models in DOSBox Staging; the tuning problem manifests only when 'sb16' is selected. Well, that's my default, so I haven't played with the other SB types until now...

But in DOSBox-X it's in tune with 'sb16' too, which indicates that either Staging or X is wrong 😀 Needs further investigation, and I'll definitely get to the bottom of it, as I don't want our 'sb16' model in Staging to be out of tune (if it's our code at fault and it's not *supposed* to be out of tune a bit compared to the other SB models... I guess that's also a possibility).

Anyway, it seems that your PT4DOS doesn't have tuning problems. The reason I did not want to let it go that easily is to figure out whether PT4DOS is the problem or something in Staging, because if the latter, I need to fix it 😀 A recording of the output with the 'sb16' model is attached anyway, if you're interested.

Apparently all other replayers are out of tune then, because the relative tuning difference is there... So yeah, it was a bit confusing.

8bitbubsy wrote on 2023-07-11, 11:40:

Do note that PT1.x/2.x requires you to set the "DMAWait" value in the SETUP screen to 9999 (max) if you don't use a cycle-accurate A500 emulator configuration.

Interesting, I know nothing about such things as I'm only using the cycle-accurate option 😀

Hm yeah, the pitch is some cents low in your recording. I can only assume it's because of the SB16 emulation.

Reporting some actual issues now about the clones 😀

1) Both the PT2 and the FT2 clone have mouse problems in fullscreen mode on my M1 MacBook with Retina screen (3456 × 2234). The coordinates seem to be offset a bit; e.g. if I click on "DISK OP." when in fullscreen, that toggles the scopes, unless I'm clicking on the top ~20% of the button.

So either your programs don't handle high DPI entirely correctly, or this is yet another bug in SDL2. Their high DPI support is still not perfect, we reported quite a few high DPI handling issues to them over the past year, e.g. this is one of the latest ones:
https://github.com/libsdl-org/SDL/issues/7855

Not sure if you're aware of this, but the common theme in these issues is that high DPI handling is inconsistent across platforms. E.g. they fixed the above issue quickly, but without the fix we'd have to resort to some platform specific #ifdefs. So whatever you do to fix it, ideally you want to test fullscreen mode on all platforms.

2) Not a bug, but a usability/documentation issue. I had to spend about 15 minutes figuring out how to configure the PT2 clone via the .ini file, and I'm a coder 😀 So here are some suggestions on how to improve this for regular people as I'm sure it will trip many people up:

• In README.md, the macOS notes section only says this: "To get the config file to load, protracker.ini has to be in the same directory as the .app (program) itself". No mentioning of where this file can be found. You mention it in the Linux notes section, but I did not even read that first as I'm not using Linux (which is reasonable). So the macOS notes section should have all relevant info in a self-contained manner.
• Most people (like me) will put the app into /Applications, so you need to spell this out to macOS users because it's highly unusal: you need to put protracker.ini into /Applications if PT2 clone is there. But it would be a lot better to store this in "~/Library/Application Support/PT2 Clone" or something, just like your FT2 clone does (and document it).
• In the distribution ZIP downloadable from your website, although the .ini file is included, it's not described in the help.txt where to put it. You should simply copy the (improved) OS-specific instructions from the README.md there.
• Lastly, it would be best to put an actual link to protracker.ini in the README.md as opposed to describing where to find it.

3) Finally, managed to configure 3x scaling in windowed mode because the defaults are tiny on my Retina screen. But it was a bumpy ride because you're parsing *some* ini properties in a case-insensitive manner, but others are case-sensitive. Here's how it went:

• First I tried "FULLSCREEN=true", that worked.
• Let's try "PIXELFILTER=linear" next. Okay, that works too.
• Now let's do "VIDEOSCALE=3x". Hmm, no workie.
• After much trial and error, I realised the X needs to be uppercase... 3X works, but 3x gets ignored...

So at least lowercase (or uppercase) all input in your config parser, but personally I'd lowercase all property names and values in the ini file itself too. That is just a more standard approach.

Ok, found the regression and fixed it 😀 Thanks for your assistance on troubleshooting this!

https://github.com/dosbox-staging/dosbox-staging/pull/2676

The rate is in fact 45454.545454 (repeating), so you should handle the fractional part too.

Rincewind42 wrote on 2023-07-12, 00:20:

1) Both the PT2 and the FT2 clone have mouse problems in fullscreen mode on my M1 MacBook with Retina screen (3456 × 2234). The coordinates seem to be offset a bit; e.g. if I click on "DISK OP." when in fullscreen, that toggles the scopes, unless I'm clicking on the top ~20% of the button.

I've heard another person mention the same, but it works perfectly fine in fullscreen mode (PT2/FT2 clone) on my MacBook Air Retina 13" M1 Late-2020 running latest macOS, and also on my MacBook Pro Retina 13" Early-2013 running macOS Catalina. I tested the very edges of buttons, and the coordinates are perfect. Also tried to stretch the image out in fullscreen mode, still works. Also tried different scaling settings in macOS (larger text/more space). As I don't have the issue myself, I don't know how to start debugging it.

Rincewind42 wrote on 2023-07-12, 00:20:

2) Not a bug, but a usability/documentation issue. I had to spend about 15 minutes figuring out how to configure the PT2 clone via the .ini file, and I'm a coder 😀 So here are some suggestions on how to improve this for regular people as I'm sure it will trip many people up:

Ok. These are hobby projects done by ONE person. If you have the energy to perfectionize your one-man projects, then good for you. This software is also completely free, so if spending 15 minutes configuring it is too much to pay, then all I can say is that my projects feel like a waste of time.

protracker.ini is located next to the .app in the release zip... And I'm perfectly aware that the de-facto standard is to have the config in the folder you mentioned.
The reason I want to have it in the same folder as the .app is because the only way to change the config in the PT2 clone, is to edit protracker.ini. Many people don't even know about that config folder you're talking about, and as such it would be even harder to find it.

Yes, this goes against the ".apps go to the application folder" policy and is impractical in that regard, but this is how it will stay. The program's low 320x256 resolution makes it too messy for having a flexible config screen for editing all of these entries, it's just not worth it. The FT2 clone is following the standards better here.

Rincewind42 wrote on 2023-07-12, 00:20:

3) Finally, managed to configure 3x scaling in windowed mode because the defaults are tiny on my Retina screen. But it was a bumpy ride because you're parsing *some* ini properties in a case-insensitive manner, but others are case-sensitive. Here's how it went:

Yeah, I can fix that. Thanks for mentioning.

What version of the PT2 clone are you using? The latest version defaults to "AUTO", which attempts to set a reasonable upscaling size based on the screen resolution. However, this sometimes result in a lower upscale factor than what is optimal, as it tries to take the dock and stuff into account without knowing its height or if it's present or not. It's a quite naive approach.

Sorry for being grumpy. I just wish I could be completely done with these two projects and move on, but alas... Also, please mention things related to my PT2/FT2 clone in relevant threads next time, or send me PMs. 😀

This thread is about PT4DOS.

8bitbubsy wrote on 2023-07-12, 10:27:

Ok. These are hobby projects done by ONE person. If you have the energy to perfectionize your one-man projects, then good for you. This software is also completely free, so if spending 15 minutes configuring it is too much to pay, then all I can say is that my projects feel like a waste of time.

Oh, I think we have a case of mismatched expectations here. My assumption was that a person who posts an alpha version of his software in a public forum is actively looking for feedback and improvement ideas. Especially if that person seems to be a perfectionist (translating the 68k ASM code of some ancient Amiga tracker into C and x86 ASM is pretty hardcore, and I'm quite happy that someone has finally done it, so congrats again!)

My intention was certainly not to upset you; I was merely giving you detailed, thoughtfully written suggestions I would be very thankful to receive if our roles were reversed. But okay, we're all different, so I will refrain from offering further improvement ideas if that's your wish. It's all good man 😀

Rincewind42 wrote on 2023-07-12, 00:20:

What version of the PT2 clone are you using? The latest version defaults to "AUTO", which attempts to set a reasonable upscaling size based on the screen resolution. However, this sometimes result in a lower upscale factor than what is optimal, as it tries to take the dock and stuff into account without knowing its height or if it's present or not. It's a quite naive approach.

Latest version from your website I downloaded yesterday. Yes, the setting was on "AUTO", but that only resulted in 2x scaling. Had to bump it up to 3x so it becomes usable.

Rincewind42 wrote on 2023-07-12, 00:20:

Sorry for being grumpy. I just wish I could be completely done with these two projects and move on, but alas...

Also, please mention things related to my PT2/FT2 clone in relevant threads next time, or send me PMs. 😀
This thread is about PT4DOS.

No problem at all 😀 I'm old and grumpy too, haha 😁 Like I said, mismatched assumptions/expectations on both of our parts 😀

Thanks again for releasing the sources so I can hack in whatever I feel necessary in the future. If you want, I can send you my improvements; if not, I'm fine with that too 😀

I found a few small bugs in the FT2 clones, I will report those in the FT2 thread then.

Have a nice one! 😀

Don't get me wrong, I do want to know about bugs and all of that, but this thread is about PT4DOS (MS-DOS), not the PT2 clone (Windows/macOS/Linux). It's mostly the talk about lacking documentation that I don't have the energy to deal with, I'm not good with writing documentation and guides.

8bitbubsy wrote on 2023-07-12, 12:27:

Don't get me wrong, I do want to know about bugs and all of that, but this thread is about PT4DOS (MS-DOS), not the PT2 clone (Windows/macOS/Linux). It's mostly the talk about lacking documentation that I don't have the energy to deal with, I'm not good with writing documentation and guides.

All clear, I'll report only bugs from now and in their respective threads 👍 (I'm quite liberal with "forum usage", haha 😀 )

8bitbubsy wrote on 2022-06-17, 21:31:

I'm trying to port ProTracker to MS-DOS (386+, Sound Blaster 2.0/ Pro / 16). This is just a proof of concept for now, so the onl […]
Show full quote

I'm trying to port ProTracker to MS-DOS (386+, Sound Blaster 2.0/ Pro / 16).
This is just a proof of concept for now, so the only thing that works is to load a module through Disk Op, then press Play or Stop (or change the BPM).

It won't be "just another .MOD player" though, as the goal here is playback accuracy. I've ported the ProTracker replayer from 68k asm to i386 asm, and I've written a Paula (Amiga sound chip) i386 assembler mixer that kinda works like Paula in the way it handles looping and register updating (DAT/LEN). I don't think there's a single ProTracker player for MS-DOS that does "live sample-swapping" correctly, but this one does. This tecnique was used in several chiptune-styled .MODs to simulate SID PWM. The swapping shouldn't happen instantly (many players do this, it's wrong), but rather at the next "sample end" point inside the mixer.

The mixer runs at 43.5kHz (SB 2.0/Pro) or 45.5kHz (SB16). 16-bit mixing, 8-bit/16-bit output, no resampling interpolation.

Minimum system requirements:
- Intel 386SX processor @ 25MHz (486 recommended)
- At least 2MB RAM
- Sound Blaster 2.0 / Pro / 16 (earlier SB cards not supported, output rate must be >32kHz)
- NOTE: Audio might have occasional buffering issues under DOSBox

A 486+ w/ SB16 is going to give the best experience and sound quality.

Download: https://16-bits.org/etc/pt4dos.zip
Source code: https://16-bits.org/etc/pt4dos_src.zip (tabsize = 8 for the .asm files)

I try ussing this DOS tracker in a TV BOX emulated with Emuelec ussing DOS emulator, and work very fine than another more heavy trackers as impulse tracke or fast tracker, we need make a Arm version of this for ussing in Rasphberry pi , Banana pi or TV Box arm hardware

I updated PT4DOS today, and these are the following changes since the last post:
1) PT4DOS no longer crashes under Windows 9x when trying to play a song
2) Added stereo separation control if using Sound Blaster 16 (check readme.txt). Now mixes in stereo. Default separation is 20% (comfortable when using headphones)
3) The "LED" filter has been removed, but you can now toggle the audio mode between Amiga 1200 (default, no filter) and Amiga 500 (4.421kHz low-pass). Check readme.txt
4) Mouse cursor is now slightly taller
5) Sampler screen has been implemented, but for now the only thing it can do is to draw the current sample's waveform and playback position
6) Several bugfixes/crashfixes

Download: https://16-bits.org/etc/pt4dos.zip
Source code: https://16-bits.org/etc/pt4dos_src.zip (tabsize = 8 for the .asm files)

Fixed no audio + crashes on some systems.

Download: https://16-bits.org/etc/pt4dos.zip
Source code: https://16-bits.org/etc/pt4dos_src.zip

Thanks for the new version.

May you instead possibly provide an uncompressed binary, or compress it with UPX instead of DOS32/A compressor? The DOS/32A compressor is very inefficient, and binaries created with it are unable to be decompressed. Compressing with UPX instead will get the binary size down to ~85 kb instead of 105 kb. (Unfortunately, I don't have the toolchain necessary to re-compile this on my DOS machine to create an uncompressed binary). Your previous versions of PT4DOS were released uncompressed.

And, incidentally, are there any special hardware tricks you're using to detect the presence of a SB16? Blasphemous, I know, but I've been trying to run PT4DOS on a modern system in baremetal DOS with an Intel HDA onboard audio with SBEMU and VSBHDA. Everything's set up properly, BLASTER= variable set, etc, yet PT4DOS says it can't detect a sound blaster card. It would be very nice to use this best and most authentic .MOD player on modern machines without ISA cards and via the SBEMU emulation interface. Perhaps allow us to override your disabling sound output if it thinks no real Sound Blaster is detected, since it might just work with the SBEMU emulator running after all.

Thanks for the constructive input!

I have replaced the compressor with upx now.

As for SB detection, I do it like most other programs:
1) Reset the DSP by sending a 1 to the reset port, then wait at least 3µs before sending a 0 to the reset port again
2) Read a byte from the DSP "read data" port (when it's ready). If the byte is 0xAA, then a Sound Blaster sound card has been successfully detected

However, I just found out that the Sound Blaster programming guide suggest you try to do step 2) a lot of times until you give up, instead of just once. I doubt this fixes your issue, but I have rewritten it to be like that now and included a new PT4DOS version below.Do you have the same sound card detect problem with FT2, btw?

Download: https://16-bits.org/etc/pt4dos.zip
Source code: https://16-bits.org/etc/pt4dos_src.zip

8bitbubsy wrote on 2025-01-28, 12:16:

Thanks for the constructive input! […]
Show full quote

Thanks for the constructive input!

I have replaced the compressor with upx now.

As for SB detection, I do it like most other programs:
1) Reset the DSP by sending a 1 to the reset port, then wait at least 3µs before sending a 0 to the reset port again
2) Read a byte from the DSP "read data" port (when it's ready). If the byte is 0xAA, then a Sound Blaster sound card has been successfully detected

However, I just found out that the Sound Blaster programming guide suggest you try to do step 2) a lot of times until you give up, instead of just once. I doubt this fixes your issue, but I have rewritten it to be like that now and included a new PT4DOS version below.Do you have the same sound card detect problem with FT2, btw.

Great news! I got it working (with caveats) because of your changes. I had to destub and replace the DOS32A extender entirely with either D3X or the ancient DOS4GW 1.97. When either of these extenders was stubbed into the linear executable of PT4DOS and all other things were equal (SBEMU loaded as above) ,and I specified on the command line a .MOD to play, it worked and played the module perfectly. However whenever I moved the mouse pointer, the program crashed with an exception 0D. I was unable to open a .MOD via your file menu, immediate crash (Exception 0D).

It may have something to do with my "modern" system (i5-8250 with trackpad mouse via CTMOUSE in DOS, no serial mouse or serial ports in the system). NB: I got further with the DOS4GW extender than with the D3X extender. With DOS4GW, I could actually move the mouse pointer and do a few things before it crashed. None of this was possible with DOS32A extender; crashed without playing anything).

Implementing your step 2 above re: detecting Soundblaster seems to have fixed the detection problem I was having. (In all previous PT4DOS versions, restubbing with D3X and / or DOS4GW results in an immediate crash even when specifying the .MOD on the command line as above with no sound output, but no error message about SB being disabled by the program, either).

So, next question: are there keyboard equivalents which may be used in lieu of the mouse? This would possibly obviate the crash during .MOD playing, at least in my case. Pressing keys does NOT crash the program, but I don't know if you're polling for keypresses at all. Just a guess, but there's some sort of incompatibility with mouse polling and / or memory management, at least in my very "overpowered" modern system.

As to your FT2 program, I downloaded v. 2.13 and under the same setup as above (i5 8250 cpu, with SBEMU loaded), it doesn't detect SBEMU as a valid Sound Blaster, with SB variable set, etc. Just outputs silence, but the .XM module "plays" fine from the command line, the mouse can be moved (mouse enabled as above with CTMOUSE v 2.0), settings can be altered, etc. SB can't be selected from the setup, just refuses to see it. PC speaker works perfectly, though! No crashes at all, even with SBEMU loaded while running your FT2 2.13. I'm not sure which DOS extender you're using for that program, however. I couldn't destub it and put in either D3X or DOS4GW.exe to try that angle.

Just a guess, but might a change (recompilation) of FT2 2.13 to the same method as you just applied (your #2 above) for its SB detection also magically enable it to work with SBEMU as well? Worth a try for "modern" systems and getting it working via "modern" soundcards like Intel HDA, AC97, etc. via SBEMU / VSBHDA Soundblaster emulation.

No, there are no keyboard shortcuts to use for loading modules in DIsk Op. with PT4DOS, however you can pass a module to the command line parameter to play it that way.
FT2 uses Triton's own DOS extender. It also has proper SB detection code already, so I think the problem lies elsewhere.

Great work! However, I have a query - when I run pt4dos.exe from a shortcut on the desktop or from the start menu (win98se), a message appears:
"WARNING: Couldn't detect a Sound Blaster sound card! If you really have a Sound Blaster card installed, make sure its drivers are properly installed.
Press any key to continue with no sound..."
On the other hand, when I run the pt4dos.exe program from Windows Commander everything works fine. My card is an AWE64 CT 4520.