VGA Leaper for DOS

VGA Leaper is a Frogger clone written for DOS by Lee Chapel in 1992. We got this game on a shareware magazine cover disc in the mid 90’s, and never having played the original Frogger in the arcades we thought it was pretty good. If you’ve played Frogger in the arcades this game will be very familiar.  The basic elements of Frogger are all there:

• The highway with different speed vehicles that you have to cross.
• The logs and turtles flowing up and down the river (or lake) that you use to get to the end zone.
• The female frog you can get for extra points and the other creatures that are obstacles throughout the levels.

As I’ve said I have never really played the arcade version myself, although I have seen footage of others playing. So I can’t make much in the way of a comparison between the two gameplay wise. What I have noticed from watching the footage is that the original Frogger is much faster paced, and the snake may appear on a log as well as the middle (safe) area of the screen. VGA Leaper starts out much slower, and is fairly easy to beat on the early levels. It does quickly get harder however but I suspect not as difficult as the original. This is to be expected really as arcade games were always notorious for being very hard, and ports to other systems usually are easier by quite a margin.

The graphics for this version of Frogger are quite good, and compare well to other clones on the PC and other systems. It doesn’t support any modes other than VGA from what I can see, but the documentation states that there was a CGA version available upon request. There is very little in the way of sound, with it only supporting PC speaker. There is no music which may be a blessing and there are also very few sounds, which all sound ok for what they are.

Playing this as a kid before I knew anything about the original, I thought this little game was pretty alright. It wasn’t something we ever spent a lot of time playing, but it was a nice quick distraction that could be finished pretty quickly. The graphics are nice, and the gameplay is reasonably challenging without being impossible, so I’d encourage anyone looking for a Frogger clone for PC to try this.

Title Screen

The Second Level

The First Level

Information Screen

Finished the First Level

Lemmings for DOS

Lemmings was created by DMA design and published by Psygnosis in 1991. I first saw Lemmings on my cousins Tandy 1000 computer when visiting his family during christmas. We all had a quick go at it, but only really just scratched the surface as we didn’t have time to even complete the easy levels. Lemmings was one of the few games that supported almost every platform around including computers like the Amiga and Archimedes. In the PC version there is support for XT style machines with CGA, AT style machine with EGA or Tandy graphics and newer PCs with VGA graphics.  Sound wise I’ve only seen support for Tandy, Adlib and PC speaker. There was also a version made that supports windows (either win9x or win3.1).

We got Lemmings on our old 386sx computer originally, and everyone played it a lot trying to solve the harder puzzles. It had some of the best VGA graphics we had seen on our computer with impressively smooth animations and well designed sprites. It was also one of the few games I’ve seen that used a 640x350x256 VGA mode, which was used primarily to intermission screens and the main title screen. The other graphics modes are similarly impressive for each of the different capabilities of the machines.  We used PC speaker for sound which was unfortunate not because the PC speaker sound was bad, but because we missed out on some of the best Adlib music you can find.

The gameplay in Lemmings is fairly simple in concept, but can have some very difficult puzzles. You have to guide your group of Lemmings through levels filled with various hazards such as bottomless pits, crushers, and fire/steam throwers. Fortunately the Lemmings have various abilities you can use to avoid the hazards or neutralize them. The early puzzles are fairly easy and are basically there to teach you how to use the various abilities of the Lemmings. The difficulty ramps fairly gently but there are so many levels with so much variety that there is always something to make you think. The later levels also get very hard, and no-one in my family has been able to complete all of the levels. I’ve found that the gameplay is still good to this day, and since I haven’t played it for quite a while, I still find it to be quite challenging.

EGA Graphics in game

Title Screen

VGA Graphics in game

CGA Graphics in game

Python Script: Clean up out of date packages in pkgsrc.

Having updated some packages on my NetBSD system, I had some duplicate copies of the built binaries in my pkgsrc tree. This of course is pretty much just a waste of disk space so I went about writing a script to clean up the extra package tarballs.

I made a script that would examine the list of files and find ones with the same package name (with the version info chopped off). It would then compare the files by date and the delete the older files. The main problem with this script is packages like apache and samba. Those packages have multiple packages within pkgsrc that are simply different versions of the same software. Unfortunately these different versions share the same package name as far as the package management system is concerned, which means this script could delete a binary package file you wanted to keep. For example apache-1.3x versus apache-2.x.x.

Fortunately I wouldn’t imagine many people installing more than one copy of packages like samba and apache, but it is something to be aware of as it does affect some other packages as well. So far it hasn’t been a problem for me. I’ve noted some packages like python are fine as the version has become a part of the package name (eg. python27 for the 2.7.x series of python). So it would be a good idea to have a quick look in your package directory.

After removing the extra tarball files, the script goes and checks all the symlinks in the packages tree to make sure they are still good, and removes the link if it is broken.

Note you will need the common.py file in addition to this one (clean-packages.py) for the common utility functions. This was in my last post containing the build script.

Python Scripts for building in pkgsrc packages in NetBSD

I’ve been a little busy of late, so sorry this post is coming in rather late.

As you may have already read, I have been learning python for work. So I decided to use it to try to solve some problems I had been having on my SparcStation.

There aren’t any binary packages for my old sparc available so I often take it upon myself to build packages from source using the pkgsrc system. There are a few problems in doing this: Firstly the old machine doesn’t have a lot of disk space, so I do not wish to keep the build dependencies installed all the time (bison, m4, digest etc…). Secondly the machine is quite slow, so when building a package I do not wish to rebuild ones that are already built. Normally I would have to perform the installation and removal manually as the pkgsrc system doesn’t seem to detect previously built/downloaded packages. So I decided to make a python script that would automate the process, so I could ask the machine to build and install something, and not have to interact with it unless there was a problem or it finished.

