You have a clean MSDOS system, and you need to write some software for it. What do you do? You could use debug, of course. But there are no labels so while you can get machine code from mnemonics, you’ll still need to figure out the addresses on your own. That wasn’t good enough for [mniip], who created an assembler using mostly batch files. There are a few .COM files and it looks as if the first time you use debug to create those, but there’s also source you can assemble on subsequent builds with the assembler.
Why? We aren’t entirely sure. But it is definitely a hack. The technique sort of reminded us of our own universal cross assembler — sort of.
Continue reading “Bootstrapping An MSDOS Assembler With Batch Files”
Collecting old CPUs and firing them up again is all the rage these days, but how do you know if they will work? For many of these ICs, which ceased production decades ago, sorting the good stuff from the defective and counterfeit is a minefield.
Testing old chips is a challenge in itself. Even if you can find the right motherboard, the slim chances of escaping the effect of time on the components (in particular, capacitor and EEPROM degradation) make a reliable test setup hard to come by.
Enter [Samuel], and the Universal Chip Analyzer (UCA). Using an FPGA to emulate the motherboard, it means the experience of testing an IC takes just a matter of seconds. Why an FPGA? Microcontrollers are simply too slow to get a full speed interface to the CPU, even one from the ’80s.
So, how does it actually test? Synthesized inside the FPGA is everything the CPU needs from the motherboard to make it tick, including ROM, RAM, bus controllers, clock generation and interrupt handling. Many testing frequencies are supported (which is helpful for spotting fakes), and if connected to a computer via USB, the UCA can check power consumption, and even benchmark the chip. We can’t begin to detail the amount of thought that’s gone into the design here, from auto-detecting data bus width to the sheer amount of models supported, but you can read more technical details here.
The Mojo v3 FPGA development board was chosen as the heart of the project, featuring an ATmega32U4 and Xilinx Spartan 6 FPGA. The wily among you will have already spotted a problem – the voltage levels used by early CPUs vary greatly (as high as 15V for an Intel 4004). [Samuel]’s ingenious solution to keep the cost down is a shield for each IC family – each with its own voltage converter.
Continue reading “Universal Chip Analyzer: Test Old CPUs In Seconds”
There is a high probability that the device on which you are reading this comes somehow loosely under the broad definition of a PC. The familiar x86 architecture with peripheral standards has trounced all its competitors over the years, to the extent that it is only in the mobile and tablet space of personal computing that it has not become dominant.
The modern PC with its multi-core processor and 64-bit instruction set is a world away from its 16-bit ancestor from the early 1980s. Those early PCs were computers in the manner of the day, in which there were relatively few peripherals, and the microprocessor bus was exposed almost directly rather than through the abstractions and gatekeepers we’d expect to see today. The 8088 processor with an 8-bit external bus though is the primordial PC processor, and within reason you will find software written for DOS on those earliest IBM machines will often still run on your multiprocessor behemoth over a DOS-like layer on your present-day operating system. This 35-year-plus chain of mostly unbroken compatibility is both a remarkable feat of engineering and a millstone round the necks of modern PC hardware and OS developers.
Those early PCs have captured the attention of [esot.eric], who has come up with the interesting project of interfacing an AVR microcontroller to the 8088 system bus of one of those early PCs. Thus all those PC peripherals could be made to run under the control of something a little more up-to-date. When you consider that the 8088 ran at a modest 300KIPS and that the AVR is capable of running at a by comparison blisteringly fast 22MIPS, the idea was that it should be able to emulate an 8088 at the same speed as an original, if not faster. His progress makes for a long and fascinating read, so far he has accessed the PC’s 640KB of RAM reliably, talked to an ISA-bus parallel port, and made a CGA card produce colours and characters. Interestingly the AVR has the potential for speed enhancements not possible with an 8088, for example it can use its own internal UART with many fewer instructions than it would use to access the PC UART, and its internal Flash memory can contain the PC BIOS and read it a huge amount faster than a real BIOS ROM could be on real PC hardware.
In case you were wondering what use an 8088 PC could be put to, take a look at this impressive demo. Don’t have one yourself? Build one.
There was a time when building your own computer meant a lot of soldering or wire wrapping. At some point, though, building a PC has come to mean buying a motherboard, a power supply, and just plugging a few wires together. There’s nothing wrong with that, but [Scott Baker] wanted to really build a PC. He put together an Xi 8088, a design from [Sergey] who has many interesting projects on his site. [Scott] did a great build log plus a video, which you can see below.
As the name implies, this isn’t a modern i7 powerhouse. It is a classic 8088 PC with a 16-bit backplane. On the plus side, almost everything is conventional through-hole parts, excepting an optional compact flash socket and part of the VGA card. [Scott] acquired the boards from the Retrobrew forum’s inventory of boards where forum users make PCBs available for projects like this.
Continue reading “Build Your Own PC — Really”
The demoscene usually revolves around the Commodore 64, and when you compare the C64 hardware to other computers of a similar vintage, it’s easy to see why. There’s a complete three-voice synthesizer on a chip, the hardware allows for sprites, a ton of video pages, and there are an astounding sixteen colors, most of which look good. You’re not going to find many demos for the Apple II, because the graphics and sound are terrible. You’re also not going to find many demos for an original IBM PC from 1981, because for thirty years, the graphics and audio have been terrible.
8088 MPH by [Hornet], [CRTC], and [DESire], the winner of the recent 2015 Revision Demo compo just turned conventional wisdom on its head. It ran on a 4.77 MHz 8088 CPU – the same found in the original IBM PC. Graphics were provided via composite output by a particular IBM CGA card, and sound was a PC speaker beeper, beeping sixty times a second. Here’s a capture of the video.
Because of the extreme nature of this demo, it is unable to run on any emulator. While the initial development happened on modern machines with DOSbox, finishing the demo needed to happen on an IBM 5160, equivalent to the 5150, but much easier to find.
Despite the meager hardware and a CPU that reads a single byte in four cycles, effectively making this a 1.19 MHz CPU, the team produced all the usual demoscene visuals. There are moire patterns, bobbing text, rotated and scaled bitmaps, and an astonishing 1024-color mode that’s an amazing abuse of 80×25 text mode with NTSC colorburst turned on.
Below you can find a video of the demo, and another video of the audience reaction at the Revision compo.
Continue reading “Demoing an 8088”
A quick look at the pinouts of an Intel 8086 & 8088 processor reveals a 20 bit address bus. There was high demand for the ability to address 1 meg (2^20) of address space, and Intel delivered. However, a curious individual would wonder how they can achieve such a feat with only 16 bit registers. Intel solved this riddle by combining two registers so they could make it compatible with code written for the 8008, 8080 & 8085. The process they use can be a bit confusing when trying to figure out where to locate your code in the ROM. In this article, we are going to go over the basics of how the Physical Address is calculated and how to locate your code correctly in ROM.
Continue reading “Ask Hackaday: Understanding the x86 Memory Addressing System”
Ten years ago, [Trixter] created 8088 Corruption, a demo for the original PC, the IBM 5150, that displayed full motion video using a CGA card and a SoundBlaster. It was hailed as a marvel of the demoscene at the time, garnered tons of hits when it was eventually uploaded to Google Video, and was even picked up by the nascent Hackaday.Now, ten years later, and seven years after [Trixter] said full motion video using the graphics mode of a CGA adapter was impossible, he’s improved on his earlier work. Now, it’s possible to display video at 640×200 resolution at 30 frames per second on a 30-year-old computer.
[Trixter]’s earlier work used the text mode of the CGA adapter, only because the 40×25 character, 16 color mode was the only graphics mode that could be entirely updated every single frame. It’s still one of the high points of the PC demoscene, but from the original video, it’s easy to see the limitations.
A while back, [Trixter] said displaying video using his computer’s graphics mode was impossible. He’s had years to think about this statement, and eventually realized he was wrong. Like the developers of modern video codecs, [Trixter] realized you don’t need to change every pixel for every frame: you only need to change the pixels that are different from frame to frame. Obvious, if you think about it, and all [Trixter] needed to do was encode the video in a format that would only change dissimilar pixels from frame to frame, and manage the disk and memory bandwidth.
After reencoding the 10-year-old demo for graphics mode, [Trixter] turned toward his most ambitious demo to date: playing the ‘Bad Apple’ animation on an 8088. As you can see in the video below, it was a complete success.
Continue reading “(Better) Full Motion Video On The First PC”