Scrolling on the Amiga

Introduction

Depending on what your computer hardware can do, there are a number of different ways to approach displaying a scrolling game. We used to have to evaluate each machine that we were writing for, and then design our games around the advantages. That all comes unstuck, of course, when you're asked to convert a game from one platform to another.

 

Things to consider are: do we have user definable character modes?  Do we have bitmap modes? Do we have smooth scrolling in hardware? Do we have more than one playfield? Do we have hardware sprites? Do we have enough CPU time to rebuild everything on the screen every 50th of a second frame? Can we start the screen memory on any address in video RAM? Can we restart the screen display from another address during the display?

 

8-Bit Learning

Since we started on 8-bit machines, and only had the arcade games as an example of a better world, everyone was on the same learning processes. To get to the Amiga, we had to go through a number of other machines first.

 

To answer the above questions for each computer in turn:
 

Dragon 32

Do we have user definable character modes? No, character sets were fixed in ROM.

Do we have bitmap modes? Yes: 2 nasty 4-colour selections, and 2 2-colour selections. 

Do we have smooth scrolling in hardware?  No

Do we have more than one playfield? No

Do we have hardware sprites? No

Do we have enough CPU time to rebuild everything on the screen every frame?  No

Can we start the screen memory on any address in video RAM? No, only on 1K boundary

Can we restart the screen display from another address during the display? No

 

Chances of a smooth-scrolling game: sadly zero

 

48K ZX Spectrum

Do we have user definable character modes? No, only bitmaps.

Do we have bitmap modes? Yes: 320x200 (8K) with colour in 8x8 blocks. 

Do we have smooth scrolling in hardware?  No

Do we have more than one playfield? No

Do we have hardware sprites? No

Do we have enough CPU time to rebuild everything on the screen every frame?  No

Can we start the screen memory on any address in video RAM? No

Can we restart the screen display from another address during the display? No

 

Chances of a smooth-scrolling game: not at 50 frames per second. Using a lot of pre-rotated graphics in memory it's just about possible at 25 frames per second, if you're really clever - see Dominic Robinson.

 

Commodore 64

Do we have user definable character modes? Yes
Do we have bitmap modes? Yes: 320x200 2 colours or 160x200 4 colours (8K) with colour in 8x8 blocks. 
Do we have smooth scrolling in hardware?  Yes
Do we have more than one playfield? No
Do we have hardware sprites? Yes, 8.

Do we have enough CPU time to rebuild everything on the screen every frame? Yes

Can we start the screen memory on any address in video RAM? No, only  on 1K boundary.

Can we restart the screen display from another address during the display? No, but we can change the character set, for score panels and the like.

Having user-definable characters means we can hit 32 multi-colour pixels on screen in one go by changing one byte, which really saves a lot of time. By changing the actual graphic we can change all occurrences of the character on the screen at once - very powerful.
 

Chances of a smooth-scrolling game: excellent. Fast scrolling is possible because we have time to rebuild the entire background every frame, and control the sprites. We can also more economically slowly scroll and build a new buffer over, say 8 frames, and switch to a new 1K screen area as required.

 

Atari ST

Do we have user definable character modes? No, only bitmaps.

Do we have bitmap modes? Yes: 320x200 in 16 colours (32K).

Do we have smooth scrolling in hardware?  No, not until the STE.

Do we have more than one playfield? No

Do we have hardware sprites? No

Do we have enough CPU time to rebuild everything on the screen every frame?  Not really.

Can we start the screen memory on any address in video RAM? No, limited boundaries.

Can we restart the screen display from another address during the display? No

 

Chances of a smooth-scrolling game: Just about enough CPU time if you pre-rotate the graphics in all possible positions and possibly reduce the number of bit-planes/colours and reduce the play area by adding large control panel.

 

I did prototype Paradroid 90 with a 4-colour background scrolling in all directions, but we chose to go for a 16-colour version with only vertical scrolling because we felt that less colours would be unacceptable.

 

Commodore Amiga A500/A600/A1000

Do we have user definable character modes? No, only bitmaps.

Do we have bitmap modes? Yes: 320x200 or over-scanned in up to 64 colours (48K or more).

Do we have smooth scrolling in hardware?  Yes

Do we have more than one playfield? Yes, 2, if we limit each to up to 8 colours.

Do we have hardware sprites? Yes 4 16-colour 16-pixel wide sprites down the whole screen.

