Excellent!
The ROM builder emits some information about available cycles on different scan line types.
Code: Select all
runVcpu at 014a cycles 100 info line0
runVcpu at 019a cycles 130 info line1-39 typeC
runVcpu at 01a1 cycles 134 info line1-39 typeABD
runVcpu at 01db cycles 126 info line40
runVcpu at 02ec cycles 148 info line41-520 typeBCD
This means the SYS instruction must fit in 148 cycles. Or ≤134 cycles if we want to maintain some minimum I/O level when the system is in video mode 0. From this, the vCPU+SYS overhead of 20 cycles still must be subtracted. That makes handling of 16 bits per scan line a rather high goal. If we achieve 8 bits we can hope to make the SYS function self-restarting and eliminate the loop overhead for multibyte transfer. (Much like the sprite functions that are self-restarting as well.)
Indeed, the masking and branching sets us back 3 cycles. We use the branch delay slot to keep it small. I think we can win one cycle back in the last instruction, for a total of 12 cycles per bit transfer. Like this:
Code: Select all
ld [data_reg],y ;once
ld [ctrl_reg],x
st $??,[y,x++]
st $??,[y,x++]
ld [$00]
st $??,[y,x]
anda [miso_mask]
beq .label
bra .label
ld $01
.label: adda [data_reg]
adda [data_reg]
st [data_reg],y
We'll have an unrolled loop anyway, and could address each bit directly if we so desire. This is a nice moment to reflect that 12 cycles take less than 2 microseconds...
I coin the mnemonic 'ctrl' for our new instruction. Maybe it should have its operands given without brackets, because we're not addressing RAM. Like so:
The point for the split MISO lines is primarily around the power-on behaviour. The /SS lines come up in an arbitrary state that lasts for 350 milliseconds before software starts running:
- Power on sequence
- photo_2019-02-23_21-12-57.jpg (72.05 KiB) Viewed 8964 times
[Well, technically, software is running in that time, but only repeating the instruction at ROM address 0.]
The point is, if multiple peripherals can drive a shared MISO line in this phase, that creates a short circuit.
We don't have a reset line on the RAM socket that can reset the flip-flops from hardware land. Adding another MCP450 power-on reset component alone doesn't solve it, because we've lost the output inverters along the way. It would also be nice if the user can't create a short circuit from software land.
Edit 1: Changed last "st $??,[y,x++]" to "st $??,[y,x]" because the increment is not used.
Edit 2: Moved "st $??,[y,x]"
before "anda [miso_mask]" because RAM is still disabled otherwise.
Note: Alternatively, "anda [miso_mask]" can become "anda 0xf" if the MISO lines are pulled-
down.
Edit 3: Fixed conditional sequence