Chip Swap Fixes a Dead Amiga 600

The Amiga 600 was in its day the machine nobody really wanted — a final attempt to flog the almost original spec 68000 platform from 1985, in 1992. Sure it had a PCMCIA slot nobody used, and an IDE interface for a laptop hard drive, but it served only to really annoy anyone who’d bought one when a few months later the higher-spec 1200 appeared. It’s had a rehabilitation in recent years though as a retrocomputer, and [LinuxJedi] has a 600 motherboard in need of some attention.

As expected for a machine of its age it can use replacement electrolytic capacitors, and its reset capacitor had bitten the dust. But there’s more to that with one of these machines, as capacitor leakage can damage the filter circuitry surrounding its video encoder chip. Since both video and audio flow through this circuit, there was no composite video to be seen.

The hack comes in removing the original chip rather than attempt the difficult task of replacing the filter, and replacing it with a different Sony chip in the same series. It’s nicely done with a connector in the original footprint, and a small daughterboard. The A600 lives again, but this time it won’t be a disappointment to anyone.

If you want to wallow in some Amiga history as well as read a rant about what went wrong, we have you covered.

hackaday.com/2025/12/18/chip-s…

Bare Metal STM32: Increasing the System Clock and Running Dhrystone

When you start an STM32 MCU with its default configuration, its CPU will tick along at a leisurely number of cycles on the order of 8 to 16 MHz, using the high-speed internal (HSI) clock source as a safe default to bootstrap from. After this phase, we are free to go wild with the system clock, as well as the various clock sources that are available beyond the HSI.

Increasing the system clock doesn’t just affect the CPU either, but also affects the MCU’s internal buses via its prescalers and with it the peripherals like timers on that bus. Hence it’s essential to understand the clock fabric of the target MCU. This article will focus on the general case of increasing the system clock on an STM32F103 MCU from the default to the maximum rated clock speed using the relevant registers, taking into account aspects like Flash wait states and the APB and AHB prescalers.

Although the Dhrystone benchmark is rather old-fashioned now, it’ll be used to demonstrate the difference that a faster CPU makes, as well as how complex accurately benchmarking is. Plus it’s just interesting to get an idea of how a lowly Cortex-M3 based MCU compares to a once top-of-the line Intel Pentium 90 CPU.

Stitching The Clock Fabric

The F103’s clock tree isn’t identical to that of other families of STM32 MCUs, but the basic concepts remain the same. See the below graphic from Reference Manual 0008 for the clock tree of STM32F10x MCUs:
The clock tree of the STM32F10x MCUs. (Source: RM0008)
We can see the HSI clocked at 8 MHz, which feeds into the clock input switch (SW), from where it can provide the 8 MHz system clock without further fuss. Our other options are to use the HSE, which is fed in via its respective oscillator pins and from there is wired to the same switch as the HSI. If we want to get a higher clock speed than what the HSI or HSE can provide directly, we need to use the Phase Locked Loop (PLL) to generate a higher clock speed.

For this we need to first configure the PLL, enable it and select it as the input source for the clock switch. Before we can throw the switch, however, we also need to make sure that the prescalers for the buses (APB1, APB2, AHB) are set correctly. As we can see in the clock tree diagram, we have maximum speeds for each bus and fixed scaling numbers for each prescaler.

This pattern continues with individual peripherals, some of which also have their own prescaler – like USB and the ADC – but this is just something to keep in mind for when using these peripherals. If we’re just trying to crank the CPU core up to its maximum speed and still want to use the UART, all we need is to get the PLL configuration right, along with the AHB and APB prescalers so that the UART peripheral can be interacted with.

Plugging In Numbers

Before we start happily punching numbers on our keyboard to make the MCU go faster, there’s one tedious detail that we have take care of first: appeasing the Flash memory so that it can keep up. This involves configuring the right number of wait states, the use of prefetching and similar options. For this we open our copy of RM0008 to page 60 to ogle at the FLASH_ACR register and its options.

