ABC80 AIR-FIGHT 1981

ABC80 AIR-FIGHT 1981 is a recreated program/code from a paper trail. Originally, the program was coded for the Swedish home computer ABC80¹ in 1981. It was inspired by the Atari VCS/2600 game Combat #24. AIR-FIGHT has never been published until now, partly because of potential copyright infringement at the time. It has also only been used on one occasion.

There may be spelling mistakes in the code, as it has not been run. The program is being published here as a remembrance of U. Kristian Lidberg, who disappeared without a trace in the mid-80s and never returned. (Another program of his is KOL.TXT, of which remain only some fragments, it's not complete.)

Background and intro

But we will return to this program later. Keeping to my own dictum from around the time, a wider context should be given when introducing computer related topics. Development doesn't progress in a vacuum. I wrote an opinion article in around the summer of 1982, about education and computers for the Swedish magazine "Nova gram". About a two years later to my astonishment it was published in the then recently renamed computer newspaper "Computer Sweden" "Shift the focus of education!" ("Flytta tyngdpunkten i utbildningen!") in April 1984.

My thesis was in short that narrow focus on the computer itself in general education was misleading for those who did not had the purpose set for becoming computer specialists. Not far from what was happening in other countries such as Britain, at the time, Sweden was discussing to do a very broad political/educational program for the masses on computers. In case of Britain, the BBC and the industry produced the BBC Micro and complementary educational TV programs starting from around 1981. Sweden much later came to discuss special hardware for schools which led them astray (Esselte 100, Compis ..), but also produced TV series around especially home/personal computers in the mid 80s. The grand plan politicians in Sweden had in the beginning of the 80s were more evidently public slightly in time after I wrote the article but before the publication. Thus I guess that's why the article was published, because it was taken as an argument in that later debate -- although it wasn't intended as such. My article was created in a more open context, where there was yet no national grand plan, or at least no annonced plan, for education on computer topics. It related to the diverse field where hardware (remember that IBM PC was launched in Sweden in 1983) and software were constantly shifting, and innovation was done in a very different way. Yes, education were brought to the masses, but not evolving around a single plan. It was diverse, discrete, non-uniform, but too much -- in my opinion -- focused on a single topic: the programming language BASIC.

As a side note I can see that what today is referred to as working with "refactoring" as an educational tool mentioned by such people as Kevlin Henney, is already present here, but in the way that change do not break but alter (or proper code refactoring do not alter) behaviour of programs, but debugging or testing is not really educational in the same sense.

The education can get a completely different character as we also see that the programs' behaviour changes through changes in atomic functions. My intention here is not that, but what HS tends to, that tests and corrections etc. in programs should become some main task.

Well, let's go back some years to 1978 and the computer ABC80. It was a Swedish computer quite new at the time, and which came to market this year. It was bought by our school for classroom education in circa early 1979. Thus we must have been one of the earliest schools in Sweden to have computers.

Read an anecdote from about 1981 giving some more personal context to the experience of ABC80.

Modern captured photo of a ABC80 computer.²

Some historical context

Let's have a look at a timeline of some contemporary microcomputers introduced during the years 1975-1984, with year of introduction and computer respectively:

• 1975
  • MITS Altair 8800
  • IMSAI 8080
• 1976
  • MOS KIM-1
  • Sol-20
  • Apple I
  • Rockwell AIM 65
• 1977
  • RCA COSMAC VIP
  • Apple II (in Sweden 1978)
  • Commodore PET
  • Radio Shack TRS-80
  • Atari VCS (2600)
• 1978
  • ABC80
• 1979
  • Atari 400
  • Atari 800
  • TI-99/4
• 1980
  • TRS-80 Pocket Computer
  • Sinclair ZX80
• 1981
  • ABC800
  • Commodore VIC-20
  • Sinclair ZX81
  • Osborne 1
  • TI-99/4A
  • IBM PC (in Sweden 1983)
  • Acorn BBC Micro
• 1982
  • Victor 9000
  • Sinclair ZX-Spectrum
  • Commodore 64
• 1983
  • Jupiter Ace
  • Apple Lisa
• 1984
  • Apple Macintosh
  • IBM PCjr ...

A year after the three amigos (triad): Commodore PET, Apple II and TRS-80 were released, ABC80 had some kind of the same flavour to it. These were machines that took the step to a compact all-in-one computer for the expanding hobby/home computer market. Previously there were mainly boards sold, kit computers, you could solder on the components yourself, add cards, peripherals, tape recorders, printers, disc drive units, screens etc. that required much more skill than plugging in a power cable. The new generations of machines had burnt in BASIC in ROM. When started there would respond instantly with a prompt, ready for programming. Quite a difference from just a few years earlier.

Another observation is that the field of both innovation and diversity is widespread during these "early" years. Each system had its own dependencies, its own configuration, its own programming language. Yes, there were standards and de facto standards such as Centronics parallel port, some wiring of RS-232, the IBM 8" floppy disc, CP/M or even some tracking the older S-100 bus. But they did not kill the other systems. Rather, they cooperated. But poorly. Maybe too poor were the connections. But that was about to change. With such climbing staggering diversity, the equilibrium of standards were needed even more.

IBM PC was introduced in 1983 in Sweden, two years after the introduction in the USA. But the nationally homebrew computer ABC80 and its successor ABC800 (or read about the later in 1983 introduced ABC802 and the extended BASIC II), had strong sales in the late 70s until the mid-80s inside of Sweden, when it was gradually replaced by foremost IBM PC and its clones. But even if there was success of the PC, it was not immediate. The IBM PC XT, later AT, as well as Microsoft DOS made it harder to keep the competition at a profitable level for other competing computers. The constant increased flow of new hardware as well as software (translated software), internal fighting over contracts of who had the right to sell what and when among retailers of ABC-computers, made sales even harder.

In the late 70s CP/M was the system to keep track of. Also in Sweden. But it was starting to get old. It was uncertain if this was the right choice. There were cards and software for ABC80 that could run CP/M, not unusual at this time to expand contemporary systems for CP/M with the intention of generalising the computer. If you already had a computer why not expanding it to a system with well supplied software. Even IBM PC had from the start three systems to choose from: UCSD Pascal (p-code), CP/M-86, and IBM/Microsoft DOS. In the start of the 80s the prognosis was that UNIX and C was the standard to be. Many bet on Unix, a few bet on the PC because it was IBM behind. Even Microsoft wasn't sure about its DOS project. They also went with Xenix, a Unix variant. Some were more sure on their opinions, they said Unix was here to stay, but as we learned: it wasn't. Hardware and software for these often larger systems were expensive. Truely, too expensive. They were however multiuser, endorsed by many authorities, better systems overall, but the old way of sharing was not really suitable for these times. The terminal faded and the personal computer became the established configuration. This however wasn't clear at the time. Eventually in the late 80s and start of in the 90s the fog dissipated and direction was set.

In the chart below you can see how the sales were internationally of some home (or personal) computers were during late 70'ties until circa 1983 (when my interest in these types of computers waned, and "the fifth generation computers" came to light).

In total, from 1978-1985, the sales of ABC80 were 33,000 units. But then Apple II were at 4.8 million, and Commodore 64 somewhere around 12-17 million. They were obviously not playing on the same field. A diagram of sales of ABC80, and the successor ABC800, and the rest of computers inside Sweden, shows how much the national products were dominant for some time.³

The cost of computers was quite high at this time, but also shrinking rapidly.

Year	Computer	Sold at	Today 2022 value
1977	Commodore PET	$595	ca $2,850 USD
1978	ABC80	6,900 SEK (no VAT)	ca $2,900 USD
1983	Commodore 64	$595	ca $1,700 USD

The computer ABC80

Specifications of the ABC80:

• Zilog Z80A, 3 MHz (2.9952 MHz)
• 8 bit words
• 64K address space
• 16K RAM installed (could be expanded originally to 32K)
• 1K RAM for screen
• 16K ROM with BASIC semi compiler/interpreter and e.g. driver for a tape recorder
• Monitor B/W included (modified TV set from Luxor)
• Graphics 78 x 72 dots (near the "standards" of Teletext /Videotex /Prestel Plus ... )
• 24 rows x 40 columns character screen
• Swedish keyboard (made by Keytronic) (sold in some other countries also, Hungary e.g. with presumably Hungarian keyboard)
• Special version of Swedish standard SIS 662241 for keyboard
• Keycodes according to Swedish standard SEN 850200 ver. 2
• Sound (actually a decent chip SN76477, but not fully used by the computer)
• Expansion slot (the DIAB favoured 4680 bus, used often for miscellaneous instruments, measurements, ...)
• Conn. 64-pol DIN ABC-bus
• Conn. 12-pol power + video
• Conn. 9-pol V-24 (RS232)
• Conn. 5-pol DIN for cassette memory
• Conn. 2-pol motor control of cassette memory

The tape recorder was included when you bought the package (monitor, computer, cables). (Here are some code for transferring files between ABC80 and a modern computer through the audio jack.) Disc drives were sold both from 3rd parties, and from the original manufacturer of ABC80. An affordable disc drive FD2 was offered. Later a double disc drive unit ABC832 from Luxor would cost 14,000 SEK in 1982, double the price of the computer itself.

Later on the ABC80 could be extended with other 3rd party additions such as contemporary popular 80 column cards, CP/M, and local network, which expanded its lifetime in the start of the 80s. But the support wasn't coming from the source itself that time, and adding possibly conflicting hardware from different manufacturers didn't make its life easier.

The ABC80 was a collaboration between DIAB Industrier (DIAB Industries) behind the technology, Scandia Metric AB with its roots in industry, and Luxor AB which made radios and television sets. There were retailers that was also behind the large, but restricted to national and local, success. Read about some of the background of ABC80.

In mid and late 80s DIAB had moved on, betting on Unix, focusing its own crafted DNIX, and had other machines at this time, with little time for something they really wasn't that interested in. They did launch computers based on Unix-variant ABC1600 and ABC9000 (in Swedish) (in principle same as DIAB Serie 90) together with partners in 1984/1985, but with little to no programs, the computers wouldn't sell.

My conclusions

ABC80 had industrial strength, was very solid with software in ROM, fast and reliable (one or two bugs maybe, later corrected). Expansion was key to the construction and essential, as it was basically designed for industry and primarily not for e.g. games or business. The later generalisation with ABC800 made it easier for expansion in those latter fields. It had colour, better graphics, better BASIC and came with more variations in configurations.

On the other hand segments which could also have gained from the success of ABC80, such as schools, those dependent on the graphic, gaming or sound technology etc. were left behind. Instead schools were completely misled by investing in failed projects such as "COMPIS". But that is quite another story...

In general the horizontal field of innovation and diversity came to be replaced by vertical strata. The highly incompatible plethora of machines in spirit of the 70s, was replaced by a single item hardware during the 80s where new competition was in speed, speed, and more speed, but also internal memory expansion, external storage and programs that copied and cloned each other's ideas.

Data, though, was still hard to convert between programs. There were new flaws such as incompatibility between programs and data, sometimes intentionally to keep customers addicted to one branch of program development e.g. word processing. Not only were there these vendor lock-ins, but also the ideas of what word processing could be. If Ted Nelson,⁴ the guy behind hypertext, had his chance of changing electronic writing (Xanadu), or Jef Raskin,⁵ the guy behind Macintosh, with his ideas of speed up typing (eventually the Canon Cat), the ideas evaporated soon in this narrow environment. What we now still have in implemented ideas is not far from what we already had 40-50 years ago.

Or look at the inevitable history and legacy that still influences our modern computers, such as architectures and processors that can still run old code almost dating back to the origin in Intel 8088, or rather: the 8086 instructions. This somewhat stifled hardware development for many many years, or rather: it took it in a special direction of just getting faster with historical constraints. But nonetheless it benefitted software development, as software can rely on older code, systems, libraries etc. You do not necessarily have to invent the wheel every other year.

Well, back to the code …

The code and additional hardware

U. Kristian Lidberg did the main code for the ABC80 in BASIC and I (to a very small degree) contributed. We were at the time in the gymnasium (Brännkyrka gymnasium, Stockholm, Sweden), in 1981. As you might recognize, it is not very consistent program and flawed. We were alternating by the keyboard under some pressure to complete this (including nights), so there are naturally a lot of those flaws as consequence. I guess at maximum we might have done this in a week, or more probably in some days. (I also did a poster, which was an illustration of two fighting aeroplanes.)

It was really only once ever used, during an afternoon when parents visited the school. It also depends on two "joysticks" which were connected to the V24-port RS232 at the back, were tailor-made by us. So it did not have much of an afterlife.

We built the joysticks out of small hotel soap containers, where the inside had cables, switches and diodes. (No pull up or pull down resistors, from which I can remember.) The joysticks were in the same spirit as Atari made them: simple switches, and for each a "fire button". Our fire button may have had a problem with "bouncing". The keyboard was really no alternative, to my recollection, because the keyboard roll-over was too limiting (even if it has "N-key roll-over" 2,5 ms scanning, i.e. 30 hits per second, somehow interruption routine might have impacted this?) or was it that joysticks were much too fun?

So what about the code?

• First there is an introduction on how to play. As a user you might also have to answer some questions
  1. Have you played before? If you have, we could skip some more info and choices.
  2. Please enter your name and the name of your opponent.
  3. Choose your joysticks.
  4. Choose if you want the game to terminate when time is out, or when the highest score has been reached.
• The main part of the game then runs, and ends with a musical score and the winner is announced!
• Play again? No? Please turn over to (presumably) the next player in line!

So what happens in the game itself?

1. As there are two players, an index of the two are kept in a game loop: First we chose one, and then the other player. Each in turn. And all the calculations are done each round for each player. The variables are stored and fetched for each player during its turn.

2. Assume a player has been chosen, so we increase the direction in which the the plane is flying (if we start then the variable has already been set) by a single move. As in an animated movie, one move is made one step for each frame. The motor is always running. The plane can move in 8 directions, let's use some geographical terms: N, NW, W, SW, S, SE, E, NE. So we can e.g. move one step in the N, north direction. If we hit a boundary of the screen, up, down, left or right, then we roll over so that we can appear on the right if the plane took a turn outside screen limits to the left, and so on.

3. So now we have the coordinates to paint the plane on the screen. But first we erase the previous painting, which have temporarily been stored from earlier passing in the loop (or if we start a fresh, some initialization which doesn't effect the game or painting). If we constantly paint like this frame by frame it would seem that the plane is moving across the screen.

4. We poll the input of the current joystick we are interested in, and check for a desired left or right turn. As we really can't "turn on a dime" (rotate around an "axis"), we delay the rotation by increasing a temporary variable that slows the turn, as we have to wait some game cycles to the increment is adequate, then we adjust the variables for the actual turning, reset the temporary variable and start over.

5. If there is a shot, then a subroutine is called. The shot has to go straight and not turn, so it has its own variables to keep track of. The routine is very much the same as for the plane when it comes to limits of the screen, and moving the shots. But we can also check for an opponent hit here. If the coordinates coincides, then the hit registers, the plane blows up, and we count up a score. For speed we used characters rather than putting out dots on the screen. Also collision detection was naturally done through the position of characters.

6. Eventually the game ends, but may start over depending on answered questions.

About the ABC80 BASIC

As noted by Wikipedia, the semi-compiled BASIC interpreter in ABC80 was quite fast for integer based programs, for the time. Games have the property of always require more of the computer that it can handle. But for our goals in this case, the BASIC was enough without having to resort to assembly. (Test your own code in a very simple emulator, where nothing but the bare bones of illustration of ABC80 BASIC.)

In fact the BASIC was one of the main advantages of ABC80. That it was fast and reliable. And that was often enough for setting up e.g. measurement of temperatures relatively easy through a computer (which we also did back in the day).

In this BASIC integers are denoted by a percent character '%' after the variable name. Thus almost all the variable names have this sign after them. I don't remember if assigning a numeric constant, a number, to a variable with the sign after it had any impact on speed. But the program as you can see is littered with them.

There are some special deviations, as there were at the time, in this BASIC, compared to other contemporary variants. All had their own solutions. A semicolon ';' is used as a shorthand for 'PRINT'. The position of the cursor for characters can be done by 'CUR(X, Y)'. Printing the character 12 clears the screen, and positions the cursor at x=0, y=0, top left corner with '; CHR¤(12)'. There are some poking going on such as 'POKE 32357,208,175,212' -- forgot all there was about that address ...

Often computers based on MOS 6502 processor did memory mapping for I/O. But Z80 had its own separate ports for I/O which was used here, and in the case for generating sound in ABC80 you could send out e.g. 'OUT 6,9' to a port, wait a while and close with 'OUT 6,0'. That would generate some sound. You could also poll the V24 port for input of the joysticks and fire buttons, by first setting the right output at port 58 and then reading from it, depending on how the wiring was done. You could do some PEEK and POKE commands to lookup clocks and do some timing. Etc.

Also can be noted that almost half of the code is actually sound, graphics, presentation, ending, tunes, interactivity with questions/answers etc. That is, most of the code is not about the actual game logic. This is important from the standpoint of what makes a game in this early era of video games is not only the time playing. It is about the whole experience, as they say.

Learning

The ABC80 was really the first school computer in general use for education. Yes, I had previous experience with a home built binary counter which my maths teacher showed me in the late 1970s, when I was about 15 or 16 years of age. But it wasn't a computer.

In the gymnasium, when you are about 16-18 years of age, we learned programming by ourselves. Entering code from books, e.g. We had no teachers. We taught each other. We were hungry for learning, even in some cases to the detriment of subjects we should learn, in school. When we understood code, we also invited others to learn. Thus, a small course in BASIC with state support through a study circle came to light.

Some observations

Programs are often considered as being synonymous with code. Or coding as synonymous with programming. Algorithms are also considered sometimes as programs. Seldom, though, are algorithms identified as code, but it happens. So maybe there are some intuitive abstractions here, even if the concepts are fussy and floating.

One distinction I've found to be useful is between "coding" and "programming". Coding can be seen as when only focus is on the code itself. Refactoring often can be looked at in this way. You look at the code, see as it could be written in other ways, but not really consider exactly all of the connections for what the code is doing to other parts. E.g. refactor from a recursive function to an iterative. But as soon as you are considering any ideas outside of the immediate code into the mental abstraction and conception of programs, you are into programming. This is no absolute distinction, but more of a guideline navigating the concepts in development. As a coder/programmer you oscillate between "programming" and "coding".

In the example of early development in software for the Atari VCS, video computer system, later called Atari 2600, programming was more of a time based experience. You have to keep track of scanlines, and when clocks made their ticks, the CPU clock, counting how time was left at the edge where the ray turned to start at another line, vertical and horizontal blanking, etc. Then 128 byte of RAM was the space to navigate within. But not even that, some bytes were already spoken for by the system for some I/O, buttons pressed, joysticks moved, etc. The finalised code would at the the introduction of the machine started with 4K of memory in a cartridge. Later games had more memory.

This is what I would label as a highly coupled coding experience. Debugging was sometimes done with oscilloscope (if they could afford it) or other analog equipment, rather than some debugging software. If something was wrong, you could see that is was wrong by looking at the flickering screen, but you could not tell what went wrong for most of the time. Of course programming was done in assembly/machine code. There was too little space and too many oddities to the hardware to even consider compiling code.

A good introduction on the difficulties and obscurities of programming the Atari VCS/2600 can be seen in the Youtube video: https://www.youtube.com/watch?v=sJFnWZH5FXc.

Historical reflections on "Combat" can be found in Montfort & Bogost, Racing the beam see below in references. An article (excerpt) can be found at at: http://gamestudies.org/0601/articles/montfort which explains Combat in detail.

contrib/JAVASCRIPT

A simple reimagination of the game in JavaScript. It illustrates a kind of "prototyping" in programming. I. e. testing your ideas as "code".

contrib/ATARI 2600/VCS

A partially implemented AIR-FIGHT, i.e. just the movement of the aeroplane in code for MOS 6502 (6507) Atari VCS/2600. It might be that it has to be heavily reimplemented and changed due to the particularities of this machine, if fully implemented. But it also easily extended as you push each value for each player (2), and switch every other loop iteration. It also illustrates my interpretation of the meaning of "code" and "coding". It has only been tested at the site https://8bitworkshop.com (by Steven Hugg) on the emulator for Atari VCS/2600.

contrib/JUPITER ACE

A small snippet of the Forth on Jupiter ACE, which I tested on an emulator, although I have an original machine seen below. I bought the Jupiter ACE sometime around 1983/1984. There were only 5,000 made according to estimates. I did not have much money at this time, and it was actually my first computer. It was interesting that it was a cheap computer, but not running BASIC. It had FORTH. I never was into games really, so game oriented machines was not in my aim at all. Rather exploring programming languages was. But the Jupiter ACE had a horrible "rubbery" keyboard, like its cousin Sinclair ZX-Spectrum. Though the interior resembles more the Sinclair ZX80/81. It was fast, but not really usable with the keyboard. Even for the time. So it was soon shelved.

ABC80 MUSIC 1981

Most simple sample we could come up with that made it to the presentation.

References

• Andersson, Anders (red.), ABC om BASIC, (1979) 2. uppl., Didact, Linköping, 1980
• Finnved, Johan, Programvaran i persondatorn i ABC80, manuskript, Inst. för tillämpad elektronik, Kungl. Tekniska Högskolan, 1979.
• Hugg, Steven, Making Games for the Atari 2600: An 8bitworkshop Book, CreateSpace Independent Publishing Platform, 2016
• Isaksson, Anders & Kärrsgård, Örjan, Avancerad programmering på ABC80, Studentlitt., Lund, 1980
• Johansson, Magnus, Smart, fast and beautiful: on rhetoric of technology and computing discourse in Sweden 1955-1995, Second edition, Linköping University, Department of Technology and Social Change - Tema T, Diss. Linköping : Linköpings universitet, 1997,Linköping, 1997 http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-4695
• Markesjö, Gunnar, Mikrodatorns ABC: elektroniken i ett mikrodatorsystem, 1. uppl., Esselte studium, Stockholm, 1978
• Montfort, Nick & Bogost, Ian, Racing the beam: the Atari Video computer system, MIT Press, Cambridge, Mass., 2009
• Wolf, Mark J. P. (red.), The video game explosion: a history from Pong to Playstation and beyond, Greenwood Press, Westport, Conn., 2008

Footnotes

1. More info in Swedish: https://www.idg.se/allt-om/abc+80. Service manual: https://www.abc80.org/docs/abc80_servicemanual.pdf ↩

2. Photo: liftarn, CC BY-SA 2.0 https://creativecommons.org/licenses/by-sa/2.0, via Wikimedia Commons. ↩

3. Diagram reproduced from: Sjöström, Roland, Positionering under strategisk osäkerhet: Vol. 2 Luxor datorer och persondatorbranschen, Unitryck, Linköping, 1996, p. 212. ↩

4. See https://en.wikipedia.org/wiki/Ted_Nelson. ↩

5. See https://en.wikipedia.org/wiki/Jef_Raskin. ↩