Me, Operating Systems, Technology, Sun Microsystems and Stuff!

The FAT File System and PrePay Credit Cards

January 21st, 2008 Michael Clarke

I’m sure that if you’ve read the title for this entry you’re most confused as to what the FAT file system has to do with PrePay Credit Cards. I have to admit that if I were in your position I would also be confused, indeed I have now confused myself in an attempt to see if there are any similarities, the answer to which I have concluded to be that there are none, other than perhaps they are both mentioned in this entry and have already taken up far too much space - having successfully distracted me totally from the originally point of this blog entry.  Good Oh!

I suppose I ought to explain. Last week I decided, in my infinite wisdom, that it might be a good idea to get one of these ‘PrePay Credit Card things’ that seem to be taking off. The idea is very simple. You buy a card (Visa, MasterCard or Maestro) and top it up with money online, via another credit/debit card, in the post office, or using top-up points in shops. Having done this you go out and spend all your money in places where normal debit cards are not accepted - one such example being hotel and flight reservations etc. As far as everyone who views and uses the card is concerned you’ve got a bog standard, normal credit card… as far as you’re concerned it’s the best credit card ever as you don’t have to pay anything back!

I think there are a number of focus groups for these cards. Those people with poor credit history who can’t get a credit card. Those people who don’t want a credit card - but need an alternative for paying for hotels, flights, hire cars etc, and teenagers who want a more ‘modern’ way of dealing with their pocket money/paper round wages. Personally I decided that getting one of these cards would be an excellent way to sort out my hotels and stuff in France without having to increase my real credit card limit - and so far I have been most impressed. My only gripe with the card that I got (but this could just be a Virgin Money thing) is that, instead of having embossed numbers it has printed numbers meaning that the card says “ELECTRONIC USE ONLY” on the front in small letters. Basically this means the card can’t be used in one of those old machines where they used to take a carbon copy of your card. Ah well, gone are the good old days I suppose.

Anyway - enough about PrePay cards. I spent this weekend programming some more stuff for MouthOS. Specifically I fixed a few bugs in my floppy disk driver (which now fully supports writing and reading of whole disk sectors) and started to implement my FAT file system driver.

I was truly amazed at how easy it was to start writing a FAT driver. Microsoft have for once (and I thought I would never ever say this) done something right and released a lovely (well, fairly good) document (found here)  which details  everything you could ever want to know about the FAT file system. Whilst FAT may be a bit antiquated nowadays it’s a nice simple file system that people writing Operating Systems can easily and quickly adapt so they don’t have to (initially) think about designing their own file system. Furthermore, because GRUB supports the FAT file system it means that you don’t have to go through all the hassle of partitioning a floppy disk into a FAT and a “MouthFS” partition… for the moment anyway.

Anyway. It’s now getting on a bit and I fear that if I don’t get to bed soon I shall have trouble getting up in the morning. Until my next post I bid you all good bye…

Sun to become the M in LAMP…

January 16th, 2008 Michael Clarke

Sun have today announced that they are buying MySQL AB, the company behind MySQL for $1 billion. This is both good news for Sun and for MySQL - not to mention all those MySQL users (including myself). MySQL will become a much more commercially viable product with Sun’s backing - reaching companies that previously wouldn’t have gone near it whilst at the same time it reaffirms Sun’s position as a leading provider of web technologies.

You can read more about the acquisition of MySQL on Jonathan Schwartz’s Blog and also on MySQLs and Sun’s websites!

OS Development: Video Memory and putchar…

January 15th, 2008 Michael Clarke

Well folks, as promised here is my next exciting installment of the ‘OS Development’ series!

Continuing on from my last post, ‘OS Development: Where to start?’, I’m now going to go over some simple things such as implementing a simple putchar(char c) function which you can then use to implement your printf function. This, apart from my boot-loader, was the first thing I developed in MouthOS. It’s a really good place to start as once you’ve got it sorted you can start printing out debug information such as stack traces, the CPU registers etc.

So, onto the theory! In order to put stuff on the screen you’re going to need to have access to the video memory. On the x86 architecture the video memory is found between 0×000A0000 and 0×000C7FFF. It is split up as follows:

