Format fix 2004/gavin/README.md
Also renamed gavin_install.txt to gavin.md and updated formatting. chmod +x prim (even though it won't work in some modern platforms - at least if it wasn't corrupted at some point it might in some; it's a 32-bit ELF LSB).
This commit is contained in:
Cody Boone Ferguson committed
1 parent
2d56d6128a
commit
b25b8d1acd
5 files changed
+94
-66
No files matched your search
@@ -3,3 +3,4 @@ gavin
|
||||
kernel
|
||||
sh
|
||||
vi
|
||||
gavin.o
|
||||
+49
-50
@@ -1,10 +1,7 @@
|
||||
# Best of Show
|
||||
|
||||
Gavin Barraclough
|
||||
Flat 20, 83 Newton Street,
|
||||
Manchester,
|
||||
M1 1EP,
|
||||
U.K.
|
||||
Gavin Barraclough
|
||||
UK
|
||||
|
||||
|
||||
## To build:
|
||||
@@ -27,8 +24,8 @@ To enjoy the results (on a Linux/x86 machine):
|
||||
su
|
||||
```
|
||||
|
||||
Make a floppy with an ext2 filesystem (mke2fs /dev/fd0), mount it under /mnt/floppy.
|
||||
Then:
|
||||
Make a floppy with an ext2 filesystem (`mke2fs /dev/fd0` replacing `fd0` with
|
||||
whatever the floppy device is!), mount it under `/mnt/floppy`. Then:
|
||||
|
||||
|
||||
```sh
|
||||
@@ -37,7 +34,7 @@ cp kernel fs.tar lilo.conf boot.b /mnt/floppy
|
||||
|
||||
NOTE: If the version of your lilo is not 21.4, use the appropriate boot.b file.
|
||||
|
||||
NOTE: If your floppy drive is not /dev/fd0, edit lilo.conf appropriately.
|
||||
NOTE: If your floppy drive is not `/dev/fd0`, edit lilo.conf appropriately.
|
||||
|
||||
```sh
|
||||
lilo -C /mnt/floppy/lilo.conf
|
||||
@@ -67,33 +64,37 @@ Press and hold any key.
|
||||
|
||||
## Judges' remarks:
|
||||
|
||||
Over the years, we've seen a program that dumps core
|
||||
if executed on a "wrong" architecture immediately (1984/mullender),
|
||||
or after a while (2001/bellard). This entry will happily compile and
|
||||
execute on any architecture - the trick is that the result, to be useful,
|
||||
must be produced (and can only be enjoyed) on a particular architecture.
|
||||
We have not decided yet whether to disallow this for future contests.
|
||||
Over the years, we've seen a program that dumps core if executed on a "wrong"
|
||||
architecture immediately ([1984/mullender](/1984/mullender/mullender.c)), or
|
||||
after a while ([2001/bellard](/2001/bellard/bellard.c)). This entry will happily
|
||||
compile and execute on most any architecture - the trick is that the result, to
|
||||
be useful, must be produced (and can only be enjoyed) on a particular
|
||||
architecture. We have not decided yet whether to disallow this for future
|
||||
contests.
|
||||
|
||||
If you do not want to mess with a floppy and you use GRUB, see below
|
||||
in the author's notes.
|
||||
You can put additional text files in fs.tar for browsing with vi.
|
||||
If you do not want to bother rebooting your computer at all,
|
||||
see http://bellard.org/ for QEMU (Fabrice Bellard is an IOCCC 2001 winner),
|
||||
but your experience will be limited (replace -DK=0 with -DK=1 in the Makefile,
|
||||
and you will have to move the mouse to trigger the initial screen update).
|
||||
|
||||
You can put additional text files in `fs.tar` for browsing with vi. If you do
|
||||
not want to bother rebooting your computer at all, see <http://bellard.org> for
|
||||
QEMU ([Fabrice Bellard](/winners.html#Fabrice_Bellard) is an IOCCC 2001 winner),
|
||||
but your experience will be limited (replace `-DK=0` with `-DK=1` in the
|
||||
[Makefile](Makefile), and you will have to move the mouse to trigger the initial
|
||||
screen update).
|
||||
|
||||
The judges were able to write a few more programs to run on this OS
|
||||
What are the limitations for such programs?
|
||||
|
||||
What you can do and what you cannot do in such programs?
|
||||
|
||||
The program called "prim", written by the judges,
|
||||
computes and prints prime numbers.
|
||||
The program called `prim`, written by the judges, computes and prints prime
|
||||
numbers.
|
||||
|
||||
## Author's remarks:
|
||||
|
||||
This is a 32-bit multitasking operating system for x86 computers,
|
||||
with GUI and filesystem, support for loading and executing user
|
||||
applications in elf binary format, with ps2 mouse and keyboard drivers,
|
||||
applications in elf binary format, with PS/2 mouse and keyboard drivers,
|
||||
and vesa graphics. And a command shell. And an application -
|
||||
a simple text-file viewer.
|
||||
|
||||
@@ -107,16 +108,16 @@ which is partially defined by the OS, and partially for
|
||||
the application's own use.
|
||||
|
||||
The program compiles into a tool to build a kernel image,
|
||||
so having built the program, the makefile will run it,
|
||||
piping the output into a file called 'kernel'.
|
||||
The makefile will then proceed to build a root filesystem image.
|
||||
so having built the program, the [Makefile](Makefile) will run it,
|
||||
piping the output into a file called `kernel`.
|
||||
The Makefile will then proceed to build a root filesystem image.
|
||||
This involves rebuilding the program with different compiler flags,
|
||||
then building a tar file containing the resulting programs
|
||||
(the filesystem format supported by the OS is the tar-file format).
|
||||
|
||||
For further usage information see 'gavin_install.txt'.
|
||||
For further usage information see [gavin.md](gavin.md).
|
||||
|
||||
The filenames 'vi' and 'sh' are significant, and should not be changed.
|
||||
The filenames `vi` and `sh` are significant, and should not be changed.
|
||||
|
||||
### Known 'features'
|
||||
|
||||
@@ -127,40 +128,38 @@ it will reappear on the right, and vice-versa.
|
||||
If it goes off the top or bottom, it will go and corrupt some memory.
|
||||
|
||||
The file system is kinda optimistic about matching names, so,
|
||||
for example if you type the command 'shell' into a command-line
|
||||
it will execute the program 'sh' - close enough a match for it.
|
||||
for example if you type the command `shell` into a command-line
|
||||
it will execute the program `sh` - close enough a match for it.
|
||||
|
||||
The elf binaries are not loaded at the correct address,
|
||||
and their entry point must be the start address of the text segment.
|
||||
The ELF binaries are not loaded at the correct address, and their entry point
|
||||
must be the start address of the text segment.
|
||||
|
||||
The keyboard driver can cope with the basic alpha-numeric keys,
|
||||
but gets confused by fancy things like 'shift' or 'backspace'.
|
||||
but gets confused by fancy things like `shift` or `backspace`.
|
||||
|
||||
In the text-file viewer, 'vi', the up/down and pgup/pgdn keys
|
||||
In the text-file viewer, `vi`, the up/down and PgUp/PgDn keys
|
||||
scroll up or down by one line. There is nothing to stop you
|
||||
[from] scrolling above the top of the file, and pressing any
|
||||
other keys may have an undefined effect.
|
||||
from scrolling above the top of the file, and pressing any
|
||||
other keys might have an undefined effect.
|
||||
|
||||
The x86 is bootstrapped into 32bit mode in 6 instructions,
|
||||
with 4 more to set up data/stack segments and a stack-pointer
|
||||
to allow C code to be run. On top of this there are also about
|
||||
a dozen instructions to switch the video card into graphics mode.
|
||||
All in all, a relatively tiny number of instructions next to
|
||||
the size of the C program. Also, the string is mostly composed
|
||||
of data - a Linux-esque kernel header for the bootloader,
|
||||
protected mode descriptor tables, keyboard maps, etc.
|
||||
(I should also mention that it contains mini functions
|
||||
to perform an x86 'in' and 'out' instruction - to allow
|
||||
the keyboard & mouse to be driven from C code).
|
||||
The x86 is bootstrapped into 32bit mode in 6 instructions, with 4 more to set up
|
||||
data/stack segments and a stack-pointer to allow C code to be run. On top of
|
||||
this there are also about a dozen instructions to switch the video card into
|
||||
graphics mode. All in all, a relatively tiny number of instructions next to the
|
||||
size of the C program. Also, the string is mostly composed of data - a
|
||||
Linux-esque kernel header for the bootloader, protected mode descriptor tables,
|
||||
keyboard maps, etc. (I should also mention that it contains mini functions to
|
||||
perform an x86 `in` and `out` instruction - to allow the keyboard & mouse to be
|
||||
driven from C code).
|
||||
|
||||
Porting to another architecture should be relatively easy* -
|
||||
Porting to another architecture should be relatively easy\* -
|
||||
the string simply needs be replaced with one containing
|
||||
data & code suitable for the new target platform.
|
||||
Accesses to data in the string are made relative to the define 'V',
|
||||
so these may need updating as appropriate (0x90200 is the address
|
||||
Accesses to data in the string are made relative to the define `V`,
|
||||
so these may need updating as appropriate (`0x90200` is the address
|
||||
at which a Linux bootloader loads an x86 kernel image).
|
||||
|
||||
* ;-)
|
||||
\* ;-)
|
||||
|
||||
## Copyright and CC BY-SA 4.0 License:
|
||||
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
# Usage
|
||||
|
||||
1. First, build the kernel and filesystem (just `make`). In short, you need to
|
||||
build this on an x86 Linux machine. If you wish to try to compile on an OS
|
||||
other than Linux you may need modify the [Makefile](Makefile) to compile `sh`
|
||||
using a cross-compiler that produces ELF binaries - i.e. a cross-compiler
|
||||
targeting x86 Linux. In short, you need to build this on an x86 Linux machine.
|
||||
|
||||
2) Next, find a suitable machine to run the OS on. It should be perfectly safe,
|
||||
and since it does not directly attempt to access any hard disk drives (only a
|
||||
ramdisk loaded by the bootloader) it should do no damage to your existing setup,
|
||||
BUT I ACCEPT NO LIABILITY FOR ANY DAMAGE DONE BY THIS PROGRAM. Run it at your
|
||||
own risk. The OS has been tested on half a dozen machines or so, and worked on
|
||||
all but one. The failure came in the form of the machine rebooting itself
|
||||
midway through loading the OS, with no nasty side-effects.
|
||||
|
||||
Hardware requirements - i386 or better processor, but the GUI is
|
||||
surprisingly power-hungry, so I would recommend a fast P3 or P4 processor
|
||||
(has been tested on P3/P4/Athlon machines). Minimum RAM is something like
|
||||
32MB. PS/2 mouse & keyboard required - no USB I'm afraid, and the keyboard
|
||||
map is for a UK keyboard. Uses Vesa VBE 3.0, so should work on any modern
|
||||
graphics card (has been tested on NVIDIA, Matrox, and SiS cards).
|
||||
|
||||
3. Now you need to setup a bootloader to load the OS. If you have a system
|
||||
using a lilo bootloader you can simply add the OS to your boot menu. Just add
|
||||
appropriate `image=` and `initrd=` lines to your `/etc/lilo.conf`, pointing at
|
||||
`kernel` and `fs.tar` respectively (as built by make earlier), then run `lilo`.
|
||||
If you do not wish modify your lilo setup, one easy option is to get yourself a
|
||||
grub boot disk image, and follow the instructions for grub below - Debian users
|
||||
can simply run`apt-get install grub-disk` to get themselves a grub boot disk.
|
||||
|
||||
If you run grub, then at the boot menu simply hit `c` to get a console, then
|
||||
type `kernel=(hd0,0)/<PATH>/kernel` (substituting appropriate hard
|
||||
drive/partition numbers & path, or using `(fd0)` to load a kernel on the
|
||||
floppy), then `initrd=(hd0,0)/<PATH>/fs.tar`, and finally `boot`.
|
||||
|
||||
4. Assuming the OS has booted, what can you do now? Well, start by trying `sh`,
|
||||
to open another shell. Then, try `vi gavin.c` to open up the OS source in a
|
||||
text file viewer (up/down or PgUp/PgDn to scroll). Note that the provided
|
||||
applications, `sh` and `vi` both have windows of the same size, and that open in
|
||||
the top left corner of the screen, so you may need drag the windows around a bit
|
||||
to tell them apart.
|
||||
|
||||
5. To shut down - just hit the power button. :-)
|
||||
@@ -1,16 +0,0 @@
|
||||
1) First, build the kernel and filesystem (just 'make'). In short, you need to build this on an x86 Linux machine. If you wish to try to compile on an OS other than Linux you may need modify the makefile to compile 'sh' using a cross-compiler that produces elf binaries - i.e. a cross-compiler targeting x86 Linux. In short, you need to build this on an x86 Linux machine.
|
||||
|
||||
2) Next, find a suitable machine to run the OS on. It should be perfectly safe, and since it does not directly attempt to access any hard disk drives (only a ramdisk loaded by the bootloader) it should do no damage to your existing setup, BUT I ACCEPT NO LIABILITY FOR ANY DAMAGE DONE BY THIS PROGRAM. Run it at your own risk. The OS has been tested on half a dozen machines or so, and worked on all but one. The failure came in the form of the machine rebooting itself midway through loading the OS, with no nasty side-effects.
|
||||
|
||||
Hardware requirements - i386 or better processor, but the GUI is surprisingly power-hungry, so I would recommend a fast p3 or p4 processor (has been tested on p3/p4/athlon machines). Minimum RAM is something like 32MB. PS2 mouse & keyboard required - no USB I'm afraid, and the keyboard map is for a UK keyboard. Uses Vesa VBE 3.0, so should work on any modern graphics card (has been tested on Nvidia, Matrox, and SiS cards).
|
||||
|
||||
3) Now you need to setup a bootloader to load the OS. If you have a system using a lilo bootloader you can simply add the OS to your boot menu. Just add appropriate "image=" and "initrd=" lines to your /etc/lilo.conf, pointing at 'kernel' and 'fs.tar' respectively (as built by make earlier), then run lilo. If you do not wish modify your lilo setup, one easy option is to get yourself a grub bootdisk image, and follow the instructions for grub below - debian users can simple "apt-get install grub-disk" to get themselves a grub bootdisk.
|
||||
|
||||
If you run grub, then at the boot menu simply hit 'c' to get a console, then type "kernel=(hd0,0)/<PATH>/kernel" (substituting appropriate harddrive/partition numbers & path, or using "(fd0)" to load a kernel on the floppy), then "initrd=(hd0,0)/<PATH>/fs.tar", and finally "boot".
|
||||
|
||||
4) Assuming the OS has booted, what can you do now? Well, start by trying "sh", to open another shell. Then, try "vi prog.c" (although this file may have been re-named...), to open up the OS source in a text file viewer (up/down or pgup/pgdown to scroll). [Note that the provided applications, 'sh' and 'vi' both have windows of the same size, and that open in the top left corner of the screen, so you may need drag the windows around a bit to tell them apart.]
|
||||
|
||||
5) To shut down - just hit the power button. :-)
|
||||
|
||||
|
||||
|
||||
Regular → Executable
File mode changed.
Reference in new issue
Block a user