In starting the script I realized I could also automate a few other pkgsrc functions such as updating all the installed packages. Because there was a lot of commonality between what I was writing I made a common module that all the scripts could use to perform some basic functions that I would need on a regular basis.

Here is the common.py code…

Using the inline assembler in Pascal

I’ve been asked recently how you go about adding assembly instructions in old pascal program using the compilers inline facility. Assembly is important if you want to write your own hardware handling routines, or need to do something as fast as possible. It can be difficult writing assembly code, but by and large it is actually a fairly simple language. With the old Borland Turbo Pascal 6 and 7 you did this using one of a few different structures.

You could use the asm directive to write assembly in a code block of its own, and this is my preferred way. The only issue is you are limited to using 286 instructions as these are the only ones that turbo pascal ever supported. So if you required 386 instructions or higher you were out of luck!

Here is some sample code I have used. It could be more efficient, but as a sample it suffices.

procedure copymem16(srcseg,srcofs,desseg,desofs,size:word);
var c,of1,of2:word;
begin
 c:=0;
 while c< size do
 begin
    of1:=c+ srcofs;
    of2:=c+ desofs;
    asm
     push es
     push di
     mov ax,srcseg
     mov es,ax
     mov di,of1
     mov bx,[es:di]
     mov ax,desseg
     mov es,ax
     mov di,of2
     mov [es:di],bx
     pop di
     pop es
    end;
   c:=c+2;
 end;
end;

procedure copymem(source,dest:pointer;size:word);
var c,of1,of2,srcseg,srcofs,desseg,desofs:word;
begin
 srcseg:= seg(source^);
 srcofs:= ofs(source^);
 desseg:= seg(dest^);
 desofs:= ofs(dest^);
 if (size mod 2) = 0 then
  begin
   copymem16(srcseg,srcofs,desseg,desofs,size);
   exit;
  end;
 for c:=0 to (size-1) do
  begin
    of1:=c+ srcofs;
    of2:=c+ desofs;
    asm
     push es
     push di
     mov ax,srcseg
     mov es,ax
     mov di,of1
     mov bh,[es:di]
     mov ax,desseg
     mov es,ax
     mov di,of2
     mov [es:di],bh
     pop di
     pop es
    end;
  end;
end;

There are some other ways of adding assembler if you need them.

You can use the inline statement to add bytes directly into your executable, but this means you need to actually write the code directly in hex instead of using the standard mnemonics for instructions. This makes this method very cumbersome, but good if you only want to add one or two instructions.

You can also link in obj files that you have made with other assembler tools. There are a lot of pitfalls to this method however. You need to convert the obj files into binary format for including in the executable, and they must be self-contained and use a small memory model. That is one segment for code, and one segment for data at the most. The stack space used by the rest of the program would be shared with the imported code. To call any of the code you have to know and work out the call address yourself (which will depend on where in ram you stored it!) in order to be able to use it. It can make having more than one procedure or function very difficult, especially if you make any changes to your code. If you want the assembler routines to be callable like pascal ones you have to be careful to use the pascal call model, and to not clobber any local variables in the stack. Finally you can’t access Pascal global variable or functions easily within your assembler code. You will generally have to push pointers on the stack (as a method of parameter passing) to be able to find out where the data is.

There are a couple of advantages to this last method. The main one being you can write using whatever assembler you see fit even using instructions for a processor Pascal doesn’t support. Also if you do it correctly you can load your code dynamically and throw it out of memory when you are done with it. This is how the BGI graphics drivers work, and a simplified version of how the overlay system works.

However if you don’t need better than 286 instructions (or want your product to support the 286) you might as well use the asm blocks as this allows you to have much more flexibility in what you can do.

Hardware pickup: New Sparc servers!

Now I’m not the one to normally brag about getting new hardware that I’ve acquired (I am collecting on a regular basis), but I have recently been given some hardware that just makes me giddy with excitement! A friend of a friend of mine was looking to get rid of some computer hardware and I was fortunate enough to get to choose some of it to save from the scrap heap. I got 3 Sun Microsystems Sun Fire servers that are in good shape. One is a Sun Fire R280 which is basically complete with the exception of a RAM module that I will have to seek out. It has both its CPU slots populated and a couple of high performance hard drives, so the system is basically complete with that minor exception. The other two systems are both the same: Sun fire V440 machines. These have both been upgraded to have all 4 processors but are missing hard disks at the moment.

Now what will I do with these machine you might ask? Well I’m still deciding but it will certainly be fun setting them up and using them. I will have to dream up some kind of processor intensive use for them. I’m still thinking about which operating system to install on them. Fortunately being one of the newer sparc architectures, most Linux and BSD operating systems will have pretty good support for them. At the moment I’m thinking of putting FreeBSD on one, and Debian on one of the others. I may use the BSD one to build all the packages for the sparc platform just for the heck of it! I’m planning on scrapping one of the V440s for spare parts for the other one. It appears to have a problem I haven’t been able to diagnose yet, but it has many spare parts that may be useful if I ever need to replace any in the working one. There may not be much wrong with it so I will try to get the management console working over serial first to find out what is wrong with it. The serial adapters I have don’t seem to communicate with the V440 machines, but work with the R280. I suspect that the newer ones require different serial adapters that I will have to seek out.

I was hoping to find some parts for my SparcStation 20, I found some hard disks that may fit but didn’t find what I wanted most. I am after a Mbus module that has one or two super sparc processors on it, but was unable to find one. That being said I was very happy to find what I did! I never imagined I would ever get to have machines such as these ones, and I am very very grateful to the person who donated them to me! They certainly will get looked after!