Do we have enough CPU time to rebuild everything on the screen every frame?  Just about.

Can we start the screen memory on any address in video RAM? Yes, any 2-byte boundary.

Can we restart the screen display from another address during the display? Yes

I did prototype Uridium 2 with a dual playfield mode. We had a 7-colour foreground and a 3 colour parallax background scrolling underneath. It was quite effective on its own, but with only 7 colours for the main background and any objects plotted onto it, distinguishing them was going to be really difficult. We could have used the hardware sprites for the Manta to make it stand out, but we needed to make the walls and the enemy ships and bullets really stand out too. We decided to use 32-colour graphics for the background instead.

 

The Amiga AGA chipset A1200 took the playfields further, allowing 2 playfields of 16 colours each, or 1 playfield with up to 256 colours from a palette of 16.8 million, and 2 MB of RAM. I'm told it had better/more hardware sprites, but I don't remember how that worked.

  

In an Ideal World

What we really wanted was what the arcade machines had. Before they got into sprite enlarging and rotation, and therefore into the 3D world, it looked like they had 2 or 3 playfields, 8x8 pixel characters that they could reflect individually in X or Y, many, many sprites that could go between or over the playfields, with reflection in X or Y, and in a number of different colour palettes. They clearly had smooth scrolling in X and Y too. That's my guess at what Taito had in 1987's Flying Shark, for example.

 

A Modern PC

I thought it would be interesting to compare and contrast a modern PC, which is not dissimilar in capabilities to a modern console in its approach.

 

Azumi , the PC
Do we have user definable character modes? No, only bitmaps.

Do we have bitmap modes? Yes: 800x600 up to 1920x1200 in 16 million colours (8MB).

Do we have smooth scrolling in hardware? No

Do we have more than one playfield? Can be done in software with layers.

Do we have hardware sprites? No

Do we have enough CPU time to rebuild everything on the screen every frame?  Yes

Can we start the screen memory on any address in video RAM? Controlled by OS, so no.

Can we restart the screen display from another address during the display? No

Whist above we started out with Nos and they became Yeses as the home computers improved, suddenly as the Amiga was swamped by consoles and PCs, the Yeses have become Nos again, with one exception: the Central Processor Unit (CPU) and the Graphics Processor Units (GPUs) now have enough time to rebuild the screen from scratch in a 60th of a second frame due to the multi-threading capabilities of each. You might find 2, 4 or even 6 CPU cores, and 50, 100 or even 1500 GPUs in your PC. Every pixel rendered can perform its own lighting calculation on one GPU. It's an impressive advancement, though it has not simplified the programmer's task, nor the graphics artists`. 

 

Some Background Information

In the old days our computer screens had borders. Nowadays the display is designed to exactly fit the screen, there is no border. You might think that's better, who needs a border? Well, we used to find it tremendously useful. We could assemble our programs in Debug mode, i.e. we could selectively switch in or remove lines of code, to set the border colour at the end of each major routine to a different colour.

We used interrupts synchronised to the picture display to control the game speed and give some stability to the border colours: they always started showing colours at the same stage on the screen, and you could make the scroll routine one colour, the screen restoration one colour, the object updates one colour and the plotters one colour. That way you would get a cascade of consistent colours down the sides and could see, for example, that updating all the objects might take a couple of character blocks down, the plotters might take 5, and so on. If a routine set half the screen border to one colour you knew it'd need some taming down. Plus, if it crashed, you'd be left with the border colour set to the last routine it didn`t finish.

We would have many compiler switches in a top-level header file to be able to control different configurations. One of them was:

No             equ 0
Yes            equ 1
MonitorDisplay equ No   ; Display CPU usage. Final build: No

We had an assembler macro called "Flash", which you could pass a colour value to, or in fact any valid assembler source such as a register, an immediate value or a variable:

Flash  Macro
    If MonitorDisplay=Yes
    move.w \1,COLOR00
    EndC
 EndM

