Reconstructing the Leftovers on the Amiga Kickstart 1.0 Disk

Update: The source is available at github.com/mist64/extract-adf

It is well-known that the “Kickstart” disk that came with the original Amiga 1000 in 1985 contained some fragments of source code: The floppy disk that was used as a master for duplication had been used by the developers before, and had not been erased completely.

Nobody seemed to have looked too closely at what is on this disk – so I did, for this episode of Computer Archeology. The revealed data tells us about how the Amiga operating system was brought up, how it related to Tripos, and where it was developed.

The Kickstart Disk

When the Amiga 1000 was released, the 1.0 ROM image was not finalized, so the machine shipped with a “Kickstart” floppy disk that was loaded into an extra 256 KB RAM bank which was then write-protected.

A double-density Amiga disk is exactly 880 KB, i.e. it consists of 1760 sectors, each 512 bytes in size. The Kickstart disk has a header on sector 0 (saying “KICK” followed by all zero bytes), and the raw ROM image is stored on the following sectors. The ROM is 256 KB in size, so this means that all sectors from 513 on are unused, and, in the case of the Kickstart 1.0 disk, preserved.

The following analysis has been done on the Kickstart 1.0 ADF disk image with an MD5 of 2fb28e7bbab0d2eef00e742c7259a674.

Amiga Old Filesystem

Before version 1.3 of the operating system, disks were formatted with the “Amiga Old Filesystem“, which was quite inefficient, as it stored metadata pretty redundantly. Every single sector, even sectors containing file data, start with a 24 byte header, which contains

  • the type of the sector (directory entry, data…)
  • a pointer to the parent
  • the sequence number of the sector inside the file
  • the number of valid bytes in the sector
  • a pointer to the successor
  • and a checksum.

Every directory entry occupies a complete sector, and deleting a file means just removing the links to the directory entry sector, without touching the data sectors or the directory entry sector at all. And what’s best: For performance reasons, directory entries are clustered around the center of the disk, i.e. sector 880, which, in our case, has not been overwritten by the ROM image, so it should be easy to get some data out of this disk.

Extraction Program

The program to extract the data from the disk uses the following algorithm: It iterates over all sectors from the end of the ROM image to the end of the disk image and looks at the sector type. If it is a data block, it looks at the parent, in the hope that it is an intact directory entry. If this is the case, it walks back the list from parent to parent to get the full path and filename of the file. If the directory entry has not survived, the file will get the index of the directory entry as a name. As we now know the filename of the file the sector belongs to and we can read the sequence number from the sector header, it is possible to write 488 bytes worth of data into the output file.

Here is the source code of the program to extract the files: extract-adf.c

Results

The disk seemed to have contained C header files and assembly includes earlier, and has then been overwritten with the current set of command line tools of AmigaOS (the name of the disk “cli26.1″ reflects this), extended with some custom development tools used by Commodore-Amiga.

Since the DOS part of the Amiga operating system is actually based on the only very slightly modified Metacomco Tripos operating system, the command line tools as well as the development tools mentioned in the following sections are mostly the same as those found in Tripos; therefore the terms Tripos and AmigaDOS may be used interchangeably.

CLI Programs

The “c” subdirectory contains the following command line tools that can also be found on the Workbench 1.0 disk:

Assign
Break
CD
Copy
Date
Delete
Dir
DiskCopy
Echo
Ed
Edit
EndCLI
Execute
FailAt
Fault
Format
If
Info
Install
Join
Lab
List
MakeDir
NewCLI
Prompt
Protect
Quit
Rename
Run
Search
Skip
Sort
Stack
Status
Type
Wait
Why

The following executables can be found in the “l” directory:

Disk-Validator
Port-Handler
Ram-Handler

But these may very well be earlier versions. “DiskCopy” for example is significantly smaller than the “Diskcopy” that shipped with Workbench 1.0.

Development Tools

