Juno First kernel demo
Based on some discussions in "The project after the project..." I decided to test out whether a ball-based kernel would work for a Juno-First style background. My conclusion: it works and is doable with a reasonable cycle load and in a reasonable amount of code on a banked cart, and horizontal motion looks great. Vertical motion is not so great, unfortunately. The pixels seem to be horizontally "jumpy" and I don't see any good remedy for that which would still have the dots move vertically. On the other hand, the effect is still rather neat for the 2600.Each row of "Juno First" pixels takes about a scan line to set up and a full scan line to display. The setup and display code need not be run consecutively, and it is expected that in a normal kernel they would not be (do sprites for one scan line, JF setup for a scan line, then sprites for a scanline, then JF display).The 'setup' scan line has no critical timings. It needs to be done before the next WSYNC, obviously, but there's a lot of flexibility. Accumulator, Y, and flags are trashed.The 'display' scan line starts with the following code sequence:
sty WSYNC ldy #2 sty ENABL JMP (JF_SB1)
That code is time-critical. If it's not necessary for pixels to go all the way to the left, it would be possible to steal a few cycles from that (depending upon how far left the pixels should go) but it would be necessary to adjust the master table. The display scan line ends with the sequence:
sta WSYNC jmp JF_EXIT
so the timing at JF_EXIT should be entirely predictable. THe display scan line routine trashes Y and flags, but does not affect A or X; it would be easily adaptable to use X instead of Y if necessary.EDITFixed scan-line count. Reversed left/right directions on controller. Changed darker dot color. Left difficulty switches between two vertical motion styles. I think the jerkier motion actually looks better, though it needs a lot less code.Fixed binary: Fixed source:
11 Comments
Recommended Comments