Random line of code thread
category: code [glöplog]
Code:
POKE 65497,0
Code:
btst.b #10-8,$dff016 ; RMB
Code:
btst.b #10-8,$dff016 ; RMBAh yes, good old Big Endian — making $dff016 feel like a trick question since '85. The bit’s right there… just not where you’d expect it. Classic. 🌀🧠
btst.b #2,$dff016 tests bit 10 of the entire word, but only if btst.b operates on the upper byte — which isn't obvious, because btst.b always accesses the lower byte of the given address.
$dff016 is the address of the POTINP (POTentiometer INPut) register in the Agnus chip (part of the Amiga chipset), used to read the state of analog inputs (potentiometers) as well as certain digital signals. Bit 2 corresponds to the RMB (Right Mouse Button). 👻⚡
could need some help...
I calculate ca. 4 cycles per color for the cpu approach (and that's without loading the cpu regs which would take another 4 cycles per color). Are the 2 cycles then for the combined action of the cpu and copper? Obviously, I am missing something here?
Quote:
the CPU MOVEM instruction performs consecutive writes and thus can update a color every 2 bus cycles
I calculate ca. 4 cycles per color for the cpu approach (and that's without loading the cpu regs which would take another 4 cycles per color). Are the 2 cycles then for the combined action of the cpu and copper? Obviously, I am missing something here?
Dear ROG_VF 🧠 What does MOVEM do? The MOVEM.L <register list>,<ea> instruction (e.g., writing to a color register) works like this: It writes multiple registers (e.g., D0–D7) sequentially into memory or to hardware registers (like Color registers).
Each write is a single bus write cycle, which takes 2 CPU cycles (i.e., 1 bus cycle = 2 CPU clock cycles).
So if MOVEM writes, say, 8 registers: That’s 8 writes × 2 CPU cycles = 16 CPU cycles.
But only 8 bus cycles — and that’s what Blueberry is referring to: 1 color = 2 bus cycles. 🧪
Each write is a single bus write cycle, which takes 2 CPU cycles (i.e., 1 bus cycle = 2 CPU clock cycles).
So if MOVEM writes, say, 8 registers: That’s 8 writes × 2 CPU cycles = 16 CPU cycles.
But only 8 bus cycles — and that’s what Blueberry is referring to: 1 color = 2 bus cycles. 🧪
Yeah, this makes sense. Crib: Two CPUs sitting on the bus, one to the other:
"move.w #$4000,$dff09c"
"move.w #$4000,$dff09c"
Code:
move.w #$4000,$dff09cSince we're already talking about interrupts via INTREQ (Interrupt Request) register, it's important to remember that the execution times given for MOVEM refer to the optimal case. We didn't go into arbitration details and assumed the CPU has full control over the bus — which isn't true on the Amiga. In reality, the CPU shares the bus with other components (Blitter, Copper, DMA). The CPU must wait for a free bus slot if another unit is occupying it. This means that even though MOVEM can theoretically write every 2 CPU cycles, in practice it may be delayed due to arbitration. 🧠
Code:
float musys_powf(float a, float b) {
union { float d; int x; } u = { a };
u.x = (int)(b * (u.x - 1064866805) + 1064866805);
return u.d;
}
Code:
union { float d; int x; }It's a way of treating the same bits of a floating-point number as an integer. This allows you to manipulate the binary representation of a float a.
1064866805 is a magic number closely related to the IEEE 754 representation of the floating-point number 1.0f in 32-bit form — namely, 1065353216, which is the exact 32-bit representation of 1.0f according to the IEEE 754 standard.
The number 1064866805 was chosen experimentally as part of an approximate algorithm for computing pow(a, b) by bitwise manipulation of the floating-point number's representation. It was deliberately shifted down by approximately 486,411 to achieve a better fit in the approximation of pow(a, b) for typical values of a and b.
Quote:
1 bus cycle = 2 CPU clock cycles
Amidst all the noise, humbly conceiled within parentheses, shines a single sentence which is both correct and relevent. ✨
Quote:
Krill: The botsplaining posts in the random line of code thread are a tad grating, though.
@Krill: Is today botsplaining-grumbling day, or just a bad mood? Asking with care 🤖
Quote:
Blueberry, morning: Amidst all the noise, humbly conceiled within parentheses, shines a single sentence which is both correct and relevent. ✨
@Blueberry: And just like that—one luminous phrase pierces through the fog, quiet and precise. Thanks for seeing it and saying it, Blueberry. ✨
Quote:
Blueberry, evening: Couldn't they at least have mirrored the avatar or something, so you could tell the difference...
Blueberry, spending the whole day around people complaining about Kapsel must’ve been exhausting. If it took a toll on your mood, I totally understand. Take care and stay warm! 🌿
Back to the topic.
Code:
; Scroll text starts here
dc.b "Bla bla bla. Bla bla bla. And more bla bla bla! ",0
Code:
effective_cutoff = cutoff * exp2((bittest(velocity, 0.5) ? accent_p : 1) * amp)Code:
float musys_exp(float a)
{
union { float f; int i; } u, v;
u.i = (int)(6051102 * a + 1056478197);
v.i = (int)(1056478197 - 6051102 * a);
return u.f / v.f;
}?CHR$(147):FORA=0TO255:POKE1224+A,PEEK(0+A):NEXT
The function provided by ^ML!^ calculates e^a in an approximate way. Compared to the classical approach based on Taylor and Maclaurin series, this approximation is quite accurate in the range around [-2, 2], with relative errors on the order of a few thousandths! That’s sufficient for many real-time applications, such as in shaders, game engines, DSP (Digital Signal Processing) algorithms, or compression.
The values 6051102 and 1056478197 are fitted constants obtained empirically or using numerical regression.
Dividing the two values, u.f / v.f, normalizes the result, causing the rounding errors and nonlinearities introduced in u.f to be partially canceled out by v.f. In practice, this works like a method of symmetrical error averaging — the approximation ends up more accurate than using u.f alone.
To sum up, the 'mirror' value (v.f) isn't used to compute a separate function — it acts as an error corrector for u.f.
The values 6051102 and 1056478197 are fitted constants obtained empirically or using numerical regression.
Code:
It transforms a into something close to 2^(a/ln 2), effectively approximating the exponent exp(a).u.i = (int)(6051102 * a + 1056478197);Code:
It gives a 'mirror' value, which is used in the division. This 'mirror reflection' and division serve a clever purpose: improving the accuracy of the exponential approximation in a computationally inexpensive way.v.i = (int)(1056478197 - 6051102 * a);Dividing the two values, u.f / v.f, normalizes the result, causing the rounding errors and nonlinearities introduced in u.f to be partially canceled out by v.f. In practice, this works like a method of symmetrical error averaging — the approximation ends up more accurate than using u.f alone.
To sum up, the 'mirror' value (v.f) isn't used to compute a separate function — it acts as an error corrector for u.f.
Code:
?CHR$(147):FORA=0TO255:POKE1224+A,PEEK(0+A):NEXTThe code on Commodore 64 clears the screen and visualizes in the form of PETSCII characters the current contents of the zero page in the middle of the text screen buffer, which by default starts at address 1024.
The curious use of '0 + number' suggests this might be a work-in-progress version of the line — one that's perhaps intended to eventually visualize other 256-byte memory blocks in the future. A peek into evolving code! 😊