0×000A0000 - 0×000BFFFF: Video RAM Memory.
0×000B0000 - 0×000B7777: Monochrome Video Memory (multiple pages).
0×000B8000 - 0×000BFFFF: Colour Video Memory (multiple pages).
0×000C0000 - 0×000C7FFF: Video ROM Memory.

To begin with the simplest thing to do would be to use the monochrome video memory. However, this is a bit boring as you may want to highlight things in different colours etc. As such the best place to start is to write to the Colour Video Memory.

When writing to the Colour Video Memory you should note that for every character you need two bytes worth of data. The first byte is the character to be displayed and the second is the colour to be used. To start with I just created a header file (video.h) with all my colours and video memory locations defined as below.

 	video.h
	/* Colours are defined as FOREGROUND_BACKGROUND */
	#define BLACK_WHITE             0×0
	#define BLUE_BLACK              0×1
	#define GREEN_BLACK             0×2
	#define CYAN_BLACK              0×3
	#define RED_BLACK               0×4
	#define MAGENTA_BLACK           0×5
	#define BROWN_BLACK             0×6
	#define GRAY_BLACK              0×7
	#define DARK_GRAY_BLACK         0×8
	#define BRIGHT_BLUE_BLACK       0×9
	#define BRIGHT_GREEN_BLACK      0xA
	#define BRIGHT_CYAN_BLACK       0xB
	#define PINK_BLACK              0xC
	#define BRIGHT_MAGENTA_BLACK    0xD
	#define YELLOW_BLACK            0xE
	#define WHITE_BLACK             0xF
	/* Locations for Video Memory. */
	#define VIDEO_MEM_RAM	0x000A0000
	#define VIDEO_MEM_MON	0x000B0000
	#define VIDEO_MEM_COL	0x000B8000
	#define VIDEO_MEM_ROM	0x000C0000
	/* Define the maximum rows and columns available on screen. */
	#define X_MAX	80
	#define Y_MAX	25
	/* Functions in video.c that the rest of the kernel is allowed to use. */
	extern void init_video(void);
	extern void cls(void);
	extern void setcolour(int _colour);
	extern void putchar(const char c);

With that done I started to implement my functions. The first one was the init_video(void) function. The aim of this function was two fold. Firstly it was to gain access to the video memory via a pointer and secondly it was to clear the contents of the video memory (as all the BIOS and/or GRUB loading information is still in video memory). On the whole this is a really simple function…

	video.c
	#include “video.h”

	unsigned char vidmemptr*;
	int colour, crsx, csry;	

	void move_csr(int _x, int _y);

	void init_video(void) {
		vidmemptr = (unsigned char *) VIDEO_MEM_COL;
		colour = WHITE_BLACK;
		cls();
	}

With this completed the next step was to implement the cls(void) function to clear the video memory. This simply involved moving along the entire video memory setting the characters to be equal to ‘ ‘ and the colour to be the currently selected colour (in this case WHITE_BLACK)…

	void cls(void) {
		int i;
		int j = Y_MAX * ( X_MAX * 2 );
		for ( i = 0; i < j; i++ ) {
			vidmemptr[i] = ' ';
			i++;
			vidmemptr[i] = colour;
		}

		move_csr(0, 0);

	}

As can be seen this still won’t compile as the function move_csr(int _x, int _y) still doesn’t exist. This function is used to position the cursor to a specific x, y co-ordinate. It is very simple in my implementation below, simply checking that the given values are not out of bounds of the screen and then setting csrx and csry. However in my full implementation in MouthOS it also sets the blinking cursor and calls another function ’scroll’ to scroll the text up the screen. Unfortunately adding the implementation of these functions to this blog entry would make it twice it’s current size - perhaps for my next entry I’ll go over implementing these extra functions. However for now here is a simple move_csr(int _x, int _y) function.

	void move_csr(int _x, int _y) {
		if ( _x <= X_MAX && _y <= Y_MAX ) {
			csrx = _x;
			csry = _y;
		}
	}

Having implemented move_csr there are two functions left. The first is the setcolour(int colour) function. This is a simple ’setter’ function…

	void setcolour(int _colour) {
		colour = _colour;
	}

