RMT Patch 5

[analmux]

Hi,

 

Here's another new RMT patch for those who'd like to do pokey music using the standard 64khz clocking. It is a patch of RMT version 1.27. It is a variation on Patch 4. Now portamento/vibrato/fshift are activated for Distortion 2 @ 1.79MHz.

 

Changes (w.r.t. unpatched RMT 1.27):

 

-Tables freqtabbasslo and freqtabbass2 are swapped. The '16bit dist 6' instrument is now 'bass2 dist E'.

-The patch of freqtabbass2 is for distortion 2 @ 1.79mhz instruments (use on channel 1 OR 3), as an alternative for the standard square waves

-The patch of freqtabbasshi is for the sawtooth wave (use on channel 1 (combined with 3))

 

I removed the problem of filtered voices interfering with '16bit' voices.

 

 

For the musicians:

-C & E basses are still there

-Sawtooth is activated by 'distortion' 4

-Distortion 2 @ 1.79 Mhz is activated by 'distortion' 6 (!Now, AUDCTL bit 6 or 5 must be set manually)

-E bass can only be used on channel 2 or 4!!!

-16bit cannot be used

 

One can find it at: http://www.phys.uu.nl/~bpos/RMTPATCH/

Again a (slightly modified) demo tune is included.

Here, instruments 00 & 01 are again examples of the sawtooth instrument, which can only be used on channel 1. Instruments 0E & 1C are examples of Distortion 2 @ 1.79 MHz instruments, which can be used on channel 1 or 3.

 

 

Have fun

 

...oh, and another note: This is the last RMT patch from my hand...

[analmux]

Here are the main files: This is RMT patch 4 and 5.

 

I removed the files from my ftp space. I temporarily put them there as on PC I couldn't attach the files to a post. On laptop I can attach them.

 

Have fun.

[miker]

A question from booker:

 

Hi Analmux. Too bad you halted your RMT improvements, they were very promising! What I mostly miss is lack of the editor for the pulsewidth defined for the filter. Obviously it would be possible to control it ie. define a different table? Also, would be nice if RMT could play samples. Cheers /booker

 

[analmux]

Hi Analmux. Too bad you halted your RMT improvements, they were very promising! What I mostly miss is lack of the editor for the pulsewidth defined for the filter. Obviously it would be possible to control it ie. define a different table? Also, would be nice if RMT could play samples. Cheers /booker

 

Hi booker,

 

My RMT-hacking was only a matter of doing some patches. I don't have the source code of the RMT tool. Raster has. So, unless I'd be REALLY doing a disassemble hack of the tool, I can't make any real changes. Maybe you could contact him, but I won't do it.

 

I discussed adding filter offset, needed for having a deterministic pulsewave offset, and adding polycounter offset programming once with Raster. However, he was worrying about how to insert the extra commands for offsetting these. So he was worrying about how to keep it backwards compatible with his older RMT versions.

 

To improve RMT untill it supports full pokey usage will give too much problems.

 

So, no real other "improvements" from my side

 

Something like adding digi-instruments I won't do at all.

 

Maybe I could do a better 'retuning' of the 5 already existing hacks, for example do some (least square method) 'best fit' procedures to minimize detuning and rounding. This is for making notation tables, especially the bass tables. However, I won't put anymore time in it.

 

Sorry to say...

[ANTIQ]

If POKEY's playing, is a reset possible without being audible?

[analmux]

If POKEY's playing, is a reset possible without being audible?

If you mean programming the pulsewidth (= wrongly named "high-pass filter") instantaneously, then YES.

 

A routine of a few machine instructions would do. So, pulsewidth can be set during, let's say, 30 CPU cyles. In RMT it's hard to do, because feature isn't really implemented. The trick emkay used many times is a second hand solution. It uses commands during two frames. During the first frame one tries to minimize the timing difference between voice 1 & 3 (or 2 & 4), by putting a highest pitch on both channels, but in a silent (volume = 1) mode. During the second frame one tries to let the two channels walk out of phase, for a desired amount. But, there's too much instability going on then. It's not completely deterministic.

 

Direct programming would solve this. Any new tracker should make use of this direct pulsewidth programming. Another problem might be difference between pokey emu library and the real machine. So, if I would pogram a complete tracker, I'd make one running on the real machine.

[sack-c0s]

I'd like to see a tracker with a windows client program that allows you to edit the music with all the comfort we're used to, sending any changed data over to a real machine for authentic playback.

 

Probably sounds a lot like having your cake and eating it, but it's definitely one for the wishlist

[analmux]

Hmmm, makes me thinking...

 

Of course, a PC tool would be much easier, as we might need much RAM workspace to compose a track, edit instruments, copy, paste, etc.

 

As me need to do fine-tuning it would be best to also have a specific tool running on the real A8. Let's say, an atari native instrument editor.

 

So, maybe a hybrid tool would be great.

 

 

Of course, an RMT correction tool, running on the real hardware, would already be great....at least, when it finally will support correct pulsewidth offset features.

[ANTIQ]

What about, if POKEY's playing, is a reset to get the right distortion possible without that being audible?

[analmux]

What about, if POKEY's playing, is a reset to get the right distortion possible without that being audible?

 

Tough question. It depends on what you're doing. In a sense it could be audible. But, compared to the experimental synth tunes by emkay, it will not really be audible.

 

Especially setting up a low note, with pulsewidth offset, might be audible, but I suppose it'll be as audible as setting up a pulse voice on SID. Only the first phase of a wave will be somewhat off. But, the duration of the first wave depends on the pitch chosen. Low notes (f.e. 100Hz) will be in a similar timespan as a TV frame. But, higher notes (f.e. 700Hz and higher) will be less noticeable.

 

But, the main pro is that we don't need to keep the voice quiet during the offset period. And, after executing the 30 cycles no CPU-intervention is needed anymore, as the pokey pulsewave voice will synchronize itself.

 

Possibly a demo would give you a better answer...

[analmux]

Oh, by the way, here's a piece of example code.

 

Suppose we want to do pulsewidth offset of a voice in 64kHz mode. Say we would like to have a pulsewidth of 0.25. Then we do VAL1 := "desired pitch" and VAL2 := 0.25*VAL1.

 

LDA #VAL1 (2 cycles)
LDX #VAL2 (2 cycles)
STX $D200 (=AUDF1) (4 cycles)
STX $D209 (=STIMER) (4 cycles)
STA $D200 (=AUDF1) (4 cycles)

 

This is really enough to set up a desired pulsewidth, and it only takes 16 cycles.

[booker]

Hi Analmux

 

Thanks for your answers.

 

 

I discussed adding filter offset, needed for having a deterministic pulsewave offset, and adding polycounter offset programming once with Raster. However, he was worrying about how to insert the extra commands for offsetting these. So he was worrying about how to keep it backwards compatible with his older RMT versions.

 

I guess the worrying about backward compatibility is a step backward, really. Why anyone would need that?

 

Maybe I could do a better 'retuning' of the 5 already existing hacks, for example do some (least square method) 'best fit' procedures to minimize detuning and rounding.

That would be cool.

 

Also, can you please attach your Patch v5? Can't find in anywhere. Many thanks!

[analmux]

Also, can you please attach your Patch v5? Can't find in anywhere. Many thanks!

OK, here it is again:

 

...and, a test-tune is included.

 

Enjoy!