Efficient multiple indirection in 6502 code

Question

Issue

I'm looking at a 6502 program that has multiple arrays of bytes (sound effect data corresponding to a particular voice), which are of varying lengths. Currently this involves explicitly iterating through the first (if queued), then the second etc, and each voice has a separate set of variables for volume, delay etc, so the code is set up to use these hard-coded labels.

I'd like to roll this into a loop, indexing into these additional variables and the sound effect data. Indexing into the variables is fairly straightforward, using indexed addressing, but indexing into the sound effect data involves a lot more work, and I'm wondering if I'm missing something in the application of indexed indirect and indirect indexed addressing.

Below is a self-contained example of what I'm doing at the moment. The part I'd like to tighten up, if possible, is the code in LoadFromTable, ideally with some use of both X and Y addressing:

  .equ  Ptr0,  0x80
  .equ  Ptr1,  0x81

  .org  0xFE00

  .org  0x0000

Init:
  LDX #0xFF
  TXS

Main:
  LDX #0x00
  LDY #0x00
  JSR LoadFromTable
  ; A should be 'H',  0x48

  LDX #0x01
  LDY #0x00
  JSR LoadFromTable
  ; A should be 'B',  0x42

  LDX #0x02
  LDY #0x02
  JSR LoadFromTable
  ; A should be 'A',  0x41

  JMP Main

LoadFromTable:
  TXA           ; Double outer index to account for 16 bit pointers
  ASL           ;   "
  TAX           ;   "
  LDA Table,X   ; Load the low byte of the array into a pointer
  STA Ptr0      ;   "
  INX           ; Load the high byte of the array into the pointer
  LDA Table,X   ;   "
  STA Ptr1      ;   "
  LDA (Ptr0),Y  ; Load the character at the inner index into the array
  RTS

  .org  0x0040

Table:
  .word Item0
  .word Item1
  .word Item2

  .org  0x0080

Item0:
  .byte 'H', 'E', 'L', 'L', 'O', 0x00

Item1:
  .byte 'B', 'O', 'N', 'J', 'O', 'U', 'R', 0x00

Item2:
  .byte 'C', 'I', 'A', 'O', 0x00

  .org  0x00FA

  .word Init
  .word Init
  .word Init

Implementation

Taking onboard the split table idea from @NickWestgate and hoisting out the initial pointer calculation as noted by @Michael, I've moved from something like this:

PROCESS_MUSIC:
  ; ...
  BNE   MusDoB

MusChanA:
  ; ...
  LDA   MUSICA,X
  BNE   MusCmdToneA
  ; ...
  JMP   MusChanA

MusCmdToneA:
  ; ...
  BNE   MusNoteA
  ; ...

MusNoteA:
  ; ...
  LDA   MUSICA,X
  ; ...

MusDoB:
  ; ...
  BNE   MusDoDone

MusChanB:
  ; ...
  LDA   MUSICB,X
  BNE   MusCmdToneB
  ; ...
  JMP   MusChanB

MusCmdToneB:
  ; ...
  BNE   MusNoteB
  ; ...

MusNoteB:
  ; ...

MusDoDone:
  RTS

to this more generalised subroutine:

PROCESS_MUSIC:
  LDX #0x01

PerChannel:
  ; ...
  BNE EndPerChannel
  LDA MusicTableL,X
  STA tmp0
  LDA MusicTableH,X
  STA tmp1

MusChan:
  ; ...
  LDA (tmp0),Y
  BNE MusCmdTone
  ; ...
  BEQ MusChan

MusCmdTone:
  ; ...
  BNE MusNote
  ; ...

MusNote:
  ; ...
  LDA (tmp0),Y
  ; ...

EndPerChannel:
  DEX 
  BPL PerChannel
  RTS

with the addition of the following tables:

MusicTableL:
    .byte <MUSICA
    .byte <MUSICB

MusicTableH:
    .byte >MUSICA
    .byte >MUSICB

This removes the need for the LoadFromTable function I'd originally been using, and seems much cleaner overall.

Will multiple sound effects be playing simultaneously? If not, it seems pretty inefficient to set up `Ptr0/1` for every single sample load (i.e. just do it when switching to a new sound effect instead). — Michael, Jun 07 '22 at 06:36
@Michael from my understanding, only one sequence will play at a time, and _should_ play through. Setting the pointer pair at the start of the load and incrementing would be more effective, though then you'd need to handle rollover of the low byte properly, which might be more of a hassle (I don't think `INX`/`INY` set the carry flag). — msbit, Jun 07 '22 at 06:58
@msbit: INX/INY sets the usual flags, so you'd BEQ when it wraps. Also, you didn't specify a platform, so I assumed you're limited to 6502. Or is 65C02 OK? — Nick Westgate, Jun 07 '22 at 08:26
_"though then you'd need to handle rollover of the low byte properly"_ Won't you have to deal with that regardless? (unless all your samples are short enough and aligned such that they never cross a page boundary). — Michael, Jun 07 '22 at 09:25
@NickWestgate yes just limited to a base 6502 (6507 actually, from the Atari 2600). — msbit, Jun 07 '22 at 10:49
@Michael after looking at your original comment, I've looked at hoisting the setting of the pointer in zero-page out before the loop at the call site, then the function degenerates to just `LDA (Ptr0),Y` so it can just be inlined. — msbit, Jun 07 '22 at 11:09