Leaving the function you’ve all been waiting for - putchar(const char c)

	void putchar(const char c) {

		int position =  ( csrx * ( X_MAX * 2 ) ) + ( csrx * 2);
		int i;

		if ( c == '\n') {

			move_csr(0, csry + 1);
		} else {
			vidmemptr[position] = c;
			position++;
			vidmemptr[position] - colour;
			move_csr(csrx + 1, csry);
		}

	}

From here there are many places you could branch to. I implemented a scroll() function to scroll the text up as the screen got full. This also required me to implement a memcpy(src, dest, size) function. I also made some modifications to the move_csr(int _x, int _y) function to move the blinking cursor to where the text was appearing and I then went on to write printf(fmt, args) which required the implementation of the va_start, va_arg and va_end macros. As they say the sky is the limit.

MouthOS gains a RSOD as France Approaches…

January 13th, 2008 Michael Clarke

I’ve not had much chance recently to work on MouthOS or to write anything on my blog as I’ve been busy getting prepared for my trip to France at the end of the month. However, I’ve now finally booked my Euro Star tickets (at a very reasonable price of 49.00 return) and my hotel - “Hotel De L’exposition - Tour Eiffel”.

With this done I’ve spent some time this weekend working on MouthOS and I’ve made some excellent progress. I’ve written a new printf function which complies with the ANSI C standard (which also included implementing variable length argument function macros). I’ve also managed to get MouthOS to identify how much RAM a system has - putting me well on the way to finishing my memory manager.

However, the highlight has got to be the new “RSOD” or Red Screen of Death! Since I’ve now got a good printf I was able to start printing out the status of the CPU registers etc, and this has lead to the ability to add a lot of debug information to my panic() function…

MouthOS Red Screen of Death

Don’t worry folks - you shouldn’t see this too often. Also it should be noted that the exception was caused by a deliberate division by zero at the end of main() to test the panic function… I’m not that bad a coder - honestly!

	printf("\n   --> Low Memory:   %iK", _LOW_MEM);
	printf("\n   --> High Memory:  %iK\n", _HIGH_MEM);

	int i = 6 / 0;

Anyway, I think it’s time for an episode of ‘Allo ‘Allo before bed.

Student Interviews

January 4th, 2008 Michael Clarke

Today we had the first face-to-face interview with the new students. The interview is split into three sections. The first is conducted by Paul Humphreys and David Cole. It lasts for about 45 - 60 minutes and focuses on questions relating more to the students past technical experience.

After this one of the current students (this time me) takes the interviewee for a tour of the labs. This lasted about 30 - 40 minutes and is a great opportunity for the student being interviewed to ask questions and get a (if brief) overview of what the job really involves. The student is shown the production cage, the overflow lab and then the main lab.

When the tour is completed the interviewee returns to the office for another chat with Paul and David - this time regarding the Sun Ray technology (as is requested that they research when they are invited for a face-to-face interview) and also a few networking questions etc.

I have to admit that I spent a lot of the time during the tour trying to remember what my interview and tour was like. I was hoping to remember some of the cool things that I really liked so that I could show this guy (who also happened to be called Daivd) the stuff that really made me go ‘wow’. In the end I got the feeling that he really liked the high-end servers - specifically the 25K and the M9000+.

All in all it was quite a different experience being the interviewer as opposed to the interviewee!

Happy New Year!

January 1st, 2008 Michael Clarke

Happy New Year everyone!

To all those people who still haven’t received a text from me - I’ve been trying since 12… unfortunately, as I suspected, the mobile phone network is congested… now had they used products from Sun they would have been able to deal with the load :)

Thus far I have received one Happy New Year text from David Cole. It arrived pretty much spot on 12 - I can only assume that he, being the clever person he is, sent the text a couple of minutes before the rush - cunning! A trick to remember for next year indeed.

I wish everyone a Happy New Year :)

My Crash - Good news at last!

December 28th, 2007 Michael Clarke

