Apple-2-SW/ii-vision
1
0
Fork 0
mirror of https://github.com/KrisKennaway/ii-vision.git synced 2024-12-28 03:29:24 +00:00
Code Issues Projects Releases Wiki Activity
5387eae674
ii-vision/player/main.s

1362 lines
32 KiB
ArmAsm
Raw Normal View History

Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
;
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; ][Vision
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
;
; Created by Kris Kennaway on 07/01/2019.
; Copyright © 2019 Kris Kennaway. All rights reserved.
;
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; W5100/Uthernet II code based on "TCP SOCKET DEMO FOR W5100/UTHERNET II" by D. Finnigan.
Add more comments and clean up timings for op_ack. Magically, this all fits in exact multiples of 36/37 ticks!
2019-03-15 22:42:33 +00:00
;
; Multiplexed audio/video decoder for 64K, 1MHz Apple II systems with Uthernet II,
; supporting:
; - 5 bit DAC audio at ~14KHz
; - 56 KB/sec video update bandwidth
;
Oops fix byte ordering for port
2019-03-21 16:35:12 +00:00
; This is sufficient for ~7.5 full page redraws of the hires screen per second, although the
; effective frame rate is typically higher, when there are only partial changes between
; frames.
Add more comments and clean up timings for op_ack. Magically, this all fits in exact multiples of 36/37 ticks!
2019-03-15 22:42:33 +00:00
;
Oops fix byte ordering for port
2019-03-21 16:35:12 +00:00
; Fitting this in 64K together with ProDOS is pretty tight. We make use of 3 memory
; segments:
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
;
Oops fix byte ordering for port
2019-03-21 16:35:12 +00:00
; LOWCODE (0x800 - 0x1fff)
; HGR (0x2000 - 0x3fff): code needed only at startup, which will be erased as soon as we start playing a video
; CODE (0x4000 - 0xbaff): rest of main memory unused by ProDOS
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
.include "apple2.inc"
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; Write symbol table to .dbg file, so that we can read opcode offsets in the video
; transcoder.
.DEBUGINFO
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
.proc main
Reorder a bit to put the configurable bits at the top.
2019-03-21 15:27:24 +00:00
.segment "HGR"
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Reorder a bit to put the configurable bits at the top.
2019-03-21 15:27:24 +00:00
; TODO: make these configurable
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
SRCADDR: .byte 192,168,1,147 ; 192.168.1.147 W5100 IP
FADDR: .byte 192,168,1,15 ; 192.168.1.15 FOREIGN IP
Oops fix byte ordering for port
2019-03-21 16:35:12 +00:00
FPORT: .byte $07,$b9 ; 1977 FOREIGN PORT
Reorder a bit to put the configurable bits at the top.
2019-03-21 15:27:24 +00:00
MAC: .byte $00,$08,$DC,$01,$02,$03 ; W5100 MAC ADDRESS
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
; SLOT 1 I/O ADDRESSES FOR THE W5100
Reorder a bit to put the configurable bits at the top.
2019-03-21 15:27:24 +00:00
; Change this to support the Uthernet II in another slot
;
; TODO: make slot I/O addresses customizable at runtime - would probably require somehow
; compiling a list of all of the binary offsets at which we reference $C09x and patching
; them in memory or on-disk.
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
WMODE = $C094
WADRH = $C095
WADRL = $C096
WDATA = $C097
Reorder a bit to put the configurable bits at the top.
2019-03-21 15:27:24 +00:00
;;;
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
headerlen = $07 ; video header length
Install RESET handler that exits to ProDOS Implement op_terminate which waits for a keypress and then exits.
2019-03-23 21:45:13 +00:00
; some dummy addresses in order to pad cycle counts
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
zpdummy = $08
Install RESET handler that exits to ProDOS Implement op_terminate which waits for a keypress and then exits.
2019-03-23 21:45:13 +00:00
dummy = $ffff
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
ptr = $06 ; TODO: we only use this for connection retry count
; soft-switches
KBD = $C000
STORE80ON = $C001
COL80ON = $C00D
KBDSTRB = $C010
TICK = $C030 ; where the magic happens
TEXTOFF = $C050
FULLSCR = $C052
PAGE2OFF = $C054
PAGE2ON = $C055
HIRESON = $C057
DHIRESON = $C05E
; MONITOR SUBROUTINES
HGR = $F3E2
HGR0 = $F3EA ; internal entry point within HGR that doesn't set soft-switches
COUT = $FDED
PRBYTE = $FDDA
PRNTAX = $F941
Reorder a bit to put the configurable bits at the top.
2019-03-21 15:27:24 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
PRODOS = $BF00 ; ProDOS MLI entry point
RESET_VECTOR = $3F2 ; Reset vector
Reorder a bit to put the configurable bits at the top.
2019-03-21 15:27:24 +00:00
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
; W5100 LOCATIONS
MACADDR = $0009 ; MAC ADDRESS
SRCIP = $000F ; SOURCE IP ADDRESS
RMSR = $001A ; RECEIVE BUFFER SIZE
; SOCKET 0 LOCATIONS
S0MR = $0400 ; SOCKET 0 MODE REGISTER
S0CR = $0401 ; COMMAND REGISTER
S0SR = $0403 ; STATUS REGISTER
S0LOCALPORT = $0404 ; LOCAL PORT
S0FORADDR = $040C ; FOREIGN ADDRESS
S0FORPORT = $0410 ; FOREIGN PORT
S0TXRR = $0422 ; TX READ POINTER REGISTER
S0TXWR = $0424 ; TX WRITE POINTER REGISTER
S0RXRSR = $0426 ; RX RECEIVED SIZE REGISTER
S0RXRD = $0428 ; RX READ POINTER REGISTER
; SOCKET 0 PARAMETERS
RXBASE = $6000 ; SOCKET 0 RX BASE ADDR
RXMASK = $1FFF ; SOCKET 0 8KB ADDRESS MASK
TXBASE = $4000 ; SOCKET 0 TX BASE ADDR
TXMASK = RXMASK ; SOCKET 0 TX MASK
; SOCKET COMMANDS
SCOPEN = $01 ; OPEN
SCCONNECT = $04 ; CONNECT
SCDISCON = $08 ; DISCONNECT
SCSEND = $20 ; SEND
SCRECV = $40 ; RECV
; SOCKET STATUS
STINIT = $13
STESTABLISHED = $17
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; this is the main binary entrypoint (it will be linked at 0x800)
Optimize some more to fit in memory!
2019-03-10 21:57:05 +00:00
.segment "LOWCODE"
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
JMP bootstrap
Optimize some more to fit in memory!
2019-03-10 21:57:05 +00:00
; Put code only needed at startup in the HGR page, we'll toast it when we're
; done starting up
.segment "HGR"
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; RESET AND CONFIGURE W5100
bootstrap:
Install RESET handler that exits to ProDOS Implement op_terminate which waits for a keypress and then exits.
2019-03-23 21:45:13 +00:00
; install reset handler
LDA #<exit
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
STA RESET_VECTOR
Install RESET handler that exits to ProDOS Implement op_terminate which waits for a keypress and then exits.
2019-03-23 21:45:13 +00:00
LDA #>exit
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
STA RESET_VECTOR+1
Install RESET handler that exits to ProDOS Implement op_terminate which waits for a keypress and then exits.
2019-03-23 21:45:13 +00:00
EOR #$A5
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
STA RESET_VECTOR+2 ; checksum to ensure warm-start reset
Install RESET handler that exits to ProDOS Implement op_terminate which waits for a keypress and then exits.
2019-03-23 21:45:13 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
LDA #6 ; 5 RETRIES TO GET CONNECTION
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
STA ptr ; NUMBER OF RETRIES
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
reset_w5100:
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA #$80 ; reset
STA WMODE
LDA #3 ; CONFIGURE WITH AUTO-INCREMENT
STA WMODE
; ASSIGN MAC ADDRESS
LDA #>MACADDR
STA WADRH
LDA #<MACADDR
STA WADRL
LDX #0
@L1:
LDA MAC,X
STA WDATA ; USING AUTO-INCREMENT
INX
CPX #6 ;COMPLETED?
BNE @L1
; ASSIGN A SOURCE IP ADDRESS
LDA #<SRCIP
STA WADRL
LDX #0
@L2:
LDA SRCADDR,X
STA WDATA
INX
CPX #4
BNE @L2
;CONFIGURE BUFFER SIZES
LDA #<RMSR
STA WADRL
LDA #3 ; 8KB TO SOCKET 0
STA WDATA ; SET RECEIVE BUFFER
STA WDATA ; SET TRANSMIT BUFFER
; CONFIGRE SOCKET 0 FOR TCP
LDA #>S0MR
STA WADRH
LDA #<S0MR
STA WADRL
LDA #$21 ; TCP MODE | !DELAYED_ACK
STA WDATA
; SET LOCAL PORT NUMBER
LDA #<S0LOCALPORT
STA WADRL
LDA #$C0 ; HIGH BYTE OF LOCAL PORT
STA WDATA
LDA #0 ; LOW BYTE
STA WDATA
; SET FOREIGN ADDRESS
LDA #<S0FORADDR
STA WADRL
LDX #0
@L3:
LDA FADDR,X
STA WDATA
INX
CPX #4
BNE @L3
; SET FOREIGN PORT
LDA FPORT ; HIGH BYTE OF FOREIGN PORT
STA WDATA ; ADDR PTR IS AT FOREIGN PORT
LDA FPORT+1 ; LOW BYTE OF PORT
STA WDATA
; OPEN SOCKET
LDA #<S0CR
STA WADRL
LDA #SCOPEN ;OPEN COMMAND
STA WDATA
; CHECK STATUS REGISTER TO SEE IF SUCCEEDED
LDA #<S0SR
STA WADRL
LDA WDATA
CMP #STINIT ; IS IT SOCK_INIT?
BEQ OPENED
LDY #0
@L4:
LDA @SOCKERR,Y
BEQ @LDONE
JSR COUT
INY
BNE @L4
@LDONE: BRK
@SOCKERR: .byte $d5,$d4,$c8,$c5,$d2,$ce,$c5,$d4,$a0,$c9,$c9,$ba,$a0,$c3,$cf,$d5,$cc,$c4,$a0,$ce,$cf,$d4,$a0,$cf,$d0,$c5,$ce,$a0,$d3,$cf,$c3,$cb,$c5,$d4,$a1
; "UTHERNET II: COULD NOT OPEN SOCKET!"
.byte $8D,$00 ; cr+null
; TCP SOCKET WAITING FOR NEXT COMMAND
OPENED:
LDA #<S0CR
STA WADRL
LDA #SCCONNECT
STA WDATA
; WAIT FOR TCP TO CONNECT AND BECOME ESTABLISHED
CHECKTEST:
LDA #<S0SR
STA WADRL
LDA WDATA ; GET SOCKET STATUS
BEQ FAILED ; 0 = SOCKET CLOSED, ERROR
CMP #STESTABLISHED
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BEQ wait_read_header ; SUCCESS
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
BNE CHECKTEST
FAILED:
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
DEC ptr
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
BEQ ERRDONE ; TOO MANY FAILURES
LDA #$AE ; "."
JSR COUT
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
JMP reset_w5100 ; TRY AGAIN
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
ERRDONE:
LDY #0
@L:
LDA ERRMSG,Y
BEQ @DONE
JSR COUT
INY
BNE @L
@DONE: BRK
ERRMSG: .byte $d3,$cf,$c3,$cb,$c5,$d4,$a0,$c3,$cf,$d5,$cc,$c4,$a0,$ce,$cf,$d4,$a0,$c3,$cf,$ce,$ce,$c5,$c3,$d4,$a0,$ad,$a0,$c3,$c8,$c5,$c3,$cb,$a0,$d2,$c5,$cd,$cf,$d4,$c5,$a0,$c8,$cf,$d3,$d4
; "SOCKET COULD NOT CONNECT - CHECK REMOTE HOST"
.byte $8D,$00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
wait_read_header:
LDA #<S0RXRSR ; Socket 0 Received Size register
STA WADRL ;
LDA WDATA ; High byte of received size
CMP #$01 ; expect at least 256 bytes
BCS op_header ; There is enough data...we don't care exactly how much
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
; TODO: Not sure whether this delay is needed?
NOP ; Little delay ...
NOP
JMP wait_read_header ; Check again
Optimize some more to fit in memory!
2019-03-10 21:57:05 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
op_header:
; Point to socket 0 buffer
LDA #>RXBASE
STA WADRH
LDA #<RXBASE
STA WADRL
; read video header
; consume 6 padding bytes from HEADER opcode.
; TODO: implement version header so we won't try to play a video for an incompatible
; player version.
LDA WDATA
LDA WDATA
LDA WDATA
LDA WDATA
LDA WDATA
LDA WDATA
Install RESET handler that exits to ProDOS Implement op_terminate which waits for a keypress and then exits.
2019-03-23 21:45:13 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
JMP _op_header_hgr
Install RESET handler that exits to ProDOS Implement op_terminate which waits for a keypress and then exits.
2019-03-23 21:45:13 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
.segment "CODE"
Install RESET handler that exits to ProDOS Implement op_terminate which waits for a keypress and then exits.
2019-03-23 21:45:13 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
; Initialize (D)HGR in the CODE segment so we don't accidentally toast ourselves when
; erasing HGR
_op_header_hgr:
LDA WDATA ; Video mode
BEQ @1 ; 0 = HGR mode
Proof of concept DHGR encoding/playback - Every time we process an ACK opcode, toggle page 1/page 2 soft switches to steer subsequent writes between MAIN and AUX memory - while I'm here, squeeze out some unnecessary operations from the buffer management On the player side, this is implemented by maintaining two screen memory maps, and alternating between opcode streams for each of them. This is using entirely the wrong colour model for errors, but surprisingly it already works pretty well in practise (and the frame rate is acceptable on test videos) DHGR/HGR could be made runtime selectable by adding a header byte that determines whether to set the DHGR soft switches before initiating the decode loop. While I'm in here, fix op_terminate to clear keyboard strobe before waiting.
2019-03-27 21:37:06 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
; TODO: clear screen before displaying it to look cleaner
; DHGR mode
Proof of concept DHGR encoding/playback - Every time we process an ACK opcode, toggle page 1/page 2 soft switches to steer subsequent writes between MAIN and AUX memory - while I'm here, squeeze out some unnecessary operations from the buffer management On the player side, this is implemented by maintaining two screen memory maps, and alternating between opcode streams for each of them. This is using entirely the wrong colour model for errors, but surprisingly it already works pretty well in practise (and the frame rate is acceptable on test videos) DHGR/HGR could be made runtime selectable by adding a header byte that determines whether to set the DHGR soft switches before initiating the decode loop. While I'm in here, fix op_terminate to clear keyboard strobe before waiting.
2019-03-27 21:37:06 +00:00
Remove stray comment
2019-04-25 20:29:38 +00:00
STA TEXTOFF
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
STA HIRESON
STA DHIRESON
STA COL80ON
STA STORE80ON
Proof of concept DHGR encoding/playback - Every time we process an ACK opcode, toggle page 1/page 2 soft switches to steer subsequent writes between MAIN and AUX memory - while I'm here, squeeze out some unnecessary operations from the buffer management On the player side, this is implemented by maintaining two screen memory maps, and alternating between opcode streams for each of them. This is using entirely the wrong colour model for errors, but surprisingly it already works pretty well in practise (and the frame rate is acceptable on test videos) DHGR/HGR could be made runtime selectable by adding a header byte that determines whether to set the DHGR soft switches before initiating the decode loop. While I'm in here, fix op_terminate to clear keyboard strobe before waiting.
2019-03-27 21:37:06 +00:00
; Clear aux screen
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
STA PAGE2ON ; AUX memory active
; Co-opt HGR internals to clear AUX for us.
Proof of concept DHGR encoding/playback - Every time we process an ACK opcode, toggle page 1/page 2 soft switches to steer subsequent writes between MAIN and AUX memory - while I'm here, squeeze out some unnecessary operations from the buffer management On the player side, this is implemented by maintaining two screen memory maps, and alternating between opcode streams for each of them. This is using entirely the wrong colour model for errors, but surprisingly it already works pretty well in practise (and the frame rate is acceptable on test videos) DHGR/HGR could be made runtime selectable by adding a header byte that determines whether to set the DHGR soft switches before initiating the decode loop. While I'm in here, fix op_terminate to clear keyboard strobe before waiting.
2019-03-27 21:37:06 +00:00
LDA #$20
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
JSR HGR0
Proof of concept DHGR encoding/playback - Every time we process an ACK opcode, toggle page 1/page 2 soft switches to steer subsequent writes between MAIN and AUX memory - while I'm here, squeeze out some unnecessary operations from the buffer management On the player side, this is implemented by maintaining two screen memory maps, and alternating between opcode streams for each of them. This is using entirely the wrong colour model for errors, but surprisingly it already works pretty well in practise (and the frame rate is acceptable on test videos) DHGR/HGR could be made runtime selectable by adding a header byte that determines whether to set the DHGR soft switches before initiating the decode loop. While I'm in here, fix op_terminate to clear keyboard strobe before waiting.
2019-03-27 21:37:06 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
STA PAGE2OFF ; MAIN memory active
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
@1:
JSR HGR ; nukes the startup code we placed in HGR segment
STA FULLSCR
Proof of concept DHGR encoding/playback - Every time we process an ACK opcode, toggle page 1/page 2 soft switches to steer subsequent writes between MAIN and AUX memory - while I'm here, squeeze out some unnecessary operations from the buffer management On the player side, this is implemented by maintaining two screen memory maps, and alternating between opcode streams for each of them. This is using entirely the wrong colour model for errors, but surprisingly it already works pretty well in practise (and the frame rate is acceptable on test videos) DHGR/HGR could be made runtime selectable by adding a header byte that determines whether to set the DHGR soft switches before initiating the decode loop. While I'm in here, fix op_terminate to clear keyboard strobe before waiting.
2019-03-27 21:37:06 +00:00
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
; establish invariants expected by decode loop
LDY #>RXBASE ; High byte of socket 0 receive buffer
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
LDX #headerlen ; End of header
LDA #>S0RXRSR
STA WADRH
; fall through
- Add some comments - Change ACK code to perform two dummy stream reads rather than relying on a preceding NOP to pad the TCP frame to 2K. This fixes the timing issue that was causing most of the low-frequency ticks. - Ticks still aren't perfectly aligned during the ACK slow path but it's almost good enough, i.e. probably no need to actually bother optimizing the slow path more.
2019-03-15 21:08:06 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; This is the main audio/video decode loop.
;
; The outer loop waits for the socket buffer to contain >2K of pending data before
; dispatching to the inner loop.
;
; The inner loop is structured in terms of "player opcodes", which receive any parameters
; from the TCP stream, and conclude with 2 bytes that are used as JMP address to the next
; opcode.
;
; Everything here has the following invariants:
; - opcodes are expected to take 73 cycles
; - (though the NOP and TERMINATE opcodes don't do this but they're only used at the start/
; end of the stream).
; - opcodes must maintain X=0 upon completion.
; - this is assumed in some of the tick opcodes as a trick to get an extra cycle
; via STA foo,X (5 cycles) instead of STA foo (4 cycles)
;
; During the ACK opcode and subsequent outer loop transit, we keep ticking the speaker
Add more comments and clean up timings for op_ack. Magically, this all fits in exact multiples of 36/37 ticks!
2019-03-15 22:42:33 +00:00
; every 36/37 cycles to maintain a multiple of 73 cycles. Because we guarantee that the ACK
; appears every 2048 bytes, this lets us simplify the accounting for the W5100 socket buffer
; management (moving the address pointer etc).
; Somewhat magically, the cycle timings all align on multiples of 73 (with tick intervals
; alternating 36 and 37 cycles, as in the "neutral" (i.e. 50% speaker duty cycle)
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
; op_tick_36_* opcodes), without much work needed to optimize this.
Add more comments and clean up timings for op_ack. Magically, this all fits in exact multiples of 36/37 ticks!
2019-03-15 22:42:33 +00:00
;
; With a 73 cycle fundamental opcode (speaker) period and 1MHz clock speed, this gives a
; 14364 Hz "carrier" for the audio DAC, which is slightly audible (at least to my ageing
; ears) but quite acceptable.
;
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
; i.e. we get about 14364 player opcodes/second, with the op_ack + checkrecv + op_nop
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
; "slow path" costing 2 opcodes. Each of the "fat" audio/video opcodes results in storing
Update main.s Fix last-minute typo
2019-03-28 23:29:10 +00:00
; 4 video bytes, so we store about 56KB of video data per second.
Add more comments and clean up timings for op_ack. Magically, this all fits in exact multiples of 36/37 ticks!
2019-03-15 22:42:33 +00:00
;
; With 192x40 = 7680 visible bytes on the hires screen, this means we can do about 7.5 full
; page redraws/sec; but the effective frame rate will usually be much higher than this
; since we only prioritize the parts of the screen that are changing between frames.
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
; Wait until we have enough received data, and
;
; Notice that this has the only conditional opcodes in the entire decode loop ;-)
;
; Calling invariants:
; X = 0
; Y register has the high byte of the W5100 address pointer in the RX socket code, so we
; can't trash this until we are ready to point back there.
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
checkrecv:
BIT TICK ; 4
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
LDA #<S0RXRSR ; 2 Socket 0 Received Size register
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
STA WADRL ; 4
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
LDA WDATA ; 4 High byte of received size
CMP #$08 ; 2 expect at least 2k
; TODO: check this doesn't cross a page bdy or it will add a cycle
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BCS recv ; 3 There is data...we don't care exactly how much because it's at least 2K
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
; TODO: Not sure whether this delay is needed?
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
NOP ; Little delay ...
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
NOP
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
JMP checkrecv ; Check again
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
; There is data to read - restore W5100 address pointer where we last found it
;
; It turns out that the W5100 automatically wraps the address pointer at the end of the 8K RX/TX buffers
; Since we're using an 8K socket, that means we don't have to do any work to manage the read pointer!
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
recv: ; 15 cycles so far
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
; point W5100 back into the RX buffer where we left off in op_ack
STY WADRH ; 4
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
STX WADRL ; 4 normally X=0 here from op_ack except during first frame when we have just read the header.
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
; Check for keypress and pause the video
@0: BIT KBD ; 4
; TODO: check this doesn't cross a page bdy or it will add a cycle
BPL @2 ; 3 nope
; Wait for second keypress to resume
BIT KBDSTRB ; clear strobe
@1: BIT KBD
BPL @1
BIT KBDSTRB ; clear strobe
; fall through - tick timings don't matter
; pad cycles to keep ticking on 36/37 cycle cadence
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
; TODO: what can we do with the luxury of 14 unused cycles?!
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
@2: ; 30 so far
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
; X will usually already be 0 from op_ack except during first frame when reading
; header but reset it unconditionally
LDX #$00 ; 2
BIT TICK ; 4 ; 36
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
NOP ; 2
STA dummy ; 4
STA dummy ; 4
STA dummy ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
op_nop:
Try to even out tick timings during ACK/slow path
2019-03-10 21:04:20 +00:00
LDY WDATA ; 4
STY @D+2 ; 4
LDY WDATA ; 4
STY @D+1 ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
@D:
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
JMP op_nop ; 3 ; 23 with following tick (37 in fallthrough case)
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; Build macros for "fat" opcodes that do the following:
; - tick twice, N cycles apart (N = 4 .. 66 in steps of 2)
; - read a content byte from the stream
; - have an opcode-specific page offset configured (e.g. STA $2000,Y)
; - read 4 page offsets from the stream
; - store the content byte at these offsets
; - read 2 bytes from the stream as address of next opcode
;
; Each opcode has 6 cycles of padding, which is necessary to support reordering things to
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
; get the second "BIT TICK" at the right cycle offset.
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
;
; Where possible we share code by JMPing to a common tail instruction sequence in one of the
; earlier opcodes. This is critical for reducing code size enough to fit.
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro ticklabel page, cycles_left
.concat ("_op_tick_page_", .string(page), "_tail_", .string(cycles_left))
.endmacro
.macro tickident page, cycles_left
.ident (.concat ("_op_tick_page_", .string(page), "_tail_", .string(cycles_left))):
.endmacro
.macro op_tick_4 page
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
;4+(4)+2+4+4+4+5+4+5+4+5+4+5+4+4+4+4+3=73
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.ident (.concat ("op_tick_4_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
STA zpdummy ; 3
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
; load content byte
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 59
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
; 4 x offset stores
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 55
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 51
STA page << 8,Y ; 5
tickident page, 46
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 42
STA page << 8,Y ; 5
tickident page, 37
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 33
STA page << 8,Y ; 5
tickident page, 28
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 24
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
; vector to next opcode
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 19
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 15
STA .ident(.concat ("_op_tick_4_page_", .string(page), "_jmp"))+2 ; 4
tickident page, 11
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 7
STA .ident(.concat ("_op_tick_4_page_", .string(page), "_jmp"))+1 ; 4
.ident(.concat ("_op_tick_4_page_", .string(page), "_jmp")):
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
JMP op_nop ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_6 page
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(2+4)+3+4+4+5+4+5+4+5+4+5+4+4+4+5+3
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_6_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
NOP ; 2
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 60
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 56
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 52
STA page << 8,Y ; 5
tickident page, 47
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 43
STA page << 8,Y ; 5
tickident page, 38
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 34
STA page << 8,Y ; 5
tickident page, 29
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 25
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 20
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 16
STA .ident(.concat ("_op_tick_6_page_", .string(page), "_jmp"))+2 ; 4
tickident page, 12
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
tickident page, 8
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
; NB: we use ,X indexing here to get an extra cycle. This requires us to
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; maintain the invariant X=0 across opcode dispatch. Surprisingly this doesn't turn
; out to be a big deal.
STA .ident(.concat ("_op_tick_6_page_", .string(page), "_jmp"))+1,X ; 5
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.ident (.concat ("_op_tick_6_page_", .string(page), "_jmp")):
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
JMP op_nop ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_8 page
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+4)+3+3+55
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.ident (.concat ("op_tick_8_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_55")) ; 3 + 55
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_10 page
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+2+4)+3+56
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.ident (.concat ("op_tick_10_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
NOP ; 2
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_56")) ; 3 + 56
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_12 page
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+4+4)+3+3+51
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.ident (.concat ("op_tick_12_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_51")) ; 3 + 51
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_14 page
Optimize more. Should now fit in main memory?!
2019-03-05 22:44:39 +00:00
;4+(4+4+2+4)+3+52
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_14_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
NOP ; 2
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_52")) ; 3+52
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_16 page
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
; 4+(4+4+4+4)+5+2+3+43
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_16_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; This temporarily violates X=0 invariant required by tick_6, but lets us share a
; common opcode tail; otherwise we need a dummy 4-cycle opcode between the ticks, which
; doesn't leave enough to JMP with.
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
LDX WDATA ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,x ; 5
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
LDX #$00 ; 2 restore X=0 invariant
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_43")) ; 3 + 43
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_18 page
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
; 4 + (4+4+4+2+4)+5+5+2+2+4+5+4+5+4+4+4+4+3
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_18_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
LDA WDATA ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
; lets us reorder the 5-cycle STA page << 8,y outside of tick loop.
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
; This temporarily violates X=0 invariant required by tick_6
LDX WDATA ; 4
NOP ; 2
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
STA page << 8,X ; 5
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
LDX #$00 ; 2 restore X=0 invariant
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; used >3 pad cycles already; can't branch to tail
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
NOP ; 2
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
; vector to next opcode
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
STA @D+2 ; 4
LDA WDATA ; 4
STA @D+1 ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
@D:
JMP op_nop ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
.macro op_tick_20 page
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+4+5+3+4)+3+46=73
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_20_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_46"))
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; TODO: this one actually has 21 cycles between ticks, not 22
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_22 page
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; 4+(4+4+5+4+4)+3+3+42
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.ident (.concat ("op_tick_22_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize more. Should now fit in main memory?!
2019-03-05 22:44:39 +00:00
STA zpdummy ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_42")) ; 3 + 42
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_24 page
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+4+5+4+3+4)+3+42
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_24_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_42"))
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_26 page ; pattern repeats from op_tick_8
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
; 4+(4+4+5+4+5+4)+3+37
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_26_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_37")) ; 3 + 37
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_28 page ; pattern repeats from op_tick_10
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
; 4+(4+2+4+5+4+5+4)+3+38
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_28_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
NOP ; 2
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_38"))
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_30 page ; pattern repeats from op_tick_12
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+4+5+4+5+4+4)+3+3+33
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_30_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_33")) ; 3 + 33
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_32 page ; pattern repeats from op_tick_14
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+4+5+4+5+4+2+4)+3+34
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_32_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
NOP ; 2
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_34"))
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_34 page ; pattern repeats from op_tick_16
Optimize some more to fit in memory!
2019-03-10 21:57:05 +00:00
; 4+(4+4+5+4+5+4+4+4)+2+5+5+3+20
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_34_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
LDX WDATA ; 4 ; allows reordering STA ...,X outside ticks
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Optimize some more to fit in memory!
2019-03-10 21:57:05 +00:00
STA page << 8,X ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize some more to fit in memory!
2019-03-10 21:57:05 +00:00
LDX #$00 ; 2 restore X=0 invariant
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_20")) ; 3+20
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_36 page ; pattern repeats from op_tick_18
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
;4+(4+4+5+4+5+4+4+2+4)+5+5+2+2+4+4+4+4+3
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_36_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
LDX WDATA ; 4
NOP ; 2
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
STA page << 8,X ; 5
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
LDX #$00 ; 2
NOP ; 2
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; used >3 pad cycles between tick pair and restoring invariant; can't branch to tail
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Fix up all but two of the off-by-one tick counts. This uses the trick of temporarily violating the X=0 invariant (which is only required in the tick_6 opcode tail path to steal an extra cycle) to reorder a STA $2000,Y outside of the tick loop. The cost of this is that we don't have enough pad cycles left to JMP to the common opcode tail, but I think this still (barely) fits in main RAM.
2019-03-05 23:20:17 +00:00
LDA WDATA ; 4
STA @D+2 ; 4
LDA WDATA ; 4
STA @D+1 ; 4
@D:
JMP op_nop ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_38 page ; pattern repeats from op_tick_20
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
; 4 + (4+4+5+4+5+4+5+3+4)+3+28
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_38_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_28")) ; 3 + 28
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; TODO: this one actually has 41 cycles between ticks, not 40
.macro op_tick_40 page ; pattern repeats from op_tick_22
Optimize more. Should now fit in main memory?!
2019-03-05 22:44:39 +00:00
;4+(4+4+5+4+5+4+5+4+4)+3+3+24
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_40_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize more. Should now fit in main memory?!
2019-03-05 22:44:39 +00:00
STA zpdummy
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_24"))
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_42 page ; pattern repeats from op_tick_24
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+4+5+4+5+4+5+4+3+4)+3+24
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_42_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_24")) ; 3 + 24
.endmacro
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_44 page ; pattern repeats from op_tick_26
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
; 4 + (4+4+5+4+5+4+5+4+5+4)+3+3+19
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_44_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_19")) ; 3 + 19
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_46 page ; pattern repeats from op_tick_28
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+2+4+5+4+5+4+5+4+5+4)+3+20
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_46_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
NOP ; 2
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_20"))
.endmacro
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_48 page ; pattern repeats from op_tick_30
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+4+5+4+5+4+5+4+5+4+4)+3+3+15
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_48_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_15")) ; 3 + 15
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_50 page ; pattern repeats from op_tick_32
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+4+5+4+5+4+5+4+5+4+2+4)+3+16
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_50_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
NOP ; 2
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Add custom cc65 config that makes space for a LOWCODE segment from 0x800-0x2000 Place some of the tick opcodes there. This gives enough room for all but 2 of the op_tick_*_page_n opcodes! It may be possible to fit the remaining ones into unused RAM in the language card, but this will require some finesse to get the code in there. Or maybe I can optimize enough bytes... 0x300 is used by the loader.system, but there is also still 0x400..0x800 if I don't mind messing up the text page, and 0x200 if I can get away with using the keyboard buffer. Something is broken with RESET now though, maybe the reset vector is pointing somewhere orphaned.
2019-03-09 22:35:56 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_16"))
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_52 page ; pattern repeats from op_tick_34
Optimize some more to fit in memory!
2019-03-10 21:57:05 +00:00
;4+(4+4+5+4+5+4+5+4+5+4+4+4)+2+3+12
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_52_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
Optimize some more to fit in memory!
2019-03-10 21:57:05 +00:00
STA .ident (.concat ("_op_tick_6_page_", .string(page), "_jmp"))+2 ; 4
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Optimize some more to fit in memory!
2019-03-10 21:57:05 +00:00
NOP ; 2
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize some more to fit in memory!
2019-03-10 21:57:05 +00:00
JMP .ident(.concat("_op_tick_page_", .string(page), "_tail_12"))
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_54 page ; pattern repeats from op_tick_36
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
; 4 + (4+4+5+4+5+4+5+3+3+4+5+4+4)+4+4+4+3
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_54_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
STA zpdummy ; 3
STA zpdummy ; 3
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; used >3 pad cycles between tick pair; can't branch to tail
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA @D+2 ; 4
LDA WDATA ; 4
STA @D+1 ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
@D:
JMP op_nop ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_56 page
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
; 4+(4+4+5+4+5+4+5+4+5+4+4+4+4)+2+4+4+3
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_56_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
STA @D+2 ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA dummy ; 4
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; used >3 pad cycles between tick pair; can't branch to tail
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
NOP ; 2
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
STA @D+1 ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
@D:
JMP op_nop ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_58 page ; pattern repeats from op_tick_40
Optimize more. Should now fit in main memory?!
2019-03-05 22:44:39 +00:00
;4+(4+4+5+4+5+4+5+4+5+4+4+3+3+4)+4+4+3
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_58_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
STA @D+2 ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize more. Should now fit in main memory?!
2019-03-05 22:44:39 +00:00
STA zpdummy ; 3
STA zpdummy ; 3
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; used >3 pad cycles between tick pair; can't branch to tail
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
STA @D+1 ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
@D:
JMP op_nop ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_60 page
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
; 4+(4+4+5+4+5+4+5+4+5+4+4+4+4+4)+2+4+3
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_60_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
STA @D+2 ; 4
LDA WDATA ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA dummy ; 4
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; used >3 pad cycles between tick pair; can't branch to tail
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
NOP ; 2
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA @D+1 ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
@D:
JMP op_nop ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_62 page
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+4+5+4+5+4+5+4+5+4+4+4+3+3+4)+4+3
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_62_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
STA @D+2 ; 4
LDA WDATA ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
STA zpdummy ; 3
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
; used >3 pad cycles between tick pair; can't branch to tail
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA @D+1 ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
@D:
JMP op_nop ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.macro op_tick_64 page
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
;4+(4+4+5+4+5+4+5+4+5+4+4+4+4+4+4)+2+3
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_64_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
STA @D+2 ; 4
LDA WDATA ; 4
STA @D+1 ; 4
STA dummy ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
NOP ; 2
@D:
JMP op_nop ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.macro op_tick_66 page ; pattern repeats from op_tick_8
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
; 4+(4+4+5+4+5+4+5+4+5+4+4+4+3+4+3+4)+3
- Improve comments and clean up a bit - un-orphan the code that sets up 5 connection retries - Pad CHECKRECV loop to 36,37,36,37 tick cycles
2019-03-15 22:18:03 +00:00
.ident (.concat ("op_tick_66_page_", .string(page))):
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDA WDATA ; 4
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
LDY WDATA ; 4
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
STA page << 8,Y ; 5
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
LDA WDATA ; 4
STA @D+2 ; 4
LDA WDATA ; 4
STA @D+1 ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Optimize down to about 42k required for full set of page opcodes - enough to fit in AUX RAM but still room to go, hopefully will be able to fit in MAIN? Fix some of the off-by-one cycle counts introduced when switching from STA tick (which is wrong since it accesses twice) to BIT tick. Hopefully can fix others by reordering?
2019-03-05 22:22:35 +00:00
STA zpdummy ; 3
STA zpdummy ; 3
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
@D:
JMP op_nop ; 3
Parametrize opcodes as macros
2019-03-07 15:20:43 +00:00
.endmacro
- Add some comments - Change ACK code to perform two dummy stream reads rather than relying on a preceding NOP to pad the TCP frame to 2K. This fixes the timing issue that was causing most of the low-frequency ticks. - Ticks still aren't perfectly aligned during the ACK slow path but it's almost good enough, i.e. probably no need to actually bother optimizing the slow path more.
2019-03-15 21:08:06 +00:00
; convenience macro for enumerating all tick opcodes for a page
Move to 0x4000 for now Generate opcodes for pages 32-49 which fit in memory without effort.
2019-03-07 15:53:35 +00:00
.macro op_tick page
op_tick_4 page
op_tick_6 page
op_tick_8 page
op_tick_10 page
op_tick_12 page
op_tick_14 page
op_tick_16 page
op_tick_18 page
op_tick_20 page
op_tick_22 page
op_tick_24 page
op_tick_26 page
op_tick_28 page
op_tick_30 page
op_tick_32 page
op_tick_34 page
op_tick_36 page
op_tick_38 page
op_tick_40 page
op_tick_42 page
op_tick_44 page
op_tick_46 page
op_tick_48 page
op_tick_50 page
op_tick_52 page
op_tick_54 page
op_tick_56 page
op_tick_58 page
op_tick_60 page
op_tick_62 page
op_tick_64 page
op_tick_66 page
.endmacro
- Add some comments - Change ACK code to perform two dummy stream reads rather than relying on a preceding NOP to pad the TCP frame to 2K. This fixes the timing issue that was causing most of the low-frequency ticks. - Ticks still aren't perfectly aligned during the ACK slow path but it's almost good enough, i.e. probably no need to actually bother optimizing the slow path more.
2019-03-15 21:08:06 +00:00
; now pack the tick opcodes into memory
Add custom cc65 config that makes space for a LOWCODE segment from 0x800-0x2000 Place some of the tick opcodes there. This gives enough room for all but 2 of the op_tick_*_page_n opcodes! It may be possible to fit the remaining ones into unused RAM in the language card, but this will require some finesse to get the code in there. Or maybe I can optimize enough bytes... 0x300 is used by the loader.system, but there is also still 0x400..0x800 if I don't mind messing up the text page, and 0x200 if I can get away with using the keyboard buffer. Something is broken with RESET now though, maybe the reset vector is pointing somewhere orphaned.
2019-03-09 22:35:56 +00:00
.segment "LOWCODE"
Move to 0x4000 for now Generate opcodes for pages 32-49 which fit in memory without effort.
2019-03-07 15:53:35 +00:00
op_tick 32
op_tick 33
op_tick 34
op_tick 35
op_tick 36
Optimize some more to fit in memory!
2019-03-10 21:57:05 +00:00
op_tick_4 63
op_tick_6 63
op_tick_8 63
op_tick_10 63
op_tick_12 63
op_tick_14 63
op_tick_16 63
op_tick_18 63
op_tick_20 63
op_tick_22 63
op_tick_24 63
Add custom cc65 config that makes space for a LOWCODE segment from 0x800-0x2000 Place some of the tick opcodes there. This gives enough room for all but 2 of the op_tick_*_page_n opcodes! It may be possible to fit the remaining ones into unused RAM in the language card, but this will require some finesse to get the code in there. Or maybe I can optimize enough bytes... 0x300 is used by the loader.system, but there is also still 0x400..0x800 if I don't mind messing up the text page, and 0x200 if I can get away with using the keyboard buffer. Something is broken with RESET now though, maybe the reset vector is pointing somewhere orphaned.
2019-03-09 22:35:56 +00:00
.segment "CODE"
Move to 0x4000 for now Generate opcodes for pages 32-49 which fit in memory without effort.
2019-03-07 15:53:35 +00:00
op_tick 37
op_tick 38
op_tick 39
op_tick 40
op_tick 41
op_tick 42
op_tick 43
op_tick 44
op_tick 45
op_tick 46
op_tick 47
op_tick 48
op_tick 49
Can fit in 7 more pages
2019-03-07 16:04:01 +00:00
op_tick 50
op_tick 51
op_tick 52
op_tick 53
op_tick 54
op_tick 55
op_tick 56
Add custom cc65 config that makes space for a LOWCODE segment from 0x800-0x2000 Place some of the tick opcodes there. This gives enough room for all but 2 of the op_tick_*_page_n opcodes! It may be possible to fit the remaining ones into unused RAM in the language card, but this will require some finesse to get the code in there. Or maybe I can optimize enough bytes... 0x300 is used by the loader.system, but there is also still 0x400..0x800 if I don't mind messing up the text page, and 0x200 if I can get away with using the keyboard buffer. Something is broken with RESET now though, maybe the reset vector is pointing somewhere orphaned.
2019-03-09 22:35:56 +00:00
op_tick 57
op_tick 58
op_tick 59
op_tick 60
op_tick 61
Optimize some more to fit in memory!
2019-03-10 21:57:05 +00:00
op_tick 62
op_tick_26 63
op_tick_28 63
op_tick_30 63
op_tick_32 63
op_tick_34 63
op_tick_36 63
op_tick_38 63
op_tick_40 63
op_tick_42 63
op_tick_44 63
op_tick_46 63
op_tick_48 63
op_tick_50 63
op_tick_52 63
op_tick_54 63
op_tick_56 63
op_tick_58 63
op_tick_60 63
op_tick_62 63
op_tick_64 63
op_tick_66 63
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Install RESET handler that exits to ProDOS Implement op_terminate which waits for a keypress and then exits.
2019-03-23 21:45:13 +00:00
op_terminate:
Proof of concept DHGR encoding/playback - Every time we process an ACK opcode, toggle page 1/page 2 soft switches to steer subsequent writes between MAIN and AUX memory - while I'm here, squeeze out some unnecessary operations from the buffer management On the player side, this is implemented by maintaining two screen memory maps, and alternating between opcode streams for each of them. This is using entirely the wrong colour model for errors, but surprisingly it already works pretty well in practise (and the frame rate is acceptable on test videos) DHGR/HGR could be made runtime selectable by adding a header byte that determines whether to set the DHGR soft switches before initiating the decode loop. While I'm in here, fix op_terminate to clear keyboard strobe before waiting.
2019-03-27 21:37:06 +00:00
LDA KBDSTRB ; clear strobe
@0: ; Wait for keypress
Install RESET handler that exits to ProDOS Implement op_terminate which waits for a keypress and then exits.
2019-03-23 21:45:13 +00:00
LDA KBD
Proof of concept DHGR encoding/playback - Every time we process an ACK opcode, toggle page 1/page 2 soft switches to steer subsequent writes between MAIN and AUX memory - while I'm here, squeeze out some unnecessary operations from the buffer management On the player side, this is implemented by maintaining two screen memory maps, and alternating between opcode streams for each of them. This is using entirely the wrong colour model for errors, but surprisingly it already works pretty well in practise (and the frame rate is acceptable on test videos) DHGR/HGR could be made runtime selectable by adding a header byte that determines whether to set the DHGR soft switches before initiating the decode loop. While I'm in here, fix op_terminate to clear keyboard strobe before waiting.
2019-03-27 21:37:06 +00:00
BPL @0
@1: ; key pressed
Install RESET handler that exits to ProDOS Implement op_terminate which waits for a keypress and then exits.
2019-03-23 21:45:13 +00:00
JMP exit
Add more comments and clean up timings for op_ack. Magically, this all fits in exact multiples of 36/37 ticks!
2019-03-15 22:42:33 +00:00
; Manage W5100 socket buffer and ACK TCP stream.
;
; In order to simplify the buffer management we expect this ACK opcode to consume
; the last 4 bytes in a 2K "TCP frame". i.e. we can assume that we need to consume
; exactly 2K from the W5100 socket buffer.
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
op_ack:
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Proof of concept DHGR encoding/playback - Every time we process an ACK opcode, toggle page 1/page 2 soft switches to steer subsequent writes between MAIN and AUX memory - while I'm here, squeeze out some unnecessary operations from the buffer management On the player side, this is implemented by maintaining two screen memory maps, and alternating between opcode streams for each of them. This is using entirely the wrong colour model for errors, but surprisingly it already works pretty well in practise (and the frame rate is acceptable on test videos) DHGR/HGR could be made runtime selectable by adding a header byte that determines whether to set the DHGR soft switches before initiating the decode loop. While I'm in here, fix op_terminate to clear keyboard strobe before waiting.
2019-03-27 21:37:06 +00:00
; allow flip-flopping the PAGE1/PAGE2 soft switches to steer writes to MAIN/AUX screens
; actually this allows touching any $C0XX soft-switch, in case that is useful somehow
LDA WDATA ; 4
STA @D+1 ; 4
@D:
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
STA $C0FF ; 4 low-byte is modified
- Add some comments - Change ACK code to perform two dummy stream reads rather than relying on a preceding NOP to pad the TCP frame to 2K. This fixes the timing issue that was causing most of the low-frequency ticks. - Ticks still aren't perfectly aligned during the ACK slow path but it's almost good enough, i.e. probably no need to actually bother optimizing the slow path more.
2019-03-15 21:08:06 +00:00
LDA WDATA ; 4 dummy read of last byte in TCP frame
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
; Save the W5100 address pointer so we can come back here later
; We know the low-order byte is 0 because Socket RX memory is page-aligned and so is 2K frame.
; IMPORTANT - from now on until we restore this in RECV, we can't trash the Y register!
LDY WADRH ; 4
; Read Received Read pointer
LDA #>S0RXRD ; 2
Try to even out tick timings during ACK/slow path
2019-03-10 21:04:20 +00:00
STA WADRH ; 4
Proof of concept DHGR encoding/playback - Every time we process an ACK opcode, toggle page 1/page 2 soft switches to steer subsequent writes between MAIN and AUX memory - while I'm here, squeeze out some unnecessary operations from the buffer management On the player side, this is implemented by maintaining two screen memory maps, and alternating between opcode streams for each of them. This is using entirely the wrong colour model for errors, but surprisingly it already works pretty well in practise (and the frame rate is acceptable on test videos) DHGR/HGR could be made runtime selectable by adding a header byte that determines whether to set the DHGR soft switches before initiating the decode loop. While I'm in here, fix op_terminate to clear keyboard strobe before waiting.
2019-03-27 21:37:06 +00:00
LDX #<S0RXRD ; 2
STX WADRL ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
BIT TICK ; 4 (36)
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
LDA WDATA ; 4 Read high byte
; No need to read low byte since it's guaranteed to be 0 since we're at the end of a 2K frame.
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
; Update new Received Read pointer
; We have received an additional 2KB
CLC ; 2
ADC #$08 ; 2
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
STX WADRL ; 4 Reset address pointer, X still has #<S0RXRD
STA WDATA ; 4 Store high byte
; No need to store low byte since it's unchanged at 0
; Send the Receive command
Try to even out tick timings during ACK/slow path
2019-03-10 21:04:20 +00:00
LDA #<S0CR ; 2
STA WADRL ; 4
LDA #SCRECV ; 2
STA WDATA ; 4
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
Minor cleanups: - Use a safe ZP address instead of $00 - Use dec instead of hex for IP address bytes - Remove some unused Uthernet/W5100 defines Optimize the socket buffer management - Since we're guaranteeing 2K frame padding, the low byte is always 0 - Remove some vestiges of the Uthernet TCP demo code - AFAICT there isn't a need to compare high and low bytes of the S0RXRSR, this was just being used as a (slightly risky) check that they were both not equal (presumably to 0) - (h/t Oliver Schmidt <ol.sc@web.de>) it turns out that the W5100 automatically wraps the address pointer at the end of the 8k RX/TX buffer space, so since we're using 8k buffers we don't need any of the pointer/mask arithmetic to make sure we don't stray outside this range - Instead, we can just save the W5100 address pointer before we start doing the stream buffer management and restore it when we're ready to read from the stream again. - Moreover, since we know the low-byte is 0 we don't even need to save it. This gives us enough free cycles to implement a keypress check. For now any key will pause the video and any other key resume it. We still have a whole 16 cycles left over while maintaining the 36/37 cycle tick cadence. We've saved 73 cycles of "dead time" though, i.e. the op_ack + CHECKRECV + op_nop "slow path" now takes 2*73 rather than 3*73 cycles. This should result in better audio quality.
2019-03-28 23:08:52 +00:00
; This will do double-duty:
; - restoring the invariant expected by the op_tick opcodes
; - used as the low byte for resetting the W5100 address pointer when we're ready to start processing more data
LDX #$00 ; 2 restore invariant for dispatch loop
Add more comments and clean up timings for op_ack. Magically, this all fits in exact multiples of 36/37 ticks!
2019-03-15 22:42:33 +00:00
Introduce a 7-byte video header and use it to select between HGR and DHGR playback modes. Actually the only difference is whether to initialize (D)HGR display since everything else is steered by the video stream. 6 of these bytes are currently unused, but it is convenient to pad to the same length as the TICK opcode so that it does not complicate the ACK stream framing. Move towards the convention of using upper-case labels for system use (soft switches etc) and lower-case for program use.
2019-04-25 15:25:36 +00:00
JMP checkrecv ; 3 (37 with following BIT TICK)
; Quit to ProDOS
exit:
INC RESET_VECTOR+2 ; Invalidate power-up byte
JSR PRODOS ; Call the MLI ($BF00)
.BYTE $65 ; CALL TYPE = QUIT
.ADDR exit_parmtable ; Pointer to parameter table
exit_parmtable:
.BYTE 4 ; Number of parameters is 4
.BYTE 0 ; 0 is the only quit type
.WORD 0000 ; Pointer reserved for future use
.BYTE 0 ; Byte reserved for future use
.WORD 0000 ; Pointer reserved for future use
Prototype audio-only player, which uses a different strategy for scheduling audio + video. Use a combined "fat" audio + video opcode that combines several features: - constant cycle count of 73 cycles/opcode (=14364 Hz) - page and content are controlled per opcode - each opcode does 4 offset stores (hence 57456 stores/sec) - tick speaker twice per opcode, with varying duty cycles 4 .. 70 in units of 2 cycles - thus 32 opcodes, or 5-bit audio @ 14364 Hz The price for this is that we need per-page variants of the opcodes, and at 53 bytes/opcode they won't (quite) all fit even in AUX RAM. The good news is that with some further work it should be possible to reduce this footprint by having opcodes share implementation by JMPing into a common tail sequence. Also introduce some ticks in approximately correct places during the ACK slow path, as a proof of concept that this does mitigate the clicking. This works and gives reasonable quality audio!
2019-03-05 21:05:41 +00:00
; CLOSE TCP CONNECTION
CLOSECONN:
LDA #>S0CR ; HIGH BYTE NEEDED
STA WADRH
LDA #<S0CR
STA WADRL
LDA #SCDISCON ; DISCONNECT
STA WDATA ; SEND COMMAND
.endproc
Reference in New Issue Copy Permalink