In this Flash access control register for the F103 and kin we get to enable or disable the prefetch buffer and the latency. Fortunately, for the latency the RM tells us exactly how many wait states we have to set here depending on our target system clock speed. For the 72 MHz that the F103 is rated for, we have to set two wait states.

Scrolling up a bit to page 58 and doing the unspeakable thing of reading the documentation, we can see that the prefetch buffer is turned on after reset by default and is best left enabled. As for the half cycle option, this is related to ‘power optimization’, which means that you will not touch this unless you know what you are doing and are sure that you need to change this.

Consequently we can configure our Flash as:
FLASH->ACR |= 2 << FLASH_ACR_LATENCY_Pos | FLASH_ACR_PRFTBE;
Next we wish to use the HSE via the PLL to get the most accurate and fastest system clock speed, which first requires enable the HSE and waiting for RCC_CR_HSERDY to change to 1 as indicate that it is ready for use.
RCC->CR & RCC_CR_HSEON
while ((RCC->CR & RCC_CR_HSERDY) == 0) {
// Handle time-out.
}
Up next is configuring the PLL, starting with setting the PLL source to HSE:
RCC->CFGR |= RCC_CFGR_PLLSRC;
Now we can configure the AHB and APB prescalers. These take the new system clock and divide it by the set number. For the F103, the 36 MHz-limited APB1 needs to be set to 2, while AHB and APB2 can run at the full 72 MHz, ergo 1.
RCC->CFGR |= 1 << RCC_CFGR_HPRE_Pos;
RCC->CFGR |= 2 << RCC_CFGR_PPRE1_Pos;
RCC->CFGR |= 1 << RCC_CFGR_PPRE2_Pos;

Final Steps

Continuing configuring of the PLL and assuming that it is currently disabled, we can now mash in its multiplier number. Unlike other STM32 families, the F1’s PLL is rather simple, with just a single multiplication factor. Since we’re using the HSE, we need to know the board that we are using and the speed that this HSE oscillates at. Taking the common ‘Blue Pill’ STM32F103 board as example, this features an 8 MHz HSE input, meaning that we have to multiply this by 9 to get the target of 72 MHz.
RCC->CFGR |= 7 << RCC_CFGR_PLLMULL_Pos;
The target PLLMUL register starts at 0x02 for a multiplier of x4, ergo we need to subtract two from our target multiplier. With that done we can enable the PLL and wait for it to stabilize:
RCC->CR |= RCC_CR_PLLON;
while (!(RCC->CR & RCC_CR_PLLRDY)) {
// Timeout handling.
}
Next we throw the big switch to use the PLL’s output as the system clock source and wait for the switch to complete:
RCC->CFGR &= ~(RCC_CFGR_SW);
RCC->CFGR |= RCC_CFGR_SW_PLL;
while (!(RCC->CFGR & RCC_CFGR_SWS_PLL)) { }
We should be up and running now, leaving us just to update the global CMSIS SystemCoreClock variable with the new clock speed of 72 MHz.

Benchmarking