The following command line utilities can also be found in “c”. They do not ship with WorkBench, but are part of a separtare tools disk for developers, as described in the AmigaDOS Manual. Some also exist on pre-1.0 beta versions of Workbench, although possibly in different versions.

Alink Amiga Linker Version 2.17, Copyright (C) 1985 by Tenchstar Ltd., T/A Metacomco.
DiskEd AmigaDOS Disc Editor
DownLoad DownLoad version 2.0, Sun->Amiga transfer utility
DumpObj Displays executable hunks in hex

Alink is the Amiga-native version of the TRIPOS/Metacomco linker

According to the AmigaDOS Manual (or Tripos Technial Reference Manual), “to inspect or patch disk blocks, you may use the AmigaDOS [Tripos] disk editor, DISKED.” The version on this disk is 3.2; the 2.0+ NDKs shipped with 3.4, and cintpos, the open source release of Tripos, includes the source for 3.0.

Download is quite interesting, not only because the binary and its documentation are very hard to find, but also because they tell a lot about the history of the Amiga operating system. According to the AmigaDOS manual, it is used to download “programs written on another computer (for example, a Sun) to the Amiga.” – the counterpart on the Sun workstation would be “binload”.

An interesting side note on this version of “Download” is that it still contains all linker symbols, and has a debugging mode (“-d”) that prints out every step that it is doing, so it is pretty easy to reverse-engineer.

There is strong evidence that the Amiga operating system has been cross developed on Sun machines. After all, the official Amiga SDK is called “NDK”, “Native Development Kit”, implying that the original bringup SDK was not native.

At that time (1985), Sun Workstations were 68000- or 68010-based computers running SunOS 1.x, which was based on 4.1BSD. The C compiler that came with BSD at that time was the Bell Labs “Portable C Compiler” (PCC), which could naturally output 68000 code. The “Bell Labs C compiler” (i.e. PCC) is mentioned in a header file in the “Native Development Kit” for AmigaOS as printed in “AMIGA ROM Kernel Reference Manual: Libraries and Devices“, next to the suggested native compiler “Lattice C” and two other compilers, implying that PCC could be used for Amiga development.

The AmigaDOS manual says that “the tools available on the Sun Microsystem for cross development include the assembler, linker, and two C compilers.” One compiler is explicitly mentioned: It is the “Greenhills C compiler” (metacc; the name suggests it was Metacomco’s shipping C compiler for Tripos); the other one is presumably PCC. According to this resume, the first versions of the ROM were compiled using the Greenhills C compiler.

So Commodore-Amiga must have cross-developed AmigaOS on BSD with the Greenhills C compiler.

New Executables

c/d
c/Read serial/parallel port receiving utility
c/ReadPref accesses config/preferences
demos/ImageEdit

“d” seems to be used to delete files, “Read” contains strings about reading from serial and parallel ports, “ReadPrefs” accesses the file “config/preferences”, which is also included on this disk. It is unknown what ImageEdit is for – it does not contain any strings, but included linker symbols imply that it deals with timers.

Devices and Libraries

The disk also comes with the Narrator device and the Translator library, which are required for speech synthesis. These two files have been overwritten once, so there are now two different copies on the disk:

devs/narrator.device narrator Version 25 (rev 3) (Thu Jun 20 18:47:53 PDT 1985)
devs/narrator.device narrator Version 26 (rev 1) (Wed Jun 19 14:22:29 PDT 1985)
libs/translator.library translator Version 26 (rev 1) (Wed Jun 19 14:49:56 PDT 1985)
libs/translator.library translator Version 26 (rev 5) (Thu Jun 20 17:25:49 PDT 1985)

The header of the libraries contain the respective versions. Note that the newer version of narrator.device has the older timestamp. “PDT” implies that AmigaOS has been written on the US West Coast – in the California office of Commodore. For comparison, Workbench 1.0 shipped with

narrator 1.6 (10 Sep 1985)
translator 1.3 (4 Sep 1985)

Misc Files

