24
Aug
14

OS Shootout: Trying to get the Sun Frame Buffer to work.

Frame buffer

Frame buffer

Quite a while ago I bought a Sun frame buffer (Wildcate Expert3d-lite) on ebay in the hopes of turning either my Sun Fire machines into a workstation. I had FreeBSD on the 280R and Gentoo Linux on the V440. FreeBSD didn’t like the card as it doesn’t have support for it, the version I have installed has become out of date and was having trouble updating packages. The Gentoo install had suffered a similar fate, I went to update it and found that the package system had become broken and couldn’t download the latest update.

So this weekend I decided to try a number of different operating systems to see if I could get the frame buffer working and see if there was a newer OS that would work better. Here are some notes about the different systems I’ve tried.

I decided to use the V440 as the base machine for performing the tests. I had been using Gentoo linux on it and had some minor success using the frame buffer. I was able to get a basic text console working beautifully, and it even displayed Tux the Linux penguin during boot up. But unfortunately the fbdev driver for X didn’t work producing some horrific corruption on screen, but the mouse and keyboard appeared to work.

Sunfire V440

Sunfire V440

The first fresh OS I decided to try out was NetBSD as it works well on my older Sparc machine. The installation went relatively smoothly, but I had to use the serial console in order to do it. I looked for support for my particular frame buffer but didn’t find any, even for some of the other available hardware. At this point I went to the documentaion online and realised I need not have tried it as the UltaSparc machines I have are not in the supported list for NetBSD. Although most hardware works, it seems that older machine are supported much better.

Next I decided to try the latest FreeBSD, the first time around I was using 8.3 which was quickly superseeded, but it was the only one that worked on the Sunfire 280R. So I downloaded the latest at the time of writing this, 10.0. Reading the documentation seemed to indicate that I’d be unlikely to get anything on this frame buffer at all, but if I buy a different type in the future there is good support. The installer was much easier than last time, again it required the serial terminal but it had everything set up very quickly. Of course the downside is the amount of time needed to build packages from ports, but thats a minor inconvenience if you leave it to build over night. I built and installed X, and with no surprise this frame buffer didn’t work.

In searching the internet for systems that support this particular device I came across OpenBSD. I had not really tried it out before so I didn’t know what to expect, but my hardware was listed as supported including the frame buffer. So I downloaded the install CD and began the process of installing. Compared to the other systems the installer is very _very_ basic, but at least you could do it from the computers console. Unfortunately I couldn’t get this one to complete installing, as the system rebooted every time it tried to extract the base system. At first I thought it likely this would be a hardware fault (as I had some in preparation for this) but I ran the system through its diagnostics multiple times and it passed every time. I may transfer the frame buffer into the SunFire 280R and try this system out again, but I think there’s something wrong with the installer/disc. The real shame is I saw in the kernel messages that it does indeed support my card!

Lastly I returned to an old favourite, Debian Linux. It is similar to Gentoo in that it supports the basic hardware and some framebuffers. Since Gentoo had some basic functionality I hope Debian might work better. I booted up the installer and was surprised to get the normal console-based Debian installer on the machines frame buffer. The installer was nice and easy, no major problems. I reboot into the new installation to see what would happen. Just like Gentoo the text console worked beautifully on the frame buffer, but X didn’t work. You could see the login screen behind some kind of strange corruption, but it seemed the keyboard and mouse were working as I could log in! I suspect Debian would work very nicely if I had a different frame buffer, but perhaps the guys working on the kernel will eventually fix the wildcat support.

So to summarise I found that Debian and FreeBSD would be quite workable if I had another frame buffer (or didn’t want to use it) and that OpenBSD might work well with this one if I could just manage to work out why it is crashing during install. NetBSD just doesn’t support the newer UltraSparc hardware well enough to use with a frame buffer, but might work quite well as a server. Basically I’m going to have to get another frame buffer card, then I can install either FreeBSD or Debian and have quite a nice Sun workstation.

18
Aug
14

Cosmic Crusader for DOS

Today I was pretty unsure what I’d write about, I’ve had a bad case of procrastinitus. I don’t know why, but today I’ve just not really felt like doing a whole lot. So in an effort to try to break the feeling I decided to have a look in my folder of _really_ old PC games. I found something interesting that I hadn’t played before.

I found a game called Cosmic Crusader written in 1982 by Michael Abrash for Funtastic. Michael Abrash is of course better known for his later work, his technical writing and working on Doom and Quake. I’ve read a good portion of his black book on graphics programming and found it quite the interesting read. I’m still part way through reading about the VGA and getting the most out of it.