By setting MonitorDisplay to Yes the macro will assemble the extra instruction to set the border colour. If set to No, it won`t assemble anything, so no time wasted. To use the macro you might have a piece of code like this:

  Flash  #$0500               ; Red
  bsr    WipeRadar
  Flash  #$0050               ; Green
  jsr    SpriteHandler
  Flash  #$0055               ; Cyan
  jsr    RestoreBack
  bsr    CharAnimateControl
  Flash  #$0005               ; Blue
  jsr    PlotSchedule
  bsr    BuildCopperList
  move.l ColourPalette\w,a0
  move.w (a0),d0
  Flash  d0

The final use of Flash sets the border to the colour it was supposed to be, usually black. You need to not make the colours too bright or the monitor starts to distort the line widths and it makes the screen difficult to read. Note that the Amiga colour zero is both the border and could be on the screen too.  
 

The graphics chips had to read the screen display memory, add the sprite data to the mix, and fire the resultant colours directly to the video output for the monitor to display all in exact timings to show a picture. At the bottom of the screen, the display is done, and has a rest as the raster crosses the lower border colour off the bottom before flying back to the top. It then displays some more border colour until the next display starts. The time when the graphics chip is not displaying data is called the "Vertical Blank" or VBlank interval. When the raster flips back to the top it`s called "Flyback". 

The Amiga was pretty flexible: we could set how many display lines we wanted to display on the screen, where they would start and end, and also we could set the left and right edge positions too. There were guidelines and standards so we stuck with those. Typically a PAL display had 312 possible display lines vertically, and we used 256 of them, at 50 frames per second. An NTSC display has 262 lines, so we had less vertical lines available, and it had to run at 60 frames per second. The display device was calling the shots. Nowadays the PC graphics card tends to tell the display what it`s going to get, and most PC displays run at 60 frames per second. There is a G-Sync system out there on some cards that allows variable frame timings whereby the screen waits until the display routine tells it there is a new screen available. Your frame rate become flexible, and because the display is not built by electrons hitting a phosphorescent screen, the LED or LCD screen just holds the last set of colour pixels it was sent until it gets new ones. Yes, you need a G-Sync monitor, graphics card and game software to do this. 

If you are plotting objects onto a bitmap screen rather than using hardware sprites, you really need to be using what we call double-buffering. Effectively we show one screen to the player and don't touch it, and then build the next screen in a second area of RAM, at our leisure, and when that's finished we can wait for the end of the display frame before swapping the buffers over, i.e. we present the new screen to the player and can start work on the old buffer.

 

Astonishingly it has taken PCs a long time to implement proper Vertical Syncing. How many times have you seen screen "tearing" where there is obviously some glitch going on across the screen; as the display is switched over to the back buffer while the screen is being displayed? The CPU had no way of detecting when the display of a whole frame was complete. On the Amiga we could set up interrupts to go off as soon as the vertical blank period started that would let us know it was safe to switch the screen buffers over.

 

To the Amiga Scroll Routine 

The Amiga display we used was made of 16x16 pixel tiles, for efficiency and flexibility. The CPU can write out twice that width but the tiles would be more difficult to work with, and collision detection would be grainier.
Since we don't really have enough CPU time to reconstruct a 40K screen from the 16x16 tiles from which the background is built, and since a fair amount of the screen doesn't change, we want to be able to use the data that is already there. This differs from the more modern PC and console games approach where there is usually a dynamic camera and we have to start every frame from scratch anyway. Most business software however only updates things on the screen that it knows have changed.

We need to be able to restore a screen back to its pristine self before we plot the new objects onto the background. otherwise things would leave trails. We could either mark the character blocks as dirty and restore the dirty ones as whole characters, or remember where we plotted the objects on the screen and copy just the area under the objects that has been disturbed. In fact, we sort of had to do a bit of both. We supported animated characters, such as the waterfalls in the jungle level 2 of Fire and Ice. In the event that we have updated the character animation then we need to update all the instances of those characters on the pristine screen buffer, and then in turn copy the data to the next 2 (or 3) back buffers to ensure that all of the screens show the same.

 

We chose not to mark characters as dirty because of the additional time to figure out which blocks to restore, and because a 4-pixel tiny object could dirty 4 entire characters if it was at the position where they meet. The plot routine already has to work out where it is going to plot on the screen, so we just store that information in a restoration list per screen.  

 

We also used hardware sprites to plot some objects. For those, we can ignore the masks and just copy the image to the sprite buffers. Additionally, we do not need to store any background restoration positions as the data is not plotted on the actual background.

 

The Amiga had a number of asynchronous operations going on. For example, there was a Copper chip. This could be given a series of instructions to  wait for specific raster lines on the screen and load hardware registers with values. This would be used to set the bitplane start addresses for the screen, since these change every frame because we are writing to 2 (or 3) screens. We also used it for colour effects, screen splits, and reflected images in the water. The Fire and Ice bottom panel at the waterline started reading the graphics data upside-down, altered the colours slightly and applied a sine-wave pattern to the X smooth-scroll position on each line.

 

We also have the Blitter chip, which can be used to copy data from A to B, or plot data onto the background (logically AND mask data at A to C, then logically OR data at B to C) . Since we interleaved our bit-planes, provided we interleaved 5 identical masks within our plot data, we could plot an object with one Blitter operation. This required more data, but means that you can let the Blitter get on with the whole plot while you work out the next object. We checked that the Blitter was ready for more action just before we have the data ready for the next Blit.  

 

Hardware sprites on the Amiga are not like the C64, more like the Atari 8-bit ones. You need to arrange all the objects you want to plot in sequence down the screen and then start putting them into the 4 lists, 1 for each 16-colour sprite. Each sprite list consists of an image, and then a wait instruction for the raster line when the next one starts. If we had too many hardware sprites on one raster line we would have to use the standard Blitter plot routine for the extra ones. In any case we can also use the Blitter to copy the image data to the sprite lists.

 

Putting Things in Order

It`s important to get things done in the right order. The right order depends on what sort of a game you are writing. There are games that scroll at a constant speed, such as Flying Shark, games that may scroll at a constant speed, or stop at times, such as Dragon Breed, or games where the player has control over where they want to go. I prefer the latter.

 