These certainly are Dhrystone results. (Credit: Maya Posch)
Running Dhrystone on our F103 seems like a bit of a challenge as the benchmark was created for your typical desktop and server systems. To achieve this, I took the original pre-ANSI C code for Dhrystone 2.1 and adapted it to a Nodate project. The [url=https://github.com/MayaPosch/Nodate/blob/master/examples/stm32/dhrystone/src/dhrystone.cpp]dhrystone.cpp[/url] file contains the benchmark itself, with no significant modifications other than to set up the MCU and the UART as standard output target. The number of runs is also hardcoded to be 100 million so that it doesn’t have to be punched in every time.

After compiling the benchmark and flashing it to the STM32F103 board, it seemed to take a few eternities for it to complete with so many runs. When the board’s single LED finally started doing its leisurely blinking routine to indicate completion, it turned out that 347 seconds had expired, or roughly 5.78 minutes. As can be seen in the start time, this wasn’t the first attempt, after a 10 million run completed too quickly according to the benchmark’s criteria. C’est la vie.

Annoyingly, the printf-lite implementation that I use with Nodate didn’t seem to like the 32-bit float values and were absent in the final output, so I had to do the calculations for the Dhrystones Per Second (DPS) and related MIPS (DPS / 1757) myself. Since the times() implementation’s ticks equal seconds, this was at least fairly easily, giving the following numbers:

• DPS: ~288,184.438
• MIPS: ~164.021

To see whether these numbers are at all plausible, I consulted a few lists of Dhrystone benchmark results, including one for DPS and one for MIPS. Taking into account the noise created by running it on an OS versus bare metal, my use of -Og optimization level and other differences, the placement at the level of about a Pentium 100 doesn’t seem too farfetched.

There is an official ARM Dhrystone benchmarking guide (AN273), which cites a DPS of 40,600.9 for a Cortex-M MCU running at 18.5 MHz. This would be 158,014 DPS if extrapolated linearly, but obviously not the exact board, MCU or compile flags are used, so ‘rough ballpark’ seems to be the term of the day here.

Perhaps the most interesting finding is that a lowly STM32F103 MCU can keep up with a once high-end Pentium CPU of the early 1990s, at least within the limited integer-only Dhrystone benchmark. Next target will probably be to run the more modern and extensive CoreMark on the F103 and other STM32 MCUs, to give a more holistic perspective.

hackaday.com/2025/12/18/bare-m…

Interactive Hopscotch Tiles Make The Game More Exciting

Hopscotch is a game usually played with painted lines or with the aid of a bit of chalk. However, if you desire fancier equipment, you might like the interactive hopscotch setup from [epatell].

The build uses yoga mats as the raw material to create each individual square of the hopscotch board. The squares all feature simple break-beam light sensors that detect when a foot lands in the given space. These sensors are monitored by a Raspberry Pi Pico in each square. In turn, the Pico lights up addressable NeoPixel LED strips in response to the current position of the player.

It’s a simple little project which makes a classic game just a little more fun. It’s also a great learning project if you’re trying to get to grips with things like microcontrollers and addressable LEDs in an educational context. We’d love to see the project taken a step further, perhaps with wirelessly-networked squares that can communicate and track the overall game state, or enable more advanced forms of play.

Meanwhile, if you’re working on updating traditional playground games with new technology, don’t hesitate to let us know!

hackaday.com/2025/12/18/intera…

Turn ‘Em On: Modern Nintendo Cartridges May Have a Limited Lifespan

Cartridge-based consoles have often been celebrated for their robust and reliable media. You put a simple ROM chip in a tough plastic housing, make sure the contacts are fit for purpose, and you should have a game cart that lasts for many decades.

When it comes to the Nintendo 3DS, though, there are some concerns that its carts aren’t up to snuff. Certain engineering choices were made that could mean these carts have a very limited lifespan, which could now be causing failures in the wild. It may not be the only Nintendo console to suffer this fate, either, thanks to the way modern cart-based consoles differ from their forebearers.

Lost Memory

Carts for early gaming systems tended to use mask ROMs, like this NES Tetris cartridge. Credit: public domain
To understand why modern cartridges are at risk, we should first understand why retro consoles don’t have the same problem. It all comes down to how cartridges store their data. Old-school consoles, like the Sega Mega Drive or the Super Nintendo, stored their games on mask ROMs. These are read-only chips that literally have their data hard-baked in at the lithography stage during the chip’s production. There is no way to change the contents of the ROM—hence the name. You simply fire in addresses via the chip’s address pins, and it spits out the relevant data on the data pins.

By virtue of being a very simple integrated circuit, mask ROMs tend to last a very long time. They don’t require an electrical charge to retain their data, as it’s all hard-etched into the silicon inside. Indeed, there are a million old game carts from the 1980s that are still perfectly functional today as proof. Eventually, they may fail, like any other integrated circuit, but if treated properly, by and large, they can be expected to survive for many decades without issue. Game carts with battery-backed save chips will still lose that storage over time, unless the battery is regularly replaced, but this is a side issue. The mask ROM that stores the game itself is generally very reliable as long as it’s not abused.

The problem for modern cart-based consoles is that mask ROM fell out of favor compared to other rewriteable methods of storing data. To a certain degree, it comes down to economics. You could spin up a custom mask ROM design for a new game, and have many copies produced by a chip foundry, and install those in your carts. However, it’s far easier to simply design a writeable cart in various capacities, and have all your company’s games released on those formats instead. You can use standard off-the-shelf parts that are produced in the millions, if not billions, and you have the flexibility to rewrite carts or update them in the event there’s a bug or something that needs to be corrected. In contrast, if you’d relied on mask ROMs, you’d have to trash your production run and start again if the data needs to be changed by even a single bit.
Where most early game carts relied on mask ROMs that last for ages, it’s believed the Nintendo 3DS may rely on a form of flash memory that isn’t as resiliant. Credit: Kungfuman, CC BY-SA 3.0
This has become a particular issue for some Nintendo systems. Up to the Nintendo DS, it was still common for cartridges to be built with bespoke mask ROMs; only certain titles that needed greater storage used writeable chips like EPROMs. However, when the Nintendo 3DS came along in 2011, norms had shifted. Carts were produced using a product called XtraROM from Macronix. Flip through the marketing materials as one forum user did in 2021, and you won’t find out a whole lot of real technical detail. However, on the basis of probabilities and datasheets in the wild, XtraROM appears to be a technology based on NAND Flash storage.

Exact details of the technology used in Nintendo carts are unclear to a degree, though, as datasheets for those part numbers are not readily available. Carts would often also contain a small amount of user-rewriteable memory for game saves, but the main game data tended to be stored in XtraROM chips. It also appears from certain Nintendo leaks that the 3DS may have certain built-in commands used to refresh this storage regularly, to keep it healthy over time.

If you’re a video game archivist, or just someone that wants their old Pokemon carts to still work in 2030, this is a bad thing. It’s all because of the way Flash memories work. Data is stored as electrical charges that are trapped in a floating gate transistor. Over time, those charges tend to leak out. This isn’t a problem in regular use, because Flash memory devices have controllers that continually refresh the charges as long as they’re powered. However, if you leave such a device unpowered for long enough, then that process can’t take place, and data loss is the eventual result. This has become a particular problem with modern solid-state drives, which can lose data in just years or even months when left unplugged, particularly in warmer environments where charge loss occurs at a faster rate.
There isn’t a lot of hardcore technical information available on precisely what Macronix put into the XtraROM chips used in modern Nintendo carts. It’s believed the technology may be flash based, which would suggest it’s may be at risk of bit rot over time. Credit: Macronix, via screenshotMacronix marketing materials are relatively vague, but do note that XtraROM relies on “charge trapping technology.” Credit: Macronix
If they are indeed based on flash technology, Nintendo 3DS cartridges could be subject to the same phenomena of data loss after long periods without power. The same problem could affect the Nintendo Switch, too, which uses XtraROM chips from the same family. Fine details are hard to come by due to it being a proprietary product, but Macronix has claimed that its XtraROM-based products should offer 20 years of reliable storage at temperatures up to 85 C. However, these products haven’t existed that long. Those results are from accelerated aging tests that are run at higher temperatures to try and back-calculate what would happen at lower temperatures over longer periods of time. Their results don’t always map one-to-one on what happens in the real world. In any case, the fact that Macronix is quoting that 20-year figure suggests that XtraROM is perhaps a particularly long-lived flash technology. You’d expect a more robust mask ROM to outlast even the best EEPROMs that claim longevity figures in centuries.

Fears around widespread cartridge failures float around social media and gaming websites every now and again. It’s believed to be a particular issue with a certain Fire Emblem title, too. However, what we don’t have is a clear idea of the scale of the problem, or if it’s actually happening in the wild just yet. There are many people complaining on the Internet that they’ve grabbed an old cartridge that has failed to boot, but that can happen for a wide range of reasons. Without dumping the cart, it’s hard to definitively put this down to bit rot of the flash storage inside. There are other failures that can happen, for example, like bad solder joints.

There are hints that flash rot really could be affecting some Nintendo 3DS cartridges in the real world, though. A particularly interesting case from a forum concerned a copy of Mario & Luigi Paper Jam Bros. that completely failed to run. After some investigation, the owner decided to see if the 3DS’s cartridge refresh routine could possibly bring the cart back to life. This led them to develop a tool for “fixing” 3DS carts, with files shared on Github. It works in a simple fashion—using the 3DS’s built-in cartridge refresh routines when errors are detected in a given area of data.

youtube.com/embed/8NkzPD0QRaE?…

This copy of Mario & Luigi Paper Jam Bros. was reportedly resurrected by using the 3DS’s built in cartridge refresh routines. It’s a very anecdotal piece of evidence that NAND flash rot could be affecting these carts. It also suggests that it can be guarded against by regularly plugging in carts so the console can run the refresh routines that keep them alive.
YouTube commenters report success using the tool to refresh their own carts. Credit: via screenshot
Ultimately, if you’re precious about your 3DS or Switch games, it probably pays to boot them up and run them once in a while. The same may go for games on the Sony PSVita, too. Even if the stated 20-year lifetime of these carts is legitimate, it’s helpful to juice up the flash every once in a while. Plus, at the very worst, you’ve spent some time playing your cherished games, so it’s hardly a waste of time.

We’d still love to see the issue investigated further. The best way would be to see some dumps and checksums of sealed 3DS games from over 10 years ago, but that’s perhaps unlikely given the value of these rare items. In the meantime, the best way forward is perhaps the cautious one—if you’re worried about data loss on your flash-based cartridges, boot them up just in case. Happy gaming out there!

hackaday.com/2025/12/18/turn-e…

L’AI cambia l’università! Gli studenti americani abbandonano in massa l’informatica

Negli Stati Uniti sta prendendo forma un cambiamento netto nelle preferenze degli studenti universitari. Sempre più giovani scelgono corsi di laurea in intelligenza artificiale, abbandonando l’informatica tradizionale, considerata meno sicura sul piano occupazionale rispetto al passato.

Il fenomeno è evidente nelle principali università. Al MIT, il corso triennale “Artificial Intelligence and Decision Making”, attivato nel 2022, è diventato in soli tre anni il secondo programma più frequentato dell’ateneo, subito dopo Informatica. Entro il 2025, il numero di iscritti dovrebbe raggiungere circa 330 studenti.

Anche altri atenei stanno seguendo la stessa direzione. L’Università della Florida del Sud ha inaugurato un Istituto di Intelligenza Artificiale e Cybersecurity con oltre 3.000 studenti nel primo semestre, mentre l’Università della California a San Diego ha avviato un corso di laurea triennale in IA che ha già attirato 150 matricole.

Un mercato del lavoro che spinge verso l’IA

Il cambio di rotta degli studenti è strettamente legato all’evoluzione del mercato del lavoro tecnologico. Le recenti ondate di licenziamenti nella Silicon Valley hanno ridimensionato l’attrattiva della laurea in informatica, un tempo considerata una garanzia occupazionale.

Secondo Hany Farid, professore all’Università della California a Berkeley, il contesto è profondamente cambiato: se in passato i laureati in informatica ricevevano più offerte di lavoro prima ancora di terminare gli studi, oggi anche una sola proposta viene considerata un risultato positivo.

La crescente automazione della programmazione, favorita dall’uso di strumenti di intelligenza artificiale, ha inoltre ridotto la domanda di programmatori junior. Aziende come Amazon stanno già richiedendo ai propri ingegneri di utilizzare sistemi di codifica automatizzata basati su IA.

Crescono i corsi di IA, calano quelli di informatica

I numeri confermano la tendenza. Secondo Programs.com, le offerte di lavoro online che richiedono competenze in intelligenza artificiale generativa sono aumentate del 323% nell’ultimo anno. Oggi oltre 300 università statunitensi offrono lauree in IA.

Tra il 2022 e il 2025, i master in intelligenza artificiale sono quasi raddoppiati, passando da 116 a 310, mentre i corsi di laurea triennale saliranno da 90 nel 2024 a 193 nel 2025. Parallelamente, il 62% dei corsi di laurea in informatica ha registrato un calo delle iscrizioni nell’ultimo anno accademico.

Secondo Tracy Camp, direttrice esecutiva dell’Association for Computing Research, non si tratta della fine dell’informatica, ma di una nuova fase di specializzazione. L’intelligenza artificiale sta diventando il fulcro di molte discipline, estendendo il proprio impatto anche a settori come sanità, finanza, diritto e ingegneria.

L'articolo L’AI cambia l’università! Gli studenti americani abbandonano in massa l’informatica proviene da Red Hot Cyber.

Attacco cyber al Ministero dell’Interno francese. 22enne, hacker di BreachForums in manette

Le forze dell’ordine francesi hanno arrestato un ragazzo di 22 anni sospettato di aver condotto un recente attacco informatico al Ministero dell’Interno. L’attacco è avvenuto a metà dicembre e ha colpito i server diposta elettronica interni dell’agenzia.

La procura di Parigi ha riferito che l’arresto è avvenuto il 17 dicembre nell’ambito di un’indagine condotta da un’unità informatica specializzata.

Secondo gli inquirenti, l’imputato ha ottenuto l’accesso non autorizzato a un sistema automatizzato di elaborazione di dati personali, il che costituisce un reato commesso nell’ambito di un’organizzazione organizzata. La pena massima per un simile atto in Francia è fino a dieci anni di carcere.

Il detenuto era già stato condannato per reati simili all’inizio del 2025. L’indagine è in corso ed è condotta dalla National Cybercrime Agency. Le autorità hanno promesso di fornire ulteriori informazioni al termine dell’interrogatorio di polizia, che potrebbe durare fino a due giorni.

L’incidente è stato reso noto diversi giorni fa. Secondo il Ministro dell’Interno Laurent Nunez, l’intrusione nella rete è stata rilevata nella notte tra l’11 e il 12 dicembre. Sconosciuti sono riusciti ad accedere a diversi file interni. Le autorità non hanno confermato il furto di dati, ma hanno osservato che le misure di sicurezza sono state rafforzate e le policy di accesso al sistema sono state riviste subito dopo l’attacco.

Quasi contemporaneamente all’incidente, è stata notata un’attività sul forum di hacker BreachForums, precedentemente inattivo . Uno degli amministratori del sito ha pubblicato una dichiarazione in cui affermava che dietro l’attacco al ministero c’era il suo gruppo.

Il rapporto affermava inoltre che l’attacco fosse una ritorsione per l’arresto di altri cinque amministratori del forum, detenuti all’inizio di quest’anno. Forniva inoltre presunte prove sotto forma di screenshot e chiedeva al governo di contattare le autorità entro una settimana per impedire la pubblicazione dei dati rubati.

Gli aggressori affermano di aver avuto accesso a informazioni su oltre 16 milioni di persone tratte dagli archivi della polizia. Tuttavia, le autorità francesi non hanno ancora confermato l’autenticità di queste affermazioni.

Non è inoltre noto se l’arrestato sia direttamente collegato ai membri di BreachForums o agli autori delle affermazioni.

L'articolo Attacco cyber al Ministero dell’Interno francese. 22enne, hacker di BreachForums in manette proviene da Red Hot Cyber.