• Please review our updated Terms and Rules here

Software written in 100% Assembly

motley2659

Member
Joined
Feb 19, 2013
Messages
48
It seems for older computers, especially the PC, that programs which were written in 100% Assembly instead of a high-level language added a speed boost as significant as any hardware upgrade. Sifting through the old computer magazines on Google Books, it seems that assembly programs like Xywrite, Volkov Commander, and Lotus 1-2-3 loaded and performed faster than any of their competitors. Same thing with Apple 68000 assembly programs like WriteNow.

What are your favorite 100% Assembly coded applications and games.
 
DM.COM - only 8564 bytes and beats most other file managers of any size. I've used this for e-mail too. My absolute favourite of any program ever.

PTS DOS is written entirely in assembly. I've only tried the sampler, but it claims to be a few percent faster than MS.
 
My favorite game written in ~100% assembly is a bit more recent than vintage, but still kinda old: Roller Coaster Tycoon! The 1% not in assembly is just a framework for simple interfacing with windows (files, etc). Too bad anything more recent than Windows XP throws access violation errors at it :(
 
The original dBase II was reportedly written in assembler. Which lead to all sorts of fun as they tried to convert later versions to a higher level language.

And speed wasn't always the reason to use assembler, sometimes it was size. It is kind of a big deal if your program doesn't fit in to available RAM.
 
I could be completely off-base give my lack of direct recent experience, but....

Architecture complexity has done more to kill use of assembly than anything else. Good compilers can model what is happening on a pre-fetch decode, branch prediction, and pipeline level more efficiently than most humans. Even in 386, 486, and Pentium days, rules and exceptions to instruction ordering were getting quite complex and it's only gotten worse.

Compilers always lag behind the ISA and its implementation, but so do humans. x86/x86_64 is a more extreme example. Simpler ISAs like ARM and MIPS are not as bad.
 
I could be completely off-base give my lack of direct recent experience, but....

Architecture complexity has done more to kill use of assembly than anything else. Good compilers can model what is happening on a pre-fetch decode, branch prediction, and pipeline level more efficiently than most humans. Even in 386, 486, and Pentium days, rules and exceptions to instruction ordering were getting quite complex and it's only gotten worse.

Oh, that's been true since at least the 1960s (Try hand-timing CDC 6600 code, for example). However, most compilers do have the disadvantage that their libraries pretty much mandate larger code space. I once griped about the lousy code generation of a piece of C code on a Microsoft forum and was ridiculed because I actually cared about optimization (everything is getting so fast, why worry about code optimization?).

The other thing is that the APIs have gotten very complex. It's much simpler to write a full-screen DOS application than code than a Windows or X application that does the same thing.

Finally, with a decent compiler and library, it makes more sense to write everything but the most critical stuff in an HLL. An HLL may not give you convenient access to certain hardware features, so write a bit of inline assembly and get most of the benefit without the bother.
 
Pinball Construction Set is pretty cool. Some really innovative physics for its time. Written for the Apple II, so I'd assume it's assembly.
 
At one time my day job was mostly writing assembly code to go in embedded devices (mainly factory and toll data collection systems with 8-bit micros). In my spare time, I wrote several cross assemblers and a linker entirely in assembly on the TI 990 and PDP-11. I did this mainly for speed because my employer had purchased some cross assemblers and a linker written in FORTRAN-IV (can you say "slow"? I knew you could.).

I have not believed for many years that it is justified to write everything in assembly. Reasonable compilers are readily available for almost every CPU, so I try to write my code in languages that can be ported, with the minimum assembly components needed to meet function and/or performance requirements.

The last thing I wrote completely in assembler ('98 or '99?) was a field debugging tool that allowed a 386 PC to run a real-mode application (embedded device with US Software RTOS and TCP/IP over DRDOS) in virtual 8086 mode, with a hook for the application to tell the system where the read-only sections should be, items to watch with the debug registers, etc. It logged all the DOS and BIOS calls, and dumped all of RAM to a floppy if the system crashed or violated a debug constraint (it would output Morse code "SOS" through the speaker to ask for the floppy, then output Morse code "OK" when it was written). IIRC there were about 150 units in the field and a few were crashing every day, and my job was to get them to 2500 hours MTBF within 90 days.

Before that, I would guess it was this caching tape driver for RSX-11M-PLUS.
 
Last edited:
Apparently all subLogic designed games are written in 100% 8088 assembly. This includes Night Pinball as well as all their flight simulators, subLogic Football and Baseball. Everything.
 
I design and program real-time controllers effectively since 1980, using 8 bit and now 16 bit micros like the MSP430. I always write in assembly language to achieve the time-critical demands making heavy use of data structures, efficient algorithms and interrupt processing. I often have to take a formulation in human-mathematics and deconstruct it into a fast algorithm in the way 8bit micros can best solve it; i.e. no math libraries or floating point bloat ( you can track your raw decimal points per operation, accumulate precision in multi-byte values and not round off until the final figure is available ). However, before wasting time doing it that way, I find that often a complete table of precision Excel solutions can be encoded and used in an efficient look-up traversal. Sometimes I just use a table look-up for parts of the calculations that micros cannot process efficiently, such as square-roots; tables are much faster than the efficient algorithms for doing that.

I use C only for PC platform applications. In microcontroller applications I have no porting issues to other micros because designs utilize unique architecture and resources of particular micros best fitted for a particular solution - C offers nothing bloat and distance from real-time metrics. I've heard all the arguments about how C compilers are very efficient but in my experience that only applies where firmware and system requirements are mundane.

eeguru said:
...Architecture complexity has done more to kill use of assembly than anything else...
In some applications there is no choice but to use those micros and tools, but many go there because they don't know how to get a small micro to solve that same goal. That gives significant competitive advantage to those that can.
 
Last edited:
motley2659 said:
...all subLogic designed games are written in 100%...assembly...includes...their flight simulators...
I recall a BYTE magazine article in the 80s describing how they used matrix manipulations to do 3D point rotation, plotting and perspective generation. I used that article to do a 3D star field traversal using the Yale Star Catalog of the 9000 brightest stars. While it worked, it wasn't as dynamic as the old Star Trek TV graphic. But it does show that you can do miraculous things in ASM... knowledge that may be lost in today's classrooms.
 
Being a veteran of a time when all systems code was done in assembly, I can say that the picture is not very clearcut.

JDallas is correct that sometimes there's no alternative. Consider, the AT-to-XT keyboard converter done in a PIC with 1K code space and 128 bytes of RAM. On the other hand, you'd have to be insane to implement Windows 7 in assembly.

There are some other places where assembly is used because the programmer has little choice. Interfacing with special hardware features not supported by an HLL can pretty much mandate it. Timing-dependent or time-critical code is another aspect. Stubborn "hot spots" in code that consumes a huge proportion of CPU resources is another, although sometimes using an alternative algorithm will work (i.e. is that nice compact bubble sort really the best way to go about things?).

Yet, I'll wager that almost all of the code for the ARM MCU (probably the most ubiquitous embedded MCU) out there is not assembly source. The advantages of an HLL simply outweigh any possible efficiency gains realized with assembly.

True story. Back in the day, when a 10MHz clock speed qualified a machine as a "supercomputer", instruction scheduling was a pretty complicated job to do by hand. Add to this the problems of register usage (i.e. keeping the most-used data in registers rather than memory) and keeping the critical parts of a loop in the very small instruction cache. Quite often, a complex loop would be coded in FORTRAN, run through the optimizing compiler and the code copied into the assembly source with perhaps a few tweaks.

It's not unusual for a very good global-optimizing compiler to generate far superior code to that being cranked out by an individual assembly programmer, particularly in numeric applications.
 
You still learn Assembly at the university level, at least they do where I went.

But mostly I believe that the lack of interest in assembly is mostly due to the close and/or badly documented hardware of modern computers.
In the good old day you could get a map of every system call and low level functions as soon as the computer came out. Some even printed it in the manual that came with the machine.
Today you're lucky if they even bother to include the OS on dvd... Instead, you have to search for documentation on every single component in your machine from dozen of manufacturer and even then the information isn't complete because of trade secrets protection.
 
If you want to see what can be done at an extremely low level that cannot be done in a high level language, read George Phillip's writeup on 'Beamhacking' on the TRS-80 Model III. Doing what he describes, in great detail, requires hand written assembly code on the Z80, with accounting having to be made of every single T-state in the code. Link to the first part of the series: http://members.shaw.ca/gp2000/beamhack1.html

In a nutshell: if you can sync your code to the video circuits in the Model III, you can set up a loop to change the video RAM during the trace to create higher-resolution graphics than is possible using the normal means. George covers all the bases here; a real 'tour de force' if you will.
 
lowen said:
...writeup on 'Beamhacking' ...requires hand written assembly code on the Z80, with accounting having to be made of every single T-state in the code...
That's basically what we call "Real-Time" code (RT), because timing of real world events become the critical constraint upon what can work and what can't work.

When I write real-time assembly language code I put the opcode byte count and execution state time in the comment field before any comments so I can quickly see how quick or tight the code is.

There's no clear definition of what real-time firmware might encompass so its better to see by example. Some 8bit micro Real-Time projects I've done follow: (note some of these use the same 8bit micros in your vintage computers)

I used an 8085 and a Signetics state machine to control four winchester disk drives from a Multi-Bus card, directly formatting the sector headers and data with interleave, reading and writing data passing thought the board as it was directly DMA'd to another Multi-Bus memory card without buffering on-board. First controller capable of handling the faster Fujitsu Eagle at the time. (circa 1981)

I used a Intel Multi-bus card in an existing postal sorter augmented to monitor mail sorted envelops flying past a segmented magnetometer sensor at 600 feet a minute to detect by sensed pattern which envelops had checks inside so they could be diverted to immediate deposit; that's why they ask not to staple or paper-clip your check. (circa 1985)

I used two Z80s to sort microfiche records traveling about the same speed past a laser barcode scanner, sorting them virtually and passing on ID and destination to the second Z80 to virtually run their positions on the belts by monitoring blocked optical sensors and to divert them into the correct trays by solenoid activation. The barcodes were decoded in real-time using my faster base 40 scheme, replacing the client's arbitrary and obtuse base 43 scheme. (circa 1985)

I used an 8085 to do digital packets over a voice radio channel at 2400 and 4800 baud. Had to redesign the packet protocol because a contract test was changed to turn off the radio 1ms of every 10ms and our shortest packet was 70ms, we won that contract after give 6 weeks to resubmit. My solution was to rebuild packets from shattered pieces in the receive buffer. (circa 1986)

I used a Texas Instruments TMS 700(?) in a cellphone design for Tandy/ Radio Shack to send muted digital packets between the base and handset phones to communicate various data... Tandy patented that. (circa 1987)

After grad school and a few years at MCI Telecommunications I designed and programmed a 3D accelerometer using a 12Mhz 8051 that rendered 3D resultant vector magnitudes 100 times a second sensitive and accurate enough to detect footsteps, fingers tapping on a desk or cars within a particular range. (circa XXXX)

Since then I'm been working primarily with a 16bit Texas Instruments MSP-430 micro, not because 8bit micros lack processing power but because the MSP-430 is excellent at ultra-low power for sensors running from battery. One of the design constraints of this particular market is that the system cannot run wire power the units. :S

Just recently I started another 8bit design using an eZ80 which will include real-time code to directly control signals on the floppy cable going to the floppy disk drive. It will format, read and write the floppy disks directly from the eZ80 pins, i.e. no Floppy Disk Controller (FDC) required. The firmware and the eZ80 will directly convert the READDATA signal and write the WRITEDATA signal to the floppy disk drive. It seems rather *ZEN* because its like the very first design I mentioned from 1981. :)

Each of those were 8bit micros, like the ones in your vintage computers, which have been elsewhere characterized as *good for keyboard interfacing* :)
 
Last edited:
Back
Top