The player`s movement from the input device is used to adjust the player`s speed, and this decides the player`s new position. The player`s position on the map decides the player`s position on the screen, and depending on whether the player is locked in the middle or allowed to move around in a box in the middle of the screen, the player`s position on the screen decides the new required scroll position. In either case, the screen won`t scroll any faster than the player`s movement, which we have defined in the control mode.

 

We're always working in co-ordinates, the new scroll position is decided by simple tests that keep the player on the screen, and possibly in the middle. The actual scroll speed isn`t stored anywhere, we just have a new scroll position and a previous scroll position, and the routine has to do whatever it takes to align the new screen display for the player, regardless of where it was last time, which might be 2 moves hence in a double-buffered system, or 3 in a triple-buffered system.   

  

Vertical Scrolling First

Everything herein refers to Uridium 2, but most of it applies to Fire & Ice too. Fire and Ice used 16-colour graphics, whereas Uridium 2 used 32 colours on ECS chipset, and 64 colours on AGA chipset.

 

In order to preserve as much of the background as possible while scrolling, we need to use an Amiga trick of being able to restart the screen display at any point down the screen. The origin was always the top left, so let's start there.

 

Our background is made of 16x16 pixel characters. One could just as easily use 32x32 characters, or 8x8s. Our choice was based on efficiency against drawing flexibility. We did Rainbow Islands in 8x8s because that's what we thought Taito used, though they tended to arrange them in 2x2 blocks anyway.  

 

We had a map of the whole level laid out in RAM for quick access. This was just the character codes of the 16x16 graphics. Objects would need to know what characters they are flying over. All of the wall and high towers characters were at one end of the character set to give an easy cut-off point. Only the Mantas and their bullets actually collide with the background.

 

As we scroll the map downwards a pixel at a time, we start the screen bit-planes one raster line's worth of data later. The top character begins to recede under the top of the screen and a new character is revealed at the bottom. The screen buffer is one character taller (and wider) than the displayable screen. The Copper list has a static format and is updated during the vertical blank while it is not being used for display.

 

When we get to 16 pixels down, we have lost a whole character row at the top, it is no longer on display. What we now do is reuse the now-unseen top row of the screen with the graphics for the new row that's about to arrive at the bottom. Firstly we set up the graphics in the pristine restore buffer by copying the character graphics over, one by one. Then we can copy the entire rectangle one row deep by 20 characters wide from the pristine buffer to the back buffer area. We then have to deal with any animated characters, and also restore any areas that were covered by objects that will be moving on. The actual on-screen display will have moved twice (or three times) since its last display, so possibly a small area of restoration will be done that is unnecessary due to the new block being added, that's minimal and OK.

 

