JIT

4 Articles

JIT Vs. AM: Is Additive Manufacturing The Cure To Fragile Supply Chains?

April 1, 2021 by 46 Comments

As fascinating and frustrating as it was to watch the recent Suez canal debacle, we did so knowing that the fallout from it and the analysis of its impact would be far more interesting. Which is why this piece on the potential of additive manufacturing to mitigate supply chain risks caught our eye.

We have to admit that a first glance at the article, by [Davide Sher], tripped our nonsense detector pretty hard. After all, the piece appeared in 3D Printing Media Network, a trade publication that has a vested interest in boosting the additive manufacturing (AM) industry. We were also pretty convinced going in that, while 3D-printing is innovative and powerful, even using industrial printers it wouldn’t be able to scale up enough for print parts in the volumes needed for modern consumer products. How long would it take for even a factory full of 3D-printers to fill a container with parts that can be injection molded in their millions in China?

But as we read on, a lot of what [Davide] says makes sense. A container full of parts that doesn’t arrive exactly when they’re needed may as well never have been made, while parts that are either made on the factory floor using AM methods, or produced locally using a contract AM provider, could be worth their weight in gold. And he aptly points out the differences between this vision of on-demand manufacturing and today’s default of just-in-time manufacturing, which is extremely dependent on supply lines that we now know can be extremely fragile.

So, color us convinced, or at least persuaded. It will certainly be a while before all the economic fallout of the Suez blockage settles, and it’ll probably longer before we actually see changes meant to address the problems it revealed. But we would be surprised if this isn’t seen as an opportunity to retool some processes that have become so optimized that a gust of wind could take them down.

Does PHP Have A Future, Or Are Twenty Five Years Enough?

June 29, 2020 by 51 Comments

In June, 1995, Rasmus Lerdorf made an announcement on a Usenet group. You can still read it.

Today, twenty five years on, PHP is about as ubiquitous as it could possibly have become. I’d be willing to bet that for the majority of readers of this article, their first forays into web programming involved PHP.

Announcing the Personal Home Page Tools (PHP Tools) version 1.0.

These tools are a set of small tight cgi binaries written in C.

But no matter what rich history and wide userbase PHP holds, that’s no justification for its use in a landscape that is rapidly evolving. Whilst PHP will inevitably be around for years to come in existing applications, does it have a future in new sites?

Continue reading “Does PHP Have A Future, Or Are Twenty Five Years Enough?” →

Atari Now Runs Java, Thankfully Doesn’t Require Constant Updates

January 2, 2017 by 24 Comments

Java Grinder is a tool that compiles Java programs to run on platforms like microcontrollers and consoles, by outputting native assembly code and using APIs to work with custom hardware like bespoke graphics and sound chips. Amongst other hardware, Java Grinder supports the Commodore 64, which uses a variant of the 6502 CPU. [Michael Kohn] realized the Atari 2600 shares this processor, and figured he’d get started on making Java Grinder work with the Atari by expanding on the C64 work done by [Joe Davisson]. Together, they brought Java to the Atari 2600 and made a game along the way.

According to [Michael], parts of the project were easy, as some Java routines compile down into as little as 1 or 2 instructions on the 6502. Other parts were harder, like dealing with the graphics subsystem, and modifying Java Grinder to output 8-bit bytecode to fit into the Atari’s tiny 4K ROM limit. Even with this tweak, they still couldn’t fit in a game and title screen. In the end they relied on bank switching to get the job done. [Joe]’s game is pretty solid fare for the Atari 2600 — blocky graphics and bleepy sounds — and they’ve uploaded it to the page so you can try it yourself in an emulator.

At the end of the day, porting Java code to a system with 128 bytes of RAM probably isn’t going to be particularly useful. However, as a coding exercise and learning experience, there’s a lot of value here in terms of building your skills as a coder. Other such experiments have shown us Java running on other unexpected devices, like the Sega Genesis or the MSP430. Video after the break.

Continue reading “Atari Now Runs Java, Thankfully Doesn’t Require Constant Updates” →

3 Billion Devices And A Sega Genesis Run Java

November 23, 2015 by 24 Comments

A few years ago, [Mike]’s friend gave him an old Sega Genesis with the very cool and somewhat rare SegaCD drive attached. The SegaCD gave him an idea – while it’s not easy to burn a cartridge and play homebrew games on a real Genesis console, everyone has a CD burner somewhere. [Mike] began writing his demo and then realized adding Java would be easy on the 68000. The result is Java on three billion devices and a Sega Genesis.

This project is built around Java Grinder a Java byte code compiler that will compile classes, factories, and all the horrible Java design.design.pattern.pattern.patterns() into assembly language. Already, there are a lot of platforms supported by Java Grinder, including the Commodore 64, the TI99, and thanks to some work from [Joe Davisson], the Apple IIgs

With a byte code compiler, an assembler, and an API for the Sega-specific hardware, [Mike] set about building his demo. Since this was a Sega, it needed the ‘SEGA’ sound at the start. [Mike] ended up recording his voice saying ‘JAVA!’ This plays through the Z80 on the Genesis.

The complete demo – viewable in its emulated format below – has everything you would expect from a proper demo. Starfields, dancing sprites, and even a Mandelbrot pattern make it into the three-minute long demo.

Continue reading “3 Billion Devices And A Sega Genesis Run Java” →