Now that I’ve been thoroughly distracted lets return to the game itself. It supports CGA and PC speaker sound, which is unsurprising as there was little else. The graphics are well drawn but the speed of the graphics is perhaps the most impressive feature. There are many moving objects on screen, and they manage to do so at a reasonable pace. Something that wasn’t easy on the original PC. The only flaw I noticed is some flicker when sprites overlap, perhaps unavoidably.

Sound is as you’d expect, your usual assortment of noises that is pretty good given the hardware. You can of course turn them off if you find them annoying.

The game is very much like Galaxian, but of course on a reduced scale. There are some extra elements that make it different to the original game. Firstly you have a shield to protect yourself, you engage it by pressing the space bar and it lasts a fixed period. Whilst your shield is up anything that collides with you is destroyed. However you only get a limited number of shields, but you can increase this by shooting a power-up that travels across the screen.

Sometimes a large mothership descends to join the enemies at the top of the screen. It shoots a large and fast projectiles that are quite dangerous, combined with the diving enemies it can be difficult to dodge everything, a good time to use a shield.

The only thing I found that let the game down was the controls are a bit fiddly. You press a button to move either left or right and you will keep moving until you either press the other direction or a stop key. This resulted in me zig-zagging a little bit as I got used to it, which sometimes got me hit and sometimes helped me dodge, so it all evens out.

The game is CPU dependant for speed so the best way to play it now is via Dosbox. I use a setting of 250 cycles normally to be roughly the same speed as the original PC, but this game is quite playable at 350 cycles. I had fun with Cosmic Crusader, it is enjoyable as a new experience even today. It seems to have at least cured my procratinitus, at least temporarily.

 

This slideshow requires JavaScript.

12
Aug
14

Hardware Donation

It’s not everyday that someone moves house, and when someone I know moved house recently they found a pile of old computer gear they didn’t want anymore. They asked me if I wanted any of it and of course I said yes! So last weekend I got this rather large box of old computer gear. I just had enough time this weekend to unpack it and take some photos.

Continue reading ‘Hardware Donation’

07
Aug
14

Gwbasic Demonstrates Chaos

Back when in my late teens my older brother brought home a program that was supposed to demonstrate some of chaos theory. He originally wrote it in QBasic but I have reconstructed it here for gwbasic.

It’s a fairly simple construction, you have an “Ant” which can move in any one of 8 cardinal directions like that on a compass. Instead of being labeled North South etc, each direction is given a number 0-7 like in the diagram. As the ant moves around the screen it changes the colour of the pixel it moves over increasing its colour by 1. when the colour reaches its limit (in this case 15 as it is an EGA mode) the colour is cycled back around to 0. When the ant moves onto a new pixel it adds the colour of the pixel to its direction and uses the MOD operator to restrict the direction to the range 0-7. There is also some code to keep the ant on-screen.

The initial state requires a series of coloured boxes be drawn on the screen so there is something for the ant to react to. I’ve set up the code to pick random colours for these boxes and for the initial direction the ant travels (its initial position is fixed although it need not be). After this initial setup the ant essentially behaves deterministically.

Here are a set of images from one run of the program.

This slideshow requires JavaScript.

You can see in the first image that the ant has moved in a pretty much structured and predictable way, but as the program runs for longer the ant begins to produce patterns that seem unpredictable and random, notably the longer it runs the more “chaos” is introduced into the image. Because the ant is deterministic you’ll get the same image over time if you use the same initial state, but given any change no matter how small you will end up with a dramatically different image.

I’m no expert in the field of chaos but from what I could glean from the Wikipedia page one of the main attributes of a chaotic system is sensitivity to initial parameters, there are two other attributes, topological mixing and dense periodic orbits but I don’t really understand them. So I think the program may demonstrate chaotic behaviour, but I’m not sure that it’s a particularly good example. In any case it’s certainly fun to watch and play with the initial state.

As a bonus I coded another graphic example that produces a fractal pattern based on triangles. I was told the algorithm by a friend at Uni who had been shown the code when he was young. I’ve reproduced the algorithm here. Fractals are one of those things I’ve been meaning to learn about, but never really seem to get around to. That’s all for today!

04
Aug
14

Electro Man for DOS

Electro Man

Electro Man