I've just remembered that some non-moving background features done with plotted objects could be drawn without transparent pixels and get plotted on the screen without saving the restore position because we know they're going to be re-plotted next frame. Hatchways and small gun turrets qualify. Every saving helps. These objects are also typically nicely aligned with the characters/bytes, so we can call the optimised plotter that knows it doesn't have to shift the graphic sideways into place. Rainbow Islands hidden fruit is an example. As long as the final frame of the animation matches what was on the background in the first place we can switch the animation off at the end and save plot time.

 

Now we have a background screen with a split near the top, which we need to aware of. As the screen scrolls downwards, the split moves upwards from the bottom at the same rate, and we have to tell the Copper chip to restart the bitplanes display at the top of the screen RAM. We also have to check for this split when we plot objects across the split, since we need to plot the top part of the object to one area of the screen buffer RAM, and the lower part to another. This results in 2 restore buffer entries also.

 

As the screen scrolls down further, the split moves up the screen until it hits the top, and then flicks back to the bottom again. You might think of the screen RAM buffer as a rolling barrel. We even referred to it as a barrel in the code.

 

If the screen scrolls upwards, the split moves down and we have to restore rectangles of characters at the top of the screen rather than the bottom. We had a routine for each, since it needs to be fast, though both do the same job, albeit based on different positions. It`s fastest if it doesn`t have to cater for 2 or more situations. Make the decision early when you can, and although it takes more space to code 2 near-identical routines, the saving of a few cycles gives you the more time for other things.
 

Horizontal Scrolling Second

This is the clever bit. We hadn't worked this out ourselves but we did have a chat on the phone with the Factor 5 team: Holger, Thomas and Julian. They had written Turrican II by this time and we had seen what they had achieved. They told us how to get the screen scrolling sideways using a similar technique to that used above, and all we had to do was allocate a few extra bytes at the end of our buffer, as many as we wanted to scroll one pixel row sideways from one side of the map to the other, in fact, say 20x2x10 bytes, i.e. 400 bytes per buffer, not much at all. 

 

So, starting from top left, we start smooth scrolling by 1 pixel to the right. This is done with the hardware scroll X register. What it's really doing is throwing away the number of pixels you tell it, from 0 to 15, before it starts displaying the screen picture. Our screen buffers always support one more character wide and high than the screen is; because in 15 out of 16 cases that extra character row or column is partially visible.

 

