pouët.net

Go to bottom

Random line of code thread

category: code [glöplog]
Poke 53280,0
added on the 2025-04-24 06:21:00 by Punane Punane
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%
added on the 2025-04-25 08:13:06 by KeyJ KeyJ
Code: let (next_ref, next) = self.next_half_edge(he);

Not pictured: Banging my head against the table.
added on the 2025-04-25 11:08:57 by sagacity sagacity
Code:dc.w $0040,$1FE8
added on the 2025-05-07 18:18:26 by Blueberry Blueberry
var encoded = Packages.java.util.Base64.getEncoder().encodeToString(appended.getBytes(Packages.java.nio.charset.StandardCharsets.UTF_8));
added on the 2025-05-08 17:09:12 by uncle_H uncle_H
L-,
added on the 2025-05-09 11:30:41 by Punane Punane
Code:call Interpol
added on the 2025-05-21 12:13:03 by ltipl ltipl
Code:ana l \ rlc \ rlc \ rlc
added on the 2025-05-21 18:57:13 by svo svo
ADD ONE TO COBOL GIVING COBOL
added on the 2025-05-27 11:50:22 by orac81 orac81
Code:move.l #Copper-$b80000,$dff080
added on the 2025-05-30 11:08:00 by Blueberry Blueberry
I love doing lines
added on the 2025-06-09 00:19:32 by leaq leaq
int getRandomNumber() {return 4;} // Chosen by fair dice roll, guaranteed to be random (https://xkcd.com/221/)
added on the 2025-06-10 12:29:23 by orac81 orac81
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
added on the 2025-06-19 21:57:15 by Shantee Shantee
Code:ld a,high(-PLAYER_JUMP_HEIGHT_HIGH)
added on the 2025-06-20 06:11:41 by DevEd DevEd
Code:sub.b $dff007,d0 lsl.w d0,d0
added on the 2025-06-24 14:00:11 by Blueberry Blueberry
lsl.w d0,d0 — Ah, it warmed my heart to recall that pseudo-random raster register shuffling... 😈
added on the 2025-06-24 14:16:03 by kapsel kapsel
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?
added on the 2025-06-24 17:51:10 by Blueberry Blueberry
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.
added on the 2025-06-24 20:26:24 by kapsel kapsel
...provides you with a constant horizontal beam position?! But what is so sinister
about that?
added on the 2025-06-24 20:44:42 by ROG_VF ROG_VF
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? 😈
added on the 2025-06-24 21:06:13 by kapsel kapsel
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?
added on the 2025-06-25 06:58:09 by kapsel kapsel
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.
added on the 2025-06-25 08:07:22 by Blueberry Blueberry
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?
added on the 2025-06-25 10:59:31 by Krill Krill
Attaboy. Good human.
added on the 2025-06-25 11:04:58 by 4gentE 4gentE
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.
added on the 2025-06-25 11:10:49 by 4gentE 4gentE

login

Go to top