Low-Cost Saliva-based Biosensor For Cancer Detection

More and more biomarkers that can help in the early diagnosis of diseases like cancer are being discovered every year, but often the effective application relies on having diagnostic methods that are both affordable and as least invasive as possible. This is definitely true in the case of breast cancers, where the standard diagnostic method after seeing something ‘odd’ on a scan is to perform a biopsy so that a tissue sample can be tested in a laboratory. What [Hsiao-Hsuan Wan] and colleagues demonstrate in a recently published research article in the Journal of Vacuum Science & Technology B is a way to use saliva on disposable test strips to detect the presence of cancer-related biomarkers. Best of all, the system could be very affordable.

The two biomarkers tested in this experiment are HER2 (in 10 – 30% of breast cancer cases) and CA 15-3, both of which are indicative of a variety of cancers, including breast cancers. According to the researchers, the levels of these biomarkers in saliva can be correlated to those in blood serum. Where other biosensors may include the read-out circuitry – making those disposable and expensive – here the disposable part is the test strips which are plated with electrodes.

Continue reading “Low-Cost Saliva-based Biosensor For Cancer Detection”

Doubling The CPU Speed Of The TRS-80 Model 100 With A Mod Board

The TRS-80 Model 100 was released in 1983, featuring an 80C85 CPU that can run at 5 MHz, but only runs at a hair under 2.5 MHz, due to 1:2 divider on the input clock. Why cut the speed in half? It has a lot to do with the focus of the M100 on being a portable device with low power usage. Since the CPU can run at 5 MHz and modding these old systems is a thing, we got a ready-made solution for the TRS-80 M100, as demonstrated by [Ken] in a recent video using one of his ‘daily driver’ M100s.

This uses the board design from the [Bitchin100] website, along with the M100 ROM image, as one does not simply increase the CPU clock on these old CPUs. The issue is namely that along with the CPU clock, connected components on the CPU bus now have to also run at those speeds, and deal with much faster access speed requirements. This is why beyond the mod board that piggybacks on top of the MPU package, it’s also necessary to replace the system ROM chip (600 ns) with a much faster one, like the Atmel AT27C256R (45 ns), which of course requires another carrier board to deal with incompatible pinouts.

Continue reading “Doubling The CPU Speed Of The TRS-80 Model 100 With A Mod Board”

WoWMIPS: A MIPS Emulator For Windows Applications

When Windows NT originally launched it had ports to a wide variety of platforms, ranging from Intel’s x86 and i860 to DEC’s Alpha as well as the MIPS architecture. Running Windows applications written for many of these platforms is a bit tricky these days, which [x86matthew] saw as a good reason to write a MIPS emulator. This isn’t just any old emulator, though. It maps 32-bit Windows applications targeted at the MIPS R4000 CPU to an x86 CPU instead. Since both platforms run in a little-endian, 32-bit mode, this theoretically should be a walk in the park.

The use of the Windows PE executable format is also the same, so the first task was to figure out how to load the MIPS PE binary in a way that made sense for an x86 platform. This involved some reverse-engineering of the MIPS ntdll.dll file to figure out how relocations on that platform were handled. Following this, the mapping of the instructions of the R4000 CPU to the (CISC) x86 ISA was pretty easy. Only Floating Point Unit (FPU) support was left as a future challenge. Memory access was left as direct access, meaning no sandboxing or isolation, for simplicity’s sake.

The final task was mapping the native API calls, which call almost directly into the underlying host Windows OS’s API, with a bit of glue logic. With all of this done, Windows NT applications originally written for 1990s MIPS ran just fine on a modern-day x86_64 PC running Windows — as long as you don’t need an FPU (for now).

PC AT mainboard with both 16-bit ISA and 32-bit PCI slots. (Credit: htomari, Flickr)

How Intel Gave Us The PCI Bus While Burying VESA’s VL-Bus

Gigabyte GA486IM mainboard from 1994 with ISA, VLB and PCI slots. (Credit: Rjluna2, Wikimedia)
Gigabyte GA486IM mainboard from 1994 with ISA, VLB and PCI slots. (Credit: Rjluna2, Wikimedia)

The early days of home computing were quite a jungle of different standards and convoluted solutions to make one piece of hardware work on as many different platforms as possible. IBM’s PC was an unexpected shift here, as with its expansion card-based system (retroactively called the ISA bus) it inspired a new evolution in computers. Of course, by the early 1990s the ISA bus couldn’t keep up with hardware demands, and a successor was needed. Many expected this to be VESA’s VLB, but as [Ernie Smith] regales us in a recent article in Tedium, Intel came out of left field with its PCI standard after initially backing VLB.

