MobyGamer wrote on 2020-09-24, 00:25:

so if you were trying to "behave" properly, you'd change the rate of INT08 but still put in your 08 handler to call 1Ch at 18.2 Hz, or as close to that rate as you can

IMO, a better approach is for the new IRQ 0 handler to finish by jumping to the BIOS IRQ 0 handler (i.e. chain to it) at the usual ~18.2 Hz rate, dividing a faster rate to decide when to take those finishing jumps. The BIOS handler will then increment the tick counter, call INT 1Ch, and acknowledge the IRQ. Of course the new handler could take over responsibility for incrementing the tick counter and calling INT 1Ch, but I don't see much of a reason to. BTW, if the timer is run at a high rate then it might be a good idea to use mode 2 (rate generator) rather than the usual mode 3 (square wave), because mode 3 has the IRQ line high for only half of the cycle, making it easier to miss servicing the IRQ if the system is slower and spends too much time with interrupts disabled.

ripsaw8080 wrote on 2020-09-24, 03:26:

IMO, a better approach is for the new IRQ 0 handler to finish by jumping to the BIOS IRQ 0 handler (i.e. chain to it) at the usual ~18.2 Hz rate

That's what I implied but did not write explicitly. Yes, chain to the original INT08 at the correct interval and that takes care of both.

Same issues on AM5x86 133Mhz, Headland Chipset, Card at 0C0h.
Also crashes when using TNDLPT when starting playback.

But it works great on Escom Blackmate 33Mhz 386SX/387SX FPU, 2Mb RAM Notebook.
No issues here with TNDLPT.

You can see how mod master play Tandy .vgm here:
https://youtu.be/PKg762dr4kE

I checked your file format. It is quite compkex and it is too much dedicated to the tandy chip. There is few room for improvement.

You use the frequency for reference for portamento and the tandy volume that is in log for volume slide > Too different from the protracker standard we need to rebuils a complete player for it.
Try to convert the partition and effects in my current player may be too longer than redo a full player in assembly.

You should have used a bigger volume range. You will be limitted for volume slide effects. I suppose it is not too late to change it.
I really recommend you to think about it.

The replay of the sierra file format does not seems to be accurate. The larry music sounds strange.
I need to see if it is worse to add this format as well.

Thank you all for testing and feedback!

ripsaw8080 wrote on 2020-09-24, 03:26:

MobyGamer wrote on 2020-09-24, 00:25:

so if you were trying to "behave" properly, you'd change the rate of INT08 but still put in your 08 handler to call 1Ch at 18.2 Hz, or as close to that rate as you can

IMO, a better approach is for the new IRQ 0 handler to finish by jumping to the BIOS IRQ 0 handler (i.e. chain to it) at the usual ~18.2 Hz rate, dividing a faster rate to decide when to take those finishing jumps. The BIOS handler will then increment the tick counter, call INT 1Ch, and acknowledge the IRQ. Of course the new handler could take over responsibility for incrementing the tick counter and calling INT 1Ch, but I don't see much of a reason to. BTW, if the timer is run at a high rate then it might be a good idea to use mode 2 (rate generator) rather than the usual mode 3 (square wave), because mode 3 has the IRQ line high for only half of the cycle, making it easier to miss servicing the IRQ if the system is slower and spends too much time with interrupts disabled.

Thank you for bringing this to my attention. I was unsure about it and had a look at the timing code of SWAG (sourceware archive group). The code used 1Ch..
I have adapted my code accordingly.

Version 1.1 is almost finished!
Everything checked again, cleaned up my code and removed small glitches and the bug Dreamblaster told me about.
Hopefully the nasty bug with the stack overflow is now also fixed.
And I also added some new features and improvements I was missing myself.

And.... The current source code is available at Github since just now!
https://github.com/JKnipperts/TNDY-Tracker

It would be interesting to know whether that thing can be compiled with FreePascal's 8086 backend.

DragonSphere wrote on 2020-09-27, 07:54:

Thank you for bringing this to my attention. I was unsure about it and had a look at the timing code of SWAG (sourceware archive group). The code used 1Ch..
I have adapted my code accordingly.

1  Timing.clock_tick := Timing.clock_tick+round(Timer.Frequency / 18.2065);

Don't do complex math inside a timer interrupt 😀 Calculate complex things outside the interrupt handler, then just refer to them inside the hander. For example:

1  inc(PITCycles,Chan0Counter); {Keep track of how many PIT cycles have gone by}
2  if longrec(PITCycles).hi <> 0 then begin {Did we roll over?  Is it time to call the 18.2Hz BIOS handler?}
3    longrec(PITCycles).hi:=0; {Update our PIT cycles counter}
4    asm pushf end; {simulate an interrupt by pushing flags, then CALLing handler}
5    BIOSTimerHandler; {this will acknowledge the interrupt}
6  end

