SID interface, timing (technical q)

[jkeyzer]

Hi there,

I have a technical question about the approach to timing for data transfers in the midibox SID.

I have noticed that on the SID daughter boards that the SID gets its own 1.0MHz oscillator, which is connected only to the phase2 clock input of the SID (and nothing else).

Given that this clock is not synchronous to the PIC's clock on the host board, how does the PIC ensure that data is latched correctly by the SID?  I thought that the SID latched data on the falling edge of the phase2 clock?  If the clocks are unconnected, how does the PIC know when the data will be latched, to avoid latching it twice or corrupting the data etc?

I am trying to better understand the SID interface and am in the process of gathering the parts to build one of these very interesting and unique synthesizers!

Thanks for any info!

Jeff

[TK.]

Hi Jeff,

the SR handler activates the write line for 1.2 uS to ensure that the data word will be taken.

This doesn't ensure that data will be written twice, but fortunately the SID registers are not sensitive to write events. Means: it doesn't make a difference if a value is written multiple times so long it doesn't change

Best Regards, Thorsten.

[jkeyzer]

Thorsten,

Thanks!  That clears it up.

Jeff

[jfmateos]

First, let me congratulate you all for this marvellous project.

I am also interested in interfacing SID6581 to a PIC microcontroller. I understand that the PIC inside MIDIbox SID doesn´t know wheter the SID clock (PWM signal) is high or low; it just keeps the data to be written more than 1 us (1.2us). Have I understood it properly?

I found this image in other thread of this forum, but I don´t understand the meaning of WAIT CLK=1, WAIT CLK=0 and pipeline delay. Could anybody help me?

Thanks and best regards from Madrid.

[TK.]

I am also interested in interfacing SID6581 to a PIC microcontroller. I understand that the PIC inside MIDIbox SID doesn´t know wheter the SID clock (PWM signal) is high or low; it just keeps the data to be written more than 1 us (1.2us). Have I understood it properly?

This was the case in an early firmware version, but I found out, that the clock phase has to be considered when writing into SID registers to avoid unintended OSC gate triggers. So far I remember, I descriped the failure scenario in the article where you found the image

I found this image in other thread of this forum, but I don´t understand the meaning of WAIT CLK=1, WAIT CLK=0 and pipeline delay. Could anybody help me?

The firmware reads the PWM pin, and waits until it is 1, thereafter it waits until it is 0. This synchronizes the firmware to a falling edge of the SID clock. The range marked with "pipeline delay" means, that I've considered, that the input pin of the PIC goes through two internal FF stages (see datasheet), which adds a delay of 200 nS (if PIC is clocked at 40 MHz)

The routine ensures that:

   - CS# is set to 0 before the rising edge of the SID clock to avoid a setup/hold violation

   - data is registered only once during a falling edge of the SID clock

   - CS# is set back to 1 after the next rising edge of the SID clock to avoid a setup/hold violation (again)

Best Regards, Thorsten.

[jfmateos]

Thank you very much for your kind answer, Thorsten.

So... PIC pin17 (PWM output) is connected to other PIC´s pin that detects whether the PWM is high or low? Which pin is this?

Using your approach, writting two SID registers would take 6 clock cycles (6us). Is it right?

Thank you again.

[TK.]

So... PIC pin17 (PWM output) is connected to other PIC´s pin that detects whether the PWM is high or low? Which pin is this?

It isn't required to connect such a clock output to another IO pin, just read the port input register of the output pin.

For the case you don't know - the source code is located here, and this is the code which strobes the write:

	;; synchronize with rising edge of SID clock to avoid setup or hold violation
	;; note: due to pipeline effects, the "bcf" will be executed 3 instruction cycles after
	;; the polling loop. Therefore we are waiting for the falling edge
	btfss	PORTC, 2; wait for falling clock edge
	bra $-2		
	btfsc	PORTC, 2
	bra $-2
	bcf	SID_SR_LAT_WR, SID_SR_PIN_WR	; enable write (MBHP_SID: chip select)
	bra	$+2				; to ensure compatibility with on-board oscillator,
	bra	$+2				; wait for 1.2 uS (> one SID clock cycle)
	bra	$+2
	bra	$+2
	bra	$+2
	bra	$+2
	bsf	SID_SR_LAT_WR, SID_SR_PIN_WR	; disable write (MBHP_SID: chip select)
