Thoughts on sound, timer, and joystick drivers

[ivop]

Brain dump below:

SOUND driver
============

Note:       0-119, ten octaves from C0-B9
Channel:    0-2
Volume:     0-15
Noise:      0,1, off/on, ch. 2 only (SN limitation we impose on others,too)

Implementation: three channels is the lowest common denominator of SN, AY,
                SID, and Pokey. Leaves channel 4 on Pokey free for timer.
                For SID, use pulse with 50/50 duty cycle to get a clear tone.
                All others play clear tone. Pokey might use distortion C
                for low notes? Notes outside the playable range are either
                transposed up/down, or ignored. Setting noise switches to
                one of the LFSR noise types.

SOUND_VERSION
    Enter:
    Exit:   A = API version

SOUND_BELL
    Enter:
    Exit:

SOUND_PLAY_NOTE
    Enter:      A = Note, X = Channel
    Exit:

SOUND_SET_VOLUME
    Enter:      A = Volume, X = Channel
    Exit:

SOUND_SET_NOISE
    Enter:      A = 0,1, X = Channel
    Exit:

SOUND_SET_IGNORE_INVALID
    Enter:      A = 0,1
    Exit:


TIMER driver
============

Granularity of time? Hertz might be computational expensive for platforms
that do not specifically have a timer frequency that can be set in hertz.
Perhaps a list of predefined values?
    1Hz, 2Hz, 10Hz, 25Hz, 30Hz, 50Hz, 60Hz, 100Hz, 1000Hz, 15.7kHz (scan line)
Or maybe only one fixed frequency of 1 VBlank?
Commodore PET can only do VB on pin CB1 of its PIA?

Implementation:     Oric, C64, BBC, VIC-20: CIA or VIA timer
                    Atari: Pokey timer or Antic (GPU) VBI
                    PET: PIA vertical retrace
                    Apple: No timers? Not even VB? Only IIc seems to have VBI

TIMER_VERSION
    Enter:
    Exit:   A = API major version, X = API minor version

TIMER_GET_CPU_SPEED     (API 1)
    Enter:
    Exit:   YXA = 24-bit frequency in Hertz
            Could be used for busy waiting timing loops if there's no timer
            capability. Of limitted use on systems with cycle stealing (RAM
            refresh, display memory access)

TIMER_WAIT_VBLANK       (API 2)
    Enter:  X = Number of times (1-255, 0 is a nop)
    Exit:

TIMER_GET_FRAME_RATE    (API 2)
    Enter:
    Exit:   A = 50 or 60

TIMER_SET_FREQUENCY     (API 3)
    Enter:  XA = Frequency (?)
    Exit:

TIMER_SET_CALLBACK      (API 3)
    Enter:  XA = Address

TIMER_START             (API 3)
    Enter:
    Exit:

TIMER_STOP              (API 3)
    Enter:
    Exit:


JOYSTICK
========

JOYSTICK_VERSION
    Enter:
    Exit:   A = API version

JOYSTICK_GET_STATUS
    Enter:  A = 0, 1    (joystick 0 or 1)
    Exit:   A = 0-7,8     (UP, UPRIGHT, RIGHT, etc... clockwise, 8 = center)
            X = trigger

Thoughts? :smile:

[davidgiven]

Oops, just spotted this!

The only one I've thought of so far is the timer driver, and I was thinking of something much simpler: a routine which fetches a 32-bit millisecond monotonic counter, and possibly another which does a delay. I'm unsure about anything which requires a callback because if the application exits without resetting it you get a guaranteed crash (this is an issue with a BRK handler too). Let me look at the timer driver.

[ivop]

Didn't think about that. Perhaps bdos_exit_program could disable any dangling timers before continuing? Or if control is turned back to CCP without doing a warm boot, CCP could disable them?