Archive for the ‘Technology’ Category

The FAT File System and PrePay Credit Cards

Monday, January 21st, 2008

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…

OS Development: Video Memory and putchar…

Tuesday, January 15th, 2008

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…

Sunday, January 13th, 2008

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.

equery - a tool I didn’t know about…

Sunday, December 23rd, 2007

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)

Gentoo ‘emerge –deep –newuse –update world’ issues…

Saturday, December 22nd, 2007

Many people tell me that they have issues when running a emerge world on Gentoo to keep their system up to date. I have long argued that the problems are simply because they don’t run the updates regularly enough, and if they were to run updates every week they wouldn’t have these problems.

Unfortunately I have fallen foul of my own advice and haven’t run updates in a couple of weeks. This is now resulting in the following error:

 * ERROR: gnome-extra/evolution-data-server-1.12.2-r1 failed.
 * Call stack:
 *               ebuild.sh, line   46:  Called src_compile
 *             environment, line 3397:  Called gnome2_src_compile
 *             environment, line 2573:  Called die
 * The specific snippet of code:
 *       emake || diefunc “$FUNCNAME” “$LINENO” “$?” “compile failure”
 *  The die message:
 *   compile failure
 *
 * If you need support, post the topmost build error, and the call stack if
 * relevant.
 * A complete build log is located at ‘/var/tmp/portage/gnome-extra/evolution
 * -data-server-1.12.2-r1/temp/build.log’.
 * The ebuild environment file is located at ‘/var/tmp/portage/gnome-extra/
 * evolution-data-server-1.12.2-r1/temp/environment’.

When you hit errors like this there are a number of things that should and can easily be done which 99% of the time will fix the problem. The first is to actually check the logs! The number of times I read the Gentoo forums and people don’t post the true topmost build error is unbelievable. Read the error and read the logs:

 michaelfclarke@mikes-computer ~ $
 cat /var/tmp/portage/gnome-extra/evolution-data-server-1.12.2-r1/temp/build.log \
 | grep -i error
 checking for library containing strerror… none required
  mode, hide preprocessor errors, passes: stubs skels common headers
  mode, hide preprocessor errors, passes: stubs skels common headers
 /bin/sh ../../libtool –tag=CC   –mode=compile x86_64-pc-linux-gnu-gcc
 -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../src -I../../src -I../../src/libical
 -I../../src/libical -I. -DPACKAGE_DATA_DIR=\”"/usr/share/evolution-data-server-1.12″\”
 -I/usr/include/db4.5  -O2 -pipe -MT icalerror.lo -MD -MP -MF .deps/icalerror.Tpo -c
 -o icalerror.lo icalerror.c
 x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../src -I../../src
 -I../../src/libical -I../../src/libical -I.
 -DPACKAGE_DATA_DIR=\”/usr/share/evolution-data-server-1.12\” -I/usr/include/db4.5
 -O2 -pipe -MT icalerror.lo -MD -MP -MF .deps/icalerror.Tpo -c icalerror.c  -fPIC -DPIC
 -o .libs/icalerror.o
 mv -f .deps/icalerror.Tpo .deps/icalerror.Plo
 /bin/sh ../../libtool –tag=CC   –mode=link x86_64-pc-linux-gnu-gcc  -O2 -pipe
 -version-info 0:0:0 -o libical-evolution.la   icalderivedparameter.lo
 icalderivedproperty.lo icalrestriction.lo icalderivedvalue.lo icalarray.lo icalattach.lo
 icalcomponent.lo icalenums.lo icalerror.lo icalmemory.lo icalmime.lo icalparameter.lo
 icalparser.lo icalproperty.lo icalrecur.lo icaltime.lo icaltz-util.lo icaltimezone.lo
 icalduration.lo icalperiod.lo icaltypes.lo icalvalue.lo pvl.lo sspm.lo vsnprintf.lo
 icallangbind.lo caldate.lo -lpthread
 x86_64-pc-linux-gnu-ar cru .libs/libical-evolution.a .libs/icalderivedparameter.o
 .libs/icalderivedproperty.o .libs/icalrestriction.o .libs/icalderivedvalue.o
 .libs/icalarray.o .libs/icalattach.o .libs/icalcomponent.o .libs/icalenums.o
 .libs/icalerror.o .libs/icalmemory.o .libs/icalmime.o .libs/icalparameter.o
 .libs/icalparser.o .libs/icalproperty.o .libs/icalrecur.o .libs/icaltime.o
 .libs/icaltz-util.o .libs/icaltimezone.o .libs/icalduration.o .libs/icalperiod.o
 .libs/icaltypes.o .libs/icalvalue.o .libs/pvl.o .libs/sspm.o .libs/vsnprintf.o
 .libs/icallangbind.o .libs/caldate.o
 x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../src -I../src
 -I../src/libical -I../src/libical -I/usr/include/db4.5  -O2 -pipe -MT errors.o
 -MD -MP -MF .deps/errors.Tpo -c -o errors.o errors.c
 mv -f .deps/errors.Tpo .deps/errors.Po
 /bin/sh ../libtool –tag=CC   –mode=link x86_64-pc-linux-gnu-gcc  -O2 -pipe
 -o doesnothing access_components.o
 access_properties_and_parameters.o errors.o main.o parse_text.o
 ../src/libical/libical-evolution.la ../src/libicalss/libicalss-evolution.la
 ../src/libicalvcal/libicalvcal-evolution.la -lpthread
 x86_64-pc-linux-gnu-gcc -O2 -pipe -o doesnothing access_components.o
 access_properties_and_parameters.o errors.o
 main.o parse_text.o  ../src/libical/.libs/libical-evolution.a
 ../src/libicalss/.libs/libicalss-evolution.a
 ../src/libicalvcal/.libs/libicalvcal-evolution.a -lpthread
  mode, hide preprocessor errors, passes: stubs skels common headers
  mode, hide preprocessor errors, passes: stubs skels common headers
 x86_64-pc-linux-gnu-gcc -O2 -pipe -Wall -Wmissing-prototypes -Wno-sign-compare
 -o .libs/create-account create-account.o
 -pthread -Wl,-R/usr/lib64/nspr  ../../libedataserver/.libs/libedataserver-1.2.so
 -L/usr/lib64/nspr -L/usr/lib64/lib
 /usr/lib64/libdb-4.5.so /usr/lib64/libsoup-2.2.so -L/usr/lib64 -lnsl
 /usr/lib64/libgnutls.so /usr/lib64/libtasn1.so
 /usr/lib64/libgcrypt.so /usr/lib64/libgpg-error.so /usr/lib64/libxml2.so -lz
 -lm /usr/lib64/libbonobo-2.so
 /usr/lib64/libbonobo-activation.so /usr/lib64/libORBitCosNaming-2.so
 /usr/lib64/libgconf-2.so /usr/lib64/libORBit-2.so /usr/lib64/libgmodule-2.0.so
 /usr/lib64/libgthread-2.0.so -lrt /usr/lib64/libgobject-2.0.so /usr/lib64/libglib-2.0.so
 -lplds4 -lplc4 -lnspr4 -ldl -lpthread
 x86_64-pc-linux-gnu-gcc -O2 -pipe -Wall -Wmissing-prototypes -Wno-sign-compare
 -o .libs/soap-test soap-test.o -pthread -Wl,-R/usr/lib64/nspr  -L/usr/lib64
 ./.libs/libegroupwise-1.2.so -L/usr/lib64/nspr /usr/lib64/libsoup-2.2.so -lnsl
 /usr/lib64/libgnutls.so /usr/lib64/libtasn1.so /usr/lib64/libgcrypt.so
 /usr/lib64/libgpg-error.so /usr/lib64/libxml2.so -lz -lm /usr/lib64/libbonobo-2.so
 /usr/lib64/libbonobo-activation.so /usr/lib64/libORBitCosNaming-2.so
 /usr/lib64/libgconf-2.so /usr/lib64/libORBit-2.so /usr/lib64/libgmodule-2.0.so
 /usr/lib64/libgthread-2.0.so -lrt /usr/lib64/libgobject-2.0.so /usr/lib64/libglib-2.0.so
 -lplds4 -lplc4 -lnspr4 -ldl -lpthread
 make[4]: *** [create-account] Error 1
 make[4]: *** [soap-test] Error 1
 make[3]: *** [all] Error 2
 make[2]: *** [all-recursive] Error 1
 make[1]: *** [all-recursive] Error 1
 make: *** [all] Error 2
 * ERROR: gnome-extra/evolution-data-server-1.12.2-r1 failed.
 * If you need support, post the topmost build error, and the call stack if relevant.
 michaelfclarke@mikes-computer ~ $

