Hacker News Reader

nynyny7on CrowdStrike Update: Windows Bluescreen and Boot Loops

Crowdstrike marketing slogan on their website: "A radical new approach proven to stop breaches". I'll give them that: Putting all Windows computers within a company into an endless BSOD loop is a very radical approach to stop breaches. :)

nynyny7on Atari Falcon030

As a sidenote, there is even an open-source recreation of the TOS operating system for the Atari 16/32 bit computers called EmuTOS that is in active development to this day. It just had a new release a few days ago: https://emutos.sourceforge.io/. And this new release happens to have better support for the Falcon video chip.

nynyny7on i386 Assembly Language trick for storing data in .text

I don't get the purpose, at least of his minimal example. The author says he wants to make his code position-independent, i.e., so that it can be executed from everywhere in memory (without relocation). But that is defeated by the...

mov edx, print

... in the example.

nynyny7on A C64 MP3 Player

As other commenters have pointed out, this is a C64 controlling an MP3 player.

People old enough to remember the late 1990s / early 2000s might recall that back then it was popular, too, to hook up an external MP3 decoder, e.g., to the parallel port; so that the PC's CPU would not be at 100% just for playing MP3 music.

nynyny7on 10BASE-T1S is the missing Ethernet link for automotive communications

10BASE-T1S is more of alternative/replacement/upgrade to CAN and CAN FD, which use a single wire pair as bus, too. And automotive 100 MBit/s and 1 GBit/s Ethernet are also single-pair. (But they are point-to-point and therefore more expensive, as the article explains.)

nynyny7on 10BASE-T1S is the missing Ethernet link for automotive communications

Exactly. A few dollars is an enormous price saving the automotive industry.

nynyny7on 10BASE-T1S is the missing Ethernet link for automotive communications

You'd be surprised how much the reduced cable cost matters to an OEM.

nynyny7on 10BASE-T1S is the missing Ethernet link for automotive communications

Not really. There is no ring, neither physically, nor logically. It's based on CSMA/CD, like the "good old" coaxial cable Ethernet. (Optionally it can use additional methods to avoid collisions, though.)

nynyny7on 10BASE-T1S is the missing Ethernet link for automotive communications

There isn't the connector for 10BASE-T1S or other Automotive Ethernet standards such as 100BASE-T1. OEMs (= car manufacturers) will often define their custom connector. E.g., the Ethernet signal might just occupy two pins on an much bigger ECU connector.

nynyny7on Inside the 1040ST

... and nowadays, retro-hobbyists can add USB(!) ports to the 1040ST: https://wiki.newtosworld.de/images/f/fd/Lightning_ST_IDE_USB...

nynyny7on Inside the 1040ST

As for "there seem to be quite a few different Atari 1040ST board designs" noted in the article. There is actually a huge number of different board layouts. Look at the entries for "STF" or "STFM" in this overview: https://temlib.org/AtariForumWiki/index.php/Atari_ST_motherb....

As for why Atari redesigned the board so many times: no idea.

nynyny7on A 74xx-Defined Radio (2021)

When I had my "I want to build my own SDR" phase ;) ca. 15 years ago, I also used analog switches as a switching mixer - with a PLL running at 4x the desired frequency so I could utilize dividers to get nice 0°, 90°, 180°, 270° LO signals for IQ mixing. Brings back memories...

nynyny7on Raspberry Pi Pico: What is this code doing in its boot ROM, line 442?

The quoted description is correct. The boot ROM loads code from flash: the "second stage" loader. That loader then (usually) configures the RP2040 to execute the actual application directly from flash.

But the "Easter egg" function discussed in this HN thread is not inside any code loaded/executed from flash. It is inside the boot ROM (as I've repeatedly stated); and that is indeed read-only memory, i.e., it cannot be modified except by manufacturing a new chip revision.

nynyny7on Raspberry Pi Pico: What is this code doing in its boot ROM, line 442?

What are you trying to say here? Please have a look into the RP2040 data sheet to understand what "boot ROM" means. It is not programmable!

https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...

"A 16kB read-only memory (ROM) is at address 0x00000000. The ROM contents are fixed at the time the silicon is manufactured."

nynyny7on Raspberry Pi Pico: What is this code doing in its boot ROM, line 442?

And here is code to run it on the actual hardware (i.e., Pi Pico or similar boards): https://gist.github.com/czietz/c37eab1e4623ad5f619e7acf84ee3...

Also returns 42.

nynyny7on Raspberry Pi Pico: What is this code doing in its boot ROM, line 442?

It is in the boot ROM; not in flash memory.

nynyny7on Raspberry Pi Pico: What is this code doing in its boot ROM, line 442?

As it is in ROM (inside the RP2040), removing it might involve a Focused Ion Beam machine ;-)...

