You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know you've said you're not completely familiar with the Tube in the previous issue I raised, but Is there a reason why jsBeeb's implementation forces me to write code that introduces a delay between repeatedly polling the ULA to know when the R1 FIFO has space and then writing to it, and doing the same again, whereas on a real machine that is not required? It's slowing my parasite code down unnecessarily in jsBeeb, for something that needs to run as fast as possible.
The result of running the code in the .else block is that spurious values are received on the host side of R1 that are nothing to do with the actual values written on the parasite side, at a rate of roughly 500ms. Hoping the 500ms points you to the cause.
In this instance, the parasite OS and Acorn host code have both been completely eliminated and this is raw, tight loop communication between both sides. This code snippet is run as part of a NMI handler on the parasite side.
; write the command queue
_loopCommandQueue
lda ZP_COMMAND_QUEUE_INPUT_PTR
cmp ZP_COMMAND_QUEUE_OUTPUT_PTR
bne _doCommandQueueByte
lda ZP_COMMAND_QUEUE_INPUT_PTR + 1
cmp ZP_COMMAND_QUEUE_OUTPUT_PTR + 1
beq _done
_doCommandQueueByte
lda (ZP_COMMAND_QUEUE_OUTPUT_PTR)
.ifdef JSBEEB_BROKEN_TUBE
; RAISE-ISSUE: Tube ULA timing
; the code in the .else block waits until there is space in the FIFO
; and is the exact same code as in the function TubeParasiteWriteR1
; I shouldn't need to introduce a delay like this
; I don't on a real machine or in BeebEm
; but I do in b-Em and jsBeeb
; this is parasite side and interrupts are enabled
; but nothing is even attempting to trigger them at this point
beq _send
cmp #0
bcs _send
_send
jsr TubeParasiteWriteR1
.else
_loopWaitUntilR1HasSpace
bit TUBE_STATUS_REGISTER_1_PARASITE
bvc _loopWaitUntilR1HasSpace
sta TUBE_DATA_REGISTER_1_PARASITE
.endif
inc ZP_COMMAND_QUEUE_OUTPUT_PTR
bne _loopCommandQueue
inc ZP_COMMAND_QUEUE_OUTPUT_PTR + 1
bne _loopCommandQueue
_done
Thanks
Sam
The text was updated successfully, but these errors were encountered:
Hi Sam! Honeslty, nothing in the Tube stuff is "on purpose" :) I copy pasted from various emulators until Tube Elite "sort of" worked. I can't imagine what's causing those 500ms pulses BUT I'll try and take a look.
Hello.
I know you've said you're not completely familiar with the Tube in the previous issue I raised, but Is there a reason why jsBeeb's implementation forces me to write code that introduces a delay between repeatedly polling the ULA to know when the R1 FIFO has space and then writing to it, and doing the same again, whereas on a real machine that is not required? It's slowing my parasite code down unnecessarily in jsBeeb, for something that needs to run as fast as possible.
The result of running the code in the .else block is that spurious values are received on the host side of R1 that are nothing to do with the actual values written on the parasite side, at a rate of roughly 500ms. Hoping the 500ms points you to the cause.
In this instance, the parasite OS and Acorn host code have both been completely eliminated and this is raw, tight loop communication between both sides. This code snippet is run as part of a NMI handler on the parasite side.
Thanks
Sam
The text was updated successfully, but these errors were encountered: