Faster Computers Lead to Slower Experiences?

Ever get that funny feeling that things aren’t quite what they used to be? Not in the way that a new washing machine has more plastic parts than one 40 years its senior. More like “my laptop can churn through hundreds of gigaflops, but when I scroll it doesn’t feel great.” That perception of smoothness might be based on a couple factors, including system latency. A couple years ago [danluu] had that feeling too and measured the latency of “devices I’ve run into in the past few months” (based on this list, he lives a more interesting life than we do). It turns out his hunch was objectively correct. What he wrote was a wonderful deep dive into how and why a wide variety of devices work and the hardware and software contributors to latency.

Let’s be clear about what “latency” means in this context. [danluu] was checking the time between a user input and some response on screen. For desktop systems he measured a keystroke, for mobile devices scrolling a browser. If you’re here on Hackaday (or maybe at a Vintage Computer Festival) the cause of the apparent contradiction at the top of the charts might be obvious.

Q: Why are some older systems faster than devices built decades later? A: The older systems just didn’t do much! Instead of complex multi-tasking operating systems doing hundreds of things at once, the CPU’s entire attention was bent on whatever user process was running. There are obvious practical drawbacks here but it certainly reduces context switching!

In some sense this complexity that [danluu] describes is at the core of how we solve problems with programming. Writing code is all about abstraction. While it’s true that any program could be written directly in machine code and customized to an individual machine’s hardware configuration, it would be pretty inconvenient for both developer and user. So over time layers of sugar have been added on top to hide raw hardware behind nicer interfaces written in higher-level programming languages.

And instead of writing every program to target exact hardware configurations there is a kernel to handle the lowest layers, then layers adding hotplug systems, power management, pluggable module and driver infrastructure, and more. When considering solutions to a programming problem the approach is always recursive: you can solve the problem, or add a layer of abstraction and reframe it. Enough layers of the latter makes the former trivial. But it’s abstractions all the way down.

[danluu]’s observation is that we’re just now starting to curve back around and hit low latency again, but this time by brute force! Modern solutions to latency largely look like increasingly exotic display technologies and complex optimizations which reach from UI draw functions all the way down to the silicon, not removing software and system infrastructure. It turns out the benefits of software complexity in terms of user experience and ease of development are worth it most of the time.

For a very tangible illustration of latency as applied to touchscreen devices, check out the Microsoft Research video after the break (linked to in [danluu]’s piece).

Continue reading “Faster Computers Lead to Slower Experiences?”

34C3: Vintage Verification, Stop Nuclear War With A 6502

Our better-traveled colleagues having provided ample coverage of the 34C3 event in Leipzig just after Christmas, it is left to the rest of us to pick over the carcass as though it was the last remnant of a once-magnificent Christmas turkey.  There are plenty of talks to sit and watch online, and of course the odd gem that passed the others by.

It probably doesn’t get much worse than nuclear conflagration, when it comes to risks facing the planet. Countries nervously peering at each other, each jealously guarding their stocks of warheads. It seems an unlikely place to find a 34C3 talk about 6502 microprocessors, but that’s what [Moritz Kütt] and [Alex Glaser] managed to deliver.

Policing any peace treaty is a tricky business, and one involving nuclear disarmament is especially so. There is a problem of trust, with so much at stake no party is anxious to reveal all but the most basic information about their arsenals and neither do they trust verification instruments manufactured by a state agency from another player. Thus the instruments used by the inspectors are unable to harvest too much information on what they are inspecting and can only store something analogous to a hash of the data they do acquire, and they must be of a design open enough to be verified. This last point becomes especially difficult when the hardware in question is a modern high-performance microprocessor board, an object of such complexity could easily have been compromised by a nuclear player attempting to game the system.

We are taken through the design of a nuclear weapon verification instrument in detail, with some examples and the design problems they highlight. Something as innocuous as an ATtiny microcontroller seeing to the timing of an analogue board takes on a sinister possibility, as it becomes evident that with compromised code it could store unauthorised information or try to fool the inspectors. They show us their first model of detector using a Red Pitaya FPGA board, but make the point that this has a level of complexity that makes it unverifiable.

The gamma ray energy spectrum of a cobalt-60 source as seen from an Apple II.
The gamma ray energy spectrum of a cobalt-60 source as seen from an Apple II.

Then comes the radical idea, if the technology used in this field is too complex for its integrity to be verified, what technology exists at a level that can be verified? Their answer brings us to the 6502, a processor in continuous production for over 40 years and whose internal structures are so well understood as to be de facto in the public domain. In particular they settle upon the Apple II home computer as a 6502 platform, because of its ready availability and the expandability of [Steve Wozniak]’s original design. All parties can both source and inspect the instruments involved.

If you’ve never examined a nuclear warhead verification device, the details of the system are fascinating. We’re shown the scintillation detector for measuring the energies present in the incident radiation, and the custom Apple II ADC board which uses only op-amps, an Analog Devices flash ADC chip, and easily verifiable 74-series logic. It’s not intentional but pleasing from a retro computing perspective that everything except perhaps the blue LED indicator could well have been bought for an Apple II peripheral back in the 1980s. They then wrap up the talk with an examination of ways a genuine 6502 system could be made verifiable through non-destructive means.

It is not likely that nuclear inspectors will turn up to the silos with an Apple II in hand, but this does show a solution to some of the problems facing them in their work and might provide pointers towards future instruments. You can read more about their work on their web site.

Fixing Bugs In A 37 Year Old Apple II Game

Emulators are a great way to reminisce about games and software from yesteryear. [Jorj Bauer] found himself doing just that back in 2002, when they decided to boot up Three Mile Island for the Apple II. It played well enough, but for some reason, crashed instantly if you happened to press the ‘7’ key. This was a problem — the game takes hours to play, and ‘7’ is the key for saving and restoring your progress. In 2002, [Jorj] was content to put up with this. But finally, enough was enough – [Jorj] set out to fix the bug in Three Mile Island once and for all.

The project is written up in three parts — the history of how [Jorj] came to play Three Mile Island and learn about Apple IIs in the first place, the problem with the game, and finally the approach to finding a solution. After first discovering the problem, [Jorj] searched online to see if it was just a bad disk image causing the problem. But every copy they found was the same. There was nothing left for it to be but problem in the binary.

Continue reading “Fixing Bugs In A 37 Year Old Apple II Game”

Apple II Web Server Written In BASIC

The Apple II was the machine that many say launched Apple as a company. As with many popular computers of the 1980s, the Apple II maintains a steady following to this day who continue to develop new hardware and software to keep the platform alive.

[deater] had scored an Uthernet II Ethernet interface for his Apple IIe, based off the venerable W5100 chipset. He decided to have some fun and wrote a webserver for the Apple II in BASIC. The program sets up the Ethernet card with a series of PEEKs and POKEs, and then listens out for incoming packets before responding with the requisite data loaded from floppy disk.

The server can deal with HTML, text, and even JPEG and PNG images. It’s even compliant with RFC 2324. It does suffer from some limitations however — the disk format used can only hold 140 kB, it can only serve an 8kB file at a time, and due to using a lot of string manipulation in the code, is painstakingly slow.

Before you get too excited, the machine is running on a local network only, so you can’t check it out from here. However, [deater] has kindly released the source code if you wish to run it for yourself.

If you’re thirsty for more 8-bit action, check out this Apple II playing animated GIFs.

A New OS For Apple II Computers

Although this sort of work is usually reserved for KansasFest and other forums for highly technical and very skilled Apple enthusiasts, [John Brooks]’s release of a new version of the ProDOS operating system is no less important. It is, without a doubt, the greatest release the Apple II platform will see for the next few years. This swan song of the Apple II platform is simply ProDOS 2.4, an update to the last version of Apple’s ProDOS, last released in 1993.

For a bit of historical context, ProDOS was not the operating system that shipped with the Apple ][ in 1977. That OS was simply called DOS. ProDOS, released in 1983, included support for the new 3.5″ floppy drives, allowed for hierarchical directories, supported hardware interrupts, and kept the Apple ][ line going well into the 90s. Despite these improvements, not all Apple ][ systems were supported. The original ][ and ][+ were out in the cold. Now, with the ability to add Compact Flash and USB devices to an Apple ][, even the latest version of ProDOS is horribly out of date.

[John]’s release of ProDOS 2.4 fixes all of this. This release is the most important development in the Apple ][ ecosystem in recent memory, and will remain so for at least a decade. The only person who still uses an Apple ][ as a daily driver agrees, and ProDOS 2.4 is now enshrined in The Archive for all eternity.

prodos-2-4-bitsy-bye-768x543New features abound, although most of them are geared toward the now thirty-year-old Apple IIGS. These features include enhanced utility in GS/OS – the Apple equivalent of the Commodore GEOS – slot remapping, and an OS that is both smaller and loads faster. Older machines aren’t left out, and ProDOS includes the usual features and improvements found in ProDOS 2.x that weren’t available in the Apple ][, Apple ][+ and un-enhanced Apple //e.

The killer feature and one more thing of this release is the BitsyBye utility, a small ($300!) system program that allows you to boot various Apple II devices and programs. Think of this as the Norton Commander of the Apple II ecosystem, allowing slots to be selected, booting the most recently used ProDOS device, and basic file system exploration. BitsyBye also includes an easter egg. A few utilities are also included on the ProDOS 2.4 disk image including ADTPro, Shrinkit archive expander, and disk utilities.

A 140k ProDOS 2.4 disk image is available on [John]’s site and on Archive.org. Since you’re probably not downloading directly to an Apple II disk, grab ADTPro and load it over audio.

Streaming Video on an Apple IIc

Some of the projects we feature solve a problem. Others just demonstrate that they can be done. We’re guessing that it’s the latter that motivated [Joshua Bell] to write a VNC client for an Apple IIc. To fully appreciate how insane this is, have a look at the video below the break.

There’s more than one thing amazing about this hack. Somehow, [Joshua]’s VNC program runs entirely in the memory of an Apple IIc, as he demonstrates at the beginning of the video by downloading all of the code into the Apple over a serial cable. After the initial bootstrap, he runs the code and you see (in full four-color splendour!) a low-res Windows XP appear on the IIc.

2440964467_decb0daf10_oWhat’s more incredible, but is unfortunately not demonstrated in the video, is that he appears to have not just mirrored the PC’s screen on the Apple, but has actually managed to get a one-frame-per-second bi-directional VNC working at 115,200 baud. In this snapshot from his flickr gallery, he appears to be playing Karateka on the IIc and watching it on his laptop.

If you’ve got a IIc kicking around, and you want to show it yet more new tricks, don’t neglect this browser written for the Apple IIc. Or if you’ve only got an Apple IIc+ and you’re totally ticked off that the beep is different from that of the IIc, you can always go on an epic reverse-engineering quest to “repair” it.

Continue reading “Streaming Video on an Apple IIc”

An Apple ][ emulator on an Arduino Uno

April Fools’ Day may have passed, but we really had to check the calendar on this hack. [Damian Peckett] has implemented an Apple ][, its 6502 processor, and a cassette port, all on an Arduino Uno. If that wasn’t enough, he also uses a PS/2 keyboard for input and outputs analog VGA. [Damian] is doing all this with very few additional components. A couple of resistors, a capacitor and some very clever hacking were all [Damian] needed to convince an Arduino Uno that it was an Apple.

Making all this work boiled down to a case of resource management. The original Apple ][ had 4KB of RAM and 8KB of ROM. The ATmega328 has only 2KB of RAM, but 32KB of Flash. The only way to make this hack work would be to keep as much of the emulation and other routines in Flash, using as little RAM as possible.

The core of this hack starts with the MOS 6502, the processor used in the Apple. [Damian] wrote a simple assembler which translates the 6502 opcodes and address modes to instructions which can be executed by the Arduino’s ATmega328. To keep everything in ROM and make the emulator portable, [Damian] used two large switch statements. One for address modes, and a 352 line switch statement for the opcodes themselves.

A CPU alone is not an Apple though. [Damian] still needed input, output, and the ROM which made the Apple so special. Input was through a PS/2 keyboard. The PS/2 synchronous serial clock is easy to interface with an Arduino. Output was through a custom VGA implementation, which is a hack all its own. [Damian] used the lowly ATmega16u2 to generate the video timing. The 16u2 is normally used as the Arduino Uno’s USB interface. The only external hardware needed is a single 120 ohm resistor.

The original Apples had cassette and speaker interfaces. So does this emulated Apple. [Woz’s] original cassette and speaker interface accurate loops to generate and measure frequencies. One of the trade-offs [Damian] accepted in his 6502 was cycle accuracy, so he couldn’t use the original routines. Not a problem though, as he was able to write simple functions to replace these routines and drop them in place of the Apple’s own ROM calls.

The Apple ][ ROM itself is handled as one giant character array. This includes the system monitor, Mini-Assembler, Sweet-16, and [Woz’s] own Integer Basic. [Damian] caps off this incredible project by booting his new computer, loading a  Mandelbrot set program from cassette -or in this case an audio file stored on his cell phone, and running it. The well-known fractal is displayed in all its glory on a modern LCD monitor, driven by a microcontroller, emulating a computer from nearly 40 years ago.

Continue reading “An Apple ][ emulator on an Arduino Uno”