nynyny7on Raspberry Pi Pico: What is this code doing in its boot ROM, line 442?

Okay. I have an idea. Let’s see what happens if we treat…

    06:  00 B5          push {lr}

… as the start of this weird code(?) sequence. It pushes the link register (i.e., the return address to the caller).

    08:  42 40          eors r2, r0
    0a:  00 2A          cmp  r2, #0

This XORs R2 and R0 and compares the result against zero. But that’s just a decoy, as we’ll see.

    0c:  00 F0 02 F8    bl   #0x14

This calls into…

    14:  70 46          mov  r0, lr
    16:  00 47          bx   r0

… which moves the return address to R0, and then returns. Using the addresses in this disassembly (not in the actual boot ROM), the return address is 0x10; but LR and, therefore, R0 will actually contain 0x11 because the LSB signifies Thumb mode.

None of the previous three instructions modifies the flags. (I checked in the ARM reference manual.) Thus, “BHS” (branch unsigned higher or same) uses the flags from the “CMP R2,#0” above. _Every_ value of R2 is higher (in the unsigned sense) or same as 0. Hence, the following branch is always taken:

    10:  F6 D2          bhs  #0

… to…

    00:  11 38          subs r0, #0x11

R0 contained 0x11 relative to the start of this code sequence. (The absolute address in boot ROM is of course different.) Now, R0 points to the start of the code sequence.

    02:  C0 7A          ldrb r0, [r0, #0xb]

This loads the byte at offset 0xB in this code sequence. Look above, it is 0x2A.

    04:  00 BD          pop  {pc}

This returns to the caller, using the LR pushed at the beginning. The return value in R0 is 0x2A.

0x2A is 42 (decimal)! Could this be an Easter egg; a very obfuscated way of returning 42, the Answer to the Ultimate Question of Life, the Universe, and Everything? (Remember that the Raspberry design team is from Britain, same as Douglas Adams.)

nynyny7on Raspberry Pi Pico: What is this code doing in its boot ROM, line 442?

The 'zphd' label seems to appear nowhere else in the boot ROM code, though: https://github.com/raspberrypi/pico-bootrom/search?q=zphd

nynyny7on Raspberry Pi Pico: What is this code doing in its boot ROM, line 442?

This makes a bit of sense when the actual entry point is at

    06:  00 B5          push {lr}

However, even then, the code appears unnecessarily convoluted. Easter egg? Back door ;-)?

nynyny7on Raspberry Pi Pico: What is this code doing in its boot ROM, line 442?

Lines 442-445, but apparently line numbers are stripped from GitHub URLs posted to HN: https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5...

nynyny7on How to take credit for someone else's work on GitHub

Yes, as it is rewriting history. And that would be a massively bad idea.

nynyny7on How to take credit for someone else's work on GitHub

Interesting. One never stops learning new git features...

However, while this works for git (i.e., maps old address to new address in "git log" for example), GitHub does not seem to honor this file.

nynyny7on How to take credit for someone else's work on GitHub

I do see a point in it working like it does, though. I'm one of the lead developers on a free software project with over 20 years of history. Even though the project has used multiple version control systems (and hosting providers) over time, we have imported our entire project's history going back to the very first commit into git and GitHub.

Not every contributor has kept their email address for over 20 years. Some don't have access to the old addresses they once used for commits. Still they want the commits to be associated with their current GitHub account; even if it's just for statistics and "bragging rights".

If GitHub required email address verification, how would this be done?

EDIT: To be clear: With "working like it does" I'm referring to the possibility to add unverified email addresses to your account and have commits attributed to you.

nynyny7on mmWave radar, you won't see it coming

Hm, the article makes it sound as if mmWave radars are a fairly new addition to cars. But 77 GHz radar sensors have been in cars since over a decade now, thanks to suppliers such as Bosch and Continental.