[/code]
Using your approach, writting two SID registers would take 6 clock cycles (6us). Is it right?
It depends on how the address/data bus is connected to the SID(s). I don't know which method you are using exactly, therefore I cannot answer this question.
Best Regards, Thorsten.

[jfmateos]

Thanks Thorsten, the source code makes it all clear... although I don´t quite understand why it is neccesary to wait for the rising flange; wouldn´t be enought to just wait for the falling flange?

	btfss	PORTC, 2; wait for falling clock edge
	bra $-2		

I suppossed you were using some kind of interrupt, but I see it is just a polling/loop.

the input pin of the PIC goes through two internal FF stages (see datasheet),

I cannot find information in the datasheet about this (I usually program in C), but I will keep up searching.

I have modified siddump to extract the SID registers states from PSID files, and my aim is to play this states using the PIC; the project is a PIC-PSID-SID player.

Thank you very much again.

[TK.]

although I don´t quite understand why it is neccesary to wait for the rising flange; wouldn´t be enought to just wait for the falling flange?

No, because if the polling starts while RC2 is already 1, you would miss the edge and shift the strobe

I suppossed you were using some kind of interrupt, but I see it is just a polling/loop.

With interrupts you wouldn't be able to achieve the strict timings.

Btw.: interrupts should be disabled while the polling loop is processed.

I cannot find information in the datasheet about this, but I will keep up searching.

Just study the pictures ;)

There is a D FF between the input pin and the data bus. I believe, that these are in fact two FFs (common design rule to prevent metastabilities), because I measured a delay of 3 clock cycles. The third FF stage is in the CPU pipeline

I have modified siddump to extract the SID registers states from PSID files, and my aim is to play this states using the PIC; the project is a PIC-PSID-SID player.

So, you've an huge external memory which contains the SID register traces. I guess that preloading this memory will take very long... so, why not emulating a 6502 with the PIC, and process the player code (which is embedded in the .sid file) directly? You would need an external RAM (64k), so that the whole address space of a C64 is available, and a CPU emulation routine which processes the SID player code. Since this routine is normaly clocked at 50 Hz, you've 20 mS to decode the CPU instructions - this should be possible.

I would also propose to connect the SID pins directly to the PIC, and not via serial interface, because your application doesn't require so many different external components like a MBSID. This would give you more CPU time for the emulation.

Best Regards, Thorsten.

[jfmateos]

No, because if the polling starts while RC2 is already 1, you would miss the edge and shift the strobe

I understand, but shouldn´t it be "No, because if the polling starts while RC2 is already 0, you would ..."?

Btw.: interrupts should be disabled while the polling loop is processed.

I will take into account this advice.

Just study the pictures

There is a D FF between the input pin and the data bus. I believe, that these are in fact two FFs (common design rule to prevent metastabilities), because I measured a delay of 3 clock cycles. The third FF stage is in the CPU pipeline

I think I don´t quite understand the meaning of FF stage  :-[ ... I will keep on studying ;)

why not emulating a 6502 with the PIC,

This is my second aim, but first I want to know exactly how to communicate with the sid.

BTW, would you recommend me any good resource with information about 6502 emulation?

Thank you very much for sharing your huge knowledgements...

[TK.]

I understand, but shouldn´t it be "No, because if the polling starts while RC2 is already 0, you would ..."?

Yes, I was confused by the code you quoted

Best Regards, Thorsten.

[TK.]

BTW, would you recommend me any good resource with information about 6502 emulation?

Just have a look into the sidplay code :)

(I guess, it's hosted at sourceforge)

Best Regards, Thorsten.