When you get to 16 pixels across you reset the Scroll X position to 0, and add one word (16 bits/pixels to the pointers to the start of the buffer display, and the split pointers, for each bitplane. You've now restarted your screen a whole character to the right. At this point we need to build the incoming column of characters to the right in our pristine buffer, and copy the rectangle of that buffer to our back buffer. All the data we need to display is untouched, and we have new data arriving on the right. You can keep going right for as much extra as the extra bytes we added. Going 10 screens worth to the right only costs 400 bytes. The whole screen is sliding sideways through the buffer.

 

To come back to the left, we just reduce the offset into the buffer by 2 bytes, or 16 pixels, at a time, keeping it synchronised with the smooth scroll X position, set up by the Copper list. We then add columns back on the left side and copy the rectangles from the pristine copy to the real screen buffers as they come round. 

 

Now all this does generate a lot of code, I won't deny it. The plot routines, the background refreshes, the character animations, the Copper list, everything has to work together. What we get out of it is an efficient system that doesn't cost us much time to just run the background, and each object only has to clean up the bytes that it alters. All of these components took quite a few weeks to code, and longer to get my head round it all.

 

Initialisation.

The easiest way to get the initial screens set up is to start the screen position 1 screen to the side of where we want. We then scroll the screen to the position we really want while it is blanked out, and since no game objects are active we can do this quickly, and we don`t have to wait for vertical blanks, so just the scroll routine will loop round 20 times if you do it horizontally, or only 12 if you go vertically. The same amount of work is done whichever you do because you're refreshing the whole screen either way.

 

Starting up any on-screen objects is usually also driven from the scroll movement, so by calling that as well, any on-screen objects are also started up by this initial scroll movement to set up the game graphics. All very convenient, it is.

 

Development

This scroll routine itself was coded at the beginning of Fire and Ice development. It took me a couple of weeks to get it done. You have to start with one character and build it up. I made up a set of basic blocks with numbers drawn on them so that I would be able to see that the correct characters were being displayed, and the animation could be seen. You can use the assembler to set up a simple map area so you don`t have to write a map editor and packer/unpacker yet.

Fire and Ice had an additional test mode since it supported slopes. Each character had a 16-bit word to define either the ground surface angle and height, or the side or ceiling blocking. On a key-press I could switch from showing the real characters to showing a wireframe diagram of the ground surface. This helped to see that the ground was continuous and the ice was smooth, and that there were no ways through that shouldn`t be there. I also had a ring of 2 blocked characters all the way round the map to make sure bullets, fish and birds stayed within the main play area. This eliminated the need for additional code to test for the map extremities as well as blocked characters.

As a point of note: due to the philosophy of not updating anything unnecessarily, the wire-frame map appears as you scroll along, at the leading edges or as objects move across the background, which also confirms how the restoration is working.

At first I hooked up the screen scroll position to the mouse input, so I could move the screen with the mouse. This input had less limitations, and of course I could add a multiplier to exaggerate or slow down the movement. This would prove the screen display could handle any movements. At this early stage of development there was no game, and no other objects to plot on the screen.

It is tough working on a screen display routine that is working completely on an unseen back buffer. There are lots of times when you don`t see anything happen on your display because you`ve used the wrong pointer, or got something else wrong. Usually there`s some evidence gets to the screen: a plotted object might splay out diagonally because you got the distance to the next row wrong, or it finishes early, or late. I don`t recall ever being able to set the screen to single-buffered mode so you could see stuff being written to screen.

Graphics are also removed from the screen by the restoration system so likely graphics would flicker and you'd be no better off in single-buffer mode. You have to write a lot of code and get it all working with will-power and staring at the code looking for mistakes. We started with a double-buffered system and then added the third buffer as an option later. Start as simply as you can. I'll do another page on the 16-bit plot routines for the Amiga soon. For example, we already had plot routines from the Atari ST, so we first adapted those for the Amiga bitmaps (easy few lines to change), and then altered them to generate Blitter commands later.

 

The Epilogue

When the game is at its busiest it is using all the available time and there will be little or no waiting time between frames. The slightest over-run into the next frame will cause the whole process to stall for a frame and the screen will not move smoothly for one frame. Naturally we design the game to run within the limits of the hardware whilst getting as much happening on screen as possible. Your game should not be generating meanies and bullets willy-nilly, you need to limit these elements to ensure over-runs don`t occur.

 

I have referred to a third background screen a few times. This is because we implemented triple buffering if there was extra RAM available. With a double-buffered system you have one screen on display, and another being worked on. Once the work is finished, you then have to wait for the raster to reach the end of the current display before you can swap the screens over. What if you could use the waiting time to start work on a third screen? You'd be getting ahead, so you could soak up any short over-runs if a few more bullets got fired.

 

When there is more RAM available on the ECS Amigas; it would be non-video RAM, called Fast RAM, because code executed there would run faster than in video RAM since the video chips might be using the video RAM, and will block the CPU. In those cases we would also load our game code into the Fast RAM where it would run faster as well. Double win! Bonus! On the AGA A1200s we get 2MB of video RAM and a faster CPU too. Party time!

Running a third buffer does allow us to get ahead, and allowed Mayhem Mode for the maniacs on the A1200 running the non-AGA version. The AGA version is permanently in near Mayhem mode. There is a slight downside in that the player may be looking at a frame that effectively happened 2 fiftieths of a second ago and what happened 1 fiftieth of a second ago is about to be displayed, and we're already building the next frame as well. No-one thinks that fast anyway, reaction time is about a tenth of a second so hopefully it doesn't make much difference. It can knock the sound effects ahead of the visuals by the same amount if you don't buffer the sound effects, which we didn't even think about! 

 

I've seen DirectX references to triple-buffering too, so I think it's a legit strategy if you're running on the ragged edge occasionally.

 

I'm considering in future projects doing a graphics performance test at the beginning or as the game progresses, to ensure that we don't over-run the magic sixtieth of a second. It`s the sort of thing to get done discretely during the titles sequence. There should be plenty of time for effects, and they can be tamed, and of course the user expects to be given overall control of the screen size/resolution and some of the more advanced rendering features.

 

 

 

 

 

 

Read More

Archiving Old Games



Introduction

I was recently tweeted about an article regarding the archival of old games. The article is here:
www.eurogamer.net/articles/2017-12-03-your-amiga-games-are-likely-dying

The basis of this article is that our 8 and 16-bit floppy disks were not manufactured to last 30 years, and we haven`t really been looking after them in a way that would help their longevity.

 

In order to preserve these historic games then, we are relying on failing media, and also failing hardware.

 

Now, companies are looking at archiving as many games as they can, and inviting submissions of software. Some of that software is tainted by having been cracked, altered, possibly broken. Therefore they want untainted originals that are still readable.

 

Additionally, in order to be able to see the games, either the requisite hardware is needed, or an emulator.

 

All this without treading on anyone`s toes or breaching copyright!

 

Why Doesn't the Music Industry Have This Problem?

In the games industry we would often look to the music industry as a model of how things worked. What we missed though was that music artists had struggled for years to earn rights and set up a proper royalty payment system.

 

The other difference is that artists in the studio were recording onto analogue tape, usually on 32-track tape, and then mixing down to the final stereo tape. They were smart enough to keep the 32-track and stereo masters in temperature-controlled vaults, though they are deteriorating over time.

 

The music industry has always moved with the times. Many albums have been available since the day they were released. They have therefore been able to re-release music by rendering the original masters onto whatever new media formats come along. Analogue master tapes were cut onto analogue vinyl and then onto analogue 8-tracks and analogue cassettes. Then came digital...  

 

Music publishers thrive on re-releasing the same material on a new format: a chance to sell the same thing to the same person again. The advent of the digital CD format meant that the old analogue tapes had to be rendered into digital data. Better than that, they found out pretty quickly that just copying the 2-track master resulted in a dull CD so they then tried doing it properly. Thus the CD re-master was born, whereby they might render the 2-track tape onto a hi-res digital medium, then process it to get the best out, and finally reduce the resolution for CD.

 

Later albums are all recorded in the digital arena now, so should be preserved for all time. They are recorded at a better resolution than the old analogue tapes, and better than the human ear can handle, so are as good as they need to be. The old master tapes have also been copied to digital, and though not as good as newer material, at least are no longer subject to deterioration over time. The film industry is undertaking similar transfers to digital.

 

Thus the music industry has been able to further the quality of home music into DVD, Blu-ray and FLAC, including re-mixing from the multi-track masters into 5.1 surround interpretations.

 

By supplying music in the new formats, the old ones can be allowed to peel away and die. Whilst you can still get the hardware to play the older formats you can keep your library of those formats, or upgrade at your own pace. Since the digital age the hardware manufacturers have been remarkably backwards compatible. The 5.25" aluminium disc marches on, as your new Ultra-HD Blu-ray player can play UHD BD, BD, DVD and CDs, and if you go for a universal player, maybe your DVD-Audios too.

 

Back to the Games

In the games industry the game code was written for specific hardware and is also written for specific media of the hardware, such as floppy disk and maybe hard-disk. As a developer, we would construct the original unprotected floppy disk master, possibly with many steps; as there would be the main program executable and loadable graphics and level data. This process may also involve the development kit as the code and graphics would originally be stored on a PC, and have to be saved out on an Amiga disk by the Amiga.  We would deliver a master floppy disk without protection usually directly to a disk protection specialist. They would then apply their own security and loading system to the disk, possibly being more inventive for a non-OS-compliant disk than one that has to play ball with the OS. The protected disk then gets passed to the duplicators with any special instructions. The upshot of this is that publishers don`t know how the disk is actually put together, and may not even have the master. The developer doesn`t know what the disk protection specialist has done either. I did try to debug one of our secure Amiga loaders, but it was fiendish. 

 

As time passes and machines change, the developer no longer has the hardware to make the disks any more. Additionally, we were very protective of our software. We never handed over source code to the publishers, citing that without the exact same development kit they would not be able to even compile the code. We regarded our code as trade secrets that gave us development advantages.

 

We were also so familiar with the build processes that we became very blasé about them, and never felt the need to document them. Now I can`t remember the processes or even what development kit we had for each game. It`s all a bit embarrassing. We never really expected to be talking about those games 30 years after; as we knew the hardware was advancing all the time and that our code would become irrelevant.

   

My Amiga disks

I was certainly conscious of the fragility of floppy disks from the start. I seem to recall that utility programs used to recommend that the supplied floppy disks be copied and then you put them safely away and use the copies only. That way, if you do get a disk read error; you can make another copy and carry on. I used to make a copy of my early Amiga games, indeed I have the originals and the copies in boxes to this day, though I haven't been through them all to see if they still work. I am sorting through my loft boxes to at least collect together all the games I own for each machine.

 

The article above then touches on copy-protected disks, and copy-resistant security sheets. Both of these measures cost us time and effort, and wouldn't have existed if unauthorised copying and sharing wasn't a problem, but it was a huge problem for us. Estimations were that for every legitimate purchase there were 10+ copies out there. Doubtless some people wrote out the security sheets by hand, and later the hackers removed security checks in the code anyway. The advent of disk-copier software that could circumvent our copy-protected disks was also a major irritation. Ironically I did use the same disk-copier software for the legitimate purpose of making backups of our source code and run-time disks for testing.

 

I was fortunate enough to find two Amiga A1200s in the loft. The first one I set up was my Dad`s, and has a 20MB hard drive in it. We designed an install to hard-drive script for Uridium2 and Fire and Ice, and I did indeed install those to the hard-drive. Fortunately the A1200 and the hard-drive still work, and I can play the games on it. I do also note that two games still requires the security sheet from the original game in order to play the whole game. That's what led me to instigate a search through my loft boxes for the original security sheets. Fortunately I have some of the complimentary author boxed games with the security sheets in-tact. I concur that feeding in the security info is a pain, and welcome suggestions as to what else we could have done at the time. If the un-tainted original version were implemented on an emulator, you`d still need the security sheet to play. Maybe I could set up a premium-rate phone line? I jest, maybe.

 

Fragile Media

From the time I started buying music albums on vinyl, I was painfully aware that they wore out. I accepted that I had bought a licence to listen to the music for the lifetime of the vinyl, which was limited. Indeed I still own my 3rd vinyl of A Farewell to Kings by Rush. I bought the first one in 1977, and was getting about 3 year's use out of each one. It was probably one of my most played albums. I have also bought 3 different renderings of the same album on CD, so I'm getting more like 10 years out of each one now! They're not wearing out, but Rush are finding new ways to re-master them. In fact they've released a 40th anniversary edition in 2017 and I expect to buy that too, and I'm also after the Blu-ray surround edition, but you can keep the vinyl.

 

I`m thinking then that computer games are no different in the respect that we buy the game knowing that it`s only for the lifetime of the media on which it is recorded, though I wish that it was at least a digital medium. I am therefore sympathetic to the idea that anyone who legitimately owns the original game could have access to the digital content to be able to continue to play, which is a bonus above the original deal.

 

Since mostly we can`t now buy replacement games anyway, unlike music and films, then no-one is getting any payment for the games any more. Some developers that possibly also published seem to be "re-mastering" titles for more modern kit, since they know they have the rights to do that. They presumably either still have the old development kit or have converted the source code to new kit. Even source code ages! More correctly, assemblers have slightly different flavours. 

 

We can`t ignore copyright and copy anything we want for free, but where is the middle ground? Are the publishers willing to make limited quantities of old games available for sale, either on original media or for emulators? How many 8 and 16 bit games publishers still exist? Do they even have the original materials to achieve that?  As an ex-developer I know that I don`t, and Graftgold in administration was not bought in-tact, only the IP was, and what is that worth 20 years later? To whom would publishers pay the author`s royalties on old titles, if any? Of course the contracts are written in perpetuity, so someone should be getting the author`s royalties, right?

 

In the article, above, the archival company was inviting submissions of original disks for archival copying. They had decided to send a digital copy back to the submitter. I don`t think that`s quite right. I`m happy that the submitter gets their original disk or disks back, maybe with a copy on the same type of media, for their own further use, and even potentially a personalised licence code for an emulator. A digital copy should only be supplied back to the submitter if they can prove that they are a legitimate representative of the developer of the original material. I suppose that wouldn`t even include me any more, which is a shame! 

 

In Conclusion

The only way forward is machine emulators. These appear to be the work of enthusiastic and clever amateurs who do it for the challenge and the love of the games. The real hardware will eventually fail, and if no-one brings them back into production then they will fade away.

 

Is it only the people that did own the original hardware that are in any way interested? In which case the old games will not so much be resigned to history; as dissolve into legend over the next few decades.

 

Personally, I`d prefer my games to be remembered, and seen, and played, and I have to let go of the fact that I won`t make a penny from that preservation. I`d prefer the archives to show the original work and not copies tainted by thieves. To that end I guess I should try to ensure that the archives have access to any mint-in-box originals I have, before it`s too late.

 

 

 

 

 

 

Read More