config/preferences 240 bytes, mostly 0s, no strings, read by c/ReadPrefs
s/startup-sequence ReadPref
echo "Use the DATE command to set date and time"
wait 1 sec
date
t/ed-backupequence echo "Use the DATE command to set date and time"
wait 1 sec
date

This is an “ED” backup of startup-sequence
demos/src/wtest.asm Assembly source in Metacomco format (“MOVE.L”; for “assem”) that prints “Hello World” to the console and opens a window. The source has been generated with “metacc -S”.

Files for Development

For many of the files on the disk, the original directory entry has been lost, but it was possible to reconstruct the filename using the printed headers in “AMIGA ROM Kernel Reference Manual: Libraries and Devices“, digital versions of older and newer versions of the headers, and the AROS versions of the headers.

Sector Filename Comment
0935 amiga.lib C wrapper code around the Amiga APIs (first few sectors missing)
1077 crt0.obj Linker object that contains the code that gets executed before “main()”. It opens dos.library, caches stdin and stdout, and provides an exit() function.
1074 clib/macros.h
1025 exec/alerts.h (first few sectors missing)
1026 exec/execname.h
1045 graphics/clip.h 02-04-85 Dale created file from graph.h
1050 graphics/clip.i
1051 graphics/collide.h 8-24-84 Dale added this header file
1052 graphics/copper.h 2-09-85 Dale made #defines for union ignorance
1053 graphics/display.h 8-24-84 Dale added this header file
1054 graphics/gels.h 9-28-84 -=RJ=- for GELS16 added Bob.h to this file
1055 graphics/gels.i
1056 graphics/gfx.h Feb 85 Dale added Rectangle,BitMap structures
1057 graphics/gfx.i
1048 graphics/gfxbase.h 10-20-84 Kodiak added this header file & TextFonts
1059 graphics/gfxbase.i
1060 graphics/gfxmacros.h 9-07-84 Dale fixed macros to use new RastPort
1061 graphics/graphint.h
1062 graphics/layers.h
1063 graphics/layers.i
1064 graphics/rastport.h 02-04-85 Dale created from graph.h
1065 graphics/rastport.i
1058 graphics/regions.h
1066 graphics/regions.i
1067 graphics/sprite.h
1068 graphics/sprite.i
1027 1071 graphics/text.i $Header: text.i,v 25.1 85/05/06 10:54:07 kodiak Exp $
(version at 1027: first few sectors missing)
1028 1069 graphics/text.h $Header: text.h,v 25.1 85/05/06 10:53:57 kodiak Exp $
(two identical copies)
1072 graphics/view.h 2-8-85 Dale conversion to 24 View->ViewPort
1073 graphics/view.i
1044 intuition/intuition.h 1-30-85 -=RJ=- created this file!
1047 intuition/intuition.i 6-13-85 =VoodooDrRj= added back the comments
1046 intuition/intuitionbase.h 3-1-85 -=RJ=- created this file!
1009 libraries/translator.h
1029 libraries/translator.i
1030 libraries/dos.h
1032 libraries/dos.i
1033 libraries/dosextens.h
1034 libraries/dosextens.i
1035 libraries/mathffp.h
1036 resources/cia.i
1043 resources/ciabase.i
1041 resources/disk.i $Header: disk.i,v 26.1 85/06/17 12:19:27 neil Exp $
1042 resources/disk.h $Header: disk.h,v 26.2 85/06/17 13:01:21 neil Exp $
1038 resources/potgo.h
1031 resources/potgo.i
1039 resources/misc.i $Header: misc.i,v 26.1 85/06/17 12:08:29 neil Exp $
1040 resources/misc.h $Header: misc.h,v 26.1 85/06/17 12:08:26 neil Exp $
1070 diag/romdiag.i only came with 1.0 of the includes

Unlike the published NDK headers, these still contain the revision control and author information. All files use UNIX line breaks (LF).

Some files contain the address of Commodore-Amiga, which was:

Commodore-Amiga Incorporated
983 University Ave. Building #D
Los Gatos, California, 95030

Directory Entries with Missing Data

There are directory entries for the following header files and includes on the disk, but the data is missing

devices/audio.h
devices/audio.i
devices/bootblock.h
devices/bootblock.i
devices/console.h
devices/console.i
devices/gameport.h
devices/gameport.i
devices/inputevent.h
devices/inputevent.i
devices/keyboard.h
devices/keyboard.i
devices/keymap.h
devices/keymap.i
devices/narrator.h
devices/narrator.i
devices/parallel.h
devices/parallel.i
devices/serial.h
devices/serial.i
devices/timer.h
devices/timer.i
devices/trackdisk.h
devices/trackdisk.i
hardware/blit.i
hardware/intbits.h

There are four more directory entries for executable files:

Assem AmigaDOS/Tripos macro assembler by Metacomco.
Avail shipped with developer tools, and OS >= 1.3
ObjDump probably same as “DumpObj”
SetPref probably the counterpart to “ReadPref”

Conclusion

The following conclusions can be drawn from this exercise:

  • The reduncandy in the Amiga Old Filesystem makes this filesystem perfect for reconstructing deleted and even partially overwritten data.
  • AmigaOS seems to have been bootstrapped using SunOS and the Metacomco/Tripos toolchain, and has probably not been self-hosting for 1.0.
  • The disk was used to move developer tools and header files between machines.
  • Version 1.0 of the OS has been developed in the California office of Commodore – the original Amiga office.

Open Questions

  • What source control system was used?
  • How does the version numbering (“26.1″ etc.) work? How is it related to source control?
  • Does the 1.0 NDK still exist somewhere? It should have shipped with Lattice C, at least. It would be very interesting to compare these headers and includes with the 1.0 NDK ones; for real differences, and for changes in the comments.
  • What are the differences between these headers and the 1.0 headers? Any last minute changes?

Links

1