FreddyV wrote on 2020-09-26, 16:39:

You can see how mod master play Tandy .vgm here: https://youtu.be/PKg762dr4kE […]
Show full quote

You can see how mod master play Tandy .vgm here:
https://youtu.be/PKg762dr4kE

I checked your file format. It is quite compkex and it is too much dedicated to the tandy chip. There is few room for improvement.

You use the frequency for reference for portamento and the tandy volume that is in log for volume slide > Too different from the protracker standard we need to rebuils a complete player for it.
Try to convert the partition and effects in my current player may be too longer than redo a full player in assembly.

You should have used a bigger volume range. You will be limitted for volume slide effects. I suppose it is not too late to change it.
I really recommend you to think about it.

The replay of the sierra file format does not seems to be accurate. The larry music sounds strange.
I need to see if it is worse to add this format as well.

My file format is based on the formats of typical Adlib trackers (Amusic, RAD). And I also used portamento according to the approach of FM trackers (seemed to make more sense as an orientation for a tandy tracker than sample based ones).

That the format is too much tailored to the Tandy sound chip, I don't really see. Only Noise is of course not playable everywhere.
But I agree with you about the volume. Of course it would be great to have more volume levels available for the volume slide. But how can this be done if the chip only supports 15 volume levels and you want to keep the possibility for a slow and steady volume slide? Of course I am willing to change something in my format and tracker if you know a good way to achieve this.

The sierra format should be easy to implement if your Player already supports VGM:
The Sierra format basically consists of raw data for the soundchip and delay values between them.
It is very well explained in the wiki of ScummVM: https://wiki.scummvm.org/index.php/AGI/Specifications/Sound

That the Larry music sounds wrong is due to difficulties converting the timing to a tracker format. One delay in the SND files seems to correspond to about 18 milliseconds and mapping this with a corresponding number of empty rows is not always 100% accurate. Depends on the timing of course. Hence the options to adjust the timing of SND files in my tracker.
With Green Sleeves (Kings Quest) for example, it's not a big problem because there are very long waiting times between notes. But with Larry or Space Quest there are multiple extremely short delays between notes . 110 Hz at speed 2 is a good value to play them (9 ms per tick). I originally had some problems with a speed of 1 (keyboard query failed then) therefore Version 1.0 does not support this setting. I have fixed this issue in the meantime, so in version 1.1. it is possible to use also settings like 55 Hz tempo with speed 1.

Benedikt wrote on 2020-09-27, 10:16:

It would be interesting to know whether that thing can be compiled with FreePascal's 8086 backend.

This should be possible with some minor changes to the code (pointers have to be declared as far/near etc. and I had problems with case statements from TP/BP in the past when I tried Freepascal, this could be a problem here). I will test it on occasion.

MobyGamer wrote on 2020-09-27, 20:30:

Don't do complex math inside a timer interrupt 😀 Calculate complex things outside the interrupt handler, then just refer to them inside the hander.

Good point! Thanks. I will change that in a moment. 😀

DragonSphere wrote on 2020-09-27, 21:00:

My file format is based on the formats of typical Adlib trackers (Amusic, RAD). And I also used portamento according to the appr […]
Show full quote

My file format is based on the formats of typical Adlib trackers (Amusic, RAD). And I also used portamento according to the approach of FM trackers (seemed to make more sense as an orientation for a Tandy tracker than sample based ones).

That the format is too much tailored to the Tandy sound chip, I don't really see. Only Noise is of course not playable everywhere.
But I agree with you about the volume. Of course it would be great to have more volume levels available for the volume slide. But how can this be done if the chip only supports 15 volume levels and you want to keep the possibility for a slow and steady volume slide? Of course I am willing to change something in my format and tracker if you know a good way to achieve this.

That the Larry music sounds wrong is due to difficulties converting the timing to a tracker format.

Hi, I say this about the portamento because you implemented the .MOD file import.

Regarding the volume, you can simply say that a Volume slide of 1 increase or decrease the volume by 0.5 for example.

For the problem of timing, you can also think about adding the Note Delay command, that can help to start a note a little later.

FreddyV wrote on 2020-09-28, 14:03:

Regarding the volume, you can simply say that a Volume slide of 1 increase or decrease the volume by 0.5 for example.

I tried a little bit with it. 0.5 is not optimal, because I can't write a decimal number into the chip register, so the numbers have to be rounded there again. And then 0.5 would be 1 again....
So I need a lower value . 0.2 sounds quite good for me. Then it takes 3 ticks to change the volume audibly (for the slowest slide with parameter 1). This results in a nice smooth slide and takes 75 ticks to go through the whole spectrum from 0-15 (1.5 seconds at tempo 50 and speed 6).
Even 0.1 would have something to it. This would give the possibility of a really slow slide and would be easy to calculate when composing a song.
The disadvantage is that when playing a row with a volume slide effect and parameter 1, there might be no audible change at all. Only several in a row would do the trick. But of course you can adjust this by increasing the speed of the slide.
Should I adjust it accordingly? What do you think?