As many of you will know, in June 2007 I was unfortunate enough to have a quite bad car crash. We were on our way to Go Karting as a end of exams trip and a guy in a red Fiesta drifted across the road and hit my car head on at a combined speed of about 100MPH. Fortunately everyone was (is now) okay from the accident. This accident in turn caused a smaller shunt further down the road. I promised in my old blog that I’d put up some photos of my car after the incident, however I never did - so I’ve included them now.

My Car Crash My Car Crash My Car Crash

Ever since then there have been legal battles between a whole host of people who all claimed that it wasn’t their fault. At the same time, the police investigation (which had six months allowance to be concluded) was crawling along. At the end of November (26th to be precise) I was informed at last that the guy in the red Fiesta was to be taken to court on the charge of ‘driving without due care and attention’.

This court hearing took place on the 19th December at 9.30am at Aberystwyth Magistrates Court and I’ve finally heard from the Police that he pleaded guilty! This is excellent news as it now means two things:

  • His claim that I was the cause of the accident to his insurance company is invalid (otherwise why would be plead guilty?)
  • My insurance company will finally pay out my excess and give me back my no claims.

Overall a pretty good day.

OS Development: Where to start?

December 27th, 2007 Michael Clarke

As most people who read this blog will know I’m currently developing a small 32Bit Multi-tasking Operating System called ‘MouthOS’. I figured that I’d start sharing my thoughts and ideas of the development with you all so that, should you be a fool like me, you can write your own OS!

The hardest part of writing an Operating System is where to start! Many people will say ’start wherever you like’. Others will give you warnings about trying to develop ‘Graphical User Interfaces’ straight away. Others will suggest that you do a lot of reading of books relating to Operating System design theory. This is all good advice, and whilst I don’t pretend to be an expert, in my opinion there are three even more important things to consider when starting to develop an Operating System:

  1. What do you want your Operating System to achieve? Many will say be realistic here - don’t be thinking graphical user interfaces and to a certain extent they are correct. However, if you do want to have a graphical user interface this will effect your initial development - you will have to think about interrupts etc. Also this will affect your architecture - is your OS for a washing machine or is it for a fully blown desktop computer?
  2. This brings me onto the next thing - do you know the architecture that you’re going to be developing for? This means understanding what the registers do on your chosen CPU, how the CPU deals with interrupts, what extra features the CPU may or may not have, how the CPU starts execution (where does it get its first instruction from?), how much RAM can it address, and also knowing the assembly language for your chosen architecture.
  3. Once you know your architecture this leads to my final question - what language are you going to develop in? Pure assembly, C, Java, Python? If you’re planning on using Java or Python (or any other interpreted language) you’re going to have to go back to the drawing board - it simply won’t work.

Once you’re comfortable with what your OS is going to achieve, what language its going to be written in, and what it will run on you can start with the boot-loader. In x86 the boot-loader takes over from BIOS. In SPARC the boot-loader takes over from OBP etc. Boot-loaders can be as simple or as complex as you like.

In x86 (as MouthOS is coded in) your boot-loader could directly start calling kernel code, or it could setup the environment, for example setting up the GDT (Global Descriptor Table), IDT (Interrupt Descriptor Table), enable the A20 line and entering into 32Bit Protected Mode. This really depends on what you want your OS to do. If it’s just print some text on screen then there is little point with memory management and 32Bit instructions. However, if you’re planning on having graphics, multiple applications, and if you want to be able to address more than 65K of memory then 32Bit (or even 64Bit) is the way to go. There is loads of information available on the Internet relating to boot-loaders. However, if you’re struggling to find it a good place to start is the wiki and forums at OSDev.Org.

Personally I decided, after the second write of MouthOS, that I was going to use GRUB as my boot-loader. Using GRUB provided a nice way to get into my kernel as GRUB deals with all the above mentioned tasks such as enabling the A20 line, setting up the GDT, getting into 32Bit Protected Mode etc - in essence it puts the system into a known state ready for the kernel. However, even if you’re going to use GRUB at some point (and best sooner than later) you need to re-write the GDT, IDT etc. The reason for this is that you don’t know what GRUB has used for these values and so you could have various things such as users applications overwriting your kernel etc.

