Random line of code thread
category: code [glöplog]
Poke 53280,0
SCREEN 8:KEY OFF:CLS:DEF SEG=&HA000:OUT &H3C4,2:FOR Y%=0 TO 199:FOR X%=0 TO 79:OUT &H3C5,(X%/13+Y%*Y%/4321) AND 15:POKE Y%*80+X%,X% XOR Y%:NEXT X%:NEXT Y%
Code:
let (next_ref, next) = self.next_half_edge(he);
Not pictured: Banging my head against the table.
Code:
dc.w $0040,$1FE8
var encoded = Packages.java.util.Base64.getEncoder().encodeToString(appended.getBytes(Packages.java.nio.charset.StandardCharsets.UTF_8));
L-,
Code:
call Interpol
Code:
ana l \ rlc \ rlc \ rlc
ADD ONE TO COBOL GIVING COBOL
Code:
move.l #Copper-$b80000,$dff080
I love doing lines
int getRandomNumber() {return 4;} // Chosen by fair dice roll, guaranteed to be random (https://xkcd.com/221/)
piece of a "tracker" i am making in 100% pure bash ^^
first_pattern=${SEQUENCE[0]}
eval "first_array=(\"\${${first_pattern}[@]}\")"
for ((i=0;i<${#first_array[@]};i++)); do
master="$tmpdir/master_${i}.raw"
>"$master"
MASTER+=("$master")
done
first_pattern=${SEQUENCE[0]}
eval "first_array=(\"\${${first_pattern}[@]}\")"
for ((i=0;i<${#first_array[@]};i++)); do
master="$tmpdir/master_${i}.raw"
>"$master"
MASTER+=("$master")
done
Code:
ld a,high(-PLAYER_JUMP_HEIGHT_HIGH)
Code:
sub.b $dff007,d0
lsl.w d0,d0
lsl.w d0,d0 — Ah, it warmed my heart to recall that pseudo-random raster register shuffling... 😈
I find it fascinating that those instructions make you think of random number generation.
This code snippet actually has a completely different, much more sinister purpose. Can you guess what it is?
This code snippet actually has a completely different, much more sinister purpose. Can you guess what it is?
Let me take a guess :) First attempt. Were you referring to detecting whether d0 contains 0? The lsl.w d0,d0 operation shifts the contents of register d0 to the left by the number of bits specified in that same register d0. So if d0 contains 0, no shift occurs, but the Z flag is set — a perfect way to check if the register holds 0 without using an explicit comparison.
...provides you with a constant horizontal beam position?! But what is so sinister
about that?
about that?
That was supposed to be a moment of sinister ambiguity… and you mercilessly dropped the spoiler about beam position 😜 The whole aura of mystery is gone! 😄 Since the beam sync fun is ruined, what now — shall we switch to Copper sync instead? 😈
So that you don't come across merely as a mutual admiration club with a slight tone of 'testing your mental resilience,' let's refresh the Amiga Hardware Reference Manual.
The lower byte of the VHPOSR register is located at the aforementioned address $dff007 — this represents the horizontal beam position, bits H8-H1. Remember to mentally append bit H0=0 at the end, i.e., multiply the beam's horizontal position by 2 to get an approximate X coordinate.
The sub.b $dff007,d0 instruction assumes that the least significant byte of d0 contains something comparable to the current horizontal beam position — probably the previous beam value. It looks as if we want to check whether the horizontal position has changed. This can be used for synchronization with a new pixel.
We still need to consider many other questions: what’s in the remaining part of the d0 register, whether getting a zero in the result on the lower bytes of d0 while the upper bytes are non-zero sets the Z bit, why not use a simple cmp.b $dff007,d0, or even how many bits of d0 are used by lsl.w to determine how many bits to shift, and that there's no such instruction as lsl.b $dff007,d0.
Returning to the question of whether d0 equals zero using lsl.w d0,d0, tell me, dear scener, what will be the result of lsl.w d0,d0 when d0 = 63? After all, 63 is a perfectly valid horizontal beam position. And what if d0 = 10? You may consult the Motorola 68000 Programmer's Reference Manual to assist in your reply.
Perhaps in your reply you could include a table of actual results from your Amiga or Atari ST showing the effect of the lsl.w d0,d0 instruction for d0 in the range 0 to 255?
The lower byte of the VHPOSR register is located at the aforementioned address $dff007 — this represents the horizontal beam position, bits H8-H1. Remember to mentally append bit H0=0 at the end, i.e., multiply the beam's horizontal position by 2 to get an approximate X coordinate.
The sub.b $dff007,d0 instruction assumes that the least significant byte of d0 contains something comparable to the current horizontal beam position — probably the previous beam value. It looks as if we want to check whether the horizontal position has changed. This can be used for synchronization with a new pixel.
We still need to consider many other questions: what’s in the remaining part of the d0 register, whether getting a zero in the result on the lower bytes of d0 while the upper bytes are non-zero sets the Z bit, why not use a simple cmp.b $dff007,d0, or even how many bits of d0 are used by lsl.w to determine how many bits to shift, and that there's no such instruction as lsl.b $dff007,d0.
Returning to the question of whether d0 equals zero using lsl.w d0,d0, tell me, dear scener, what will be the result of lsl.w d0,d0 when d0 = 63? After all, 63 is a perfectly valid horizontal beam position. And what if d0 = 10? You may consult the Motorola 68000 Programmer's Reference Manual to assist in your reply.
Perhaps in your reply you could include a table of actual results from your Amiga or Atari ST showing the effect of the lsl.w d0,d0 instruction for d0 in the range 0 to 255?
Quote:
...provides you with a constant horizontal beam position?! But what is so sinister
about that?
Spot on.
While cycle-exact beam synchronization of the CPU is the bread and butter of demo effects on many other platforms, it is my impression that its use on Amiga is very rare, due to the copper filling that role in a (usually) more practical way.
That's pretty neat. Usually it's very annoying that the shift operation takes longer with farther shifting on 68000, due to missing barrel-shifter, but it comes in very handy here. :)
But where on Amiga do you need to sync the CPU itself with the beam?
But where on Amiga do you need to sync the CPU itself with the beam?
Attaboy. Good human.
Yeah, sorry Krill. I thought HAL was playing you like a guitar. But in fact I was playing myself. Anyway, sorry for the interruption, back to code.