Electro Man was created by a small company called xLand and published by Epic Mega Games in 1993. It is a puzzle platform game with a few action elements. The story is simple, your name is Jacek who has been modified with robotic components until he looks like Robocop. Your goal is to find three computer chips within each level and to fight off the robots that inhabit the space. You have a gun you can use to destroy enemies, but you need energy in order to power it. You can find energy around the level in the form of batteries, as you fire the gun you eventually use up the energy.

Credits

Credits

Today I played the Creative Commons version of the game released in 2006. It was compiled from the original source by Maciej Miasik who is one of the original authors. It hasn’t been tested on any real hardware and was built specifically with Dosbox in mind. This has to be one of the first games re-released specifically for Dosbox. It supports VGA and a range of different sound devices.

Robot Enemies

Robot Enemies

The original game before Epic published it was called Electro Body instead and had support for EGA and CGA graphics modes and the PC speaker. They published the game a company called CDV for a while until they caught the attention of Epic Mega games, who published the game under the new name. They later published a pack of puzzle games, all from xland, including Heart Light, Adventures of Robbo and of course Electro Man.

The version of the game I have supports only VGA graphics, and like Heart Light offers monochrome VGA in addition to colour. I thought the graphics are very well done. Levels and sprites are quite nicely drawn with plenty of detail and texture in a style similar to other platform games. The animations are quite smooth with a higher frame count and frame rate than I’ve seen in some games.

Green Guns

Green Guns

I played the game using the Sound Blaster support the game has. Sound effects in general suite the game, although some of the effects are a little long and contain speech. Fortunately because the game is not fast-paced, you won’t get overloaded by sound, and the more common sounds like shooting and explosions are shorter and sound good. There is some in game music that I quite enjoyed, but I didn’t hear that many different tunes so there isn’t much variety.

Computer Chip

Computer Chip

Whilst Electro Man isn’t fast-paced, there is certainly quite a bit of difficulty in the game. The first thing I noticed is that everything kills you in one hit. This is very punishing of any kind of mistake as it sends you back to the last checkpoint that you have visited. Visiting the checkpoints takes away all the energy for you weapon, so you would be wise to not pick up all the nearby energy. Fortunately there is no lives count which means you can die as many times as you need, and believe me you’ll die. I did get a little frustrated going back to the same checkpoint and replaying the same parts of the level so many times before I found another checkpoint. Fortunately whilst you lose you weapon upon death, you don’t lose any collected computer chips.

End of level 1

End of level 1

All the basic element of the game are fairly simple, but arranged the way they are make for some devious traps. It took me quite some time, about 2-3 hours just to complete the first level! Something that made the game harder was the way jumping works. Basically you can’t change your direction or speed of movement once you’ve left the ground. This means if you need to jump to a narrow platform you have to start your jump from precisely the right spot.

Level 2

Level 2

I’ve quite enjoyed playing Electro Man despite the frustrations with repetition. Once I got used to the games jumping mechanic moving around was easy but still challenging, and the enemies and traps whilst individually easy to overcome were more challenging when encountered in groups. The downside of the game is the time investment required for any progress beyond the first few levels. Fortunately you can save mid-level, returning to your the last checkpoint you visited when loading, and if things are really a pain you could use the cheat codes provided in the readme file.

This slideshow requires JavaScript.

27
Jul
14

The Micro-Professor MPF-1B

I’ve been meaning to get into building my own Z80 based micro computer for quite some time. This is because I did an interesting course as part of my degree where we learned to program 8085 micro processors and learned how to wire up extra memory to it. I did a project with a good friend of mine to build a simple voice recorder that behaved a little like an answering machine. I forget the full details of what we did but I remember it was a heck of a lot of fun.

MPF-1B with Manuals

MPF-1B with Manuals

Step in the Micro-professor, a Z80 based developement board targeted towards the education sector. I was lucky enough to see a few of them on ebay recently and doubly lucky to manage to get one for a reasonable price. The model that I have is the MPF-1B which has a very limited BASIC in ROM as well as all the extra on-board peripheral chips such as the Z80 PIO and CTC. It has a Zilog Z80A processor running at 1.79 Mhz and only 2kB of RAM which doesn’t sound like much, but seems much larger when programming in assembly.

The Micro-professor was designed and built by a company called Multitech in 1981. It has an unusual vacuum formed case and comes with a series of manuals including sample programs, schematics for the board, ROM listing and basic information for programming the Z80 CPU. Multitech later became Acer in 1987 and in 1993 sold the Micro-professor and associated materials to Flite electronics who still make and distribute the system.