Nick Westgate · Accepted Answer · 2022-06-10T08:01:33.183

3

Here are a few ideas. One is passing in an index that's already doubled (i.e. if you can arrange that, or it might already be in the accumulator at some earlier stage).

Another is splitting up the address tables:

LoadFromTable:
  LDA TableL,X ; Load the low byte of the array into a pointer
  STA Ptr0      ;   "
  LDA TableH,X ; Load the high byte of the array into the pointer
  STA Ptr1      ;   "
  LDA (Ptr0),Y  ; Load the character at the inner index into the array
  RTS

TableL:
  .byte #<Item0
  .byte #<Item1
  .byte #<Item2

TableH:
  .byte #>Item0
  .byte #>Item1
  .byte #>Item2

If you can't split up the tables, you can probably still get rid of an INX by doing:

  LDA Table,X   ; Load the low byte of the array into a pointer
  STA Ptr0      ;   "
  LDA Table+1,X ; Load the high byte of the array into the pointer
  STA Ptr1      ;   "

Self modifying code might be useful. Living on page zero will be a factor:

  LDA Table,X   ; Load the low byte of the array into a pointer
  STA Load+1    ;   "
  LDA Table+1,X ; Load the high byte of the array into the pointer
  STA Load+2    ;   "
Load:
  LDA $FFFF,Y   ; Load the character at the inner index into the array

You could also see whether adding Y to the pointer as you store it saves any cycles. It might depend on the most common path used (i.e. if it usually doesn't INC Ptr2/Load+2).

edited Jun 10 '22 at 08:01

answered Jun 07 '22 at 06:33

Nick Westgate

3,088
2
34
41

These are good. The self modifying example won't be applicable in this case (unfortunately) as the code is stored in ROM, but is quite nifty. Let me have a play around with the split table and whether I can premultiply the offset before passing to the function. – msbit Jun 07 '22 at 07:02
Using the split table cleaned that up significantly. I may add include my final implementation in the question, for reference ✌️ – msbit Jun 07 '22 at 23:41
If you have enough RAM, you could copy the code to RAM and run it from there, which would allow you to use self-modifying code. – puppydrum64 Feb 06 '23 at 15:50
@puppydrum64: I've just tagged the question with the platform, Atari 2600, which has 128 bytes of RAM. It's looking a bit tight! ; - ) – Nick Westgate Feb 07 '23 at 02:05
1

You'd be surprised how little space code takes up. But data tables on the other hand... – puppydrum64 Feb 08 '23 at 11:39

supercat · Answer 2 · 2023-03-14T22:36:23.227

If you're trying to generate real-time audio on 1 MHz 6502, I've done four-voice music using 40 bytes per sample plus the time to actually feed the DAC(s), which in my case was two zero-page stores to the AUDV0 and AUDV1 registers.

The key was to use a "rolling" sequence of four code snippets of the form:

; Carry must be clear on entry; will be clear on exit
; Acc, Y, and other flags ignored on entry; trashed on exit
; X register ignored and left alone
ldy phase1
lda (wave1a),y
ldy phase0
adc (wave0d),y
sta AUDV0
lda (newPhase0),y
sta phase0
ldy phase2
lda (wave2c),y
ldy phase3
adc (wave3d),y
sta AUDV1

This approach made it possible to produce four-voice music range over a five-octave range, using half-rate and quarter-rate playback for the bottom two octaves, but ties up 40 bytes worth of zero-page pointers (almost a third of the total RAM on the 2600!). If a choice of playback rates was not required, and one could afford to pad each sample out by an extra 256 bytes, one could have the main sample loop be something like:

 ldy outCounter
 clc
 bmi useSetB
useSetA:
 lda (wave0a),y
 adc (wave1a),y
 adc (wave2a),y
 adc (wave3a),y
 inc outCounter
 bne storeAndDone ; Will be 1-128
useSetB:
 lda (wave0b),y
 adc (wave1b),y
 adc (wave2b),y
 adc (wave3b),y
 inc outCounter
 nop ; Equalize time
storeAndDone:
 sta DACoutput

Two other pieces of code would need to run sometime between when the upper bit of outCounter is set and when it's clear again, and again between then it's clear and when it's re-set.

; Run when outCounter reaches 128
 ldx #6 ; Counts by 2 for each voice
fixLp1:
 lda wave0b,x
 sta wave0a,x
 dex
 dex
 bpl fixLp1

; Run when outCounter reaches 128
 ldx #6
fixLp2:
 sec
 lda wave0a,x
 sbc top0,x
 lda wave0a+1,x
 sbc top0+1,x
 bcc notTopYet
 lda wave0a,x
 sbc length0,x
 sta wave0a,x
 lda wave0a+1,x
 sbc length0+1,x
 sta wave0a+1,x
 dex
 dex
 bpl fixLp2
 bmi done2
notTopYet:
 lda wave0a,x
 sta wave0a,x
 lda wave0a+1,x
 sta wave0a+1,x
 dex
 dex
 bpl fixLp2
done:

The latter portion of the code would be fairly long, but it would only need to be run once every 256 samples, and could accommodate arbitrary looping sections.

Efficient multiple indirection in 6502 code

Issue

Implementation

2 Answers2