IBM, of course, wanted to see its own proprietary MCA standard used, while VLB was an open standard. One big issue with VLB is that it isn’t a new bus as such, but rather an additional slot tacked onto the existing ISA bus, as it was then called. While the reasoning for PCI was sound, with it being a compact, 32-bit (also 64-bit) design with plug and play and more complex but also more powerful PCI controller, its announcement came right before VLB was supposed to be announced.

Although there was some worry that having both VLB and PCI in the market competing would be bad, ultimately few mainboards ended up supporting VLB, and VLB quietly vanished. Later on PCI was extended into the Accelerated Graphics Port (AGP) that enabled the GPU revolution of the late 90s and still coexists with its PCIe successor. We covered making your own ISA and PCI cards a while ago, which shows that although PCI is more complex than ISA, it’s still well within the reach of today’s hobbyist, unlike PCIe which ramps up the hardware requirements.

Top image: PC AT mainboard with both 16-bit ISA and 32-bit PCI slots. (Credit: htomari, Flickr)

Why Stealing A Car With Flipper Zero Is A Silly Idea

In another regular installment of politicians making ridiculous statements about technology, Canada’s Minister of Innovation, Science and Industry, [François-Philippe Champagne], suggested banning Flipper Zero and similar devices from sale in the country, while accusing them of being used for ‘stealing cars’ and similar. This didn’t sit right with [Peter Fairlie] who put together a comprehensive overview video of how car thieves really steal cars. Perhaps unsurprisingly, the main method is CAN bus injection, for which a Flipper Zero is actually a terribly clumsy device. Rather you’d use a custom piece of kit that automates the process.

You can also find these devices being sold all over the internet as so-called ‘Emergency Start’ devices for sale all over the internet, all of which use weaknesses in the car’s CAN bus network. The common problem appears to be that with these days even the lights on the car being part of the CAN network, an attacker can gain access for injection purposes. This way no key fob is needed, and the ignition system can be triggered with the usual safeties and lockouts being circumvented.

Ultimately, although the Flipper Zero is a rather cutesy toy, it doesn’t do anything that cannot be done cheaper and more effectively by anyone with a bit of CAN bus knowledge and a disregard for the law.

Thanks to [Stephen Walters] for the tip.

Continue reading “Why Stealing A Car With Flipper Zero Is A Silly Idea”

Developing In Pascal On The Commodore 64 With Abacus Super Pascal 64

Abacus Super Pascal 64 for the Commodore 64.

Most people associate the Commodore 64 with Commodore BASIC and precompiled applications, but it also had a number of alternative development environments produced for it. One of these was Super Pascal 64 by Abacus. A solid introduction to this software package is provided in a video tutorial by [My Developer Thoughts] on YouTube. This uses the Abacus Super Pascal 64 software and manual from the [Lyon Labs] website, which incidentally has a lot more development environments and operating systems for the C64 listed for your perusal.

Abacus’ Super Pascal supports the official Pascal language, requiring nothing more than a Commodore 64 and two Commodore 1541 floppy disk drives to get started. One FDD is for the Super Pascal software, which boots into the development environment, the other FDD and the disks in it are the target for the current project’s source code and compiled binary. Although the lack of support for FDDs other than the 1541 is somewhat odd, this comes presumably from the operating system nature of the development environment and the 1541 being by far the most common FDD for the C64.

Continue reading “Developing In Pascal On The Commodore 64 With Abacus Super Pascal 64”

Shuji Nakamura: The Man Who Gave Us The Blue LED Despite All Odds

With the invention of the first LED featuring a red color, it seemed only a matter of time before LEDs would appear with other colors. Indeed, soon green and other colors joined the LED revolution, but not blue. Although some dim prototypes existed, none of them were practical enough to be considered for commercialization. The subject of a recent [Veritasium] video, the core of the problem was that finding a material with the right bandgap and other desirable properties remained elusive. It was in this situation that at the tail end of the 1980s a young engineer at Nichia in Japan found himself pursuing a solution to this conundrum.

Although Nichia was struggling at the time due to the competition in the semiconductor market, its president was not afraid to take a gamble on a promise, which is why this young engineer – [Shuji Nakamura] – got permission to try his wits at the problem. This included a year long study trip to Florida to learn the ins and outs of a new technology called metalorganic chemical vapor deposition (MOCVD, also metalorganic vapor-phase epitaxy). Once back in Japan, he got access to a new MOCVD machine at Nichia, which he quickly got around to heavily modifying into the now well-known two-flow reactor version which improves the yield.

Continue reading “Shuji Nakamura: The Man Who Gave Us The Blue LED Despite All Odds”