New Version works on my XT but is a bit slow.
Maybe there is headroom for a bit of optimization.

DragonSphere wrote on 2020-10-01, 13:37:

Should I adjust it accordingly? What do you think?

.MOD Use 64 volume level.
Then, I recommend to have a value close to this, 0.23 : 0.2 is good, and the effect will be close when you import a .MOD

matze79 wrote on 2020-10-03, 21:26:

New Version works on my XT but is a bit slow.
Maybe there is headroom for a bit of optimization.

Matze79, thank you for retesting. I'm very happy that the tracker is now running on your XT, even if it's still a bit too slow.
That it would run too slow I almost expected due to the timing problems in Dosbox at low cycles. I tried a bit of trial and error last night and finally replaced my function to calculate the frequency of a note with a simple table to reduce the CPU load during playback. This already helps a lot in Dosbox.
So the calculation, which was executed in my interrupt vector, was the reason for the runtime error on slower CPUs. Thanks again to MobyGamer for bringing this to my attention!

FreddyV wrote on 2020-10-05, 08:09:

.MOD Use 64 volume level.
Then, I recommend to have a value close to this, 0.23 : 0.2 is good, and the effect will be close when you import a .MOD

Yes, 0.23 sounds good. I will use that value.
It won't sound as clean as a .MOD, because there are still ticks in between where no audible change in volume happens. But I also think, with 0.23 it is as close as you can get with the Tandy-3-voice.

Notice that .MOD Use linear volume, Tandy is doing log volume.

Good news. Yesterday evening I tried again intensively to speed up the playback code. After I had already avoided bigger calculations, I now identified redrawing the current part of the pattern as the biggest additional time consumption during playback.
I solved this with two buffers. The whole pattern is now drawn in memory and only the current part of the pattern is displayed. During playback, whenever a row is played, the corresponding row of the next pattern is written to the second buffer. After row 63 the buffers are swapped.
This is very fast and in Dosbox the tracker on my modern PC now runs absolutely smooth from about 1200 cycles. Before it needed about 4000 cycles. Increasing the cycles does not speed up the playback anymore.
So I guess, problem solved. 😀

FreddyV wrote on 2020-10-07, 08:16:

Notice that .MOD Use linear volume, Tandy is doing log volume.

I'm aware of this and so far I've used the closest matching volume in decibels for the conversion of sample volume and set volume commands.
Fortunately I found a detailed description of the MOD file format, which also contains a table for the 64 volume levels in decibels. And the data sheet of the TI SN76496A contains decibel values for the attenuation values of this chip. But this sounds not always optimal because of the 64 to 15 conversion, so I left the possibility to use the volume directly in the settings of the tracker, just the value from the MOD divided by four for the Tandy chip. Technically of course totally wrong, but sounds better with slides. 😀
There is of course a more perfect and elegant solution, but I think it sounds not bad and when playing MODs on the four tuned chip there are much more inaccuracies. For example, for the tone length I would have to take into account the playing time of the sample from the MOD and possible loop of the sample and so on.

https://www.youtube.com/watch?v=yBhzzm0rVhk

here is it, running on my XT Machine.

DragonSphere wrote on 2020-10-09, 09:17:

This is very fast and in Dosbox the tracker on my modern PC now runs absolutely smooth from about 1200 cycles.

Honestly, it should run fine at 300 cycles. The music playback routine should be running completely in the background, then it doesn't matter how slowly you update the screen.

I'll try to find time to look at the code. I'm sure there's some easy performance optimization to be found.

Hi,

If you redo the full replay in an external .ASM file, I can integrate it in Mod Master 😀
Anyway, it will be worth it if musicians start to use it.

New version of TNDY Tracker released!

Life outside of DOS and retro PCs kept interfering and I unfortunately found little time for this project in the last few months. But now I finally have a new version ready for release!
Version 1.21 contains many improvements and is optimised to run on original Tandy hardware (but requires a memory expansion). Of course, it also runs on faster computers. There are also many new features, such as copy & paste, more intuitive controls, playback of individual rows, transpose options and much more.
I have also written player code in assembler and included it with two sample programs. And there is also a new demo song. So a complete tracker package like in the good old days.

Here is the link to the release on GitHub:
https://github.com/JKnipperts/TNDY-Tracker/re … TNDYTRK_v12.zip

Nice release! Finally another new thing to play with on my TNDLPT!