VOGONS


New versions of Fasttracker 2 for MS-DOS

Topic actions

First post, by 8bitbubsy

User metadata
Rank Member
Rank
Member

I'm making an updated version of FT2 for MS-DOS, having fixed a ton of bugs.
It's based on the FT2.09 code.

Download: https://16-bits.org/other.php

Here's a list of the changes from 2.09 so far:

Changes in v2.10:

  • Removed broken GUS InterWave support, fixes GUS problems
  • Scrollbars are now less frustrating to use
  • Waveform polarity was wrong on scopes and in Smp. Ed.
  • Max audio mixing rate was changed from 44000 to 44100
  • Channel numbers now start at 1 instead of 0
  • WAV loader has been improved and now supports weird files
  • Sample rate tuning (WAV playback freq.) when loading .wav
  • Changed default sample test play note from C-5 to C-4
  • Right mouse button = clear pattern mark
  • The scopes now show their number even while muted
  • Updated (and corrected some parts of) the help text

    Bugfixes to prevent crashes:
  • "Cut Pattern" on pattern lengths of 256/$100 (v2.09)
  • "Morph Sample" could crash FT2 in some cases
  • Editing empty patterns with lengths above 204/$0CC
  • Using XM effect E7x (x >= 4) would freeze FT2 on notes

    General bugfixes:
  • Improper Bxx (position jump) use would mess up the GUI
  • Disk Op: .wav files were accidentally listed in module mode
  • WAV loader now safely rejects non-supported files
  • Properly clamp instrument data on load (prevent GUI mess)
  • "Save Range" didn't support .wav mode
  • Replen should never be set to below 2 when saving as .mod
  • Use register $41 instead of $42 to set output rate on SB16
  • You can now rename FT2.EXE and it will still run properly
  • Fixed bugs with keyboard pattern marking
  • Pattern mark. wasn't clamped when adding/removing chans
  • "Song repeat start" is now cleared during song zapping
  • Nibbles grid was wrongly rendered

Changes in v2.10a:

  • Two small general bugs fixed
  • List WAV files in module mode again (I see why now)
  • Reject loading of WAV files in module mode
  • Refresh the Disk Op. directory after writing song to WAV
  • Fixed some critical bugs with save/load on track/pattern

Changes in v2.10b:

  • SB/SB Pro: Fixed an error in audio rate calculation on some rates (f.ex. 22050Hz stereo or 44100Hz mono)
  • Changed some of the default audio settings

Changes in v2.10c:

  • .MOD/.S3M/.STM import is now improved and bugfixed
  • Improved and bugfixed the .MOD saver
  • Fixed a really old bug with uninitialized values in the sample headers while saving .XMs
  • Fixed sample rates being slighly off when importing .STMs
  • Added some missing keybindings to the help text
  • Removed some unneeded code
  • Removed unused graphics, making the .EXE almost 100kB smaller

