User Tools

Site Tools


base:triangle_waveform

Examination of SID triangle waveform

Data recorded on the triangle waveform ($10)

The data are recorded using a REU. The recording is done like this:

        ;* Program 1 *

	;Turn off screen and sprites

	...

	;Set frequency of voice 3

	LDA #<freq
	LDX #>freq
	STA $D40E
	STX $D40F

	;Reset waveform

	LDA #$08	;Set test bit
	STA $D412

	;Setup REU to sample register $D41B for $10000 cycles

	...

	;Start recording

	LDA #$10	;Waveform: Triangle
	LDX #%1001000	;REU-command: Start transfer
	STA $D412	;Start waveform
	STX $DF01	;Start transfer

	...

Furthermore, a construct like this is used to get a value from the waveform as fast as possible (via software) from the SID:

	;* Program 2 *

	...

	LDA #$10
	STA $D412	;Start waveform
	LDA $D41B	;Record early value
	STA Haps	;Save value

	...

The table below summarizes the recordings (all values in hex):

Frequency  Haps REU

8000	   04   05 06 07 ... FD FE FF FF FE ... 01 00 00 01 ...
4000       02   02 03 03 04 04 ...
2000       01   01 01 01 02 02 02 02 03 03 03 03 04 ...
1000       00   00 00 00 01 01 01 01 01 01 01 01 01 02 ...
FFFF       07   09 0B 0D 0F 11 13 15 17
DEAD       06   08 0A 0C 0D 0F 11 13 14 16 18 1A 1B 1D 1F 21 22 24 26
                28 29 2B 2D 2E 30 32 34 35 37 39 3B 3C 3E 40 42 43 45
                47 49 4A 4C 4E 50 51 53 55 56 58 5A 5C 5D 5F 61 63 64

Legend:

  • Frequency is the value stored to $D40E and $D40F.
  • Haps is the value of the Haps variable from program 2.
  • REU is the data collected with the REU after running program 1.

Conclusion: The triangle waveform starts with value $00 and goes to $ff linearly. Then it goes from $ff to $00 linearly.

