nynyny7

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. :)

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.

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.

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.

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.)

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

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

Not really. There is no ring, neither physically, nor logically. It's based on CSMA/CD, like the "good old" coaxial cable Ethernet.

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.

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

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.

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...

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.

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."

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.

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

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

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.)