Changes in v2.11:

  • Fixed a bug from FT2.10c where setting a sample's loop to "pingpong" would crash the program if "Replen." was zero
  • XFade didn't work correctly on 16-bit pingpong samples and could crash the program
  • Stereo samples from loaded XMs/XIs will no longer be unplayable (but will still only contain the left channel data)
  • .MOD/.S3M/.STM import is yet again improved and bugfixed. Certain 15-sample MOD files may still load incorrectly though
  • Prevent system lock-up when loading very specific S3M files
  • Up/down pushbutton delay has been increased to prevent accidentally skipping too much
  • Fixed a bug with the sampling position line (Smp. Ed.) after a non-looping sample has been played
  • Inserting a key-off in edit mode where "Add." is 0 would cause it to not be displayed until you move the row up/down
  • 44100Hz is now the default mixing frequency
  • The default amp is now 10x (doesn't affect GUS)
  • SB16: Setting the mixing frequency to 44100Hz now gives a true frequency of 45454Hz instead of 41666Hz
  • SB Pro/SB16: Added a config switch to not allow FT2 to modify the SB mixer volumes. Handy for laptops with digital volume controls, where FT2 would reset vol. to 100% at times
  • More small changes not worth of a mention
  • Fix sample loop corruption when loading very specific .MOD files (f.ex. "FARLAND.MOD" - this is a bug I introduced myself, doesn't exist before FT2.11)

Changes in v2.12:

  • Because of a bug in FT2, pattern loop commands will manipulate the row the next pattern will begin at (should be 0). However, this can overflow the number of rows (length) for that pattern and cause out-of-bounds reads. Set to row 0 in this case.
  • Since multiple changes were added to 2.11 after release, I decided to bump up the version number to 2.12 so that people see it's time to update from 2.11

Changes in v2.13:

  • Fixed a possible song redrawing issue when loading a song as a command line parameter
  • Show a warning if GUS went out of sample RAM during song loading, as this can make the tracker unstable
Last edited by 8bitbubsy on 2024-06-14, 15:29. Edited 10 times in total.

386:
- CPU: 386DX-40 (128kB external L1 cache)
- RAM: 8MB (0 waitstates at 40MHz)
- VGA: Diamond SpeedSTAR VGA (ET4000AX 1MB ISA)
- Audio: SB Pro 2.0 + GUS 1MB
- ISA PS/2 mouse card + ISA USB card
- MS-DOS 6.22 + Win 3.1
- MR BIOS

Reply 2 of 143, by root42

User metadata
Rank l33t
Rank
l33t

Nice. Do you have the source to FT2? IIRC it is closed source, right?

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 3 of 143, by 8bitbubsy

User metadata
Rank Member
Rank
Member
Tronix wrote:

Hello, 8bitbubsy.
Thank you for release. Сould you check please Stereo covox (LPT1+LPT2) output bug, i describe there: FastTracker II halted when trying switch output to two COVOX (lpt1+lpt2)

I'll have a quick look in the sources to see if there's anything obvious which makes it hang, but I'm afraid that I can't help you there. I'm not really good with this kind of code, and I don't even have any ability to test LPT1+LPT2 properly.
Keep in mind that accessing both of these will most likely use interrupt 5 and 7, which is almost always in use by the sound card. This mode probably works the best on machines with no sound card installed.

EDIT: Yeah sorry, I can't see anything wrong, also this is kinda complicated low-level code.

root42 wrote:

Nice. Do you have the source to FT2? IIRC it is closed source, right?

Yes I do, and yes it's closed source.

386:
- CPU: 386DX-40 (128kB external L1 cache)
- RAM: 8MB (0 waitstates at 40MHz)
- VGA: Diamond SpeedSTAR VGA (ET4000AX 1MB ISA)
- Audio: SB Pro 2.0 + GUS 1MB
- ISA PS/2 mouse card + ISA USB card
- MS-DOS 6.22 + Win 3.1
- MR BIOS

Reply 4 of 143, by Scali

User metadata
Rank l33t
Rank
l33t
8bitbubsy wrote:

I'll have a quick look in the sources to see if there's anything obvious which makes it hang, but I'm afraid that I can't help you there. I'm not really good with this kind of code, and I don't even have any ability to test LPT1+LPT2 properly.

I could help. I have a bunch of Covox devices, and I should be able to add an MDA card to one of my machines to act as a second LPT.

8bitbubsy wrote:

Keep in mind that accessing both of these will most likely use interrupt 5 and 7, which is almost always in use by the sound card.

You only need to output raw bytes to a Covox, no interrupts are involved (the interrupt is connected to one of the input lines, namely the ACK line at pin 10. Covox is a write-only device, so it never communicates back to the PC at all).

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 5 of 143, by 8bitbubsy

User metadata
Rank Member
Rank
Member

Alright, I see, so it's not an interrupt conflict then. Anyway, I'm not allowed to share the source code, so how would we go from here? Thanks for the offer though.

386:
- CPU: 386DX-40 (128kB external L1 cache)
- RAM: 8MB (0 waitstates at 40MHz)
- VGA: Diamond SpeedSTAR VGA (ET4000AX 1MB ISA)
- Audio: SB Pro 2.0 + GUS 1MB
- ISA PS/2 mouse card + ISA USB card
- MS-DOS 6.22 + Win 3.1
- MR BIOS

Reply 6 of 143, by jxalex

User metadata
Rank Member
Rank
Member

Hello, it seems like dream. IF there will be a new software then why not the new hardware devices too? Look here we are also creating new soundcards.
Is it difficult to get 2 cards at the same time to work (multitrack output!) ? In a work of double GUS?

Or what about the new multitrack card?
After I get the card ready then I can fully provide specifications so it can as well be 3x stereo output, with one IRQ in use, which can be used as routing for different external effect units.
Also there is not so much technical difficulty to add 2 MIDI ports on the new card, as then the data sending will be with 16bit port instead of 8bit port, while status register will be the same.

Current project: DOS ISA soundcard with 24bit/96Khz digital I/O, SB16 compatible switchable.
newly made SB-clone ...with 24bit and AES/EBU... join in development!

Reply 7 of 143, by 8bitbubsy

User metadata
Rank Member
Rank
Member

Because it's not trivial to implement. We're talking low-level hardware interraction through x86 assembler here. I'm not the correct dude for implementing new big things like that.

386:
- CPU: 386DX-40 (128kB external L1 cache)
- RAM: 8MB (0 waitstates at 40MHz)
- VGA: Diamond SpeedSTAR VGA (ET4000AX 1MB ISA)
- Audio: SB Pro 2.0 + GUS 1MB
- ISA PS/2 mouse card + ISA USB card
- MS-DOS 6.22 + Win 3.1
- MR BIOS

Reply 9 of 143, by Scali

User metadata
Rank l33t
Rank
l33t
8bitbubsy wrote:

Alright, I see, so it's not an interrupt conflict then. Anyway, I'm not allowed to share the source code, so how would we go from here? Thanks for the offer though.

Where did you get the code from? From the Triton people themselves? Perhaps they want to share the code with me, being a fellow-scener.

Failing that, I wrote a streaming sample player for Covox a while ago. I wanted to extend it to stereo using two Covoxes. I could finish that, and once it works, we should have a working proof-of-concept for dual-Covox playback.
It should actually be quite trivial: you just output samples via a timer interrupt. Where single Covox just writes one byte to port 378h (or whatever), stereo Covox should write a byte to the left Covox and to the right Covox from a single interrupt. So port 378h and 278h usually (although port 3BCh is also an option, it's what MDA cards use, so my machine will use that).

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 10 of 143, by 8bitbubsy

User metadata
Rank Member
Rank
Member
Scali wrote:

Where did you get the code from? From the Triton people themselves? Perhaps they want to share the code with me, being a fellow-scener.

From Vogue and Mr.H after some long dialogs, convincing them that it would help me with my FT2 clone development. The code I got from them is an incomplete pre-release version of FT2.07, but I re-sourced it back to 2.09 by hand, and the code/data is bit-perfect to that of FT2.09. I already had the 2.09 replayer laying (from kebby/kb), so after injecting that it was only a matter of looking for changes in comparing disassemblies, which made me find out what to rewrite next. Was not a lot of code.

Scali wrote:

Failing that, I wrote a streaming sample player for Covox a while ago. I wanted to extend it to stereo using two Covoxes. I could finish that, and once it works, we should have a working proof-of-concept for dual-Covox playback.
It should actually be quite trivial: you just output samples via a timer interrupt. Where single Covox just writes one byte to port 378h (or whatever), stereo Covox should write a byte to the left Covox and to the right Covox from a single interrupt. So port 378h and 278h usually (although port 3BCh is also an option, it's what MDA cards use, so my machine will use that).

FT2 already has dual-LPT-DAC support in stereo, but as someone said in this thread it seems like it's broken.

386:
- CPU: 386DX-40 (128kB external L1 cache)
- RAM: 8MB (0 waitstates at 40MHz)
- VGA: Diamond SpeedSTAR VGA (ET4000AX 1MB ISA)
- Audio: SB Pro 2.0 + GUS 1MB
- ISA PS/2 mouse card + ISA USB card
- MS-DOS 6.22 + Win 3.1
- MR BIOS

Reply 11 of 143, by jxalex

User metadata
Rank Member
Rank
Member

FT2.10 ... (did I just prayed for this) ? Anyway, thats the best birthday happening ever, however with a one day delay for my 40-th anniversary.

Current project: DOS ISA soundcard with 24bit/96Khz digital I/O, SB16 compatible switchable.
newly made SB-clone ...with 24bit and AES/EBU... join in development!

Reply 12 of 143, by Falcosoft

User metadata
Rank l33t
Rank
l33t

Oh, my... I never expected this could happen. Also I have not noticed your Win32/64 Fasttracker II clone so far. It also works very well, and includes Nibbles 😀

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 13 of 143, by DevanWolf

User metadata
Rank Newbie
Rank
Newbie

Uh, 2.10c already released and you haven't updated this post in a while!

Reply 14 of 143, by 8bitbubsy

User metadata
Rank Member
Rank
Member
DevanWolf wrote:

Uh, 2.10c already released and you haven't updated this post in a while!

Sorry, I simply forgot that I had made this thread after making the new version. Updated.

386:
- CPU: 386DX-40 (128kB external L1 cache)
- RAM: 8MB (0 waitstates at 40MHz)
- VGA: Diamond SpeedSTAR VGA (ET4000AX 1MB ISA)
- Audio: SB Pro 2.0 + GUS 1MB
- ISA PS/2 mouse card + ISA USB card
- MS-DOS 6.22 + Win 3.1
- MR BIOS

Reply 15 of 143, by traffkin

User metadata
Rank Newbie
Rank
Newbie

hi!

i can't express how much i'm appreciated for the support of the FT2! i'm loyal DOS and FT2 user, it is my primary sequencer 😀

the only thing i really, really need is the ability to turn off MIDI Program Change on instrument's MIDI output... is it possible to do in some future update?

thanks again for incredible work!

Reply 16 of 143, by 8bitbubsy

User metadata
Rank Member
Rank
Member

Sorry, but I can't do that. It would require me to make a new "program change disabled" field in the XM instrument headers, and that would be messy and could cause issues with older FT2 versions.
The only thing I could do is to give you a custom FT2.10c version where MIDI out program change is permanently disabled, but I assume that's not what you're looking for...

386:
- CPU: 386DX-40 (128kB external L1 cache)
- RAM: 8MB (0 waitstates at 40MHz)
- VGA: Diamond SpeedSTAR VGA (ET4000AX 1MB ISA)
- Audio: SB Pro 2.0 + GUS 1MB
- ISA PS/2 mouse card + ISA USB card
- MS-DOS 6.22 + Win 3.1
- MR BIOS

Reply 17 of 143, by traffkin

User metadata
Rank Newbie
Rank
Newbie

that's perfect! give me that version please! it would be very helpful! million thanks in advance!!!

otherwise all my external stuff gets crazy and i need to make special empty pattern to have time to get them back to order...

8bitbubsy wrote on 2020-03-26, 11:30:

Sorry, but I can't do that. It would require me to make a new "program change disabled" field in the XM instrument headers, and that would be messy and could cause issues with older FT2 versions.
The only thing I could do is to give you a custom FT2.10c version where MIDI out program change is permanently disabled, but I assume that's not what you're looking for...

Reply 18 of 143, by 8bitbubsy

User metadata
Rank Member
Rank
Member

https://www.dropbox.com/s/ozdpo0oxtz0u3ua/FT2 … DI_PRG.ZIP?dl=1
15:41 EDIT: I did a mistake in the code, I fixed it now.

Let me know if it works, I don't really know what I'm doing since I don't know MIDI stuff very well.
As said before, this will permanently disable the program change on MIDI out, so it's possible that it messes something up by never sending that data.

386:
- CPU: 386DX-40 (128kB external L1 cache)
- RAM: 8MB (0 waitstates at 40MHz)
- VGA: Diamond SpeedSTAR VGA (ET4000AX 1MB ISA)
- Audio: SB Pro 2.0 + GUS 1MB
- ISA PS/2 mouse card + ISA USB card
- MS-DOS 6.22 + Win 3.1
- MR BIOS

Reply 19 of 143, by traffkin

User metadata
Rank Newbie
Rank
Newbie

thanks a lot! will test it tonight 😀

8bitbubsy wrote on 2020-03-26, 14:27:
https://www.dropbox.com/s/ozdpo0oxtz0u3ua/FT2 … DI_PRG.ZIP?dl=1 15:41 EDIT: I did a mistake in the code, I fixed it now. […]
Show full quote

https://www.dropbox.com/s/ozdpo0oxtz0u3ua/FT2 … DI_PRG.ZIP?dl=1
15:41 EDIT: I did a mistake in the code, I fixed it now.

Let me know if it works, I don't really know what I'm doing since I don't know MIDI stuff very well.
As said before, this will permanently disable the program change on MIDI out, so it's possible that it messes something up by never sending that data.