(As a sidenote, I'll mention that the data for the sawtooth waveform at frequency $8000 is Haps= 02, REU= 02 03 03 04 04 … FE FE FF FF 00 00 01 01 …)

The Haps variable is the value of the waveform on one cycle earlier than the REU starts recording.

Further data used to investigate the frequency/waveform mapping:

Frequency
      Haps+REU, Number of this*value

0001  7FFC*00 8000*01 8000*02 ...
0002  3FFC*00 4000*01 4000*02 ...
0003  2AA7*00 2AAB*01 2AAA*02 2AAB*03
0004  1FFC*00 2000*01 2000*02 ...
0005  1996*00 199A*01 1999*02 199A*03 1999*04
0006  1552*00 1555*01 1555*02 1556*03 1555*04 1555*05 1556*06
0007  1245*00 1249*01 1249*02 1249*03 1249*04 1249*05 1249*06 124A*07
      1249*08
0008  0FFC*00 1000*01 1000*02 ...
0009  0E35*00 0E39*01 0E39*02
000A  0CC9*00 0CCD*01
000B  0B9F*00

Legend:

  • Frequency is the value stored to $D40E and $D40F.
  • Haps+REU is the contents of the Haps variable from program 2 and the contents of the REU after running program 1.
  • The format is number of times of repeation * value. (i.e. 7FFC*00 means that the value “00” repeated $7FFC times after each other in the data. 0003*FE 0004*DE would mean this sequence of data was recorded: FE FE FE DE DE DE DE. The first FE would come from the variable Haps, while the rest would be obtained with the REU.)

Conclusion: We know that with the STA $D412; LDA $D41B construct, A contains the value of the waveform after 4 cycles. This is consistence with the observation that the number of times the value $00 appears generally is 4 lower than the number of times the other values appear.

The overall behaviour can thus be simulated with this C-program:

void Triangle(long Frequency) {
  long Cycle; /* Count of Phi2 cycles */

  long Delay= 0x8000;
  long Counter= 0; /* Initial value is 0 */

  for (Cycle=0; ;Cycle= Cycle+1) {

    /* Build waveform: Triangle */
    if (Counter  256)
      Waveform[cycle]= Counter;
    else
      Waveform[cycle]= 511- Counter;

    /*
      For the sawtooth waveform, use:

      Waveform[Cycle]= Counter / 2;
    */

    /* Handle frequency-function */
    Delay = Delay- Frequency;

    /* Frequency overflow? */
    while (Delay =0 ) do {
      /* For frequencies above $8000, this will be executed twice */

      Delay = Delay + 0x8000;

      /* Calculate new value for waveform */
      Counter= (Counter+1) % 512; /* Keep in range 0..511 */
    }
  }
}

The above program (when checked) is only capable of reproducing the output of register $1B. We can't be sure that the true output of pin 27 of the SID is the same. In this respect, there are two issues:

  • Is the output digital and 8 bit?
  • Is the output aligned to the ø2 clock?

Is the output digital and 8 bit?

People have used oscilloscopes and concluded that this is the output is digital and probably 8 bit. This can also be checked with this program, if you have decent audio-equipment:

	jsr $e544	;Clear screen

	ldx #0
	stx $d021       ;Background color black
	stx $d020	;Border black
			;(The black color reduces noise with my equipment)

	lda #11		;As of request from Andreas with kernal R2 :-)
col	sta $d800,x	;Character color dark grey
	inx
	bne col

	lda #$01 	;Frequency 1
	sta $d40e
	lda #$00
	sta $d40f

	lda #$00	;ADSR:00F0
	sta $d412
	lda #$f0
	sta $d413

	lda #$81	;Waveform: Random, changes rarely.
			;Change for other waveforms
	sta $d412

	lda #$0f	;Max volume: $f
	sta $d418

	ldx $d41b
loop1	stx temp

loop2	ldx $d41b
	cpx temp
	bne loop2

	lda $0400,x	;Display when value changes
	eor #$80
	sta $0400,x
	jmp loop1

temp 	.byte $00

Turn up the volume of the TV-set and you can hear the “ticks” when the waveform changes every few seconds. If the ticks happen in alignment with the changes on the screen, the output is digital and 8 bit.

You can also try other waveforms (substitute the lda #$81 with lda #$11 for triangle or lda #$21 for sawtooth. Pulse ($41) requires definition of the pulse width in $d410 and $d411), but these are all much faster and/or the changes in the waveform are small, so it is not as easy to hear the distinct ticks.

Is the output aligned to the ø2 clock?

This is an open question as of now (23 Mar 1995 :-)). My feeling is that the output is aligned, but this is only a feeling based on the fact that, all, the SID has available to synchronize with, is the ø2 feed.

I believe examination of this requires an oscilloscope, which I have no access to. What should be done is to display the ø2 clock along with the pin 27 output with a triangle waveform at frequency $ffff (Just modify the above program to use frequency $ffff and triangle waveform). If the waveform change only once every ø2 cycle, the output is ø2 aligned and thus “skipping values”. If not, the waveform would change twice every ø2 cycle and thus display all 256 values. If this is the case, I have further studies to be done to clarify whether the output is happening in a discrete partition of the ø2 cycle.

Observation: If you record the data of the waveform with a structure like this:

	...

	lda #$08 	;Reset waveform: Test bit is 1.
	sta $d412

	lda #$00	;Frequency $8000
	sta $d40e
	lda #$80
	sta $d40f

	...

	ldy #$00	;Clear test bit
	lda #$10	;Waveform triangle
	ldx #$90	;REU command
	sty $d412	;The difference!
	sta $d412
	stx $df01

the recorded data are all 4 cycles behind! I.e. the first value in the REU data is not $05, but $09. The similar thing happens if you use the capture in program 2: Instead of getting $04, you get $08. The 4 cycle delay is the time, the sta $d412 takes.

If you change the ldy #$00 (test bit=0) to ldy #$08 (test bit=1), the effect disappears, so the conclusion is:

  • The triangle counter counts all the time, whether or not the waveform is activated. The counter is held reset to 0 when the test bit is 1 (supposedly), and as soon as the test bit is 0, the counter starts counting.

Another explanation, with the same result, is that the counter is reset on falling edge of the test bit.

I have not examined whether this is the case for the sawtooth and the pulse waveforms, but my bet is, this is the case.

base/triangle_waveform.txt · Last modified: 2015-04-17 04:34 (external edit)