Like many other developement boards of the time you interact with the machine via a very basic keyboard and 6 7 segment displays. This actually works well for inspecting memory and entering your hand assembled code. That’s right, the programs need to be entered in hexidecimal and thus assembled either by hand or by a cross assembler that produces convenient output.

Here we see the complete board in all its glory. It’s a very compact design mostly because the Z80 didn’t require as many support chips compared to many contemporary micros. This particular example is hard to date as the chips have a wide range of date codes on them. For instance the 8255 is dated 1981 where as the CTC chip is dated the 5th week 1987.

Here we can see the key overlay and display reference for the BASIC built into the ROM. I tried it out but found it was too limited for anything but the most mundane computations. Systems like this were really designed for learning machine language and hardware principles. The BASIC was limited because of the limited size ROM it had and the limited nature of the machine.

Here is  a close-up of the display and keyboard. The monitor has an impressive array of functions available at the keyboard including loading and saving memory to tape. I have tried using the tape system connected to my PC but I was unable to load any code into the MPF, although saving appeared to give audio data.

I remember the 8085 systems at uni didn’t have a keyboard or display at all, they instead did everything via serial line, which was quite good because the set-up allowed coding and assembly on a local unix machine then transfer directly to the micro for testing.

Close-ups of the chips showing their date codes.

Finally a picture from the manual showing part of the schematic for the machine. These manuals are very detailed and will certainly be very helpful.

The long-term plan is to learn about interfacing devices with this board in an effort to learn enough about the Z80 that I can build my own complete system. The first expansion I hope to build will be an external RAM module that will either add 32kB or more in a banked configuration. I then want to build an interface that allows an Arduino to read and write to all the memory in the system so I can simplify loading and saving programs. After that maybe I’ll add a multi-line LCD onto the outputs of the PIO chip to perhaps make the machine a bit more interactive. Considering I don’t have any parts yet, it could be a while before I accomplish any of this.

I have found one thing that will be handy, a nice Z80 assembler that will output in Hex or a number of other formats. This will save me hand assembling everything! You can find the cross assembler here.

22
Jul
14

Run-Length Encoding

I hadn’t quite gotten over the horrible cold this weekend, and have had to spend most of my time looking after children. So today’s post will be a short one. I’m looking at a very basic data compression technique frequently used in many older micro-computers of the 80’s to store level information and graphics for games.

The technique is called Run-length encoding (often called RLE), it takes advantage of repetition in data to reduce the storage requirement. It used to be a common compression technique for encoding graphics, but can be used effectively to encode level data or anything that has repeating data in it. The GIF image format is a well known example that uses the technique.

The encoding algorithm is very simple, you simply encode runs of data (repeated identical data) as the number of repetitions and a copy of the data. So if you had data that looked like this aaaaabbbbcaaa it could be encoded as a5b4c1a3. The trouble with this scheme is the worst case scenario (different data every byte) can actually increase the file size significantly, in some cases resulting in a larger file than uncompressed. You can avoid this scenario by encoding the start of a run as repeated characters with single characters representing themselves. This results in the previous data being encoded as aa5bb4caa3 which goes to show that even that technique has its downside.

I wrote up a quick implementation in pascal as an example and used it to compress some data files from my DOS platform game, Bob’s Fury.  The first two data files I tried were the graphics data files which you can see compressed quite well, this is because there are many long runs of the same colour pixels. The third data file takes it to the extreme, it is a level data file that is pretty much one big long run of empty spaces, it compresses to an impressively small size. The fourth data file is normal level data (albeit a much larger level), it is much like the graphics data in that there are many runs, but it has some data at the end which does not compress well resulting in a worse ratio. The last file in the table is actually an ASCII  map file detailing the contents of the executable for the game, it is useful in determining where errors are in the code, but this clearly shows that ASCII data is unsuitable for this compression technique, it resulted in a much larger file!

What follows is the pascal code I wrote for this quick test. It needs the buffer unit I wrote for buffered reading and writing files. You can also download the source file from here.

Continue reading ‘Run-Length Encoding’




Blogs I Follow

Enter your email address to follow this blog and receive notifications of new posts by email.


Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm - Vintage & Retro Computing Blog

Random mutterings on retro computing, old technology, some new, plus any other stuff that interests me

ancientelectronics

retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way

lazygamereviews

MS-DOS game reviews, retro ramblings and more...

Follow

Get every new post delivered to your Inbox.