nynyny7on Atari System V Unix – Unofficial Website

If your question was for a machine to run Atari System V Unix on, though, I'm afraid the answer is: an Atari TT. None of the m68k machines (or FPGA emulations thereof) mentioned in the other comments will run it.

Perhaps (but I didn't test) Atari System V Unix would run under the Hatari emulator.

nynyny7on Atari System V Unix – Unofficial Website

Apart from Atari's proprietary Unix, the TT also runs Linux (https://imgur.com/a/gpvi3du) and NetBSD (https://twitter.com/nbtt030).

nynyny7on A 100LOC C impl of memset, that is faster than glibc's

PS: It's STRD, which as far as I understand the Arm Architecture Reference Manual always requires word alignment.

  Program received signal SIGBUS, Bus error.
  small_memset (n=<optimized out>, c=<optimized out>, s=0x29690)
      at /home/pi/memset_benchmark/src/lib.c:33
  33          *((uint64_t *)last) = val8;
  1: x/i $pc
  => 0x11c8c <local_memset+1560>: strd    r0, [r7, #-8]
  (gdb) info registers
  r0             0x0                 0
  r1             0x0                 0
  r2             0x0                 0
  r3             0x1475              5237
  r4             0x5f5e100           100000000
  r5             0x11674             71284
  r6             0x29690             169616
  r7             0x29699             169625

nynyny7on A 100LOC C impl of memset, that is faster than glibc's

Yes it is 32 bit code on a 64 bit kernel. I didn't debug what the instruction is that ultimately causes the bus error.

  pi@rasppi400:~/memset_benchmark $ uname -a
  Linux rasppi400 5.10.63-v8+ #1459 SMP PREEMPT Wed Oct 6 16:42:49 BST 2021 aarch64 GNU/Linux
  pi@rasppi400:~/memset_benchmark $
  pi@rasppi400:~/memset_benchmark $ file ./bench_memset
  ./bench_memset: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=ebeb69b6cb9664d78c1256a2c862f3d28f11e15e, with debug_info, not stripped

nynyny7on A 100LOC C impl of memset, that is faster than glibc's

What do I mean by "not every CPU allows to make unaligned 32-bit or 64-bit writes"? Let's test the code (as of commit eac67b6) on a Raspberry Pi 400:

  pi@rasppi400:~/memset_benchmark $ uname -a
  Linux rasppi400 5.10.63-v8+ #1459 SMP PREEMPT Wed Oct 6 16:42:49 BST 2021 aarch64 GNU/Linux
  
  pi@rasppi400:~/memset_benchmark $ ./bench_memset
  size, alignment, offset, libc, local
  0, 16, 0, 1237452, 834116, 1.483549,
  1, 16, 0, 1612697, 945325, 1.705971,
  2, 16, 0, 1779538, 945320, 1.882472,
  3, 16, 0, 1557081, 945324, 1.647140,
  4, 16, 0, 1779527, 889736, 2.000062,
  5, 16, 0, 1557103, 1000940, 1.555641,
  6, 16, 0, 1779551, 1000944, 1.777873,
  7, 16, 0, 1557111, 1000945, 1.555641,
  8, 16, 0, 1334654, 889723, 1.500078,
  Bus error
  
  pi@rasppi400:~/memset_benchmark $ gdb ./bench_memset
  [...]
  (gdb) run
  Starting program: /home/pi/memset_benchmark/bench_memset
  size, alignment, offset, libc, local
  0, 16, 0, 1557105, 722928, 2.153887,
  1, 16, 0, 1557103, 889797, 1.749953,
  2, 16, 0, 1557107, 889849, 1.749855,
  3, 16, 0, 1557108, 889759, 1.750033,
  4, 16, 0, 1557117, 889789, 1.749985,
  5, 16, 0, 1557110, 889745, 1.750063,
  6, 16, 0, 1557116, 889754, 1.750052,
  7, 16, 0, 1557110, 889758, 1.750038,
  8, 16, 0, 1557109, 889803, 1.749948,
  
  Program received signal SIGBUS, Bus error.
  
  small_memset (n=<optimized out>, c=<optimized out>, s=0x29690)
      at /home/pi/memset_benchmark/src/lib.c:33
  33          *((uint64_t *)last) = val8;