This is where I’m going to leave it for now. However, in my next few posts relating to OS development I plan to go over some x86 specific questions like how to implement simple putchar, puts, memcpy functions for your C library. I’ll also cover some other things that you, as budding OS developers, should know - such as how paging and virtual memory work, and where to being when writing a scheduler.

A very (slightly late) Merry Christmas…

December 26th, 2007 Michael Clarke

I had planned to write a entry yesterday - however in the excitement of Christmas I’m afraid I hardly touched my computer. As such I want to wish you all a slightly late Merry Christmas :)

I hope everyone had a great day and that Santa brought everything you wanted - and some more! Enjoy the last few days of 2007 and I wish you all a happy and prosperous 2008.

Merry Christmas and a Happy New Year.

equery - a tool I didn’t know about…

December 23rd, 2007 Michael Clarke

As I was browsing the Gentoo forums earlier today I found a tool that I’ve not used before which looks really useful. Quite often I wonder what packages depend on others in the portage tree…. but no longer.

mikes-computer ~ # equery depends graphviz
[ Searching for packages depending on graphviz… ]
app-doc/doxygen-1.5.4 (!nodot? >=media-gfx/graphviz-2.6)
media-gfx/imagemagick-6.3.5.10 (graphviz? >=media-gfx/graphviz-2.6)
media-libs/libdvbpsi-0.1.5 (doc? media-gfx/graphviz)

Other cool things this little tool does include:

Listing all the packages that own a given file… For example, if I run the following on /usr/bin/gvim I get the following results telling me that the package app-editor/gvim-7.1.164 owns the file /usr/bin/gvim.

mikes-computer ~ # equery belongs /usr/bin/gvim
[ Searching for file(s) /usr/bin/gvim in *… ]
app-editors/gvim-7.1.164 (/usr/bin/gvim)

Another example is if I do a equery belongs on /etc/resolv.conf which doesn’t belong to any particular package:

mikes-computer ~ # equery belongs /etc/resolv.conf
[ Searching for file(s) /etc/resolv.conf in *… ]

Another useful feature of this tool is the ability to find out what files a package owns….

mikes-computer ~ # equery files gvim
[ Searching for packages matching gvim… ]
* Contents of app-editors/gvim-7.1.164:
/etc
/etc/vim
/etc/vim/gvimrc
/usr
/usr/bin
/usr/bin/eview -> gvim
/usr/bin/evim -> gvim
/usr/bin/gview -> gvim
/usr/bin/gvim
/usr/bin/gvimdiff -> gvim
/usr/bin/rgview -> gvim
/usr/bin/rgvim -> gvim
/usr/share
/usr/share/applications
/usr/share/applications/gvim.desktop
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/gview.1.bz2 -> vim.1.bz2
/usr/share/man/man1/gvim.1.bz2 -> vim.1.bz2
/usr/share/man/man1/gvimdiff.1.bz2 -> vimdiff.1.bz2
/usr/share/pixmaps
/usr/share/pixmaps/gvim.xpm

I have to admit that I’ve been most impressed with this tool. It can also do a few other things such as listing all the packages with a given use flag:

mikes-computer ~ # equery hasuse mmx
[ Searching for USE flag mmx in all categories among: ]
 * installed packages
[I–] [ ~] net-misc/asterisk-1.2.21.1-r1 (0)
[I–] [ ~] media-sound/mpg123-1.0_rc2 (0)
[I–] [ ~] media-video/ffmpeg-0.4.9_p20070616-r2 (0)
[I–] [ ~] media-video/mplayer-1.0_rc2_p24929 (0)
[I–] [ ~] media-gfx/inkscape-0.45.1-r1 (0)
[I–] [ ~] media-gfx/gimp-2.4.2 (2)
[I–] [  ] media-tv/xawtv-3.95-r1 (0)

Overall this is a really great tool, and if you don’t have it then you can get it by emerging the gentoolkit…. which I found out by:

mikes-computer ~ # which equery
/usr/bin/equery

mikes-computer ~ # equery belongs /usr/bin/equery
[ Searching for file(s) /usr/bin/equery in *… ]
app-portage/gentoolkit-0.2.4_pre8 (/usr/bin/equery)