27 thoughts on “Reconstructing the Leftovers on the Amiga Kickstart 1.0 Disk

    1. Olaf Barthel

      > Amazing effort, Michael. I think the system they used was RCS, based on the file extensions and common usage on Suns.

      I can confirm the use of RCS. The RCS logs reach back to August 28, 1985, when Carl Sassenrath checked in exec as “Version 1″. Prior to that only the original developers will know if source code control was used, and which kind. The Sun workstations at the time probably had SCCS installed, too.

      Reply
  1. Simon Collis

    Loving this – who’d have thought that a duplication master wouldn’t have been completely formatted before being rushed out! It happens though – I remember downloading a D64 file from a software manufacturer a few years ago and running an undelete on it and actually finding a pirate game! (And no, before you ask – not one of theirs, and complete with a crack intro…)

    Reply
  2. iDG

    Your observations are correct indeed, but as far as I can tell the fact that the early versions of AmigaOS were built on Sun hardware using the greenhills compiler is (was?) common knowledge.

    Reply
  3. Jean-François bachelet

    Great job :-)

    Concerning the SDK, I have got a box with the entire v1.0/1.1 developer kit from Commodore with the v1.0/1.1 “Rom Kernel” manuals which consist of :

    - Amiga DOS Technical Reference Manual (CBM 327266-01 rev 1.0 8.27.85)
    - Amiga DOS User Manual (CBM 327264-01 rev 1.0 8.27.85)
    - Amiga DOS Developers Manual (CBM 327365-01 rev 1.0 8.27.85)
    - ROM Kernel Manual vol. 1 : (CBM 327271-04 (327271-02 rev 2 12.9.85)
    - ROM Kernel Manual vol. 2 : (CBM 327271-05)
    - Harware Manual (CBM 327272-01 rev 1.0 8.27.85)
    - Intuition Manual (CBM 327267-01 rev 1.0 8.27.85)
    - Lattice C Manual (CBM 327270-01 rev 1.0 8.28.85)

    - Info Packet with :
    – New features in Amiga System Software release 1.1 (25 Nov 1985)
    – Support Notes
    – Cross Development Guide
    – Errata for the different guides

    Software on 3.5″ Disks :
    - Lattice C
    - 68000 Macro Assembler
    - Wack Disk

    Software on 5.25″ Disks :
    - Lattice C cross libraries (v1.1 26 Dec 1985)
    - Lattice C Cross Development Headers (v1.1 26 Dec 1985)
    - Lattice C cross Compiler (v1.1 26 Dec 1985)
    - Cross Assembler (v1.1 26 Dec 1985)
    - Assembler Cross Development Headers (v1.1 26 Dec 1985)

    A letter from David Street (Manager of Technical Support and Software Development) to the Developers.

    I have to read the cross dev manual to see on which systems the 5.25″ disks are made to run, but it’s possibly for sun…

    Amigalement,
    Jean-François “voxel” Bachelet

    Reply
    1. Olaf Barthel

      Software on 5.25″ Disks :
      - Lattice C cross libraries (v1.1 26 Dec 1985)
      - Lattice C Cross Development Headers (v1.1 26 Dec 1985)
      - Lattice C cross Compiler (v1.1 26 Dec 1985)
      - Cross Assembler (v1.1 26 Dec 1985)
      - Assembler Cross Development Headers (v1.1 26 Dec 1985)

      A letter from David Street (Manager of Technical Support and Software Development) to the Developers.

      I have to read the cross dev manual to see on which systems the 5.25″ disks are made to run, but it’s possibly for sun…

      The 5.25″ disks were used on MS-DOS. Developers such as “Electronic Arts” would use IBM-PCs as cheaper alternatives to Sun workstations. For example, “Deluxe Paint” was created using the MS-DOS cross-compiler using “Lattice ‘C’”.

      Reply
  4. Pingback: how to find and delete history stored on computer | Digg hot tags

  5. Michael Steil

    @Harry: Can we be sure it is RCS, or is it just something that uses RCS-like version strings? Hm, I guess it’s probably RCS. :-)

    Thanks for your links. But my real question is: What is the rule for bumping the major or minor version numbers? Is it connected to RCS revisions?

    Reply
  6. RenĂŠ

    @Michael

    The minor number is bumped for every compile run and reset to 1 with every major number bump.
    The major number is used for the OpenLibrary function, which opens a library only if the library’s major number is equal or greater than the required number. Therefore a major number should be increased if a library contains new functions or heavy bug fixes making the old library unusable for a program requiring the new one.

    It’s also noteworthy that AmigaOS in the Commodore days were never self hosting. It’s part of the Amiga-Hyperion lawsuit documents that Olaf Barthel cleaned up the 3.1 sources to compile on modern compilers for the 4.0 project (and Haage & Partner did this for their 3.5/3.9 sources).

    Reply
  7. Sam

    Great reading! Did you see the original Tripos article on the Amiga Forever 2008 CD? That’s also very interesting, it shows a lot of similarities.

    Reply
  8. Captain HIT

    I remember I did the same for my A1000 kickstart disk 1.2. I had some utility disk with many small programs inside. One of them scanned the disk and searched for deleted or hidden files. I recovered many files from my 1.2 Kickstart disk. Even there was a tool on the kickstart 1.2 which read the actual kickstart rom and created a new kickstart disk for use. So I tried it on an A500, made a kickstart 1.3 disk for myself and it even worked! I’ve tried the same on an A1200 but loading this kickstart disk only led me to the red screen on my A1000. :))
    Man, this was ages ago when I was a kid and experimenting stuff on the miggy. :)))

    Reply
  9. MiaM

    @Captain HIT:

    Starting with kickstart 2.0, the ROM size is 512kiB. The 1.x series was 256kiB. A utility written when only 1.x existed will probably only write out the upper 256kiB of a 512kiB kickstart. Even if you have the whole 512kiB on disk, A1000 would only load 256kiB anyway.

    Reply
  10. FrĂśhn

    “LDX #$07 STA $D019,X will first read from $D019, discard the result, and then write to $D020. On the C64, this read form $D019 would ACK all pending VIC interrupts, while it is only supposed to write to the border color ($D020).”

    That is wrong. Reading doesn’t clear the VIC2 IRQ flags, I guess you mixed it up with the CIA IRQ flags.

    To clear VIC2 IRQ flags you have to do: LDA $D019 STA $D019, or alternatively a RMW instruction like DEC $D019 which reads the register value, writes back the value and then writes the modified value.

    And while we are at things like that: You can clear CIA IRQ flags by executing an RTI in the serial shift register ($DC0C). The CPU will also read the value after the RTI ($DC0D) even though it doesn’t need to, and that clears the IRQ flag. 1 cycle saved (JMP $DC0C RTI vs BIT $DC0D RTI).

    Reply
  11. Michael Steil

    @FrĂśhn: You commented on the wrong article. ;-)
    You are correct, I confused $D019 with $DC0D/$DD0D – the presentation video (next blog entry) already contained the fix; I had forgotten to update the article. Will do now.
    About the DC0C/RTI trick: Very interesting, I didn’t know!

    Reply
  12. Pingback: Tripos, the Roots of AmigaDOS « pagetable.com

  13. Paul

    What is the availability and cost of a bootable kickstart diskette for an
    Amiga 1000 rescued from a trash compactor? Using the RCA video port,
    the display shows an ‘insert kickstart diskette’ logo onscreen, no version
    given.
    I’m not even sure the drive works properly; I do have a few game disks,
    but with every one of these, the same kickstart logo shows up after the
    initial disk spin up. thx for info, -ph

    Reply
  14. Robert

    Can any one point me into the right direction for more information on the v1.0/1.1 Developer Kit that’s listed above.

    Reply
  15. Joe Cassara

    Dave Needle confirmed in TechMedia/AmigaWorld’s “History of the Amiga” VHS that, once they were hired by Commodore, SUN workstations were used for Kickstart and Workbench development. Perhaps you can tell, from the photos, what systems were used previously.

    Reply
  16. Luuana

    Too often in our lives experiments are put on real sytmses, whether the country’s economy, a separate organization or system management of a complex intersection. The person accepting the decision, hopes thus for the insight, intuition and good luck. To a bowl of all it in anything good does not result. Decision-maker, is hoping with its insight, intuition and luck. Most often it is any good does not. ” Wanted as better, and it has turned out as always ” the usual characteristic of such decisions. ” We wanted the best, but it turned out as always ” This is the usual characteristics of such solutions.Low efficiency of the administrative decisions made on the basis of intuition, speaks that, that causes and effects in complex(difficult) sytmses are carried in time and space, therefore it is difficult for person to predict, what consequences will be caused with this or that decision. The low efficiency of management decisions made based on intuition, because the cause and effect in complex sytmses are separated in time and space, so the man is hard to predict what impact will a decision. When for a rating of accepted decisions experiment with real sytmses is impossible or expensive, modelling is used. In cases where the assessment for decision-making experiment with real sytmses is impossible or too expensive, using simulation.Imitating modelling is a development of computer models and production of experiments on them. The purpose of modelling finally is acceptance adequate (i.e. proved, expedient and sold) administrative decisions. Simulation is the development of computer models and the experiments on them. The purpose of modeling is ultimately the adoption of adequate (ie sound, feasible and implementable) management decisions. Computer modelling becomes today an obligatory stage in acceptance of critical decisions in all spheres of activity of the person in connection with complication of sytmses within the framework of which the person should operate and which it(he) should operate. Computer simulation is now an obligatory stage in making responsible decisions in all areas of human activity in relation to the complexity of sytmses in which a man must act, and that it must manage. The knowledge of concepts, principles and opportunities of imitating modelling, skill to build and use model are necessary requirements to a polic

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>