8 replies to this topic

[GroovyBee]

I've been experimenting with POKEY in my latest game Apple Snaffle and I wanted a short reliable method to detect if POKEY was in the memory map. I came up with this :-

	.proc DetectPokey
; Reset/initialise POKEY.
	lda #0
	sta gamePokeyDetected
	sta PAUDCTL
	sta PSKCTL

; Short delay before RANDOM is valid.
	nop
	nop
	nop

; Read the RANDOM register (should return 0xFF when POKEY is in reset)
	lda PRANDOM
	cmp #$FF
	bne @NoPokeyDetected

; Take POKEY out of reset.
	lda #3
	sta PSKCTL

; Short delay before RANDOM is valid.
	nop
	nop
	nop

; Read RANDOM 4 times and junk the first read.
	lda PRANDOM	; Should yield 0x00 - Junked.
	lda PRANDOM	; Should yield 0x80
	ldx PRANDOM	; Should yield 0xF8
	ldy PRANDOM	; Should yield 0x0F

; See if POKEY is there.
	cmp #$80			   ; Expected value?
	bne @NoPokeyDetected   ; No... POKEY *NOT* detected.
	cpx #$F8			   ; Expected value?
	bne @NoPokeyDetected   ; No... POKEY *NOT* detected.
	cpy #$0F			   ; Expected value?
	bne @NoPokeyDetected   ; No... POKEY *NOT* detected.
	rts

; POKEY not detected.
@NoPokeyDetected:
	dec gamePokeyDetected  ; Switch off POKEY sound
	rts
	.endproc

Its in CC65 assembler format and is easily converted to DASM etc. The variable gamePokeyDetected is 0xFF if POKEY isn't detected or 0x00 if it is. The basic theory of operation is that it relies on reading POKEY's RANDOM register several times to get known values after the 17 bit polynomial counter is reset to all 1's. Hopefully this will avoid false positives caused by bus float problems.

I've tested it on my CC2 with:-

7800_32K - POKEY not detected (as expected).
78POKEY - POKEY detected (as expected).

It doesn't detect POKEY in the ProSystem emulator because the RANDOM register is not emulated . Feel free to use it but don't add/subtract code to the function otherwise you will change the values read back from RANDOM.

[Rybags]

Maybe use one of the methods from the computer to detect a second (stereo) Pokey.

I suppose the IRQ line isn't connected on the 7800 to Pokey, if so that rules out that option.

An issue with your method is that DMA accesses can affect the timing, although you could take action to ensure you're in a known state so far as that goes.

IIRC, two other methods we've discussed/implemented are:
- setup a Timer IRQ and see if it triggers (generally run with "I" set, then just check IRQST after the interval expires)
- set Fast Potscan mode then trigger the Pot Scan. The Paddle values should increment upwards shortly after at the rate of 1 per cycle. Best to test on Paddle4, 5, 6 or 7 since they're not connected on anything other than the 400/800 or 4-port 5200.

Edited by Rybags, Sun Jul 5, 2009 8:20 PM.

[GroovyBee]

Rybags, on Mon Jul 6, 2009 3:19 AM, said:

I suppose the IRQ line isn't connected on the 7800 to Pokey, if so that rules out that option.

Correct! POKEY isn't connected to the IRQ line of the processor in a 7800.

Rybags, on Mon Jul 6, 2009 3:19 AM, said:

An issue with your method is that DMA accesses can affect the timing, although you could take action to ensure you're in a known state so far as that goes.

Good call! I'm doing the detection during the cart's CPU/RAM/peripheral initialisation phase so video isn't enabled at POKEY detection time.

Rybags, on Mon Jul 6, 2009 3:19 AM, said:

IIRC, two other methods we've discussed/implemented are:
- setup a Timer IRQ and see if it triggers (generally run with "I" set, then just check IRQST after the interval expires)

I'd thought about doing that but decided against it. I just wanted a simple approach that didn't use any loops.

Rybags, on Mon Jul 6, 2009 3:19 AM, said:

- set Fast Potscan mode then trigger the Pot Scan. The Paddle values should increment upwards shortly after at the rate of 1 per cycle. Best to test on Paddle4, 5, 6 or 7 since they're not connected on anything other than the 400/800 or 4-port 5200.

Thanks for that. I'd not considered using the paddle interface, but again it involves loops which I wanted to avoid.

EDIT: For spelling

Edited by GroovyBee, Mon Jul 6, 2009 4:31 AM.

[Rybags]

The IRQ could be a valid approach - doesn't matter that it's not connected because you can just operate in polling mode anyway.

Another one - I think the Keycode value might = 00 when Pokey is in Init State (?)
Might have to test that one out.
Or, it might have been RANDOM = 00 when in Init State.

Of course, if keycode = 00 during normal operation of the 7800, then it kinda rules that option out.

I suppose the other consideration is that you want all this to work in emulation as well, and not all emus will necessarily reflect these seldom looked at qualities.

[GroovyBee]

Rybags, on Mon Jul 6, 2009 10:15 AM, said:

The IRQ could be a valid approach - doesn't matter that it's not connected because you can just operate in polling mode anyway.

Agreed!

Rybags, on Mon Jul 6, 2009 10:15 AM, said:

Another one - I think the Keycode value might = 00 when Pokey is in Init State (?)
Might have to test that one out.
Or, it might have been RANDOM = 00 when in Init State.

I wanted to avoid the situation where the bus floating (POKEY not present) would cause false positives. On some 7800s there are pull downs on the data bus, so reading a single value of 0x00 isn't a good idea. RANDOM returns 0xFF when POKEY is in its init state and that is tested in the code above.

Rybags, on Mon Jul 6, 2009 10:15 AM, said:

I suppose the other consideration is that you want all this to work in emulation as well, and not all emus will necessarily reflect these seldom looked at qualities.

ProSystem doesn't emulate the RANDOM register at all .

[PacManPlus]

Just wanted to post and say that the detection works *wonderfully* (at least in the CCII).



Thanks, GroovyBee

[DEBRO]

I thought Ken Siders had a routine for detecting POKEY. Am I wrong? What was wrong with that one?

[PacManPlus]

I didn't know there was another one...

[GroovyBee]

From what I remember Ken's routine puts POKEY into reset and checks that it can read 0xFF from the RANDOM register. Then it takes POKEY out of reset and checks that the values read from RANDOM are all different. Apologies if I've got that wrong its a while since I looked at the Beef Drop code.