Reading the above nothing stood out that much so I decided to do a grep for warning instead…

 michaelfclarke@mikes-computer ~ $
 cat /var/tmp/portage/gnome-extra/evolution-data-server-1.12.2-r1/temp/build.log \
 |grep -i warning
 configure: WARNING: krb5 support disabled
 checking what warning flags to pass to the C compiler… -Wall -W missing-prototypes
 e-data-server-module.c:86: warning: dereferencing type-punned pointer will break strict-aliasing rules
 e-data-server-module.c:89: warning: dereferencing type-punned pointer will break strict-aliasing rules
 e-data-server-module.c:92: warning: dereferencing type-punned pointer will break strict-aliasing rules
 broken-date-parser.c:125: warning: pointer targets in assignment differ in signedness
 …
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libgnutls.so.13,
 needed by /usr/lib64/libsoup-2.2.so, not found (try using -rpath or -rpath-link)

Ah! The last line of the output seemed to be the problem. My first idea was to simply create a symlink and see what happens:

  ln -s /usr/lib64/libgnutls.so.26 /usr/lib64/libgnutls.so.13

This failed to work. Instead I then tried to re-emerge libsoup. This worked and my original emerge then proceeded with no errors :)

>>> /usr/share/doc/evolution-data-server-1.12.2-r1/TODO.bz2
 * Installing GNOME 2 GConf schemas
 * Reloading GConf schemas …                                          [ ok ]
 * Updating desktop mime database …
 * Updating shared mime info database …
 * Updating icons cache …                                             [ ok ]
>>> Regenerating /etc/ld.so.cache…
>>> gnome-extra/evolution-data-server-1.12.2-r1 merged.

>>> No packages selected for removal by clean

The upshot of all this is - keep your system up to date and remember to read the log files.